How to implement data governance in a real organisation — data ownership models, metadata management, data classification, access control, data lineage, and the change management required to make governance stick without killing analytical agility.
Data governance is one of the most discussed and least well-implemented disciplines in enterprise data management. Organisations spend months writing governance policies that then sit in SharePoint folders while analysts continue doing exactly what they were doing before. The gap between governance as described and governance as practiced is where data quality problems, compliance failures, and analytical inconsistencies live.
This guide focuses on implementation — not what governance should accomplish in principle, but what operational components are required to make it work in practice, and what change management is required to get an organisation to actually follow its own policies.
What Data Governance Actually Is
Data governance is the system of decision rights and accountabilities for information-related processes. It answers: who can make decisions about data, what decisions they are authorised to make, and what processes are required for decisions about data.
It is not:
- A data catalogue software purchase
- A set of policies that describe an ideal future state
- A data quality initiative
- A metadata tagging project
It is:
- Clear ownership of specific data domains with accountability for quality
- Defined processes for data definition, access, and change management
- Enforcement mechanisms that make governance policies real rather than aspirational
- Metrics that measure whether governance is working
Data Ownership: The Foundation
The first and most important governance component is data ownership. Every significant data domain in the organisation should have a named data owner — a business person (not IT) who is accountable for the quality, availability, and appropriate use of that data.
Data ownership is a business accountability, not a technical one. The VP of Sales is the data owner for sales pipeline data. The Chief Finance Officer owns financial reporting data. The Head of HR owns employee data. These are the people who have the context to define what "correct" means for the data in their domain, who can make decisions about who should have access, and who should be accountable when the data is wrong.
Data ownership without accountability is meaningless. The data owner must have:
- Authority to define data standards for their domain
- Responsibility for resolving data quality issues
- Accountability in performance reviews for data quality outcomes
- Budget and organisational authority to make changes
Many governance programs assign data ownership titles without real accountability. When the data is wrong, the owner shrugs and says it is an IT problem. This is governance theatre. Real governance means the data owner faces consequences for data quality failures in their domain.
Data Stewards: Operational Governance
Data owners set policy; data stewards implement it. A data steward is typically a technically literate business person (not a data engineer) who handles the operational governance work for a data domain:
- Maintaining the business glossary for the domain
- Reviewing and approving metadata and definitions
- Handling data access requests and approvals
- Investigating data quality issues
- Liaising between the business and data engineering teams
Data stewards work at the domain level — there might be one steward for sales data, one for marketing data, one for product data. In smaller organisations, the data owner and data steward role may be combined. In larger organisations, multiple stewards support each owner.
Data Classification
Data classification assigns every data element to a sensitivity category that determines how it must be handled, who can access it, how long it can be retained, and what controls apply.
A typical four-tier classification:
- **Public**: no restrictions on access or disclosure (published reports, website analytics)
- **Internal**: available to employees, not for external disclosure (operational metrics, internal communications)
- **Confidential**: restricted to specific teams with a business need (customer data, pricing, strategic plans)
- **Restricted**: highest sensitivity, requires explicit approval for access (PII subject to GDPR, financial data subject to SOX, health data subject to HIPAA)
Classification should be applied at the field level, not just the table level. A customer table might have internal fields (customer ID, purchase history) and restricted fields (name, email address, physical address) in the same table. Column-level security in your data warehouse enforces field-level classification.
Classification drives access policy: which roles can access which classification tiers, what approval is required for access grants, what logging and monitoring applies, how long data at each tier can be retained.
Access Control Implementation
Data governance's access control component defines who can see what. Implementation requires:
**Role-based access control (RBAC).** Define roles that reflect actual job functions, not individual users. A "Sales Analyst" role has access to the sales data domain at confidential level. A "Finance Viewer" role has read access to the finance data mart. Grant roles to users; manage access by role, not by individual.
**Access request and approval workflow.** Define the process for requesting access: what information is required (business justification, data owner approval, duration), who approves, and how long approval takes. Without a defined process, access requests are handled ad hoc and inconsistently — both too restrictive (blocking legitimate work) and too permissive (approving requests without scrutiny).
**Quarterly access reviews.** Role assignments accumulate over time. Former employees with retained access, transferred employees whose old access was never revoked, contractors who should have left when the project ended. Quarterly reviews audit current access against current job requirements and revoke what is no longer justified. In regulated industries, access reviews are a compliance requirement; in all industries they are good practice.
**Privileged access management.** Administrators and engineers with the ability to modify data or bypass access controls require additional oversight: just-in-time access (elevated access granted for a specific task, then revoked), multi-person authorisation for sensitive operations, and comprehensive audit logging.
Business Glossary and Data Definitions
One of governance's most impactful practical outputs is a business glossary — a canonical definition of every business term that appears in data. "Active customer" means something specific. "Revenue" has a precise calculation. "Churned" has a definition based on days of inactivity or subscription status.
When these definitions are not documented and enforced, different teams use the same terms with different meanings, dashboards contradict each other, and analytical conclusions are disputed. The sales dashboard shows 4,200 active customers; the marketing dashboard shows 3,800. Both are correct according to their team's definition. Neither is trustworthy.
The business glossary makes definitions explicit and binding:
- Term name and definition
- Calculation or derivation (if applicable)
- Owner (who is responsible for maintaining the definition)
- Systems and fields where the term applies
- Related terms and disambiguations
The glossary is only valuable if it is used. It must be accessible from the data catalogue, referenced in documentation, and enforced: when a new dashboard uses "active customer," the definition must come from the glossary.
Data Lineage
Data lineage documents how data moves from source systems through transformations to analytical outputs. It answers: where does this number come from? What source system? What transformations? Which other systems depend on this data?
Lineage is operationally valuable for impact analysis (if I change this transformation, what downstream outputs are affected?) and for trust (analysts can see that the revenue figure comes from the transaction database via a defined transformation, not from an unvetted Excel sheet).
Modern data stacks surface lineage automatically. dbt generates column-level lineage for all dbt models. Data catalogues like Alation, Atlan, and Collibra capture lineage from metadata. Orchestration tools like Airflow capture pipeline-level lineage.
The governance objective is not just that lineage exists but that it is complete and trustworthy — every certified dataset has documented lineage that is current and accurate. A lineage diagram showing a six-month-old version of the pipeline is worse than no lineage, because it creates false confidence.
Making Governance Stick: Change Management
Governance programs most commonly fail not because the policies are wrong but because they are not followed. Data governance requires behaviour change across an organisation, and behaviour change requires more than documentation.
**Start with pain, not policy.** Identify a specific data problem that is causing business impact — inconsistent revenue figures, a compliance audit finding, a data breach caused by over-provisioned access. Solve that problem with governance, make the improvement visible, and use the win to build momentum. Starting with a comprehensive policy document produces compliance theatre.
**Make compliance the path of least resistance.** If the governed data source is harder to access than the ungoverned spreadsheet, analysts will use the spreadsheet. Governance must make the governed path easier, not just more official. This usually means investing in data catalogue usability, self-service access request tools, and data quality that makes governed data more reliable than shadow IT.
**Governance has to deliver value to the people it constrains.** Governance asks data producers to follow standards and data consumers to follow access processes. If governance only costs them time with no benefit, they will route around it. Demonstrate value: certified data is trusted by the business; access governance means users have clean, well-documented datasets to work with instead of undocumented messes.
Our BI strategy consulting practice designs data governance frameworks for mid-market and enterprise analytics organisations — contact us to discuss your data governance requirements.
A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.
Book a Call →