Governance in a supervised institution has one requirement ordinary governance does not: every control must produce evidence a third party can inspect months later. That single constraint changes the design. You are not building a system that works — you are building a system that can be shown to have worked on a specific date.

Seven practices follow from it, and each is testable against an examiner's question rather than against a framework.

What makes governance different under supervision?

Three differences, and they compound.

The burden of proof is inverted. In an unsupervised organisation, a control is adequate until something goes wrong. Under supervision it is inadequate until evidenced. A perfectly executed access review that produced no artefact did not happen.

Scope is dictated externally. You do not choose which data is critical; the regulator's reporting requirements do. This is genuinely helpful — it removes the hardest argument in governance, which is prioritisation.

The timeline is fixed. Examination cycles arrive whether or not the programme is ready, which favours narrow-and-complete over broad-and-partial in a way that ordinary enterprises can debate and supervised institutions cannot.

For financial institutions in Azerbaijan the anchor is CBAR's Regulation on Information Security Management in Banks, in force since April 2022 and built on the ISO/IEC 27000 series, alongside the Law on Personal Data and its registration regime for information systems processing personal data.

Practice 1 — design every control to emit evidence

The practice: for each control, decide at design time what artefact it produces, where that artefact is stored, and how long it is retained. If the answer is "we would reconstruct it," the control is not audit-ready.

What this looks like concretely. An access review is not a meeting — it is a dated record listing who held access, who reviewed it, what was revoked and why. A definition approval is not a consensus — it is a glossary entry with an approver, a date and a rationale. A quality exception is not a fixed row — it is a ticket showing the failure, the decision, the person who made it and the outcome.

The overhead of doing this from the start is small. The cost of retrofitting it two weeks before an examination is the single most common source of governance panic in banks.

Practice 2 — let classification drive enforcement

The practice: classify data assets once, and have the classification mechanically determine masking, retention, access approval path and residency — rather than having each of those decided per system by whoever built it.

The failure mode is a classification scheme that exists in a policy document while enforcement is implemented separately in every platform. When they diverge — and they always diverge — the classification is the thing an examiner reads and the implementation is the thing that governs reality.

The practical requirement is that the classification lives somewhere the platforms can read. A catalog holding classification as an attribute on the asset, and platforms consuming that attribute, is the arrangement that keeps the two aligned. This is one of the concrete reasons to prefer an automated catalog over a documentation repository: the classification has to be a machine-readable fact, not a paragraph.

Practice 3 — carry lineage to the column for reported figures

The practice: for every figure that appears in a supervisory return, maintain column-level lineage from the source system through each transformation to the reported number.

This is the highest-value governance artefact in a regulated institution, and it is worth stating why. When an examiner asks how a figure was derived, the answers available are a person's recollection, a document written when the process was built, or a lineage graph generated from the actual code and query history. The first two are frequently wrong — not through dishonesty, but because the process changed and the document did not.

Automated lineage has a second benefit that matters more day to day: impact analysis before a change ships. A source column type change becomes a visible list of affected reports rather than a discovery made after the reissue.

Scope it narrowly. Column-level lineage across the entire estate is expensive and unnecessary; across the reported figures it is the thing that makes an examination straightforward.

Practice 4 — put access reviews on a cycle with a fixed artefact

The practice: a scheduled review, per sensitive asset, with a named reviewer, producing a dated record of decisions.

Three details determine whether this survives.

The reviewer must be the business owner, not IT. IT can say who has access; only the business can say whether that is still appropriate.

The default must be revocation. A review where unreviewed access persists is not a review. Access that nobody affirmatively confirms should lapse.

The cycle must match the sensitivity, not the calendar. Quarterly for the most sensitive assets, annually for the rest. A uniform annual cycle over everything produces a review nobody has time to do properly.

The role split that makes this work — owner accountable, steward consulted, custodian executing — is set out in data stewardship roles and a working RACI.

Practice 5 — make retention and deletion actually execute

The practice: retention periods defined per classification, implemented as automated jobs, with deletion producing a log entry.

This is where regulated institutions most often have a paper policy and no mechanism. The policy says customer records are retained for a defined period after relationship closure; in reality nothing is ever deleted, because deletion is risky and nobody is rewarded for it.

The consequence is not merely non-compliance. Data retained past its purpose expands the blast radius of every incident and enlarges the scope of every examination.

VERIFY: Retention periods for financial and personal data in Azerbaijan are set across several instruments — sectoral banking rules, the Law on Personal Data and archival legislation — and the applicable period depends on record type. Confirm the specific periods with counsel before encoding them as automated deletion jobs.

The engineering point stands regardless of the specific durations: deletion must be a scheduled mechanism with a log, not a manual exercise nobody performs.

Practice 6 — bring data into change control

The practice: schema changes, transformation logic changes and access model changes go through the same change control as application releases, with data impact assessed as part of approval.

Most institutions have mature change control for applications and none for data. A developer altering a column type in a source system follows a documented release process; the fact that the change silently breaks three regulatory reports is discovered afterwards.

The mechanism is straightforward once lineage exists: the change request includes the downstream impact list, and the affected report owners approve or object before the change ships. Without lineage this is a manual investigation that teams skip under deadline pressure.

Practice 7 — maintain one control set mapped to many regulations

The practice: implement controls once, and maintain a mapping from each control to every regulatory requirement it satisfies.

A supervised bank in Azerbaijan serving EU clients may face CBAR's information security requirements, the Law on Personal Data, GDPR where its extraterritorial scope applies, and — if it deploys AI systems — the management-system expectations of ISO/IEC 42001, whose 38 Annex A controls under nine objectives overlap substantially with ISO 27001.

Implementing these as separate programmes produces duplicated controls, contradictory documentation and an examination burden that scales linearly with the number of regimes. Implementing one control set with a mapping means each new regime is a gap analysis rather than a programme.

The mapping itself is the deliverable auditors value most, because it answers "show me how you satisfy requirement X" in one lookup. How this works specifically for the AI management system is covered in what the ISO/IEC 42001 audit actually asks for, and the cross-border side in data residency and personal data law in Azerbaijan.

What do examiners actually ask for?

Across engagements the questions cluster into five, and they are worth rehearsing:

Show me who has access to this data and when that was last reviewed. Answered by the access review artefact.

Show me how this reported figure was calculated. Answered by column-level lineage.

Show me your classification and where this asset sits in it. Answered by the catalog attribute, not the policy document.

Show me what happens when this data is no longer needed. Answered by the retention job and its log.

Show me who is accountable for this data. Answered by the ownership record — and this is the question that most often has no good answer, because ownership was assigned to a team rather than a person.

A programme that can answer these five in an afternoon is in a good position regardless of what its maturity score says. One that needs a week of preparation per question has a documentation problem, not a governance problem — and those are different fixes, as set out in common data governance challenges.

Key points

  • Under supervision, an unevidenced control did not happen. Decide at design time what artefact each control produces.
  • Classification must be a machine-readable attribute that drives masking, retention and access — not a paragraph in a policy.
  • Maintain column-level lineage for reported figures specifically. Estate-wide lineage is expensive and rarely necessary.
  • Access reviews need a business reviewer, revocation as the default, and a cycle matched to sensitivity.
  • Retention and deletion must execute as scheduled jobs with logs. Confirm the applicable periods with counsel.
  • Put schema, transformation and access changes through change control, with the lineage-derived impact list attached.
  • Implement one control set and map it to each regime. The mapping is the artefact auditors value most.

Yukon Labs implements OvalEdge in supervised institutions with classification, lineage and access review configured as evidence-producing controls from the start. If you want an outside read before an examination cycle, the data and AI readiness assessment tests the five questions above directly. For the regional framing, see data governance in Azerbaijan.