Issue #48 – The Strategic Approach to Data Governance
How to turn Governance into a strategic enabler, all in a 14 minute read
Read time: 14 minutes
The primary goal of this newsletter is to encourage people to think strategically about data.
Other than data strategy, no domain is more strategically inclined than Data Governance.
While Data Strategy sets the plan for what to do with data and how to derive value from it, Data Governance is about how to utilise data to achieve that goal.
Remember my definition from last week:
Data Governance establishes clear ownership and processes that make data trustworthy, accessible, and valuable across the organisation, ensuring data drives business value rather than business risk.
The problem is that most companies don’t approach data governance as a strategic enabler for your data activities; instead, it takes on a compliance role. And who needs a strategy for a purely compliance function (hint, no company that has to pay for it).
But if you don’t see the strategic value of managing your data in a way that it is secure, properly owned, and tied to an agreed quality structure, then you aren’t taking anything away from my newsletter.
So with strategy in mind, let’s dig into how to think about Data Governance strategically and develop an approach that governs your data for sustained success.
The DAMA Data Governance Framework
Before we jump into Data Governance strategy, there was one key bit we didn’t mention last week: the Data Management Association (DAMA) definition of Data Governance.
DAMA provides one of the most comprehensive and widely-referenced frameworks for data governance through its Data Management Body of Knowledge (DMBoK). This framework positions data governance at the centre of a wheel with ten interconnected knowledge areas, including data architecture, data modelling, data quality, data security, and metadata management.
I both love this framework/ perspective and equally refuse to use it.
Why do I love it and mention it here?
Simply put, this framework has been invaluable in establishing data management as a legitimate professional discipline. It provides detailed guidance on the technical and operational aspects of managing data throughout its lifecycle, outlining the breadth of capabilities required for comprehensive data management. The wheel visualisation also emphasises the importance of Data Governance and how it connects and coordinates all other data management functions. As I mentioned last week, DG is a key enabler that impacts other domains across the data ecosystem. Overall, I highly recommend DMBoK for its thoroughness and breadth of expertise it offers (even if it is a massive book).
With that being said…
…Why I shy away from the DAMA framework?
While as comprehensive as it is from a technical perspective, it also shoots itself in the foot in three ways:
Very Technical – The DAMA approach tends to focus on data management processes and technical controls rather than the strategic business outcomes that governance should enable. It's more concerned with "how to manage data properly" than "how to make data drive business value." In this way, it is more of a textbook of knowledge, rather than a playbook to be used to enable Data Governance.
No Connection to the Business – Within a business, Data Governance needs to directly relate just to that—the business. While DAMA's framework provides excellent guidance for the operational implementation of governance, it inadvertently reinforces the perception of governance as a technical function rather than a business enabler. The connection to the Data Strategy and overall value creation needs to be a part of any framework; otherwise, DG risks gaining a reputation as a bureaucratic department overseeing data domains to maintain control.
Encompasses Too Much – As I mentioned before, a core myth of DG is that it’s extremely hard to do. This framework doesn’t help. You can’t slide architecture, modelling, warehousing, BI, etc, all under Data Governance and expect a DG to deliver on it. Yes, all of these domains are connected to Data Governance, but to have them directly linked in a fundamentally domain-defining image gives the wrong impression that this is the responsibility of the Head of DG. While I like holistic thinking, this lack of specificity actually does a disservice to the DG domain
To conclude, I love DAMA, everything it stands for, and its data governance framework. However, I believe that if we want to make DG cool again, we need to change its trajectory and build it in a more strategic and targeted way. This brings me perfectly to the next section.
Building an Effective Data Governance Strategy
If there is one thing I hate about how most companies approach data, it is how disconnected and anarchistic it is.
Therefore, to succeed with Data Governance, organisations need one thing above all else: Structure
Without it, you will frustrate individuals and undermine the role governance should play.
While the data approach is often to jump right in, clean up the data, and build something, that approach won’t work for Data Governance. DG is about ownership and accountability, trust and value enablement, both establishing these things and gaining buy-in for them across the organisation. All of this requires a more strategic approach.
This is why I treat DG as a close cousin to Data Strategy—the domains approach delivery in a very similar way. And just like Data (or business) Strategy operates off of strategic frameworks, so should your Data Governance capability.
From my perspective, this consists of five interconnected components that work together to create sustainable, business-focused governance:
1. Strategic Direction & Vision
What is the purpose of governing data to enable business value? What is our end goal?
The foundation of any successful governance program starts with a clear vision of how data will enable business objectives. This is about establishing ‘why data governance needs to exist’ to ensure your organisation gets what it needs from this initiative.
The ‘why’ should be easily articulated (maybe into a vision statement) and should directly tie into the business and data strategy. In addition, it should address existing pain points that the business and data teams are currently facing in terms of data quality, management, and governance/ownership.
It also needs to be punchy and easy to understand. To accomplish that, the direction and vision should be workshopped with business stakeholders (who work with data) and shared across the organisation to ensure everybody understands it.
2. Operational Principles for Data Governance
How do we ensure governance enables data progress instead of inhibiting it?
Just like an operating model enables a strategy, operational principles need to support a governance function.
Many organisations and teams will view this as a list of policies and rules, but what I’m proposing is more of an operational framework that provides clear, actionable guidance on how data should be handled. Artefacts or policies, such as data quality standards, privacy policies, retention guidelines, and access protocols, would be built with these principles in mind.
The key is developing principles that guide decision-making. They should help teams make consistent choices about how to govern data and technologies. Some examples of these operating principles might be:
Business Value Focused – Governance decisions should prioritise enabling business outcomes and data usability over technical perfection
Default to Access, Secure by Design – Data should be accessible by default to authorised users, with security and privacy controls built into systems rather than imposed as barriers
Business-Owned Data Assets – Data assets must have a clearly identified business owner who is accountable for their quality, usage, and adherence to compliance requirements. Technical teams will support the maintenance of the data, but business teams own and decide how it is used
Automate Governance – Governance controls should be embedded in systems and processes rather than requiring manual approvals
Measure Impact – Governance success is measured by business outcomes (faster decisions, better insights, reduced risk) rather than compliance metrics (policies written, training completed, tools deployed)
Start Small and Scale Logically – Initial governance initiatives should be high-value, low-complexity use cases that demonstrate clear business benefits, with the team expanding to more complex scenarios based on proven success
Collaborate While Defining – Governance policies, processes, and roles need to be set up with partnership and consultation in mind to ensure buy-in
These guiding principles will help convince business stakeholders that governance is working for them rather than against them. They also serve to remind data professionals of the role the government will play in enabling them, rather than hindering their progress.
3. Team Goals and Targets
What do we want Data Governance to achieve? How do we deliver on the Strategic Direction and Vision while embodying our Operational Principles?
Like any strategy, you have to set goals and targets within your governance programs. But these must measure business impact, not just compliance metrics. Make these as concrete and measurable as possible (like set ownership for 70% of data assets/ sources) rather than aspirational statements (like improving data quality).
To align with your enabling vision and business-focused operating principles, you need to have goals that span multiple dimensions. This will depend on your direction and culture; categories might include enabling business teams to interact with data, improving the operationalisation of data quality, reducing risk issues, and helping build a more compliant and data-forward culture.
After deciding on the goals, two more things remain: timelines and owners. Each goal should clearly identify when it will be measured (and how) while setting out which business stakeholders will both benefit from and be accountable for it. This fosters ownership and ensures that governance activities are measurable, thereby establishing credibility for the entire domain.
4. High-Level Roles, Responsibilities, & Processes
Who is responsible for delivering these goals and who needs to be involved? What processes need to be set out to achieve this?
Roles and responsibilities are a core tenet of any successful governance program, and any DG expert will discuss them extensively. And for good reason: accountability is the backbone of governance. Therefore, the structure must include well-defined roles that balance centralised coordination with distributed ownership. I would boil this down to six types of roles:
Executive Sponsor: Top level of accountability to provide strategic direction, business/ data linkage and remove any organisational barriers
Data Governance Lead: Your Head of or Manager who coordinates the program activities and manages stakeholder relationships
Data Governance Team: Any supporting governance analysts or technical resources who deliver on activities/ initiatives
Data Owners: Business leaders accountable for specific data domains and their business outcomes
Data Stewards: Operational experts who manage day-to-day data quality and usage
Data Custodians (Team/ Users): Tertiary roles like engineers and architects who embed governance into systems or analysts who need to follow governance policies/ processes
Within each of these roles comes the responsibilities they should have. For example, what does each role mean/ do, what are the decision points, how to escalate issues (and to whom), and what tools/ technologies can support the process.
Speaking of processes, governance requires structured workflows that don’t burden individuals or add work, but rather make it easier to utilise data. There are a whole host of processes/ workflows that might factor into an organisation’s DG strategy, but the categories I would recommend are:
Defining Data, Roles, & Ownerships: Process to create data definitions, domains, assets, or establish roles for this data
Access Request Management: Determining RBAC (Role Based Access Controls) or ABAC (Attribute Based Access Controls) to grant appropriate data access while maintaining security
Data Issue Monitoring & Resolution: Standardized workflows for identifying, assigning, and tracking data quality problems across the E3E lifecycle
Change Impact Assessment: Process points to evaluate (with business stakeholders) how data changes affect downstream activities, products and consumption
The processes above are not specific, but somewhere in the strategy, there needs to be an outline of how the repeatable process integrates with existing workflows and the benefits those create. There is a significant amount of overlap with other data and business domains (e.g., integrating data quality checks into deployment pipelines or incorporating governance considerations into data product planning templates), so it is essential to clarify these points. At the same time, avoid overburdening people with unnecessary processes; instead, focus on the key ones that will yield the most benefits and ensure they overlap and integrate well.
Finally, the last thing to mention is that processes should incorporate broader data platform and tooling investments, especially leveraging data quality platforms, observability tools, and data contracts to automate governance rather than relying solely on manual processes.
5. Delivery Roadmap
How do we execute on our Data Governance initiatives? What are the key details to ensure successful implementation?
As Charlotte Ledoux mentions, you need to "start somewhere without trying to boil the ocean." I’ve heard this advice from many DG leaders, and I want to underscore it as well: success happens when you start small, test and prove out a scalable approach, and then translate that approach to additional initiatives.
While this is essential, I haven't seen many DG strategy frameworks that specifically address a delivery roadmap. Maybe that comes down to a lack of team, budget or direction (making an executional roadmap hard to build), but I believe an execution roadmap is crucial for the success of any strategy.
We will get more into some of these elements in the Implementation article next week (and further in the Data Strategy article, where I will talk about roadmaps a lot), but here are some things to keep in mind when building your delivery roadmap:
Timelines
Overall Initiative Benefits
Value Milestones
Key Activities
Activity Owners
Cross-Functional Dependencies
In addition to all these elements, the roadmap should include a communication strategy to help establish buy-in across the organisation for governance activities. Whether it is workshops, data literacy training sessions, interviews, lunch and learns, etc., these should help stakeholders understand why governance matters to them, how it will make their jobs easier, what specific changes they can expect, key touchpoints and people to reach out to and timelines for this type of work
This is just a taste of what you need for each component (you could get into a lot more detail, especially if you want to build this for your organisation). I highly recommend following and reading both Nicola Askham and Charlotte Ledoux, who are my favourite Data Governance thought leaders. They have written extensively on all these elements, and much of my thinking stems from researching their work and interacting with them personally.
An End-to-End Governance Structure
A good data strategy only works with a well-functioning operating model and organisational structure.
The same is true for governance.
Before you deliver this framework, you need to determine the organisational structure and operating model that will facilitate it.
I like to think about this with an end-to-end Governance Model in mind. Now, this sounds big, expensive and bureaucratic; it’s not. It can be as lean or as large as you want, flexible to your organisation’s needs.
An E2E governance model operates at three levels:
Data Governance Office – Provides centralised coordination and focused DG leadership/ expertise across the organisation
Data Governance Council – Allows for strategic oversight of data usage with input by senior business and data stakeholders
Embedded Governance Roles – The distributed/ federated execution arm fulfilling the roles & responsibilities set out in the strategy
Data Governance Office
The DG Office is the central hub of the governance domain. The team would be comprised of the Head of Data Governance and associated managers/ analysts.
Their role is to provide expertise in the domain and drive support across the organisation. Some of the activities/ responsibilities they have are:
To build the strategy in coordination with the business teams
Facilitate working groups and coordinate governance activities across departments and teams to agree upon data definitions, domains, standards, and direction
Help build Data Governance artefacts, such as policies, processes, and data maps
Provide training and support to data owners and stewards
Manage governance tools and platforms to enable self-service compliance
Measure and report on governance effectiveness against set goals/ targets
The key to the DGO's success is positioning it as an enabler rather than a gatekeeper. At the same time, ensure they are not overburdened, as the role becomes quite complex when data quality and management are factored in. Having a clear RACI or ‘what the DGO does/ doesn’t do’ document is crucial to ensure people are requesting the right things from the office.
Data Governance Council
The DG Council provides strategic oversight and cross-functional alignment for governance initiatives at a senior level, bringing all necessary stakeholders together to set the direction and establish accountability for governance activities. A reason this doesn’t come from the DG Office is to ensure governance priorities align with business priorities and are embedded into ongoing operations.
The Council provides a cross-functional structure for resolving issues or making decisions that would otherwise be siloed within the data function or never discussed. Some primary functions of the Council include:
Set governance priorities and investment decisions based on the main concerns of the business and data teams
Resolve cross-functional conflicts about data ownership and usage
Identifies any large strategic initiatives that may require governance support (e.g., data platform migration, new technology implementation, etc.)
Provides senior-level (and sometimes executive level) support and sponsorship for governance initiatives
Final accountability and decision maker about governance policies and standards
As you may surmise from the responsibilities, the DG Council should include both business and technical leaders. This ensures decisions reflect the business’s operational realities and strategic objectives while including data leaders who know what it takes to get things done. It also gives different departments a voice at the table when defining/ agreeing upon KPIs or data definitions (so they don’t go do it themselves, and it doesn’t match with anybody else…).
Embedded Governance Roles
While the DGO and DG Council are more centralised in nature, a true governance domain can’t function without some federated resources. This is what I refer to as Embedded Governance Roles. Referencing the roles I laid out above, this would include the Data Owners, Stewards, and Custodians. These roles are filled by business stakeholders and supported by data professionals who form the backbone of effective governance because they are the ones living and breathing it all.
So, in as much as they are responsible for the day-to-day facilitation and implementation of data standards, the distributed structure requires:
Data Owners to interpret and translate the strategy to define quality standards, approve access policies, and ensure data serves business objectives within their data domain. These individuals are accountable for specific datasets/ domains.
Data Stewards to act as operational points of contact for managing day-to-day data quality, resolving issues, and serving as the bridge between business needs and technical capabilities. There can be different types (business-focused, technical, operational, etc.) of Data Stewards as well, depending on how mature your organisation is
Data Custodians can fulfil multiple roles. For example, they may be more backend-oriented and responsible for data-provisioning tools and systems, working closely with Data Stewards to ensure the quality of data as it progresses through the lifecycle. Or Data Custodians may be data or business analysts who need to adhere to governance processes and potentially update/give feedback to Data Stewards or Owners if something is not working properly.
Ultimately, this three-tier E2E model is about structure. Making sure everybody knows their roles helps establish accountability without unnecessary bureaucracy or extra work:
The DGO provides expertise and coordination, the Council provides strategic direction and conflict resolution, and embedded roles ensure governance principles are applied where data is actually created and used.
And let’s not forget, this isn’t the end of your Data Governance journey! Any strategy needs to have a strong implementation plan and approach supported by the right sponsorship, KPIs, and artefacts. Next week, we will cover the majority of this, but until then, have a great Sunday and a wonderful week ahead!
And remember, Data Governance needs to be thought of strategically! Only then can we ensure data is of high enough quality to deliver value across the organisation.
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!
Loved this line in particular: “Governance success is measured by business outcomes (faster decisions, better insights, reduced risk) rather than compliance metrics (policies written, training completed, tools deployed)”
YES 🙌
As soon as data governance is thought of as ‘data governance you lose the room.
But as soon as you start to use business and commercial language related to data governance, you get people listening.