Skip to main content
Daniel J Glover
Back to Blog

Data governance for IT leaders

7 min read
Article overview
Written by Daniel J Glover

Practical perspective from an IT leader working across operations, security, automation, and change.

Published 6 March 2026

7 minute read with practical, decision-oriented guidance.

Best suited for

Leaders and operators looking for concise, actionable takeaways.

If you have ever tried to get a straight answer from your organisation's data and found three conflicting versions of the same metric, you already understand why data governance matters. The challenge is that governance programmes can fail when they are treated solely as IT projects rather than business initiatives.

After years of leading technology teams through data governance implementations, I have seen what works and what remains unused. This guide sets out a practical implementation strategy.

Why data governance fails

A common failure pattern starts with a new initiative. Someone in the C-suite reads a report about data-driven decision making. A project is launched. A committee is formed. Policies are written. Six months later, nobody follows them and the committee has not met in weeks.

The root causes are usually the same:

  • No business ownership: governance is framed as an IT responsibility when it is fundamentally a business concern
  • Too much too soon: trying to govern everything at once rather than starting with what matters
  • Policy without enforcement: creating rules nobody follows because there are no consequences
  • No visible value: stakeholders cannot see how governance helps them do their jobs better

Agree business ownership and accountability before selecting supporting technology.

Building a practical framework

A data governance framework does not need to be complicated. In fact, the simpler it is, the more likely people will follow it. I recommend structuring your framework around four pillars.

1. Data ownership and stewardship

Every critical data domain needs a named business owner who understands and uses that data daily. Finance owns financial data. HR owns people data. Marketing owns customer engagement data.

Data stewards sit underneath owners and handle the day-to-day: monitoring quality, resolving issues, and ensuring standards are met. Think of owners as accountable and stewards as responsible.

In practice, this means:

  • Mapping your top 20-30 critical data elements to specific business owners
  • Creating a simple RACI matrix for data decisions
  • Making data ownership part of job descriptions, not an afterthought
  • Including data quality metrics in performance reviews

2. Data quality standards

Define quality measures for your critical data:

  • Accuracy: does the data reflect reality?
  • Completeness: are required fields populated?
  • Timeliness: is the data current enough for its intended use?
  • Consistency: does the same entity look the same across systems?
  • Uniqueness: are duplicates under control?

For each critical data element, set measurable thresholds. Customer email addresses might need 95% accuracy. Financial transaction records might need 99.9%. The thresholds should reflect business risk, not arbitrary targets.

3. Policies and standards

Keep policies short and actionable. A 50-page data governance policy that nobody reads is worse than no policy at all. Focus on:

  • Data classification: what is public, internal, confidential, and restricted
  • Access controls: who can see and modify what, and how access is granted
  • Retention and disposal: how long data is kept and how it is destroyed
  • Change management: how schema changes, new data sources, and integrations are governed

Each policy should fit on a single page. If it does not, you are overcomplicating it.

4. Technology and tooling

Notice this comes last, not first. Too many organisations buy a data catalogue before they have defined ownership or standards. The tooling should support your framework, not define it.

At a minimum, you need:

  • A data catalogue to document what data exists, where it lives, and who owns it
  • Data quality monitoring to track your defined metrics automatically
  • Lineage tracking to understand how data flows between systems
  • Access management integrated with your identity provider

Modern tools like data mesh architectures can help distribute governance responsibility while maintaining central standards.

Implementation: start small, scale fast

The biggest mistake is trying to govern all data across the entire organisation on day one. Instead, pick one high-value domain and prove the model works.

Month 1-2: foundation

  • Identify a pilot domain with a costly data problem, often finance or customer data
  • Appoint a business owner and two to three stewards
  • Audit current data quality with baseline measurements
  • Draft initial policies (maximum four pages total)

Month 3-4: implementation

  • Deploy data quality monitoring for your pilot domain
  • Implement the data catalogue for pilot scope
  • Run weekly stewardship meetings (30 minutes, no more)
  • Track and report quality improvements to leadership

Month 5-6: expansion

  • Demonstrate ROI from the pilot to secure broader support
  • Onboard the next two to three data domains
  • Refine policies based on lessons learned
  • Begin training the wider organisation

This phased approach builds credibility before asking for organisation-wide change. It is far more effective than a big-bang rollout that overwhelms everyone.

The AI dimension

Data governance has become significantly more urgent with the rise of AI and machine learning initiatives. Poorly governed data can undermine AI outputs and make errors difficult to trace.

If your organisation is pursuing AI enablement, your governance framework needs additional considerations:

  • Training data provenance: where did the data come from, and do you have rights to use it?
  • Bias monitoring: are your datasets representative, and how do you detect and correct bias?
  • Model governance: who approves models for production, and how are they monitored?
  • Synthetic data policies: if you are generating training data, what are the quality standards?

Documented provenance and quality controls help teams assess whether data is suitable for AI use.

Measuring success

Measure whether governance changes data quality and use. Track these quarterly:

  • Data quality scores against your defined thresholds
  • Issue resolution time: how quickly are data problems fixed once identified?
  • Adoption rates: are stewards actively using the catalogue and reporting tools?
  • Business impact: reduced reporting errors, faster decision-making, fewer compliance findings
  • Cost avoidance: incidents prevented, duplicate efforts eliminated

Present these to leadership in business terms, not technical ones. "We reduced financial reporting errors by 40%" lands better than "we improved data accuracy from 92% to 97%".

Common pitfalls to avoid

Having seen governance programmes succeed and fail across multiple organisations, these are the traps I would warn you about:

Do not create a data governance committee that only meets monthly. By the time you discuss an issue, it has been causing problems for weeks. Weekly 30-minute stand-ups with stewards are far more effective than monthly two-hour committee meetings.

Do not try to catalogue everything at once. Start with your critical data elements and expand. A catalogue with 50 well-documented, actively maintained entries is infinitely more useful than one with 5,000 entries that nobody trusts.

Do not separate governance from security. Data classification, access controls, and retention policies overlap significantly with your security programme. Align them from the start rather than creating parallel processes.

Do not ignore the cultural element. The best framework in the world fails if people see governance as bureaucracy rather than enablement. Frame every policy in terms of how it helps people do their jobs better, not how it restricts them.

Getting started next week

You do not need executive approval to start building momentum. Here is what you can do immediately:

  1. Identify your worst data pain point: ask three business stakeholders what data problems cost them the most time
  2. Map the data flow for that pain point from source to consumption
  3. Find a business champion who feels the pain and wants it fixed
  4. Propose a 90-day pilot with clear, measurable outcomes
  5. Start a simple data catalogue: even a spreadsheet is better than nothing

Business intelligence and AI projects depend on data that users can trace and assess. Use the pilot to resolve one recurring data problem and test whether the ownership model works.

Review the pilot's quality measures and unresolved issues before expanding to further domains. If you need support building or improving a data governance programme, my IT compliance consulting practice covers data governance, classification frameworks, and regulatory compliance.

Share this post

About the author

DG

Daniel J Glover

IT Leader with experience spanning IT management, compliance, development, automation, AI, and project management. I write about technology, leadership, and building better systems.

Continue exploring

Keep building context around this topic

Jump to closely related posts and topic hubs to deepen understanding and discover connected ideas faster.

Browse all articles

Ready to improve your IT operations?

Request a free 30-minute consultation to discuss your IT challenges. Send a short outline and I will reply to arrange a suitable time. No obligation.

Request a free 30-minute consultation

Get Occasional IT Leadership Insights

IT leadership insights, occasionally. No fluff. Unsubscribe any time.

No spam. Unsubscribe any time.