Issue #49 – Implementing Effective Data Governance
Moving beyond the "why" to master the "how" of executing on your governance goals
Read time: 14 minutes
The role of Data Governance is becoming more well-known and popular across organisations of all sizes and industries.
Executives are beginning to realise that governance is more than just a compliance checkbox—it's a strategic capability that enables data-driven transformation. Research shows that governance is ‘one of the top three differences between firms that capture value from data and firms that don't.’
But there's still a massive gap between understanding governance's importance and actually implementing it successfully.
In fact, a lot of organisations are scarred from failed implementations or going at it with the wrong idea.
This is one reason I wrote the first two pieces on Data Governance before this one: you need to approach it with your eyes wide open. What does that mean exactly?
Well, it means (1) understanding what Data Governance is and how it should be about delivering value rather than purely risk & compliance.
And (2) thinking about Data Governance in a strategic way to enable the delivery of value, rather than ad hoc activities that don’t drive buy-in and change across the organisation.
Despite this, transitioning from the "why" to the "how" remains incredibly challenging. This is true for any implementation or change management, but especially for Data Governance. To start with, Data Governance almost always starts with low resources, so unlike AI or other popular data domains in the past (e.g., Data Science, Engineering, whatever tool is popular), you can’t just throw a bunch of money at the problem and hope something works.
Moreover, when you are building a governance function, you are actively shaping the culture around data.
In other words, it is a journey, not a one-time project with a product output (like Data Science or Analytics).
This requires patience, persistence, and a clear understanding of how to sequence activities for maximum impact. Organisations that treat governance as a "set it and forget it" initiative invariably fail. On the other hand, those that embrace an iterative, value-driven approach to ensure data ownership, accountability and quality can provide a strong foundation for the data and AI products everybody is so jazzed about.
So let’s get into the "how": the things you need to think about when going about implementing a new governance team across your organisation.
Components of Implementing a Successful Data Governance Program
The first step in any implementation is to ensure that you’ve got your strategy ready to go.
Now this doesn’t need to be a 6-month exercise and require you to pay a consulting firm $200k (I mean my firm would do it for a lot cheaper and quicker 😉). No, your strategy can be quick and dirty or smaller, given the size of your organisation. However, you need to have a foundational strategy in place to ensure you are on the right path and heading in the right direction. This includes:
Strategic Direction & Vision
Operational Principles for DG
Team Goals and Targets
High-Level Roles, Responsibilities, and Processes
Delivery Roadmap
Now, if you aren’t sure you have this, give my last article a read. If you have the strategy (or plan to get it), continue below.
From an executional perspective, successful governance implementation requires five foundational components or principles that help achieve buy-in, prioritise value delivery, foster collaboration, and ensure you know what you are doing as you do it.
1) Executive Sponsorship + Champions Among Data & Business Leadership
Data Governance never gets off the ground unless it has a whole host of senior-level champions. So much of Data Governance—data accountability, alignment with the business, mitigating risks/ challenges, encouraging collaboration—relies on coordination between teams. That only really comes if you have leaders of that team involved and on board from day 1.
Ideally, you have a senior executive-level sponsor who is willing to fund the initiative/ team. Additionally, you would have champions from both the business and data teams. These individuals shouldn’t just approve budgets, but actively champion governance initiatives and be involved in decision-making (likely at a Data Governance Council level). Ultimately, these champions (and their main sponsors) must understand what's in it for them beyond mere compliance. They need to see how governance will improve their department's decision-making, reduce operational friction, or enable new business capabilities. Some key points to getting this:
Don’t put more work on their plate
Make the benefits clear
Have a clear plan
Involve them in the strategy development
2) Business Value Orientation
As I’ve defined before, Data Governance is about making data more secure and trustworthy to ensure data drives business value rather than creates risk. McKinsey research proves this value orientation is warranted, demonstrating in their paper that firms have eliminated millions in costs and enabled even more by having strong Data Governance programs.
Therefore, every governance initiative must deliver measurable ROI; each initiative should have clear business benefits attached to it. Charlotte Ledoux has a great article on this, which presents both a cost- and revenue-based approach to quantifying impact.
And while you may outline this in the business case/ idea phase, it also needs to be top of mind during implementation. Data professionals often focus solely on delivery and forget why they are doing things in the first place. You cannot do this with Data Governance; check in with key stakeholders, measure your metrics against the targets set in the strategy, and ensure continuous communication of benefits back to senior stakeholders in DG Council meetings. Otherwise, DG will get forgotten about as it’s implemented and engagement/ buy-in will drop significantly.
3) Prioritising Tasks & Scaling Strategically
If you take on too much, you will fail!
Always remember and remind yourself, not all governance problems are created equal, and you can't fix everything at once. The biggest mistake governance teams make is trying to tackle every data challenge simultaneously. Successful programs focus on identifying which data assets/ domains possess at least two of the three critical factors: business-critical data, stakeholders open to change, and areas where value can be delivered quickly.
This prioritisation approach prevents teams from "boiling the ocean" and creates early wins that demonstrate governance value. The goal is to build momentum through visible success, then scale proven approaches to more complex scenarios. Each victory creates advocates who champion governance to their peers, organically expanding the program's reach and credibility.
How do you practically do this?
Figure out what data matters most and what teams/ individuals are most bought-in
Structure your data initiatives around those teams/ use cases
Spend a disproportionate amount of time with them to outline clear benefits and ensure artefacts support their work
Measure and get feedback, checking in regularly
Showcase wins and design future initiatives with best practices you’ve just implemented
4) Partnerships Across the Organisation
Any governance team will be lean and must coordinate across multiple departments/ teams. This means that you need to partner exceptionally well to deliver, especially since a lot of DG success depends on embedded roles.
Successful programs build strong partnerships with data engineers, architects, and business stakeholders rather than trying to control everything centrally. This is an extension from getting your Executive Sponsors and Champions—those individuals on board give you the initial introduction to the right partner teams and the authorisation to implement across those teams.
Use that executive authority! Bring together different teams or roles who are all using similar data and get them thinking cross-functionally about how to own and manage that data. What might this look like?
Business stakeholders across teams request what they need from data within their domains, the benefits it will provide and eventually advocate for its governance
Analysts help translate some of those requests into technical requirements/ standards, while providing feedback as they experience problems
Engineers build controls into pipelines based on these governance principles
Architects ensure governance considerations are built into technology decisions and system designs from the start
The secret is making governance feel like enabling rather than policing. When partners view governance as a means to deliver better results more quickly, they become advocates, not detractors.
5) Clear Deliverables, Boundaries, and Value Milestones
Scope creep is very real for Data Governance teams. They cannot and should not try to fix everything related to data quality (and all the other things mentioned in the DAMA wheel).
One of the fastest ways to kill a governance program is to try to own every data-related challenge in the organisation. Privacy, security, architecture, and engineering all have legitimate governance components, but governance teams must clearly define what falls within their remit and what is the responsibility of other functions.
Trust me on this, I’ve seen it where the Head of DG just gets pulled into meeting after meeting because everybody thinks they are responsible for everything data quality. This leaves them with no time to deliver, and nothing gets done.
Therefore, effective governance programs must establish clear boundaries and value milestones that demonstrate progress. For example, with totally made-up numbers:
Set Data Domains – Build data domain map by month 3. Ensure the map covers 80% of the organisational data
Identify Critical Data – By month 5, assess 60% of datasets by their level of sensitivity and business criticalness
Agree to Data Standards – Define passable and exceptional levels of data quality for key critical data by month 6. Agree on business definitions for the most important data assets
Dataset Ownership – Assign ownership to the 5 most critical data assets in each domain by month 8, and set up roles, responsibilities and processes to govern them moving forward
These milestones should deliver tangible benefits (again, Charlotte’s article on this is great) that stakeholders can see and measure. Each benefit/ milestone is attached to a different initiative on the strategic roadmap that you have already outlined, with owners assigned to it.
In the end, the goal is to make governance's value obvious and extend the buy-in across the organisation (rather than having to convince people to participate).
While these foundational principles apply broadly to implementation, each organisation must adapt them to its specific context, culture, and business model. However, hopefully, this provides a starting point, and please keep them in mind as you build your executional roadmap and overall delivery strategy.
Data Governance Roles and Responsibilities in Delivery
I touched on Roles and Responsibilities in my last article, including an End-to-End DG Structure to embed into your organisation. Nonetheless, R&Rs are probably the most crucial aspect to consider when implementing Data Governance properly, so I wanted to spend a few words outlining this in more detail.
This will be a brief section, so if you want more, check out the many other great articles defining these different roles and what they do:
Charlotte Ledoux - The big confusion in Data Governance roles
George Firican – The complete guide to data governance roles and responsibilities
Nicola Askham – Everything you need to know about... Data Governance roles and responsibilities
Here is a quick overview of how the DG Team, Council, Data Owners, Stewards, and Custodians collaborate to deliver and implement DG.
The Data Governance Office - Central Coordination
Primary responsibility: Translate the Governance strategy (which they had a strong hand in building) into operational success. The DGO is accountable for the operational implementation of DG standards, policies and practices, while supporting those embedded roles. This may take the form of training, workshops, updating standards/ documents, and coordinating activities across business units.
Key implementation focus: Act as executional, internal consultants for data and business teams to solve data issues related to ownership, standards and accountability
Data Governance Council - Strategic Oversight and Conflict Resolution
Primary responsibility: Provide overarching support to the DG team/ structure and make hard decisions that individual teams can't resolve alone. The Council would meet once a month/ quarter to break deadlocks, allocate resources, and ensure governance priorities align with business & data needs. Also, this is about making decisions, not status updates.
Key implementation focus: Clear escalation criteria must be established for the DG Council (potentially via a RACI). Most governance decisions should be made at the steward or owner level, and matters shouldn’t be deferred to Council involvement.
Data Owners - Business Accountability
Primary responsibility: Align on the data within their domain, determine the highest priority use cases and define what "good enough" means. Owners set quality standards, approve access policies, and ensure data serves business objectives within their teams. They should not be managing data day-to-day (they have other day jobs).
Key implementation focus: Owners must have genuine authority over their domain and clear consequences for poor data quality. Without real accountability, the role becomes ceremonial. Set up touchpoints with the DG team and other roles to ensure this.
Data Stewards - Operational Excellence
Primary responsibility: Bridge the gap between business needs and technical reality. Stewards are the SME for particular data assets and will manage their day-to-day data quality, resolve issues, and serve as the primary interface for business stakeholders and technical teams. They are responsible for facilitating and coordinating to ensure that any issues are identified and fixed. It is worth noting that there may be both business and technical stewards on some data assets/ datasets.
Key implementation focus: Stewards should be provided clear guidelines on escalation points, priorities and standards. They also need direct access to both Data Owners (for business context) and technical teams (for implementation). Finally, they should spend more time solving problems than documenting them.
Data Custodians - Technical Implementation
Primary responsibility: Embed governance controls into systems and processes. Custodians implement the technical aspects of governance—access controls, quality checks, lineage tracking—based on standards defined by Owners and Stewards. They should be executional resources, not decision-makers.
Key implementation focus: Implementing governance in a way that is completely automated and largely invisible. With clear standards and instructions from other roles, custodians should have a relatively easy job building controls that make it easier to do the right thing than the wrong thing.
In the end, success depends on clear handoffs between roles. Owners define requirements, Stewards translate them into operational processes, Custodians implement technical controls, and the DGO coordinates across all levels. The Council intervenes only when the normal flow breaks down.
The key is ensuring that these roles are actually delivered on, rather than ‘in name only’. Every role should have a measurable impact on data quality, accessibility, or business outcomes. They should be tied to rewards, incentives and performance evaluations (something that is so underappreciated and rarely implemented).
Measuring Success for Data Governance Implementation
Okay, we’ve covered implementation principles and roles. Two areas left: Measuring Success and Example Artefacts
This is already a long article, so I’ll be quick about these two areas.
I mentioned an executional roadmap in the previous article, including value milestones and linking DG to business value throughout. Therefore, it comes as no surprise that having the right KPIs and metrics to demonstrate governance value is crucial.
A company's approach to this depends on its DG strategy and setup. But, I like to break it into five categories:
Implementation Metrics – Understanding the progress of governance implementation, outlining how the DG team and organisation are delivering on the executional roadmap. Example metrics may include:
Roadmap initiative completion percentage
Governance artefacts completion percentage
Training completion percentage for data owners, stewards, and general users
Issue resolution time improvement for data quality problems and governance violations
Data Quality Metrics – Measuring the impact that governance initiatives are having on improving the reliability and usability of data across the organisation. Example metrics may include:
Percentage of datasets/domains meeting defined quality standards
Data accuracy improvement rates in business-critical datasets
Reduction in data quality incidents reported by business users
Time to resolve data quality issues (trending downward)
Integrated data quality metrics (e.g., completeness, consistency, timeliness, etc.) tracked by DQ tools, platforms or data professionals
Business Impact Metrics – Demonstrating how governance translates into tangible business value and improved decision-making or time to insight capabilities. Example metrics may include:
Reduction in time-to-insight for analytics projects
Decreased manual data processing hours across business units
Analyst productivity gains
Project delivery time for data-dependent initiatives
Revenue or cost implications from said initiatives
Compliance Metrics – Tracking adherence to governance policies and regulatory requirements to manage risk and ensure sustainable data usage practices. Example metrics may include:
Policy compliance rates across different business units
Reduction in data-related regulatory violations or audit findings
Percentage of data assets with complete metadata and ownership documentation
Privacy incident reduction rates
Adoption/ Culture Metrics – Measuring the cultural acceptance of governance rules/ standards and the overall usage of data throughout the organisation. Example metrics may include:
Self-service data usage rates and user satisfaction scores
Participation in voluntary training and/ or initiatives
Percentage of datasets with owners
Catalogue or other data tooling usage
Business unit requests for governance support
Some of these metrics within the categories may overlap, but it is as MECE (mutually exclusive, collectively exhaustive) as I can think of. Not to mention, other data teams can use some of these metrics, and they all demonstrate value for the organisation’s investment in data!
Essential Governance Artefacts
The last component of implementation that I don’t want to forget is artefacts. These documents, tools, and processes help guide individuals involved in governance on their journey by translating principles and strategy into daily practice.
I won’t get into too much detail about these, as they need to be customised for your organisation, chosen for their usefulness and practicality. So here is a list of artefacts that I might consider investing time and money to develop to aid in any governance implementation:
Data Usage Policies – Clear, actionable policies establishing the rules of engagement for data use across the organisation. This may include data access rules (e.g., RBACs), retention policies or sharing guidelines
Data Quality Assessment – A baseline assessment to measure data quality across domains and datasets. This helps prioritise improvement areas and should take into consideration business priorities and data domain maturity
Data Domain Maps – Visual documentation to establish clear boundaries around what data fits within each business area/ department
Data Governance Org Structure – A clear organisational structure document defining roles, responsibilities, reporting relationships, and decision rights for all governance participants to prevent confusion about accountability. I went over an example one last week
Roles & Responsibilities – More detailed documentation of what each governance role actually does day-to-day, including specific tasks, decision rights, and escalation procedures to ensure clarity and prevent overlap. Consider this like a job description, as the DG work required of most of your roles will likely be side of desk work, and the clearer you are, the more success you will see
Business Glossary – A comprehensive, searchable definition of business terms and data concepts to ensure consistent terminology across the organisation and reduce misunderstandings between teams
Data Quality Standards and Thresholds – Specific, measurable quality criteria for different data types and use cases that align with how the business uses data and their requirements (rather than theoretical definitions)
Data Lineage – Clear documentation of data flows and transformations from source to consumption. This should be updated and align with the architecture/ modelling work
Metadata Management Approach – A systematic framework for capturing and maintaining information about data assets, including ownership, business context, and technical specifications to enable discovery and understanding. This may fit into a Data Catalogue or other tool
DQ Tooling Documentation – Guides for data quality tools and platforms to help users understand what the technology does and how to leverage it to make their job (or their governance responsibilities) easier
Okay, Now Go Do It…
There you have it, a bunch of words that hopefully communicate how to implement a Data Governance team into your organisation successfully.
At the same time, I want to be clear that this is challenging, requires patience, and involves a lot of persuasion to both senior and junior stakeholders. Data Governance is not a sexy data domain, and it is highly misunderstood, so making it work within an organisation will take time and effort.
But it's worth it, even if you get halfway! I mean, think about all the benefits to all the other data domains that ownership, accountability, adoption, and data quality improvement can provide (not to mention not worrying about compliance or risk)!
Oh, and it is essential for one more reason…AI
Without strongly governed data, any AI tools/ products you build or use will fall apart or be so opaque that you will have no idea what is going on.
And that segways nicely into my next article next Sunday on AI Governance. This was a reader-requested article, and I’m genuinely interested in exploring it. Although people talk about AI Governance, I haven't really seen anything done well in this area other than platitudes and risk-averse frameworks. So, until then, I hope you enjoyed this three-part series on Data Governance and have a great Sunday/week!
Thanks for the read! Comment below and share the newsletter if you think it's relevant! Feel free to also follow me on LinkedIn (very active) or Medium (increasingly active). See you amazing folks next week!