Data Governance Atlas

Stewardship and the operating model

For the controller / DPO

Who owns what, how the roles actually divide, and why a governance function with no decision rights produces documents instead of change.

NIST PF GV-P
GDPR family Art 5(2)Art 24Art 37-39

Most governance programmes fail on operating model rather than on policy. The policies are usually fine; nobody is accountable for the things they describe.

The roles, and what each actually decides

Names vary between organisations. The functions do not:

  • Data owner — accountable for a domain (customer, product, employee). Decides what the data means, who may use it and for what, and what “correct” looks like. Usually a senior business figure, not a technologist. This is the role most often unfilled.
  • Data steward — responsible day to day. Maintains definitions, resolves quality issues, answers “what does this field mean”. Where the work actually happens.
  • Custodian / system owner — operates the platform the data lives in. Accountable for availability, access provisioning, backups. Frequently mistaken for the owner, and the mistake matters: an infrastructure team cannot decide what customer data is for.
  • Data protection officer — where required, an independent advisory and monitoring role. Advises, monitors compliance, cooperates with the regulator, acts as contact point. Must not be instructed how to perform the task and must report to the highest management level.
  • Accountable executive — signs off risk acceptance. Without this role, every difficult decision escalates to a committee and stalls.

The DPO is not the owner of the data

This confusion is common and consequential. A DPO advises and monitors; they do not become responsible for the organisation’s processing, and they cannot be given a role that would require them to determine purposes — that would conflict with their independence.

Practically: if your DPO is being asked to decide whether a project may proceed, the operating model is wrong. They should be advising the person who decides, and that advice — including where it was not followed — should be recorded.

Decision rights are the whole thing

A governance function without decision rights produces artefacts. It writes policies nobody is obliged to follow, maintains a catalogue nobody consults, and issues findings nobody must act on.

The minimum set of real decision rights:

  1. A gate — something that cannot proceed without governance sign-off. New processing, a new supplier, a new data sharing arrangement.
  2. A veto with an escape hatch — governance can block, and a named executive can accept the risk over that objection, in writing. The escape hatch is essential; without it the function is either ignored or becomes an obstacle.
  3. Ownership assignment — the authority to insist a dataset has a named owner.

If none of these exist, what you have is an advisory service, and it should be honest about that rather than measuring itself on documents produced.

Federated beats central, past a certain size

Central teams own the framework — definitions, standards, tooling, the register. Domains own their data. The central team’s job is to make the right thing easy and to see across the whole, not to be the bottleneck through which every decision passes.

The failure mode at both extremes is predictable. Fully central: a queue, and shadow processes that route around it. Fully federated: eleven definitions of “active customer” and no one able to answer a regulator’s question about the organisation as a whole.

Wiring it to things that already happen

Governance that depends on people remembering does not survive contact with delivery pressure. Attach it to events that already have a forced stop:

  • procurement and supplier onboarding → controllerControllerDecides why and how personal data is processed. Carries most of the duties — and the fines./processorProcessorProcesses on the controller’s instructions — cloud hosts, payroll bureaus — with its own security and breach duties. classification, contract terms
  • project initiation → is an impact assessment required
  • go-live → record of processing entry, retention rule, named owner
  • leaver process → access revocation
  • incident → breach assessment

Each of these already exists in most organisations. Adding one governance question to a process that already stops is far more effective than a parallel process that only governance attends.

Measuring whether it works

Not by artefacts. Useful signals: what proportion of datasets have a named owner; how many decisions were changed by governance input; how long a rights request takes end to end; how many incidents were detected internally rather than reported by an outsider.

The last one is the best single indicator. An organisation that finds its own problems has a working operating model, whatever its policy library looks like.

How this differs elsewhere

No departures recorded for this concept yet. That is not a finding. It means nobody has checked, not that the position is the same everywhere — see the coverage note on the governance index.

Sources

Never independently verified.