Central Bank of Azerbaijan: IT and Data Requirements for Financial Institutions

The Central Bank of the Republic of Azerbaijan supervises banks, non-bank credit organisations, insurers and payment institutions, and its expectations on information technology reduce to four practical requirements: classify your data, control access to it and evidence that control, be able to explain how a reported figure was derived, and keep the institution accountable for anything it outsources.

Everything below expands those four. The framing matters because supervised institutions frequently treat CBAR requirements as a security project when most of the work is a data governance one.

VERIFY: This article describes the shape of the requirements and their engineering consequences. It is not legal advice, and specific obligations, deadlines and thresholds must be confirmed against the current text of the applicable regulations and with counsel before being relied on. Regulatory instruments in this area have been amended repeatedly since 2022.

Which institutions are in scope, and for what?

CBAR's supervisory perimeter covers banks and bank branches, non-bank credit organisations, insurance and reinsurance companies, payment service providers and the market infrastructure around them. The intensity of IT expectations scales with systemic significance, but the categories of requirement are broadly common.

The anchor instrument for information security is the Regulation on Information Security Management in Banks, approved by the CBAR Board and in force since 1 April 2022. Its defining characteristic is that it is built on the ISO/IEC 27000 series rather than inventing a local control framework — which is the most useful single fact about it, because it means an institution that runs a real ISO 27001-aligned ISMS is doing most of the work already.

CBAR has since extended information security requirements across supervised entities in financial markets and has published a cybersecurity strategy for the sector, alongside its broader strategic programme for the financial sector.

VERIFY: Confirm the current scope and applicability of the information security requirements to non-bank supervised entities, and the status of any successor or amending instrument, before mapping controls for a non-bank institution.

What does an ISO 27000-based regulation actually require?

Because the regulation is built on a management-system standard, its requirements are structural rather than prescriptive. Five clusters carry most of the engineering weight.

An information security management system with governance. Defined scope, a risk assessment methodology, a policy set, assigned responsibilities and a management review cycle. The point of a management system is that security is operated and reviewed rather than implemented once.

Asset inventory and classification. You cannot protect what you have not enumerated, and the control set assumes classification exists. This is the single requirement most often satisfied on paper and not in practice, because classification is easy to write into a policy and expensive to apply across a real estate.

Access control tied to classification. Least privilege, periodic review, segregation of duties, and controls proportionate to the sensitivity of the asset — which is only meaningful if the sensitivity of each asset is recorded somewhere machines and reviewers can both read.

Incident management and continuity. Detection, response, notification, and tested recovery. The requirements that get most attention during examination are the ones that produce dated evidence: incident logs, test results, notification records.

Third-party and outsourcing risk. The institution remains accountable for functions it outsources, which has specific consequences for cloud services discussed below.

The practical translation of the middle three is that an institution needs an inventory of data assets carrying classification, ownership and access records — which is precisely what a data catalog is for. Institutions that approach this as a security tooling problem end up with strong perimeter controls over an estate nobody has enumerated.

What does the reporting obligation require in data terms?

Supervisory reporting is where data governance stops being optional, and the requirement behind it is simple to state and demanding to satisfy: the institution must be able to explain how any reported figure was produced.

That means, for each figure in a return:

A definition. What the figure counts, at what point in time, with which inclusions and exclusions. Held as an approved term, not as tribal knowledge.

A derivation. Which source systems, which columns, which transformations, in what order. This is column-level lineage, and it is the difference between answering an examiner in an afternoon and reconstructing a calculation from memory.

A control history. Which quality rules apply to the inputs, what failed, what was decided, and by whom.

An owner. A named person accountable for the figure — not a team, and not "Finance".

The gap most institutions have is the second one. Definitions exist, controls exist in some form, ownership can be established quickly. Derivation is where the answer is a person who has been there a long time, and that answer is fragile in exactly the way supervision is designed to detect. Automated, column-level lineage over the reported figures specifically — not over the whole estate — is the highest-return governance investment a supervised institution can make, and it is the core of the governance practices that hold up under supervision.

How should outsourcing and cloud be handled?

The governing principle in supervisory frameworks generally, and CBAR's is no exception, is that outsourcing transfers execution and not accountability. The institution remains responsible for the confidentiality, integrity and availability of data processed on its behalf, and must be able to demonstrate that it can supervise the provider.

The practical consequences that come up in architecture reviews:

The provider's controls must be visible to you. Assurance reports, audit rights, and enough transparency to answer an examiner's question about a control the provider operates.

Exit must be planned. Concentration risk and the ability to bring a function back in-house or move it are standard supervisory concerns, and they are architectural decisions made at design time.

Data location is a separate question from control. A provider with excellent controls hosting personal data outside Azerbaijan raises the cross-border transfer question under the Law on Personal Data, independently of how well the provider is run. The transfer rules and the specific traps for engineering teams are covered in data residency and personal data law in Azerbaijan.

VERIFY: Confirm the current notification, approval and reporting obligations for material outsourcing and cloud arrangements — including any pre-approval requirement and any restrictions specific to core banking functions — with counsel and directly against CBAR's applicable regulation.

The pattern in practice is that supervised institutions here deploy analytical and AI infrastructure on-premise not primarily out of preference but because the combination of transfer rules, outsourcing scrutiny and exit planning makes the domestic option materially simpler to defend. That reasoning is set out at length in sovereign AI.

What does this mean for AI systems specifically?

Supervised institutions are deploying AI, and the supervisory questions arriving with it are recognisable versions of the existing ones.

What data does the system see? An assistant with retrieval access to internal documents is a new access path to existing data. If the underlying assets are classified and access-controlled, the answer is straightforward. If they are not, the AI project has just created an uncontrolled access path — which is why classification of the AI-adjacent estate becomes urgent the moment a pilot is proposed.

Where does inference happen? If a prompt containing customer information reaches a foreign API, that is a cross-border transfer of personal data, regardless of retention promises. The deployment posture question therefore has to be settled before the pilot, not at the point of scaling.

Can you explain an output? For decisions affecting customers, the institution needs a record of what the system was given, what it produced and who acted on it. This is the audit trail requirement, and it is the same requirement the ISO/IEC 42001 audit asks about — a management-system standard whose 38 Annex A controls under nine objectives map cleanly onto ISO 27001 machinery an ISO 27000-aligned institution already runs.

Who is accountable? Model ownership, change control over prompts and model versions, and a defined process for taking a system out of service.

None of these is exotic. They are the existing control families — inventory, classification, access, change control, logging, third-party risk — applied to a new class of asset. Institutions that treat AI governance as a separate programme duplicate work; institutions that extend the existing control set absorb it.

VERIFY: Confirm whether CBAR has issued AI-specific guidance, expectations or reporting requirements applicable to supervised institutions, and reflect its content here before publication.

Which controls should be built, and in what order?

A sequence that works, based on what unblocks the most in each phase.

First — inventory and classification of critical data. Not the whole estate. The data appearing in supervisory returns, the personal data holdings, and the assets that AI or analytics projects are reaching for. Without this, every subsequent control is applied blind.

Second — ownership. A named person per data domain, with stewards under them, and a decision forum with authority. This is organisational work and takes longer than the technical work it enables, so it starts early. The role definitions are in data stewardship roles and a working RACI.

Third — access review as an evidence-producing cycle. Business owner reviews, revocation as default, dated artefacts, cycle matched to sensitivity.

Fourth — lineage over reported figures. Automated from SQL, ETL definitions and query logs rather than declared manually, because manual lineage is accurate on the day it is written.

Fifth — quality rules on the inputs to reported figures. Completeness and validity first, with a defined path from a failing rule to a person who decides what it means. The economics and the failure modes are set out in where data quality fits in a governance programme.

Sixth — retention and deletion that actually execute. Scheduled jobs with logs, not a policy nobody implements.

Seventh — the control mapping. One control set, mapped to CBAR requirements, personal data law, and any external regime the institution is exposed to. This mapping is the artefact that makes each subsequent examination cheaper than the last.

The order matters because each step is a precondition for the next. Access review without classification reviews the wrong things. Quality rules without ownership produce alerts nobody adjudicates.

What does an examination actually feel like?

Five questions recur, and an institution's readiness is measurable by how long each takes to answer.

Who has access to this data, and when was that last reviewed? The answer is an artefact, or it is nothing.

How was this reported figure calculated? Lineage, or a person's recollection.

What is your classification scheme and where does this asset sit in it? The catalog attribute, not the policy document — and an examiner will notice when the two disagree.

What happens to this data when it is no longer needed? The retention job and its log.

Who is accountable for this data? The ownership record. This is the question that most often has no good answer, because ownership was assigned to a department.

Institutions that can answer these in an afternoon pass on the substance. Institutions that need a week of preparation per question usually have adequate controls and inadequate evidence, and those are cheaper to fix than they appear — the controls exist, they simply do not emit artefacts. The remedy is design-time: decide what each control produces, where it is stored and how long it is kept.

How do the requirements interact with personal data law?

Two regimes overlap and are frequently conflated.

CBAR's requirements govern how a supervised institution manages information security and operational risk. The Law on Personal Data governs the processing of personal data by anyone, including a lawful basis requirement, a state registration regime for information systems processing personal data, and conditions on cross-border transfer.

The interaction that matters architecturally: a bank can be fully compliant with information security requirements and still be in breach on transfer, because encryption and access control say nothing about where processing occurs. Conversely, data that never leaves the country can still be inadequately controlled.

Institutions serving EU clients add a third layer, since GDPR's extraterritorial scope can apply to processing outside the EU. What must be reconciled across the two personal data regimes is treated in GDPR vs Azerbaijani data protection.

The right structural response is a single control set with a mapping, not three parallel programmes. An access review satisfies a CBAR expectation and evidences a personal data control simultaneously — provided it was designed to produce an artefact both can read.

What does a compliant data architecture look like?

Concretely, in an institution of moderate size, the components are:

A catalog holding classification, ownership and lineage, deployed on-premise, crawling the core banking system, the warehouse, departmental databases and object storage on a schedule. OvalEdge is the platform Yukon Labs implements for this in supervised institutions; the architecture, connector model and air-gapped deployment path are described in how OvalEdge works.

A federated query layer where analysts need to join across systems without building a pipeline for each question, and without creating new copies of regulated data. Federation is materially easier to defend than centralisation under transfer rules, because nothing is relocated — the argument is developed in Starburst and Trino in Azerbaijan.

Access request workflow that routes to the business owner, records the decision, and executes the grant in the source system rather than becoming a second authorisation authority.

Retention jobs with logs, driven by classification.

An AI deployment posture decided in advance — where inference runs, what the retrieval scope is, what is logged. For most supervised institutions here this means on-premise or private-cloud inference, sized deliberately; the cost and capacity reasoning is in deploying LLMs on-premise.

None of this is exotic architecture. What makes it work is that classification is a machine-readable attribute rather than a document, and that every control emits an artefact by design.

Where institutions usually have gaps

Four patterns recur, and none of them is a technology gap.

Strong inside the reporting perimeter, absent outside it. Regulatory reporting is mature because supervision forced it; departmental databases and the analytics estate have no ownership at all. AI projects source from precisely that second category.

Classification as a policy, not an attribute. The scheme exists, the assets are not tagged, and enforcement is implemented separately in each platform where it drifts.

Ownership assigned to teams. Every asset has an owner on paper and no person to call. This surfaces immediately during an examination.

Controls without artefacts. The review happens; nothing records that it happened. This is the cheapest gap to close and the most common cause of a poor examination outcome relative to actual control quality.

A structured way to test for these before an examiner does is set out in the data governance maturity model, and the organisational reasons programmes stall on them are in common data governance challenges.

Key points

• CBAR's information security regulation is built on the ISO/IEC 27000 series, so an institution running a real ISMS is already most of the way there.
• Four practical requirements dominate: classify data, control and evidence access, explain how reported figures are derived, stay accountable for outsourced functions.
• Column-level lineage over reported figures — not the whole estate — is the highest-return governance investment for a supervised institution.
• Outsourcing transfers execution, never accountability. Provider transparency, exit planning and data location are separate questions.
• AI adds no new control families. It applies inventory, classification, access, change control and logging to a new class of asset.
• Build in order: classification, ownership, access review, lineage, quality, retention, control mapping. Each step is a precondition for the next.
• The most common gap is not weak controls but controls that produce no artefact. Decide at design time what each one emits.

Yukon Labs implements OvalEdge and on-premise analytics and AI infrastructure for supervised institutions in Azerbaijan. A readiness assessment tests the five examination questions directly and produces the gap list. For the wider regional picture, start with data governance in Azerbaijan.