A Data Governance Framework That Survives Contact With an Organisation

Why Most Framework Diagrams Are Useless

A governance framework is supposed to do one job: tell people what to build, in what order, and how the parts fit. Most fail at this because they describe components rather than relationships.

The typical failure looks like a grid of boxes — data quality, metadata, security, architecture, lifecycle — arranged with equal weight and no dependencies. It is not wrong. It is simply not actionable. A team handed that diagram has no way to know that stewardship without funded time will collapse, that a catalog without enforcement is a library, or that measurement has to loop back into direction or the whole thing becomes ceremony.

Three properties separate a framework you can deliver against from one you can only present:

• It has a direction of dependency. Some layers cannot be built before others. The diagram should make that impossible to miss.
• It distinguishes what enforces from what describes. Policy documents and policy engines are different things, and conflating them is the single most common reason governance stays theoretical.
• It treats adoption as continuous, not terminal. Almost every framework puts change management in a box at the end. That box is where programmes die.

The Framework

Five layers, one spine, one feedback loop. The rest of this paper walks each layer and names its characteristic failure mode.

Layer 1 — Direction: Purpose and Principles

The top layer answers why governance exists in this organisation. Not in general. The generic answer — better data, reduced risk, regulatory compliance — is true everywhere and therefore motivates nowhere.

A usable purpose statement names a specific business condition. “Finance and Operations report different revenue figures to the board and reconciliation takes two weeks” is a purpose. So is “we cannot evidence data provenance for the credit model and the regulator has asked twice.”

Principles are the second half of this layer, and they earn their place only if they settle arguments. A principle that nobody could disagree with — “data is an asset” — settles nothing. Principles that do work look more like:

• Governance is designed with the business, never delivered to it.
• Accountability precedes automation. We do not automate a decision nobody owns.
• If a control does not measurably reduce risk or raise confidence, it does not exist.
• The governed path must be the easy path.
• We build to hand over. Success is the programme running without us.

Layer 2 — Accountability: The Operating Model

This layer answers who decides what. It is the layer organisations most often skip because it is uncomfortable — it requires naming people and taking time from their existing jobs.

A working operating model answers five questions for every domain, in writing, with names:

1. Who is accountable for this data?
2. Who maintains its quality?
3. Who approves changes to a business definition?
4. Who authorises access, and on what basis?
5. Who measures and reports on its health?

Note the shape of these. They are not role titles; they are decisions. A steward who cannot approve a definitional change is not a steward, they are a documentarian.

The four roles, and what each actually owes

Role	Owes	Fails when
Domain owner	Accountability for the domain’s data; arbitration within it; representation on the council	The role is given to someone senior enough to be accountable but too senior to engage
Steward	Definitions, quality resolution, classification, day-to-day judgement	Assigned as an unfunded addition to an existing full-time job
Custodian	Technical custody, access implementation, pipeline reliability	Treated as the accountable party because they hold the credentials
Council	Cross-domain rulings, changes to the global set, escalation	Its minutes record updates rather than decisions

Layer 3 — The Work: Core Capabilities

Six disciplines. Not all six at once, and not in arbitrary order.

Metadata and catalog comes first in almost every case, because the other five need somewhere to record their output. Lineage and provenance typically second, because it is what converts a catalog from a reference work into evidence. Data quality third, because quality rules need assets to attach to and owners to route issues towards.

Privacy and protection sits inside this layer rather than beside it, deliberately. Treating privacy as a parallel programme run by Legal produces two classification schemes, two inventories and two sets of answers to the same regulator. Purpose limitation, consent basis, minimisation and retention are governance attributes; they belong on the same assets as everything else.

Master and reference data becomes urgent the moment two domains need to mean the same thing by “customer”. AI and agent governance is the newest and, for most organisations reading this, the one with the nearest deadline — model registries, authority tiers for agents that execute rather than advise, and approval gates placed where risk actually concentrates.

Layer 4 — Enforcement: Platform and Automation

This is where policy stops being a document. The distinction that matters is between metadata that describes and metadata that acts.

A classification recorded in the catalog and a classification that propagates into masking rules are the same label with entirely different consequences. The first documents intent. The second is governance.

The four components:

• Catalog — the record, and increasingly the control plane other systems consult at runtime.
• Workflow — approvals, access requests, issue management, certification. Auditable by construction.
• Policy engine — masking, row and column filtering, quality gating, retention enforcement.
• Integration — connectors and APIs that keep the other three synchronised with reality.

A note on platform selection, since it is the question we are asked most and matters least: Collibra, Microsoft Purview, Informatica CDGC, Atlan and Alation are all capable of supporting this layer. All five have also been bought by organisations whose programmes subsequently failed. Choose for fit with your estate and your stewardship reality, then stop deliberating and go build Layer 2.

Layer 5 — Evidence: Measurement

The bottom layer exists because governance programmes are rarely killed outright. They are defunded quietly, at the second or third budget cycle, because nobody could articulate what the previous two years bought.

Three categories, and they answer different questions:

• Adoption telemetry — is governance being used? Catalog searches, unique active users, definition lookups, requests routed through workflow. This tells you whether the thing works, and it is the category most often missing.
• Health metrics — quality scores, coverage on assets that matter, open issues and their age, stewardship coverage.
• Value realised — time recovered, rework avoided, decisions accelerated, initiatives unblocked, remediation cost avoided.

Assets catalogued belongs in none of these. It measures that a crawler ran.

The feedback loop

The arrow on the left of the diagram is the part most frameworks omit, and it is not decoration. Measurement has to change direction. If the quarterly report never causes a priority to shift, a domain to be resequenced or a control to be dropped, then reporting has become ceremony and the framework has quietly become a wall poster.

The Spine: Why Adoption Is Not a Layer

Adoption is drawn vertically for a reason. Every framework we have seen that placed change management in a terminal box produced the same outcome: a technically successful implementation with no users.

The components are unglamorous and they belong at every layer:

• Data literacy, targeted by role. A steward, an analyst and an executive need three different curricula. Generic literacy training has poor returns; role-based training has good ones.
• Champion network — one named person per domain with allocated time and a direct line to the programme. Their job is translation, not enforcement.
• Change management — running from Layer 1, because if the first time a domain hears about governance is when you ask them to populate metadata, you have already lost.

The governed path must be the easy path. If finding data through the catalog is slower than asking a colleague, people will ask the colleague — and no policy compensates.

Using the Framework

A framework is a checklist for what you have not thought about, not a delivery plan. Two practical applications.

As a diagnostic

Take an existing programme and mark each layer honestly: present, partial, absent. The pattern is diagnostic in itself. Strong Layers 3 and 4 with a weak Layer 2 is the classic tool-first programme, and it explains the adoption problem without further investigation. Strong Layer 1 with nothing below it is a strategy exercise that never became delivery.

As a sequencing guide

Layers 1 and 2 first, in a single domain rather than across the enterprise. Then one capability from Layer 3, with just enough of Layer 4 to enforce it. Measurement from week one, because a baseline captured later is a baseline you cannot defend.

Then repeat in the next domain. Governance built this way is slower in the first quarter and considerably faster by the fourth, because each domain inherits a working operating model, a configured platform and a track record instead of a promise.

A framework that shows components tells you what to buy. A framework that shows dependencies tells you what to do on Monday.

Published by KRISID · 17 July 2026. This paper reflects our delivery experience and publicly available sources at the time of writing. It is general guidance, not legal advice — regulatory obligations vary by jurisdiction and by how a system is used.