Every data governance framework looks the same on paper. Six components, a steering committee, a RACI chart, and a set of policies someone approved in a meeting. Most guides on how to create a data governance framework stop at that diagram.
The diagram was never the hard part. What breaks is the distance between a rule someone wrote and a rule that actually runs.
We’ve built data and integration systems for enterprise clients since 2004. What follows is the sequence we’ve found survives contact with a real business: six steps, in order, with the two that always get skipped marked as such.
Why do most data governance frameworks fail in year two?
Most data governance frameworks fail in year two because nobody versioned them. The framework gets written, approved, and filed, and then the business changes and the document doesn’t. Eighteen months later the rules describe a company that no longer exists. Nobody rolls them back, because nobody can prove what they used to say.
Year one usually goes fine. There’s a mandate, a budget line, and someone senior asking for status. The rules get written while the business holds still long enough to be described.
Year two is when the description stops matching. A product launches with a new customer type that the rules never expected. A pricing change adds a field nobody governed. An acquisition arrives carrying its own definition of “account”.
None of those events triggers a review, because reviews are calendar items and drift isn’t. By month eighteen you have a document that’s confidently wrong, which is worse than having none. Teams still cite it. The rules inside it are still firing somewhere in a pipeline.
Step 1. Define what you’re governing before you decide who governs it
Start with scope, not the org chart. Name the datasets, the domains, and the decisions that depend on them. Most frameworks open by drawing a governance council, which produces a structure with nothing underneath it. Pick the domain where a wrong number costs someone money this quarter.
The test: can you name the decision? “We govern customer data” is a scope statement nobody can act on. “We govern the customer records feeding the monthly revenue report” is one you can check on a Tuesday.
Do this for one domain first. Three in parallel feels like a program and behaves like three pilots, and all three tend to reach year end half finished.
Step 2. Write the business definitions, not the technical ones
“Active customer” means whatever the business says it means, and that definition belongs to a person with a name. Not to a schema, and not to whoever wrote the query first. This is the step teams skip. It’s slow, it’s political, and it’s the one that decides whether the framework holds.
Skipping it feels efficient. The engineer already has a working definition in SQL, so the framework adopts that and moves on.
Six months later finance and marketing report different customer counts. Both are correct against their own query, and neither traces back to anyone who agreed to it.
Write the definition in business language. Then map it to the schema. Then record who owns it, so when it changes there’s a person to ask instead of a commit history to search.
This is where data quality stops being abstract. A record isn’t low quality in general. It’s low quality against a definition someone agreed to.
Step 3. Turn definitions into rules that execute
A definition becomes a rule when a machine can check it. That means a field, a condition, and a threshold. Keep the observation, the rule, and the result stored separately as you go. That separation is what makes the whole thing auditable a year later.
That separation matters more than it sounds. The observation is that a column came back 12% null on Tuesday. The rule says it must stay under 2%. The result is that the run failed.
Store those as one blob and you can never answer the question an auditor actually asks. That question is what the threshold was on the day the report went out. Store them apart and the answer takes a minute.
Wire the checks where the data already moves, which for most enterprises means inside the integration layer rather than in a separate scanning tool nobody opens.
Step 4. Put a human in the approval path
Rules get proposed by software and approved by a named human. Nothing becomes policy without that approval, however confident the suggestion looks. A steward accepts it, rejects it, or adjusts the threshold. This is a governance principle rather than a product feature, and it holds whether the proposal came from a profiling job or an agent.
The gate is what stops automation from turning a bad rule into policy at speed. It also creates the audit trail, because an approval carries a name and a date.
That principle is taking on more weight, not less. The same question now applies to systems that act rather than data that sits.
An agent that can update a record, open a ticket, or release a payment needs the same gate a data rule does. Who approved this behavior, when, and what did it replace? Governing an agent turns out to be the governance problem you already have, pointed at something that moves.
Keep the gate light or people route around it. One named approver per domain, a decision they can make without booking a meeting, and a log.
Step 5. Version everything
Version every rule, every threshold, and every definition. When a change causes odd behavior three systems downstream, you roll the change back. Without version history a bad rule is effectively permanent. Nobody can prove what it used to be, or who signed off the change that broke things.
This is the step nobody does and everybody needs. It’s also the cheapest of the six, because it’s a schema decision made once rather than a process someone has to run.
The practical version is that a rule change is a diff. It carries an author, a timestamp, a previous value, and a reason. When someone asks why the March numbers moved, you answer from the log instead of from memory.
Rollback pays for the framework the first time you need it. A rule that starts flagging 40% of a table at 2am is a bad threshold, and reverting it should take a minute.
Step 6. Make it compound
Approved rules become reusable contracts, so rule five on dataset one is never rewritten for dataset two. That’s the difference between a framework that scales and one quietly abandoned after four datasets. Reuse is also what turns onboarding a new dataset into a short job rather than a fresh project.
Compounding is easy to describe and easy to lose. The usual failure is a rules library that grows without a catalog. Nobody finds the null check that already exists, so everybody writes another one.
A semantic catalog fixes half of it, because rules become searchable by what they mean rather than by which pipeline they live in. A retirement path fixes the rest.
Schema drift is what tests this. When an upstream team renames a column, a compounding framework flags every rule that depended on it. A filed one finds out from a broken dashboard.
Once the first domain runs unattended, implementing data governance across the rest becomes a copy job rather than a fresh negotiation.
What does a working framework look like after twelve months?
After twelve months a working framework is boring, which is the point. Rules run on their own schedule. Failures arrive with the failing rows attached. Changes carry names and dates, and last quarter’s audit got answered from a log rather than a scramble.
The concrete picture: a steward opens a dashboard on Monday and sees six datasets scored across completeness, uniqueness, validity, accuracy, consistency, and exploratory checks. Three are green. One is amber on validity, because an upstream field changed format on Friday. That’s a short conversation rather than an incident.
ThemisData is the product our team built around this sequence.
It runs deterministic checks on every dataset every time, then proposes candidate rules and explains anomalies in business language. Above that sits the governance layer: rule lifecycle, steward approvals, and stored history. Its published figures are a 100% auditable rule lifecycle with a full evidence chain, 40% less rework downstream, and dataset onboarding that drops from days to hours.
None of that is the only way to do it. The DAMA-DMBOK and DCAM are both legitimate, both older than we are, and both worth reading. What we’re describing is narrower. It’s the part of governance we’ve found actually survives contact with a real enterprise, which is the part that runs without being remembered.
Frequently asked questions
Four questions come up in nearly every governance kickoff we run. Each answer changes the plan and the order of the work, so they’re worth settling before day one. The short versions are below. The longer ones are the six steps above them.
What are the steps to create a data governance framework?
Define scope, write the business definitions, turn them into executable rules, put a human in the approval path, version everything, and make approved rules reusable. Most frameworks skip steps two and five, which is why they stop describing reality within about eighteen months.
How long does it take to build a data governance framework?
The document takes weeks. The framework takes as long as it takes to get the business to agree what “active customer” means. That’s the real work, nobody can schedule it, and the honest answer to a steering committee is a range rather than a date.
Who should own the data governance framework?
The CDO owns the outcome and data stewards own the rules. The business owns the definitions. A framework owned entirely by IT ends up governing a technical model of a business that nobody in the business recognizes.
What’s the difference between data governance and data management?
Governance sets the rules and the authority behind them. Management is the day-to-day execution. Governance decides what “correct” means, and management makes it stay that way.
Bring one dataset to ThemisData and we’ll show you what your current checks are missing.