The data governance operating model

Data governance has a reputation problem: in most organisations it means a council that meets quarterly, a policy nobody has read since it was approved, and an estate that behaves exactly as it did before either existed. This playbook lays out the version that works — the one where governance is a property of how data is operated, not a committee that observes it. 1. What good looks like Every significant data domain has a named owner with the authority and budget to keep it healthy. Every dataset that matters carries a classification that systems can act on. When someone asks where a number came from, the answer is lineage, not archaeology. And the obligations — the Privacy Act and its APPs, CPS 234's expectations on information assets, the retention rules of your sector — are met by the way the platform works, not by an annual scramble. 2. Ownership before tooling The first failure mode of data governance is buying a catalogue before naming the owners. A tool can record who should care about a dataset; it cannot make anyone care. Name an owner for each domain — a person, not a committee — and give them three things: the mandate to fix what is broken, the budget to do it, and a definition of healthy they are measured against. Ownership is the control every other control depends on. 3. Classification that survives contact with reality Keep the tiers few enough to remember: public, internal, sensitive, and whatever your regulator adds. Then make classification the platform's job wherever possible — applied at creation, inherited through pipelines, checked at the point of use. A classification scheme that relies on every employee labelling every document correctly is a scheme that has already failed; one that relies on defaults, automation, and spot-checking has a chance. 4. Lineage and quality as operating disciplines Lineage answers where the data came from and what has touched it; quality answers whether it can be trusted at the point of use. Both decay the moment they become projects instead of properties. Build them into the pipeline: transformations recorded as they run, quality measured at ingestion against thresholds the owner set, breaches routed to the owner as incidents rather than discovered in a report review months later. 5. The cadence A register of the domains and their health. A forum that meets on a rhythm, chaired by someone with authority, deciding real things: accept this risk, fund that remediation, retire this feed. Decisions recorded where the next person can find them. The same discipline as any governance that works — and the same test: if the forum has not stopped or changed anything in two quarters, it is a briefing, not governance. 6. The obligations map Map each obligation to the mechanism that satisfies it. The APPs' collection and use limits map to classification and access controls. CPS 234's information-asset expectations map to the register and its criticality tiers. Retention and deletion obligations map to lifecycle policies that actually execute. When the regulator asks how an obligation is met, the answer should name a mechanism, not a policy. 7. The first 90 days Pick the three domains that matter most to the business and name their owners in the first fortnight. Stand up the register with honest health ratings — red is information, not failure. Get classification running automatically on one high-volume pathway. Hold the first forum in month two with real decisions on the agenda. By day 90, one domain should be measurably healthier, and the organisation should know who owns the other two. Data governance succeeds when it is boring: owners known, tiers applied, lineage recorded, forum deciding. The alternative is exciting — usually in the week a regulator, an AI program, or a breach asks questions the estate cannot answer.