Data governance readiness checklist

Why run this

What this checklist is for

Examiners ask four things consistently: who approved this, on what information, when, and can you show the control operated throughout the period. Each is answerable instantly if the evidence was captured in the flow of work.

An analytics platform without lineage produces numbers that are correct and undefendable. In a regulated institution that is functionally the same as being wrong.

Run it with

CDO, CFO or Head of Risk

And with

Data platform architects and engineers

And with

Compliance officer

The checklist

20 checks, in the order we would run them

Tick only what you can genuinely evidence today. An item you intend to do is not an item you have done, and scoring yourself generously here only produces a comfortable number and an uncomfortable project.

Section 1

Definitions and ownership

The least technical section and the one that decides everything else.

Every published metric has a written definition and a named ownerTwo functions that cannot agree what a customer is will never reconcile their reports, regardless of architecture.
A change process exists for altering a metric definitionDefinitions change legitimately. Undocumented change is what makes historical comparison meaningless.
The data dictionary is accessible to the business, not only to engineersA dictionary only the data team can read does not settle arguments between departments.
Critical data elements identified and prioritised for quality monitoringYou cannot monitor everything. Deciding what matters is a governance act, not a technical one.
Somebody is accountable for data quality, distinct from whoever builds pipelinesThe builder and the assurer should not be the same person. Examiners notice when they are.

Section 2

Lineage and traceability

What turns an internal report into something a board committee can act on.

Any published figure can be traced back to its source transactionNot approximately. Specifically, through every transformation, to the originating record.
Bronze layer holds source data untransformedThis is what lets you prove what the source actually said, separately from what you did with it.
Transformation logic is version controlled and reviewableA calculation nobody can inspect is a calculation nobody should rely on.
Reconciliation to the general ledger runs and is checked, not just builtA reconciliation with a non-zero residual that nobody looks at is worse than none, because it implies assurance.
Late-arriving and restated data are handled explicitlyRestatements happen. Whether your platform handles them or silently overwrites history is a question you want answered before an examination.

Section 3

Access and protection

Who can see what, and whether you can evidence it.

Row-level security applied and tested with real role accountsTested with an account of each role type, including one that should see nothing. Not with the designer's account.
Workspace access audited — contributors bypass row-level securityThis is the configuration error that produces incidents. Report consumers should hold Viewer access only.
Sensitive data classified and labelled in the platformClassification applied at the data layer travels further than classification applied at the report layer.
Access reviews run on a schedule with recorded outcomesA review that changed nothing still needs a record showing it happened. Otherwise it did not.
Data exfiltration paths considered, including export to ExcelRow-level security controls what a report shows. It does not stop somebody exporting what they can see.

Section 4

Operations and cost

Whether the platform is sustainable as well as compliant.

Capacity consumption is monitored with alertingConsumption-based compute behaves differently from licensed software. An inefficient notebook is expensive in a way a licence never was.
Refresh failures alert somebody who acts, within an agreed windowA silently failed refresh produces a report that is confidently out of date.
Retention applied to analytical data, not only to operational systemsAnalytical copies of regulated data carry the same obligations as the originals and are frequently overlooked.
A disaster recovery position is defined for the analytics platformAnalytics is usually classified as non-critical until a board pack cannot be produced.
Documentation would let a new engineer understand the platform without youTest this by asking somebody new to trace one figure end to end using documentation alone.

What your score means

Read this against the number above

These bands are deliberately blunt. The middle band is where most organizations honestly sit, and it is a perfectly reasonable place to proceed from — provided the gaps are written down with owners rather than carried as optimism.

0–59%Significant gaps

Do not proceed yet. More than four in ten items are unaddressed, and the ones that fail here are usually the foundational ones that make everything after them harder.

60–84%Mostly ready, with known gaps

Proceed on a defined scope, with the outstanding items written into the plan as risks with owners and dates. This is the most common honest position.

85–100%Ready

The remaining gaps are small enough to handle during delivery rather than before it. Confirm the unticked items are genuinely minor rather than simply unexamined.

Your score highlights automatically as you tick items above. Nothing is saved, sent or tracked — refreshing the page clears it.

Closing the gaps

If you could not tick these, start here

The four items below are the ones whose absence causes the most trouble downstream. If your unticked items include any of these, they are worth addressing before the rest.

Metrics have no owner

Start here. This is a governance decision that costs a workshop, and no amount of platform engineering compensates for skipping it.

No end-to-end lineage

Prioritise it for your regulatory reporting figures first. Full coverage can follow; the reported numbers cannot wait.

Workspace roles not audited

Check this today. Contributors seeing all rows despite row-level security is the most common cause of an access incident in Power BI.

Capacity not monitored

Enable it before the next invoice rather than after. Consumption surprises are avoidable and they damage confidence in the platform.

Want a second opinion on your score?

We will assess your current platform against these controls and produce a prioritised remediation plan mapped to the specific questions your examiner asks.

Talk through your result Read the related guides We reply to every message within one business day.

Keep going

Related checklists

d365-sales

financial-servicesReadiness

CRM data quality audit

Twenty checks on whether your customer data supports the pricing, risk and cross-sell decisions being made from it.

April 4, 2026 · 20 checksOpen

purview

financial-servicesReadiness

Communication supervision readiness

Twenty checks before turning on supervision, covering scope, privacy and whether the review queue is workable.

March 14, 2026 · 20 checksOpen

What this checklist is for

Run it with

And with

And with

20 checks, in the order we would run them

Definitions and ownership

Lineage and traceability

Access and protection

Operations and cost

Read this against the number above

If you could not tick these, start here

Metrics have no owner

No end-to-end lineage

Workspace roles not audited

Capacity not monitored

Want a second opinion on your score?

Related checklists

CRM data quality audit

Communication supervision readiness

Tell us what you're trying to fix

Let’s get started on something great

Phone

Email