Data Governance Strategy and Roadmap: A 5-Phase Implementation Plan (With Example)

This is the roadmap our data governance consulting team uses with US and Canadian clients, from first assessment to automated controls.

Most companies don’t have a data problem. They have a trust problem. Finance and sales report different revenue. Two systems disagree on a customer’s address. Nobody knows who owns the field.

That costs real money. Gartner research puts the cost of poor data quality at $12.9 million a year for the average organization.

A data governance strategy says why you govern data and who decides. A roadmap says what happens when. This guide gives you both, with the timelines, owners and deliverables for each phase. It draws on governance programs Algoscale has delivered for a healthcare regulator, a $7B insurer and a 14-company security integrator. If you’d rather have help building yours, see our data governance consulting services.

What is the difference between a data governance strategy, roadmap and plan?

A data governance strategy sets the goals and rules. A roadmap puts them in order over time. An implementation plan assigns the work to people, week by week.

You need all three. A strategy with no roadmap stays a slide deck. A roadmap with no plan slips because nobody owns the tasks.

	Strategy	Roadmap	Implementation plan
Answers	Why govern data, and what does success look like?	What happens in which order, and when?	Who does what, by which date?
Owned by	Executive sponsor and CDO	Data governance lead	Program manager with domain owners
Time horizon	2–3 years	12–18 months	90 days at a time
Typical format	5–10 page document	One-page phase timeline	Workstream tracker or project plan
Changes	Yearly	Quarterly	Weekly

Think of it as a funnel. The strategy decides that customer data must be trusted. The roadmap says the customer domain pilots in months 3–6. The plan says the steward signs off the definition of “active customer” by week 9.

What are the 4 pillars of data governance?

The 4 pillars of data governance are people, process, policy and technology. People own the data. Policy sets the rules. Process makes the rules repeatable. Technology enforces them at scale.

This model is close to how DAMA International describes the forces behind sustainable data management. It is also the version ChatGPT gives most often when asked.

The pillars are not built at the same time. That’s what turns them into a roadmap.

Pillar	What it covers	Built in
People	Executive sponsor, governance council, data owners, data stewards	Phase 2
Policy	Data classification, quality standards, access, retention	Phase 2
Process	Issue logging, quality checks, access requests, change control	Phase 3
Technology	Catalog, lineage, quality monitoring, access controls	Phase 4

You’ll also see 5-pillar, 3 P and 5 C versions. There’s no single standard list. They all describe the same work in different groupings; we cover each in the FAQs.

What should a data governance plan include?

A data governance plan includes eight parts: goals, scope, an operating model, roles, policies, data quality rules, tools and KPIs. Leave one out and the program usually stalls at that gap.

1. Business goals. Two or three outcomes tied to money, risk or speed. “Close the books 3 days faster” beats “improve data quality”.
2. Scope and priority domains. Which data you govern first, usually one or two domains such as customer or finance.
3. Operating model. How decisions get made: centralized, decentralized or federated.
4. Roles and RACI. Executive sponsor, governance council, data owners, data stewards and IT custodians, each with named people.
5. Policies and standards. Classification, access, retention and quality standards. Start with five or six, not fifty.
6. Data quality rules. Measurable rules for your critical data elements, with a baseline and a target.
7. Tools. What you’ll use for the glossary, catalog, lineage and quality monitoring, and when you’ll buy it.
8. KPIs. How you’ll prove the program works, reported to the sponsor every quarter.

Keep the plan short. A 10-page plan that people read beats a 60-page one nobody opens.

What should you decide before you start?

Make four decisions before phase 1: which domain goes first, which operating model you’ll use, which framework you’ll follow, and whether governance or MDM leads. Each one changes your timeline.

Which data domain should you govern first?

Start with the domain that hurts most and has the fewest source systems. You also need a business owner who will actually show up. For most mid-size companies, that’s customer data.

Score each candidate domain on three things:

• Pain: how often it causes wrong reports, failed audits or rework.
• Spread: how many systems hold it. Fewer is faster.
• Ownership: whether a business leader will sign off definitions.

From our work: A large US physical security and fire systems integrator had grown to 14+ subsidiaries through acquisitions. Customer accounts were duplicated and named differently in every subsidiary’s ERP. As one leader put it: “We had grown to 14 companies and still couldn’t answer a simple question.” That made customer data the obvious first domain, and the base for one governed data warehouse. For the full sequence after an acquisition, see our post-acquisition data consolidation playbook. Read the case study.

Should you use a centralized, decentralized or federated model?

Use a federated model unless you’re heavily regulated. A central council sets the standards. Each domain’s stewards apply them.

Model	How it works	Best for	Watch out for
Centralized	One central team makes every decision	Highly regulated firms such as banks and health systems	Bottlenecks; business units wait in line
Decentralized	Each business unit governs its own data	Small, independent business units	Definitions drift apart; cross-unit reports break
Federated	Central standards, domain-level execution	Most mid-size and large companies	Needs a strong council to settle disputes

Should you follow DAMA-DMBOK or DCAM?

Pick one framework as your reference and tailor it. Don’t try to implement either one in full.

• DAMA-DMBOK is the broad body of knowledge for data management. Use it to define terms, roles and knowledge areas.
• EDM Council DCAM is a capability assessment model. Use it if you need to score maturity, build a business case and report progress. It’s common in financial services.

Many teams use DAMA for vocabulary and DCAM for scoring.

Should data governance or MDM come first?

Governance comes first, and the two overlap. Master data management (MDM) without named owners and agreed definitions becomes an expensive copy of the mess you already have.

From our work: In an employee MDM and data governance engagement for a telecom group, we designed the governance framework, the golden record and the MDM platform evaluation together. Ownership and survivorship rules came first. Master data is a governance problem before it’s a technology problem. Read the case study.

What are the 5 stages of data governance?

The 5 stages of data governance are assess, design, pilot, scale and optimize. Together they take 12–18 months for a mid-size company. The phases overlap, but none should start until the one before it has passed its exit gate.

Video embed (paste as a Custom HTML block):

The durations below are planning ranges, not fixed rules. Heavy regulation, many legacy systems or part-time staff will stretch them.

Phase 1: Assess and align (weeks 1–6)

Phase 1 finds out what data you actually have, what it costs you, and who will sponsor the fix.

• Goal: Agree on the business problem, the baseline and the first domains.
• Duration: Weeks 1–6.
• Owners: Executive sponsor (accountable), data governance lead, enterprise architect.
• Deliverables: Stakeholder interviews (8–12 leaders), system inventory, maturity baseline, pain-point register, priority domains, business case.
• Exit criteria: A named sponsor, an approved business case and an agreed first domain.

Need a fast baseline? Algoscale’s free data maturity assessment scores you across 8 dimensions in about 4 minutes.

From our work: A telecom group told us its employee data lived in 13 systems. After checking each one with its platform owner, we found 9. Some “systems” were modules of the same platform. Two were reports, not sources. Fourteen attributes lived only in a spreadsheet kept by one person. Count your systems in writing before you plan anything else.

Phase 2: Design the operating model and standards (weeks 5–12)

Phase 2 decides who owns what and writes the minimum rules everyone follows.

• Goal: Stand up the people and policy pillars.
• Duration: Weeks 5–12, overlapping the end of Phase 1.
• Owners: Data governance lead (responsible), sponsor (accountable), domain data owners, legal, security and privacy (consulted).
• Deliverables: Governance charter, council, RACI matrix, named owners and stewards, 5–6 core policies, business glossary for the first domains, list of critical data elements.
• Exit criteria: The council has met, owners have accepted their roles, and core policies are approved.

Tie each policy to the rules you must meet: HIPAA for health data, the CCPA for California consumers, and BCBS 239 for banks’ risk data. The NIST Privacy Framework is a free checklist for the privacy side. Add GDPR only if you hold EU customer data.

From our work: For the same telecom group, we built one dictionary of 125 attributes across 10 domains. Every later deliverable — classification, quality rules, RACI, survivorship logic — referred to that one list. That’s how 19 deliverables shipped in 6 weeks. Parallel vocabularies are how governance frameworks quietly stop being used. Read the case study.

Phase 3: Pilot one domain (months 3–6)

Phase 3 proves the model works on real data before you ask anyone else to adopt it.

• Goal: Show a measurable improvement in one or two domains.
• Duration: Months 3–6.
• Owners: Domain data owner (accountable), data steward, data quality analyst, data engineering.
• Deliverables: Data quality baseline and rules, issue log and fix workflow, source-to-report lineage for key metrics, a pilot scorecard.
• Exit criteria: Quality has improved against the baseline, and the steward workflow runs without the project team pushing it.

From our work: We weighted completeness lower than accuracy in the telecom group’s quality score. A blank field is a caught error. A field that’s filled but wrong passes every check and spreads downstream. We also ran the rules in a simple Excel template before any platform was chosen. The tool can change later; the rules stay.

Phase 4: Scale across domains (months 6–12)

Phase 4 repeats what worked in the pilot, domain by domain, and adds tooling where manual work becomes too costly.

• Goal: Govern three or more domains with a repeatable onboarding process.
• Duration: Months 6–12.
• Owners: Data governance lead, domain owners, platform and security teams, training lead.
• Deliverables: Domain onboarding playbook, catalog and lineage coverage, role-based access controls, a governance check in project intake, training for owners and stewards.
• Exit criteria: Three or more domains live, and new projects pass a governance check before launch.

From our work: The College of Massage Therapists of Ontario (CMTO) had no catalog, no lineage and no access framework. Data sat in 7 SaaS platforms. We built a governed Azure and Microsoft Fabric lakehouse, aligned with Ontario’s health privacy law, PHIPA, with:

• Microsoft Purview catalog scanning and column-level lineage
• Role-based access for 61 named users across 6 roles
• A documented data quality rule catalogue
• 131 KPI definitions, each signed off by its business owner

Weekly data extraction dropped from 12 hours to 1. CMTO’s analytics maturity moved from level 1.5 to level 3, with a roadmap to level 4. Governance like this sits on top of a well-built lake; see our data lake consulting services. Read the CMTO case study.

Phase 5: Optimize and automate (month 12 onward)

Phase 5 turns governance from a project into normal operations, with as much of the checking automated as possible.

• Goal: Lower the manual cost of governance and prepare data for AI.
• Duration: Month 12 onward, with a quarterly review.
• Owners: CDO or data governance lead, platform team, risk and compliance.
• Deliverables: Automated quality and access controls, policy as code where it fits, quarterly maturity reviews, next year’s roadmap.
• Exit criteria: None. This phase runs for as long as the program does.

From our work: For a US insurer with more than $7B in revenue, we designed metadata and MDM capabilities into a single governed Data Hub. Standard definitions, lineage and decision matrices made the data ready for AI models and agents. Rationalization and migration timelines dropped by 30%. Read the case study.

Will AI replace data governance? No. AI already automates classification, lineage, metadata and quality monitoring. People still decide what use is acceptable, how much risk is fine, and who is accountable when data is wrong. Expect fewer manual tasks and more demand for people who design the controls.

How does MDM fit into a data governance roadmap?

Master data management runs as a parallel track inside phases 3 and 4. Governance defines the owners and rules. MDM then builds the golden record that applies them.

An MDM strategy roadmap usually follows five steps:

1. Profile the master domains. Customer, product, supplier, employee or location. Count duplicates and conflicts.
2. Agree on ownership and rules. Who owns each attribute, and which source wins when systems disagree (survivorship).
3. Design matching and the golden record. How records are matched, merged and given one ID.
4. Pick the implementation style and platform. See the table below.
5. Connect consuming systems and monitor. Feed the golden record back to CRM, ERP and analytics, and track match accuracy.

Video embed (paste as a Custom HTML block):

Which MDM implementation style should you use?

Style	How it works	Use it when
Registry	A hub stores links between records; sources stay untouched	You need a fast, low-risk start or a read-only single view
Consolidation	Data is copied into a hub and cleaned there for reporting	Analytics needs a golden record; operational systems can wait
Coexistence	Hub and sources both hold master data and sync both ways	You want clean data flowing back into operational systems
Centralized	The hub becomes the system of record; data is authored there	You need strict control and can change business processes

Most mid-size companies start with registry or consolidation, then move toward coexistence once owners trust the hub. For why skipping this layer breaks single-customer-view projects, read Customer 360 Without MDM Is Cosplay.

From our work: The security integrator’s customer accounts were duplicated across 14+ subsidiary ERPs. No off-the-shelf tool handled the naming mess out of the box. We built a lightweight MDM service on AWS Lambda with a 75+ brand dictionary and confidence scoring, backed by a PostgreSQL ledger (how the pattern works). It feeds canonical customer names into the governed data lake behind 20+ Power BI dashboards. Across the whole program, reporting prep time fell by more than 70%. Read the case study.

From our work: For the telecom group, we scored MDM platforms against explicit criteria: integration effort, time to first golden record, stewardship tooling, total cost and lock-in. A scored decision can be defended to procurement. A preference can’t.

How do you turn the roadmap into an implementation plan?

Break the roadmap into workstreams, give each one an owner and a target month, and review progress every two weeks. The roadmap shows when. The implementation plan shows who does what.

Data governance project plan by workstream

Workstream	Key activities	Owner	Target
Strategy and business case	Outcomes, scope, budget, sponsor	Data governance lead	Month 1
Operating model	Charter, council, RACI, owners and stewards	Data governance lead	Month 2
Policies and standards	Classification, access, retention, quality standards	Council	Month 3
Glossary and metadata	Business terms, critical data elements, source systems	Data stewards	Months 3–5
Data quality	Baselines, rules, thresholds, issue workflow	Data quality analyst	Months 4–6
Pilot domain	Run governance end to end in one or two domains	Domain owner	Months 4–6
Tooling	Catalog, lineage, quality monitoring, access controls	Platform team	Months 4–9
Enterprise rollout	Onboard more domains; add a governance check to project intake	Data governance lead	Months 7–12
Continuous improvement	KPI reviews, maturity check, next year’s plan	Sponsor and council	Month 10 onward

Workstreams overlap. Stewards can start the glossary before every policy is final.

Who you need, and how much of their time

These are planning assumptions for a company of 500–5,000 people. Regulated or complex companies need more.

Role	Main job	Time
Executive sponsor	Funding, unblocking, settling disputes	2–4 hours a month
Data governance lead	Roadmap, council, policies, reporting	0.5–1 FTE
Data quality analyst	Profiling, rules, scorecards	0.5–1 FTE
Data owners	Accountable for each domain’s definitions and quality	2–4 hours a month each
Data stewards	Day-to-day definitions and issue fixes	10–20% of their role
IT, security, privacy	Technical controls and compliance advice	Part-time, as needed

Write steward time into job descriptions. Unpaid governance work is the first thing people drop.

What are the data governance implementation steps for the first 90 days?

Video embed (paste as a Custom HTML block):

In the first 90 days, align leaders, assign ownership and get the pilot ready to run. By day 90 you should have a working council and a pilot backlog, not just policy documents.

Days 1–30: Align and prioritize

1. Name the executive sponsor and the program lead.
2. Interview 8–12 business and technology leaders.
3. Inventory critical systems and confirm each one in writing with its owner.
4. Pick the first domain and its success metrics.

Days 31–60: Assign ownership

1. Approve the governance charter and decision rights.
2. Name the first data owners and stewards.
3. Draft the core policies and the RACI matrix.
4. List the pilot domain’s critical data elements.

Days 61–90: Get ready to run

1. Approve business definitions and the first quality rules.
2. Measure baseline quality and open the issue log.
3. Map lineage for the pilot’s key reports.
4. Approve the pilot backlog, resources and milestones.

Data governance plan example: a mid-size US company

Here is a 12-month plan for an illustrative company. It’s a composite, not a client. Copy the table and swap in your own domains, owners and dates; it works as a starting data governance roadmap template.

The company: a 1,500-person US industrial distributor. It runs an ERP, a CRM and an e-commerce platform. Customer records are duplicated across all three. Finance and sales report different revenue every month. The CFO sponsors the program.

Month	Phase	Milestone	Owner	KPI checked
1	Assess	10 leader interviews; system inventory confirmed in writing	Governance lead	Systems confirmed vs listed
2	Assess / Design	Business case approved; customer data chosen as first domain	CFO (sponsor)	Funding approved
2–3	Design	Charter, council and RACI approved; owners and stewards named	Governance lead	% of customer elements with an owner
3	Design	Definitions agreed for “customer”, “active customer” and “revenue”	Customer data owner (VP Sales Ops)	Definitions signed off
4	Pilot	Quality baseline for 40 critical customer fields	Data quality analyst	Baseline quality score
4–6	Pilot	Duplicate customers matched and merged; issue log running	Customer data steward	Duplicate rate; open issues
6	Pilot review	Pilot scorecard to the council	Governance lead	Quality score vs baseline
7–9	Scale	Finance and product domains onboarded with the same playbook	Domain owners	Domains live
8–10	Scale	Catalog and lineage for the monthly revenue report	Platform team	Lineage coverage of key reports
10–12	Scale	Governance check added to new project intake	Council	% of new projects checked
12	Optimize	Maturity review and year-2 roadmap	Sponsor and council	Maturity level vs baseline

Notice what’s missing: no tool purchase before month 8. The company buys a catalog once lineage work becomes too costly to do by hand.

Which KPIs show data governance is working?

Measure whether data got more trusted, not how many policies you wrote. Set a baseline first, then agree targets with the business.

The targets below are illustrative 12-month goals for a pilot domain, not industry benchmarks.

KPI	How to calculate	Illustrative target
Ownership coverage	Critical data elements with a named owner ÷ all critical elements	90%+ in pilot domains
Definition coverage	Critical elements with an approved definition ÷ all critical elements	90%+ in pilot domains
Data quality score	Weighted pass rate of quality rules on critical elements	+10 points over baseline
Issue resolution time	Median days from issue logged to fixed	Down 30% from baseline
Duplicate rate	Duplicate master records ÷ all master records	Down 50% in the pilot domain
Sensitive data classified	In-scope sensitive fields classified ÷ all in-scope sensitive fields	100%
Report reconciliation effort	Hours spent each month reconciling key reports	Down 30%

Weight accuracy above completeness in your quality score. A 95% score can still hide wrong balances in the 5% that matters.

Why do data governance roadmaps fail?

Most roadmaps fail because ownership was assumed instead of assigned. The rest fail from trying to do too much, too soon. Data lakes fail the same way; see the 3 failure modes that turn a lake into a swamp. Here are the seven mistakes we see most, and the fix for each.

1. Ownership assumed, not assigned. Teams “know” who owns a field until two systems disagree. Fix: name an owner for every critical data element in Phase 2 and get it in writing.
2. Governing everything at once. A program that covers every domain finishes none. Fix: pilot one or two domains and prove value first.
3. IT owns it alone. IT can enforce rules but can’t decide what “active customer” means. Fix: put business owners on the council and make them sign off definitions.
4. Buying a catalog in month one. A tool with no owners and no definitions becomes an empty catalog. Fix: buy tools in Phase 4, when manual work gets too costly.
5. Policies with no enforcement. A policy no one checks is a suggestion. Fix: give every policy an owner, a workflow and a measure.
6. No time for stewards. Governance added on top of a full job gets dropped. Fix: write steward time into roles and goals.
7. No business metric. “Better data quality” doesn’t get funded twice. Fix: report one money, risk or speed metric to the sponsor every quarter.

From our work: Most programs that fail during the build fail because ownership was assumed in the design phase. That’s why we name owners for every attribute domain, through a RACI and a council charter, before any MDM build starts.

Which data governance tools do you need at each phase?

Buy tools in the phase that needs them, not before. Spreadsheets carry Phases 1–3 for most companies. Catalogs and lineage tools earn their cost in Phase 4.

Phase	What you need	Example tools
1–2: Assess and design	Inventory, glossary, RACI	Spreadsheets, Confluence, SharePoint
3: Pilot	Data quality rules and monitoring	Great Expectations, dbt tests, Soda
4: Scale	Catalog, lineage, access control	Microsoft Purview, Collibra, Alation, Databricks Unity Catalog
4: MDM track	Matching, golden record, stewardship	Informatica MDM, Profisee, Reltio, or a custom service
5: Optimize	Observability, policy automation	Monte Carlo, platform-native access policies

Match tools to your platform. If you run on Azure, Purview fits naturally. On Databricks, start with Unity Catalog. Mixed estates often need an independent catalog.

Start with one domain, not the whole company

A data governance roadmap works when it starts small and earns the right to grow. Pick one domain. Name its owner. Measure the baseline. Prove the pilot. Then scale.

That’s the pattern behind the programs in this guide, from CMTO’s governed lakehouse to a 14-company integrator’s single customer view. The tools differed. The order didn’t.

Need help building yours? Algoscale’s data governance consulting services cover assessments, operating model design, MDM evaluation and the build. Tell us which domain hurts most, and we’ll show you where to start.

Frequently Asked Questions