A data governance framework has a habit of turning into a two hundred page document that nobody in the business has read. That is not the point of governance. The point is to write down the small set of rules that lets the business trust its data, assign the small set of people who own those rules, and put in place the small set of controls that keep them honest. The whole thing should fit on a page. Here is what belongs on it.
What a good framework covers
A workable framework has six sections and no more. Any framework that has forty is overengineered.
- Scope and principles
- Roles and responsibilities
- Policies and standards
- Data quality
- Security and privacy
- Ways of working
Scope and principles
Half a page. What the framework applies to, and the handful of principles that decide close calls. A typical set for a UK mid market business might be data is owned by the business not by IT, personal data is minimised by default, one source of truth per business domain, and decisions are audit ready. Nothing clever. Just written down so people can point to it.
Roles and responsibilities
Four roles usually cover the ground. A data owner accountable for each domain, typically a senior business leader. A data steward operationally responsible for the domain, usually a senior manager who lives in the data. A central data team, in house or retained, that runs the platform and provides the expertise. And a data governance working group that meets monthly to decide anything that cannot be decided at steward level.
Policies and standards
Six policies are usually enough. Data classification, access, retention, acceptable use, external sharing and change control. Each policy is a page or less, written in plain English, with one named owner. Anything longer starts to be ignored.
Data quality
Data quality is the section governance frameworks most often skip. It should not be. Every domain should have a small number of measurable quality indicators, published on a shared scorecard and reviewed at the monthly working group. Six indicators per domain is usually plenty, mapped to the six classic quality dimensions of accuracy, completeness, consistency, timeliness, validity and uniqueness.
Security and privacy
UK GDPR sets the floor. Depending on sector, PCI DSS, FCA expectations or NHS Digital standards sit on top. The framework does not need to restate the regulations, only how the business is meeting them. Records of processing, data protection impact assessments for higher risk activity, encryption in transit and at rest, least privilege by default. If the auditor could find the evidence in an afternoon, this section is doing its job.
Ways of working
The last section is the one that turns policy into practice. It answers questions like these. How does a new dashboard get approved for wider sharing? Who signs off on a new data source being brought into the platform? How is a data incident reported and triaged? What is the change control on a production dataset? These questions come up every week in a healthy platform, and having the answers written down saves everyone time.
What not to include
A good governance framework leaves several things out. It does not contain the technical implementation of the platform, which belongs in an architecture document. It does not contain the data catalogue, which is a live artefact, not a policy. It does not contain training materials, which are separate. And it deliberately does not contain a maturity model that nobody in the business will look at again after week one.
How the framework gets adopted
A framework only works if the business uses it. Adoption in our experience needs three things. Executive sponsorship, a single page summary that new starters can absorb in five minutes, and a habit of pointing at it in real decisions. If governance is only invoked at annual audit time, it is theatre. If it is used every month by the working group to make a decision, it is real.
How Clarity approaches this
On our data governance consulting engagements we typically design and roll out this whole framework in four to six weeks. Two weeks of discovery, two weeks of drafting with the working group, and two weeks of rollout including training and the first working group meeting. Beyond that, ongoing operation is a small monthly commitment, usually running alongside a wider data consultancy engagement or a Power BI retained arrangement.
Frequently asked questions
How is a framework different from a strategy?
The strategy sets direction over one to three years. The framework is the operating model that keeps the strategy on the road day to day. You need both, and the framework tends to change less often.
Do we need a dedicated data governance team?
Almost never in a UK mid market business. A working group of existing people, chaired by a senior business leader, is usually the right shape. Dedicated governance headcount only makes sense at enterprise scale or in heavily regulated sectors.
How often should the framework be reviewed?
Once a year is a sensible minimum. Any major change in regulation, business structure or platform should trigger a lighter interim review. Rewriting the framework more than yearly is usually a sign that the framework was never quite right.
Want to talk this through with someone?
We are an independent UK Power BI and Microsoft Fabric consultancy. Honest opinions, fair prices, no sales pressure.