What Is Data Governance? A Definition, the Components and a 90-Day Plan

In Short: What Is Data Governance?

Strip the ceremony and data governance is a small set of decisions, kept: who owns each data domain, what terms mean (one definition of revenue, not five), who may use what (access, privacy, retention), and how quality is maintained (standards, monitoring, response). Governance is making those decisions explicitly, assigning them to named people, and - the step most programmes skip - enforcing them in the platforms where data actually lives.

A policy document is not governance; it is a wish. Governance is when the platform makes the wish true by default.

This guide is the starting point for everything we have written on the subject. It covers the definition, why it matters now, the components of a working data governance system, the frameworks and roles, how it maps to the Microsoft stack, a 90-day plan and the mistakes that sink most programmes - linking out to the deeper guides as it goes.

A Data Governance Definition You Can Work With

The Data Governance Institute's definition, which Microsoft quotes in its Fabric adoption guidance, is precise: "a system of decision rights and accountabilities for information-related processes, executed according to agreed-upon models which describe who can take what actions, with what information, and when, under what circumstances, using what methods."

Two words in that sentence do the work. Decision rights means someone is entitled to settle questions about data - whether a lapsed account still counts as a customer, whether a field is personal data, who may see it. Accountabilities means that same someone answers for the result. Microsoft's guidance adds a useful correction: the term is a slight misnomer, because what you are really governing is not the data itself but what people do with it.

It helps to separate governance from its neighbours:

• Data management executes governance decisions: pipelines, storage, modelling, operations
• Data security is one outcome governance specifies, enforced through identity, permissions and encryption
• Compliance is the external obligation governance helps you meet and, crucially, demonstrate

Governance decides; management delivers; security and compliance are among the things it delivers.

Why It Matters More in 2026

For years governance lost budget battles because its risks were latent. Two forces ended that.

AI. Copilot answers from whatever permissions allow, agents act on whatever definitions exist, and every gap - the overshared site, the five margins, the stale table - now surfaces fluently, at scale, to whoever asks. Data that was badly governed but hard to find has become easy to find. That is why data quality is now an AI problem, why agents need their own identities and permissions, and why organisations treating governance as AI readiness are funding in one quarter what advocacy could not achieve in five years.

Regulation. Under UK and EU GDPR, accountability means the controller must "be able to demonstrate compliance" with the data protection principles - including data minimisation, accuracy and storage limitation. Demonstrating is a governance capability: you need to know where personal data sits, who can see it and when it is deleted. Our guides to GDPR on an analytics platform and POPIA for South African data teams translate those obligations into architecture. For organisations building high-risk AI systems, the EU AI Act goes further, with Article 10 setting data governance requirements for training, validation and testing datasets - covering origins, preparation and bias examination.

If you need the executive one-liner: governance is now the difference between AI that answers and AI that embarrasses.

The Components of a Data Governance System

Ownership and stewardship. Every domain - customer, finance, product - has a named owner accountable for its quality and meaning, with stewards doing the weekly tending. Committees do not own things; people do. This is the single highest-leverage element, and its absence is why quality problems recur no matter how many clean-ups run.

Policies and standards. Short, specific rules: what each sensitivity level permits, when an owner is required, what an item must pass before it is certified. Microsoft's guidance is blunt that a data policy "should be as short as possible", and that includes how it will be audited and enforced.

Data quality management. Standards per critical dataset, automated checks in the pipeline, and a response path when checks fail. In a medallion architecture the Silver layer is where most rules live. Quality is an operated system, not an annual audit.

Metadata and cataloguing. An inventory of what data exists, where, who owns it and what it means. The business glossary belongs here, made real: contested terms settled once and recorded where users meet the data - which in the Microsoft world means encoded in semantic models and catalogued in Purview, not parked in a wiki.

Lineage. Where each figure came from and what depends on it. Lineage answers the board member's "can we trust this number?" and the engineer's "what breaks if I change this table?".

Access and security. Who may see what, enforced as workspace permissions, RLS and sensitivity labels, with privacy obligations mapped to actual controls rather than asserted in policy. Our guide to protecting sensitive data with access control covers the practical patterns.

Lifecycle and retention. How long data is kept, when it is archived, and how it is deleted - including from analytical copies, which is where retention schedules most often quietly fail.

Frameworks, Briefly

You do not need a framework to start, but a reference model helps you check for blind spots.

DAMA-DMBOK, the Data Management Body of Knowledge from DAMA International, is the most widely cited. It defines 11 knowledge areas - data governance, architecture, modelling and design, storage and operations, security, integration and interoperability, documents and content, reference and master data, warehousing and BI, metadata, and data quality - and places governance as the function that oversees the rest. The current edition is the DMBOK 2 revision, with a 3.0 update in development.

Microsoft's Fabric adoption roadmap is more practical for Microsoft estates. Its governance chapter compares three ways of introducing governance - roll out first, plan fully first, or iterate alongside staged rollouts - and recommends the iterative approach as the best choice for most organisations. It also includes a maturity scale from 100 (initial) to 500 (efficient), which is useful for an honest baseline.

Use frameworks as checklists, not as project plans. The failure mode is implementing a framework's table of contents instead of solving your problems. Our Microsoft data governance framework is deliberately reduced to four parts that can be implemented in weeks.

Who Does What: The Roles

Titles vary; the functions do not.

• Executive sponsor or CDO: sets priorities, funds the work, settles escalations
• Data owners: business leaders accountable for a domain's definitions, quality and access decisions
• Data stewards: the people who maintain definitions, triage quality issues and curate the catalogue day to day
• Data custodians and platform team: IT and engineering, who implement and operate the controls
• Governance lead or small working group: coordinates across domains, maintains standards, runs a brief monthly forum for cross-domain disputes
• Everyone who uses data: follows the policies - Microsoft's guidance phrases it as "everyone is a data steward"

The key design principle is that ownership sits in the business and enforcement sits in the platform. IT cannot decide what counts as an active customer; it can make whatever answer the business gives hold on every refresh.

How Microsoft Data Governance Works in Practice

On the Microsoft stack the tooling divides into two layers that work together.

Microsoft Purview governs across the whole estate:

• Unified Catalog: governance domains, data products, glossary terms, critical data elements, OKRs, and data quality rules with scores at asset, product and domain level
• Data Map: scans sources - Fabric, Azure, other clouds, on-premises - for metadata and lineage
• Information Protection: sensitivity labels that follow data into supported exports
• Data Loss Prevention and Audit: detection of sensitive information in Fabric items and an audit trail of user activity
• Data Lifecycle Management: retention policies and labels for Microsoft 365 workloads such as Exchange, SharePoint, OneDrive and Teams

Microsoft Fabric provides governance built into the analytics platform:

• Domains and subdomains: group workspaces by business area, with domain admins who can override delegated settings such as a default sensitivity label and who may certify content - the foundation of federated governance
• OneLake catalog: discovery, filterable by domain, with a Govern tab for governance insights
• Endorsement: three badges - Promoted, Certified and Master data - with certification and master data limited to reviewers the admin authorises
• Lineage and impact analysis: which downstream items break if you change something
• Permissions: workspace roles, item permissions, OneLake data access roles, and row-level security in semantic models

Two cautions. Several Purview capabilities need licensing beyond Fabric, so check the current position before you design around them. And Purview's retention policies target Microsoft 365 content, so retention for lakehouse and warehouse data is something you engineer in the pipelines. Our guide to Fabric data governance with Purview covers the integration in depth, and Power BI workspace governance covers structure and certification for the reporting layer.

A Pragmatic 90-Day Starting Plan

The failure mode is universal: a governance council, a 40-page framework, no enforcement, quiet death. The working alternative is deliberately small.

Days 1-30: pick the pain and name the people.

• Start from felt pain: the two domains where wrong or leaked data costs real money this quarter
• Name owners for those domains only; give them time, not just titles
• Inventory the critical assets in those domains and profile their quality honestly
• Settle the three to five most contested definitions

Days 31-60: enforce.

• Encode the settled definitions in certified semantic models, and certify sparingly
• Enforce access properly: permissions reviewed, groups rather than individuals, labels applied, RLS tested
• Put automated quality checks on the tables that feed decisions, alerting the owners

Days 61-90: make it observable, then expand.

• Connect Purview, populate the catalogue for the priority domains, and review lineage on the critical path
• Publish a quality dashboard the owners actually look at
• Agree the next two domains on evidence, using Fabric domains to delegate as you grow

Note what is absent: an enterprise glossary project, a tool selection exercise, a policy library as the first deliverable. Those can follow demonstrated wins. They cannot substitute for them.

Common Mistakes

• Starting with documents. Policies without enforcement decay at exactly the rate you would expect
• Governing by committee. Committees preserve the absence of ownership while appearing to address it
• Boiling the ocean. Trying to catalogue and label everything before anything is useful
• Treating it as an IT project. IT can enforce meaning; only the business can decide it
• Fixing data in the report. Corrections applied downstream become folklore; fix at source or in the pipeline
• Certifying everything. The Certified badge is a promise; overuse makes it worthless
• Leaving AI out of scope. Copilot and agents are now among the heaviest consumers of governed data, and they inherit every gap
• No review cadence. Access drifts, owners leave, definitions change - a quarterly review is the minimum

None of these are exotic. All of them are the difference between governance people can point to and governance that exists only on slides.

Where Solv Systems Comes In

We implement working governance on the Microsoft stack in the order above: priority domains first, named owners, definitions encoded in certified models, access and labels enforced, and quality checks that alert the people who can fix the problem. Because it runs on the Fabric and Purview estate you already own, governance becomes a property of the architecture rather than a parallel bureaucracy.

The outcome clients notice is not a policy. It is the day a surprising number appears in a report and the first question is "what should we do about it?" rather than "is that right?"

Sources and Further Reading

• Microsoft Fabric adoption roadmap: Governance
• Governance and compliance in Microsoft Fabric
• Learn about Microsoft Purview Unified Catalog
• Endorsement overview in Microsoft Fabric
• DAMA-DMBOK framework
• ICO: A guide to the data protection principles