Governance fails where decision rights were never assigned.

The three decisions that have to be assigned

Every governance question reduces to one of three: what the rules are, who owns a given dataset, and where a rule is enforced. Assigning all three centrally produces a bottleneck that domains route around, whoever operates the platform. Assigning all three to domains produces inconsistency nobody can audit. The federated split — central rules, domain ownership, platform enforcement — is the arrangement most estates converge on. The healthcare data foundation illustrates why purpose, permitted access and retention decisions need accountable owners across source systems and derived views.

Microsoft describes the same middle ground explicitly: a central data office sets the rules, while the people in each domain who use the data and understand its function are entrusted to govern it. The stated reason is the practical one — centralised oversight without the central team becoming the queue that every access request waits in.

The failure mode of getting this wrong is recognisable. A central team owns classification for the whole estate, cannot possibly know what a column in a domain system means, classifies conservatively to be safe, and the domain works around the resulting restriction with an export. The policy is now perfect and the data is in a spreadsheet.

• What the rules are: policy, classification scheme, retention, access principles
• Who owns each dataset: accountable for meaning, quality and access approval
• Where enforcement happens: at query time in the platform, not in a document

What a central function should and should not own

A central function should own the things that must be identical everywhere: the classification scheme, the retention policy, the access principles, and the measurement of coverage. It should not own individual access approvals, dataset-level quality rules or business definitions, because it lacks the context to decide them and will become the delay everyone complains about.

The classification scheme is the clearest case for central ownership, because its entire value is uniformity. Five domains with five schemes cannot be audited together, and an access rule written against one scheme means nothing in another. Four or five levels are usually sufficient, and each needs a written test that a non-specialist can apply — "would disclosure harm an identifiable person" is usable; "sensitive" is not.

Coverage measurement is the second central responsibility and the one most often missing. The central function should be able to state what share of the estate has a named owner, a classification and an access rule — and report the gap rather than close it personally. That reporting is what turns governance from an assertion into a number, and it is what gives a domain owner a reason to act.

Policy volume is worth constraining deliberately. A small number of rules that are enforced beats a comprehensive framework that is not, because every unenforced rule teaches the estate that the rules are optional. Write the smallest policy that holds, and add to it only when a real decision could not be made without it.

What a domain owner is actually accountable for

A domain owner is accountable for four things about their data: what it means, whether it is fit for use, who may see it, and what happens when it is wrong. That is an accountability, not a task list — the owner does not do the engineering, but the owner is the person a question is escalated to, and the person whose decision is recorded when access is granted.

The most important of the four is access approval, because it is the one that fails most visibly when unassigned. An access request with no approver goes to whoever has the permission to grant it, usually a platform engineer, who has no basis on which to say no and therefore says yes. Every subsequent access review then discovers grants nobody can justify.

Vendors now model this role directly. Purview's framing separates data owners, who register assets, manage classification and access and hold quality standards, from data stewards responsible for quality, discovery, glossary consistency and lineage, with consumers finding trusted datasets through a request workflow. The distinction between owner and steward is useful: one decides, the other maintains.

One caution about naming owners: the role has to come with the authority and the time to exercise it. An owner named on a slide who is not consulted before a schema changes is not an owner, and appointing them makes the register look complete while changing nothing. The test is whether their approval is genuinely required for something.

Enforcement belongs where the query runs

A rule that is enforced in a document is not enforced. Access policy, row and column restrictions, masking and retention have to be expressed where the data is queried, because that is the only place they cannot be bypassed. Every modern platform now supports this, and the practical governance question is whether your policies are expressed in those mechanisms or in a wiki.

Databricks expresses it through Unity Catalog, with a three-level catalog, schema and object namespace, privileges granted to users, service principals or groups, attribute-based policies, row and column filters, and workspace bindings — alongside automatic lineage across data and AI assets. Purview assembles governance domains, data products and glossary terms across a wider estate, with role-based access and an access request workflow. The mechanisms differ; the principle does not.

The consequence for policy writing is that a policy should be expressible as a rule the platform can evaluate. "Personal data is only accessible to staff with a legitimate business need" cannot be enforced by anything. "Columns classified as personal are masked except for principals in the group named in the dataset's access rule" can be. Writing policy in the second form is a discipline, and it is what determines whether the programme has any effect.

Automatic lineage matters here for a reason beyond debugging: it is what makes classification propagate. A column classified as personal in a source table is only protected if you know which downstream tables contain it, and hand-maintained lineage does not survive contact with a real estate.

Why access reviews are the honest measure of a programme

The state of access is the most reliable indicator of whether governance is working, because it is hard to fake. If an access review can produce, per dataset, who has access and which approval granted it, the model is functioning. If the review produces a list of principals with no attached justification, the programme has a policy and no operating model.

The common outcome of a first review is uncomfortable and useful: a large number of grants that nobody can account for, usually accumulated through group membership rather than through direct grants. That is not a failure of the review; it is the review doing its job and revealing what the previous arrangement actually produced.

What makes the second review better is recording the approver and the reason at the moment of granting, not reconstructing it later. That is a small workflow change with a large effect, and it is the point at which a catalogue with an access request workflow starts paying for itself.

Governance for retrieval systems is the same model under more pressure

A retrieval-based AI system does not need a separate governance model, but it exposes weaknesses in the existing one immediately. Authorisation has to be applied before content reaches the model rather than after, deletions have to propagate into the index, and the corpus needs an owner who can say which version of a document is current — all of which are ordinary governance questions that a retrieval architecture makes explicit and that enterprise AI search has to answer before launch.

The reason the pressure rises is that a retrieval system removes the incidental controls a reporting estate relies on. A dashboard restricted to a team is a boundary; an assistant that answers questions for everyone from a corpus assembled across systems has no such boundary unless one was built. The permission model has to be explicit because nothing else is limiting the blast radius.

Deletion is the specific case worth planning before launch rather than after. A record removed from a source system remains in a vector index until something removes it there too, and the interval between the two is a period in which a deleted record is still answerable. That is a governance requirement with an engineering implementation, and it is straightforward when designed in and awkward when retrofitted.

A first ninety days that produces something

Start with one domain, not with a framework. Name an owner for its ten most-used datasets, classify them against a scheme of four or five levels, express the access rules in the platform rather than in a document, and run one access review. That produces a working model on a real domain, which is far more persuasive internally than a complete policy nobody has applied.

Pick the domain by consequence and cooperation together: enough regulatory or commercial exposure that the effort is justified, and a team willing to participate. The output that matters is not the policy document, it is the first access review that can answer who has access and why — because that is what a sponsor recognises as governance working.

Expand by repeating the pattern rather than by writing more policy. Each new domain adds owners, classifications and enforced rules to the same scheme, and the central function's job becomes measuring coverage and reporting the gap. A programme structured this way produces evidence at every stage; a programme that begins with a framework produces evidence at the end, which is usually after the sponsorship has moved on.

• One domain, its ten most-used datasets, and a named owner for each
• A classification scheme with four or five levels, each with an applicable test
• Access rules expressed in the platform, evaluated at query time
• One completed access review, with approver and reason recorded per grant

What this guide does not address

It is about decision rights and enforcement, not about legal compliance. Which regulations apply to your data, what a lawful basis for processing is, and what a retention period must be are legal determinations that belong with qualified advice. This guide describes where those determinations are recorded and how they are enforced once made.

It also assumes an estate with a platform capable of enforcing policy. Where data sits in systems with no useful access model — file shares, spreadsheets, an application with a single shared login — enforcement at query time is not available, and the honest options are migration or compensating controls. Describing that situation as governed because a policy exists is the kind of overstatement that fails an audit.

Questions and trade-offs

Technical references

• Microsoft Purview: data governance, federated model and roles ↗
• Databricks: Unity Catalog object model and access control ↗
• OpenLineage: specification and integrations ↗