Data governance implementation: A 30/60/90 day playbook
Contents
Data governance implementation rarely fails for lack of a framework. It fails in the months after kickoff, when policy documents pile up faster than anyone enforces them. What decides the outcome is sequencing: which decision rights you assign first, which datasets you govern first, and which tools you hold back until the organization is ready to use them.
This playbook covers the phased plan, a RACI structure you can adapt, tool choices, the metrics to watch, and the points where programs most often stall.
The 30/60/90 day data governance rollout plan
A 30/60/90 day rollout plan uses a 90-day horizon on purpose. It's long enough to put real controls on one data domain and short enough that the executive who sponsored the program is still paying attention when the first results arrive.
The checkpoints:
- Day 30: a chartered data governance council, owners and stewards assigned against a RACI matrix, and the first entries in a data catalog.
- Day 60: data quality rules and lineage tracking running on the pipelines the council marked as high-risk.
- Day 90: access control policy tested against real entitlements, open exceptions closed, and steward adoption reported back to the council.
Why stage it at all? Gartner predicts that by 2027, 80% of data and analytics governance initiatives will fail due to the lack of a real or manufactured crisis (Gartner, 2024).
"A D&A governance program that does not enable prioritized business outcomes fails," as Gartner VP Analyst Saul Judah put it when the prediction was published. A checkpoint with a visible result every 30 days is one way to create that sense of urgency without waiting for an audit failure to do it for you.
Treat the timeline as a default. A bank or insurer with a heavy change-approval process may need 45 days per phase, and a 200-person scale-up can move faster. Keep the phases in this order, whatever their length.
If you need the framework components themselves (catalog, role-based access control, metadata and master data management), start with our guide to building an AI-ready governance framework. This article picks up where that one ends, with putting the framework into operation.
Days 1-30: Scoping, sponsorship, and the governance council
Lock in executive sponsorship during the first week. The sponsor should be a named Chief Data Officer, or a VP with real budget authority, who signs a one-page charter before the data governance council's first working session. Without that signature, business units tend to file governance under "IT project" and give it the attention that label usually gets.
Getting the signature is easier if you:
- Tie the program to a problem the sponsor already owns, such as a failed audit, a regulatory deadline, or a board report built on figures nobody fully trusts.
- Put a number on the pilot domain: hours spent on manual reconciliation, report rework, or access requests stuck in a queue.
- Ask for a standing 15-minute monthly slot where the sponsor sees the program's metrics. It keeps governance on their calendar after the launch meeting.
Keep the charter short: scope, decision rights, and the one domain where the program will prove its value. Pick a domain that hurts but has clear edges, such as customer master data or a single finance data mart. An enterprise-wide first scope usually turns the council into a policy-drafting committee.
By around day 15, name the council's core members and sketch a draft RACI matrix that separates data owner from data steward responsibilities.
DAMA-DMBOK describes the split this way: owners are accountable for decisions, stewards manage day-to-day quality and definitions, and custodians handle the technical side (OvalEdge summary of DAMA-DMBOK).
The council itself should include the business, so a compliance lead, a domain owner and an engineering lead make a reasonable starting trio.
Expect the first cracks to be cultural. A Gartner survey of 223 data and analytics leaders, run in March 2026, found that cultural resistance outweighs funding constraints as the primary reason governance initiatives fail, by 60% to 40% (Gartner, 2026). In practice, that often looks like a sponsor who signs the charter and then sends a deputy who can't approve anything.
A realistic day-30 target is a chartered data governance council, a named sponsor, one prioritized domain and a draft RACI matrix. A finished catalog isn't on the list yet.
Days 31-60: Rolling out data quality rules and lineage tracking
The second month turns the charter into infrastructure. Data quality rules go live on the pipelines the council flagged as high-risk, data lineage tracking is wired into the same pipelines, and the data catalog starts filling with metadata stewards can search. Most of this is data engineering work, because the rules and lineage hooks have to live inside the pipelines to be enforced.
We'd suggest tracking time-to-first-catalog-entry from day 31. If the catalog is still empty in week five, treat it as an early warning and ask why before the next council meeting.
Set a data quality SLA for each tier from the start. Gold datasets, the ones feeding finance and compliance reporting, get same-day remediation and automated freshness alerts, while bronze datasets used for exploration get a weekly batch check. A single SLA across the whole catalog tends to bury stewards in alerts for data nobody depends on.
This is also the right moment to choose tools, now that you know which pipelines and datasets matter. Useful criteria are fit with the existing data platform, API extensibility, how willing stewards are to use the interface every day, and cost against the business case in the charter.
Roll business units onto the program in the order the council set in the first month. Collibra recommends the same incremental approach, starting with one domain or a subset of assets and expanding from there (Collibra, "From pilot to payoff").
Watch the steward role closely in this phase. When it's unfilled or treated as a side task, lineage output goes unread and access exceptions pile up without an owner. Writing stewardship into someone's performance objectives, and bringing security into the access sign-off early, prevents most of that.
Days 61-90: Access control review and entitlement cleanup
The third month moves the program from building to enforcing. Every access control policy is tested against real entitlements, and every dataset is checked against its data classification tier.
Access reviews often stall after the first audit: permissions get pulled, the mess gets documented, and nobody closes it. Measure this phase by the number of exceptions closed. A workable review:
- Pulls every entitlement on the pilot domain's gold datasets.
- Compares each one against the data owner's approved access list.
- Logs every mismatch as an exception.
Typical exceptions are a user with access beyond their classification tier, a service account with stale credentials, or a gold dataset readable by a team with no business need. Each one gets a named owner and a resolution date. Gold-tier exceptions should close within the phase; bronze-tier ones can wait for the next quarterly review.
Tier approval chains the same way, with stricter sign-off for financial and customer data. Before a dataset's access tier locks in, its steward confirms the classification is right. It's also worth checking that the policy is usable. People route around access rules they can't work within, and the workarounds are harder to see than the original problem.
By day 90, aim for a written access control policy, a classification scheme mapped to every catalog entry, and a closed exception list the council can bring to the next compliance review.
Who owns what: RACI for the CDO, owners, stewards, custodians, and council
Confusion between data owner and data steward is one of the most common reasons governance programs lose momentum, so give each role its own decision rights.
The Chief Data Officer owns the program as a whole: policy, budget, and the objectives the council reports against. The data owner is a business role, usually a VP or department head, accountable for what a dataset should contain, who can access it, and how it's classified and retained.
The data steward does the operational work of enforcing quality SLAs, tagging lineage and chasing exceptions. Custodians sit in IT or platform engineering and look after storage, pipelines, encryption and security configuration. The council arbitrates between business units and sets policy.
| Role | Owns | Reports to |
|---|---|---|
| Data owner | Data definition, access approval | Governance council |
| Data steward | Data quality, catalog accuracy, lineage tracking | Data owner |
| Custodian | Storage, pipelines, security controls | IT/platform lead |
| Governance council | Policy, escalation, cross-business arbitration | CDO or sponsor |
The table above describes roles. For a RACI to hold up in practice, each recurring decision also needs exactly one accountable role. A starting point for decisions that come up in the first 90 days:
| Decision | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
| Approve the governance charter | CDO | Executive sponsor | Council | Business units |
| Grant an access exception | Data steward | Data owner | Custodian | Council |
| Override a data quality SLA | Data steward | Data owner | Consumers of the dataset | Council |
| Onboard a new dataset to the catalog | Data steward | Data owner | Custodian | Analysts |
| Change a governance policy | Council | CDO | Data owners | All data users |
The bigger structural choice is centralized versus federated stewardship. A central team with authority over every dataset is quicker to launch, but becomes a queue once you're past a handful of domains. Stewards embedded in each business unit scale better, although they need a council with enough authority to keep standards consistent.
Our view: start centralized for the first 90 days and federate once catalog coverage and access enforcement are stable. A data mesh organization with strong domain teams can often federate from the start.
Which tools do you need: Catalog, lineage, quality, access
A data governance implementation needs coverage in four areas: catalog, lineage, quality and access control. That doesn't mean four purchases. Many teams buy a catalog, get lineage from it or build it, and enforce quality and access through the pipelines and identity systems they already run.
Alation, Collibra and Atlan are common names on enterprise catalog shortlists. The decision usually comes down to metadata scale and fit with your existing stack.
Atlan is often chosen for its integration with the modern cloud data stack, while Collibra and Alation are frequent picks in regulated organizations with mature compliance programs. If the tooling question is tangled up with a wider one about where your data platform is heading, settle the data strategy first.
For data lineage tracking, check what your catalog ships with first. Most modern catalogs offer column-level lineage for SQL-based pipelines, which is usually cheaper than maintaining custom parsers against every ETL job. Building your own makes sense when much of your transformation logic lives outside tools the catalog can parse, such as in custom Spark jobs or stored procedures.
If your transformations already run in dbt, its lineage graph is a reasonable starting point either way.
Quality and access work best as policy enforced in code. Tier datasets gold, silver or bronze and set checks to match. Gold data (finance, regulatory reporting) gets automated freshness and completeness checks with paging alerts, and bronze data gets a weekly batch check with no on-call commitment.
Route access control through your existing IAM where you can. A dedicated access tool starts to earn its cost when you need attribute-based rules, such as "analysts in the finance department can read gold finance tables, with customer PII masked". Role-only systems would need a separate role for every such combination.
Where implementations fail, and how to fix it
Most stalls trace back to council cadence, steward accountability or enforcement mechanics.
Cadence tends to erode without anyone deciding to stop it. The council meets weekly in the first month, biweekly in the second, and some time in month three the meeting stops appearing on calendars. The catalog is populated and the RACI is signed off, so everyone assumes the program will run itself, and nobody is left reviewing exceptions or missed SLAs.
Steward accountability erodes in a similar way. Owners and stewards are named in the charter, but nobody ties steward hours to a performance objective, so stewardship becomes unpaid overtime and adoption drops.
The fix for both is to move enforcement out of meetings and into pipelines. Encode access control policy and data quality SLA thresholds as policy-as-code and check them on every pipeline run. A quarterly committee review finds the same problems months later. The same approach helps with master data drift: golden-record rules enforced in code keep working when a steward is on leave.
If the council is already losing momentum at around day 45:
- Ship one quick win, such as closing the oldest open access exception or fixing the quality issue analysts complain about most, and announce it.
- Get the sponsor back into one meeting to re-confirm the charter's priority domain.
- If the sponsor has left, re-sign the charter with a new one before doing anything else. A program without a sponsor loses its budget sooner or later.
- Reduce the cadence instead of cancelling it. A fixed 30-minute biweekly agenda built on the metrics below is easier to sustain than a weekly meeting nobody attends.
Longer term, give the program a maintenance budget and an owner after day 90. Governance that is funded as a one-off project tends to stop when the project does.
Measuring whether governance is working
Watch steward adoption, SLA compliance and exception closure, and start tracking all three at launch.
Steward adoption usually moves first. If stewards aren't tagging fields, resolving quality flags or attending council reviews by the end of the first month, the program is in trouble, however complete the catalog looks.
Report SLA compliance per tier. A missed gold-tier SLA deserves attention, while a missed bronze-tier check usually doesn't, and a combined figure lets the noise from low-value datasets hide the failures that matter.
For exception closure, track the open count weekly against the RACI matrix and the access control policy it enforces. Exceptions tend to cluster where accountability was left vague during rollout, so a rising count points you to the part of the RACI that needs work. It's also a sign the data governance council may have stopped acting as an escalation body.
FAQ: Data governance implementation
What are the top 5 data governance tools?
What are the five pillars of data governance?
What are the four main roles in data governance?
What is the data governance salary?
Get help planning your governance rollout
The hardest part of a governance rollout is usually deciding who has authority: who sits on the council, who breaks ties between business units, and who owns the budget once the pilot is over.
If you'd like a second opinion on council composition, RACI ownership or which access control tradeoffs to prioritize, we can help you plan a rollout that lasts beyond the first 90 days. Talk to our data team about your rollout.
Once governance is in place, the same data can support new use cases, such as real-time personalization, self-service analytics and instant answers for customers. If that's next on your roadmap, you can add AI to your product on top of governed data. Scaling those capabilities reliably depends on solid data foundations, so it's worth getting that groundwork right first.
