[A companion to the Demystifying Data Governance series]

Every data governance program claims to know its own state. However, many cannot even answer a simple question like, “How many tables do you have?” and we usually get a pause, then an estimate, then a qualification about which environments count. That pause is the finding.

This article is a checklist for surfacing the gap between what a program claims and what it can actually answer. It is organized around the four pillars the Demystifying Data Governance Series is built on — know the data, secure the data, use the data properly, and improve data quality — plus a closing section on business value, the part most checklists leave out.

The checklist is built to be timeless. Tools, vendors, and regulations may evolve, and the technology could become unrecognizable in a decade. Yet, the fundamental question remains: “How many people can read customer PII, and for how long have they had that access?” is a question worth asking in 2026, and it will be just as sharp in 2036, regardless of which catalog, cloud, or model we are running. The checklist asks what to know, not which tool to use to know it. Run it once a year against whatever our environment has become, and it still works.

A few things this checklist is not. It is not a score — there is no rating out of ten at the end. It is not a maturity model — there are no levels to climb. It is not a compliance audit — passing it satisfies no regulator. Its only purpose is diagnostic: to help an honest program notice the questions it cannot answer, because those are precisely the places it is blind.

Table of Contents

How to Use This Checklist

Before the questions, five ground rules. They are what separate a checklist that surfaces truth from one that produces comfortable nodding.

If we cannot answer a question, that is the finding. An honest “I don’t know” is more valuable than a confident guess, because it marks exactly where the program cannot see itself. Do not skip the questions that are uncomfortable to answer — those are the ones doing the work.

Demand specific answers. The list is only useful when answers are concrete: a number, a date, a name, a documented policy. “Yes, we classify data” is not an answer. “94% of datasets are classified; the last full pass ran on the 3rd of this month; here are the 41 that are not” is an answer. If the response to a question is a sentence with no number, date, or name in it, treat the question as unanswered.

Run it with the people who touch the data. Doing the checklist alone gives us our own mental model of the program, which is exactly the thing most likely to be wrong. Run it with the engineers who build the pipelines, the analysts who query the tables, the owners who are accountable for them. The gaps between our mental model and theirs are where the real risk lives.

Write the answers down. This is the step that converts a one-time exercise into a measurement. The answers become the baseline. A year from now, we compare. Gaps that have closed are real, demonstrable progress. Gaps that have stayed open tell us which parts of the program are structurally stuck — starved of attention, owned by no one, or genuinely hard.

Prioritize by risk and leverage, not by count. The output is a list of gaps, but not all gaps are equal. A missing description on a low-traffic internal table is not the same finding as a missing classification on a table full of customer PII. The goal is to surface gaps, not to generate a to-do list where every item carries the same weight. The closing section explains how to triage.

Note on target bands included with some questions: when the math is solid, a range indicates what a healthy or concerning answer looks like. These bands are based on current practice and serve as guidelines, not strict standards. If an answer depends heavily on context, the question remains open. Our environment defines the target, and the checklist ensures we measure against it.

Pillar 1: Know the Data

We cannot govern what we don’t know. This pillar is the foundation — every other pillar depends on the answers here being real.

Inventory

How many datasets — tables, files, streams, topics — do we have, across every environment? Count production, staging, development, analytics, and any cloud or region that holds data. A single number we can defend is the goal.
How confident are we in that number? What fraction of the estate is systematically discovered and cataloged, versus estimated or remembered? Target band: a healthy program can account for 90%+ of its estate through automated discovery rather than memory. Below 70% means the inventory is largely guesswork.
When did the most recent full discovery scan run, and what did it find that was not already in the catalog? A scan that never surfaces anything new is either perfectly comprehensive (rare) or not really running (common).
How frequently does discovery run — continuously, on a schedule, or on demand? In an environment where new tables, pipelines, and AI-generated datasets are constantly appearing, a quarterly manual scan is already behind.
How many datasets have no owner? Target band: critical and sensitive datasets should be at 100% ownership coverage. Any unowned dataset that contains sensitive data is a finding in itself.
How many datasets have not been read or written in the last 12 months? Are they still needed, or are they unmonitored risk and unnecessary cost? Stale data nobody uses is data nobody is watching.
How fast is the estate growing, and how much of that growth is AI-generated? Logs, embeddings, model outputs, agent traces, and synthetic data are now among the fastest-growing categories. Is governance coverage growing at least as fast as the estate? If coverage rises more slowly than the estate grows, the program is losing ground even as the absolute numbers improve.

Sensitivity and Classification

Where does sensitive data — personal, health, financial, confidential — actually live? Can we produce the list of datasets in each sensitivity class?
What fraction of the estate has been classified? Target band: sensitive-data coverage should approach 95% or higher. A large gap here means access policies built on classification are operating on incomplete information.
When did the last classification pass run, and is classification continuous, scheduled, or on demand? Classification that runs once and is never re-run goes stale the moment a schema changes.
Do we know of any datasets that contain sensitive data but have not been classified? If the honest answer is “probably, but we don’t know which,” that is the finding.
How do we detect when sensitive data appears somewhere new — a new table, a new environment, or an existing table that has quietly taken on a new field that holds personal data? A pipeline that starts capturing a phone number tomorrow should trigger something today.
Do we account for combinatorial sensitivity — fields that are not sensitive on their own but identify a person in combination, such as postal code plus birth date plus gender? Classification that only looks at fields one at a time misses this.

Lineage

For our most important datasets, do we know where the data comes from and where it goes — the upstream sources and the downstream consumers?
What is our overall lineage coverage? For what fraction of datasets can we trace both directions? Target band: critical production datasets should be near 100%. A program that can only trace lineage for a minority of its estate cannot answer the two questions below.
If an upstream source produced wrong data for a day, could we name every downstream dashboard, report, and model that consumed it? This is the question that determines how fast a data-quality incident can be contained.
If a customer requests deletion, can we trace every place their data has propagated — derived tables, backups, exports, analytics copies, and model training sets? A deletion that stops at the source table is not a deletion.
Do we track model lineage — which datasets trained which models, at which version? If sensitive data were in a training set and consent is later withdrawn, can we even tell which models are affected?

Metadata, Ownership, and Documentation

For our most important datasets, does the catalog hold a human-readable description that someone other than the author can understand?
Do business terms have consistent definitions across teams? When “active customer” means one thing to finance and another to product, which is right, and what is the process when they conflict?
Is the catalog the default place people go to find data, or do they ask a colleague? If the real catalog is a senior engineer’s memory, the program has a single point of failure.
When was catalog ownership last reviewed for drift — owners who have left, teams that have reorganized, datasets whose listed owner no longer recognizes them? Target band: ownership records reviewed at least annually; for sensitive datasets, at least quarterly.

Pillar 2: Secure the Data

Knowing the data makes this pillar possible. The questions here are the ones most likely to produce an uncomfortable silence — which is exactly why they matter.

Access

Who can read sensitive data today? Can we produce that list on demand, in minutes? Not “can we eventually assemble it” — can we answer now?
How many people currently have access to customer PII? A specific number. If it is larger than expected — and it usually is — that gap is the finding.
For each of those people, how did they get that access, and for what stated purpose? Access without a recorded reason is access that nobody can justify in an audit.
How long has each person had access to PII, and when did they last use it? Access granted three years ago for a project that ended two years ago is pure standing risk.
How many access grants are dormant — unused in the last 90 days but still active? Target band: under 15% dormant is healthy. Above 40% means access is granted and never reviewed — the program practices “grant once, never revoke.”
When did the last access review happen, and what percentage of access was revoked as a result? A review that revokes nothing, every time, is not a review.
Do we practice least privilege, or do we practice “grant broadly, revoke never”? The honest answer is visible in the dormant-access number above.

Authentication and Authorization

Do we require multi-factor authentication for all access to production data? A yes/no with no exceptions, or a list of the exceptions.
Are service accounts scoped narrowly, or do they carry broad permissions — often inherited from whoever created them? Overprivileged service accounts are among the most common vectors for breaches.
Do AI agents and automated systems run under their own scoped identities, or do they inherit the permissions of the person who built them? An automated system that can reach everything its creator can reach has a blast radius far larger than its task requires.
Do our access policies reference data classes (“analysts may not read PII”) or specific tables and columns? Policies tied to classes apply automatically to new data, whereas policies tied to named tables become outdated the moment the estate changes.
When someone joins a team, how long does it take for them to have the access they need? When someone leaves or changes roles, how long does it take for unneeded access to be revoked? Target band: Revocation on role change should be same-day. A gap of weeks between departure and de-provisioning is a standing exposure.

Encryption

Is sensitive data encrypted at rest everywhere it lives — including backups, archives, analytics copies, and disaster-recovery replicas? Encryption that covers the primary store but not the backup is a false sense of security.
Is data encrypted in transit between every service that handles it, not just at the public edge?
Where are the encryption keys held, who can access them, and how often are they rotated? A dataset encrypted with a key that a dozen people can read is not meaningfully protected.
Would we notice if an encryption key were accessed outside its normal pattern?

Audit

Do we have an immutable audit trail of access to production-sensitive data? Immutable, meaning the people being audited cannot alter it.
How long is the audit log retained? Long enough to cover the window a regulator or an investigation would ask about?
Could we reconstruct, after the fact, exactly who accessed a specific dataset on a specific day, and for what stated purpose? This is the question every breach investigation begins with.
Would we notice anomalous access — unusual volume, unusual time of day, unusual geography, a service account suddenly reading tables it never touched — within a useful window? Detection that arrives a quarter late is detection that did not happen.

Incident Readiness

If a single credential were compromised right now, how much data could the attacker reach before being detected and stopped? This number is the practical definition of blast radius. The smaller it is, the better the least-privilege principle is working.
When did we last test incident response for a data-breach scenario, as a drill rather than a real emergency?
Do our exfiltration controls — egress monitoring, outbound restrictions, data-loss prevention — actually work today, or were they configured for an architecture we have since replaced? Controls that silently stop applying when a system changes are worse than no controls because they create false confidence.
If we had to notify regulators of a breach within 72 hours, could we determine the scope in time? The answer depends entirely on the lineage and audit answers above.

Pillar 3: Use Data Properly

Authorized access is not the same as appropriate use. This pillar asks whether data is used for the purposes for which it was collected — a question that access controls alone cannot answer.

Purpose and Consent

Is the purpose of use documented for each sensitive dataset? Why do we hold this, and what are we allowed to do with it?
When a person grants consent, is that consent record linked to the specific datasets that rely on it? Consent stored in a system that cannot be joined to the data it governs is consent we cannot act on.
When consent is withdrawn, does the withdrawal propagate to every downstream system that used the data — and how do we know it did? “We update the source record” is not enough if the data has already flowed into derived tables, exports, and models.
Are consent records treated as first-class, queryable data, or are they buried somewhere, making “show me everyone who withdrew consent” a multi-day project?

Deletion and Retention

If a user exercises a deletion request today, can we complete it end-to-end within the regulatory deadline? Target band: deletion SLA compliance should be at least 95%. Below that point are lineage gaps (we cannot find the data) or ownership gaps (we cannot find who deletes it).
Do we have retention policies that are written down, tied to data classes, and actually enforced — not just documented in a wiki nobody reads?
What fraction of our data is past its retention window and should already have been deleted? Data kept past its policy period is subject to retention fees and has no offsetting value.
Are there copies of sensitive data in places the retention policy does not reach — analytics sandboxes, personal laptops, spreadsheets, third-party tools, AI training sets? Shadow copies are where deletion and retention quietly fail.

AI and Automated Use

These questions are phrased at the level of principle, so they survive whatever the technology becomes. The specific systems will change; the questions will not.

Are the models we train governed as carefully as the data they are trained on? A model is a derived artifact of its training data and carries that data’s sensitivity.
If sensitive data were in a training set, do we know which models are affected, and could we retrain without it if required?
When an automated system retrieves information on a user’s behalf, does the user only see content they would have been authorized to access directly? When a system answers questions by pulling from internal sources, relevance must never override permission — a user should never receive, through an automated intermediary, data they could not have queried themselves.
Do automated systems that act on data carry their own scoped permissions and their own audit trail, or do they operate invisibly under a human’s credentials?
Is there human oversight on automated decisions that materially affect people or touch sensitive data?

Data Sharing

When we share data with an external partner, do we record what they received and when?
Are sharing agreements documented and enforceable, and do we have any way to verify the partner’s governance, or do we just hand over the data and hope?
Is shared data de-identified or masked to the minimum necessary for the use case? The default should be the least data necessary to accomplish the purpose, not the most convenient.

Pillar 4: Improve Data Quality

Quality is the pillar where governance most visibly succeeds or fails, because broken quality is the failure users see directly — the dashboards disagree, the numbers drift, trust erodes.

Measurement

Which quality dimensions do we actually track — completeness, accuracy, timeliness, consistency, uniqueness, validity, anomaly? Naming them is the start; measuring them is the point.
Do our most important datasets have quality baselines, and when were they last updated? We cannot detect drift from a baseline we never established.
Are quality signals visible to the people who consume the data, before they use it? A consumer should be able to see whether a dataset is trustworthy without having to ask the team that produced it.

Detection and Response

How do we usually first learn about a quality problem — from monitoring, or from a user complaining? If the honest answer is “users tell us,” monitoring is not working, no matter what the dashboards claim.
When a quality check fails, who is notified, and how fast do they respond? An alert that lands in a channel nobody owns is the same as no alert at all.
Do quality issues have SLAs, and are those SLAs tracked and met?
What fraction of quality incidents end in a durable fix — a new check, a pipeline change, an upstream correction — versus a one-off patch that leaves the same failure free to recur? A program that patches without fixing will see the same incidents indefinitely.

Ownership

Does every critical dataset have a named owner accountable for its quality?
Is that ownership recorded in the catalog where anyone can look it up?
When ownership changes hands, does the catalog stay current, or does the record rot?

Drift

Are we tracking quality drift over time, or only firing alerts on point failures? A dataset can pass every individual check while steadily degrading over the course of a year.
Have we identified any datasets where quality has declined across multiple quarters?
Is there a mechanism to retire datasets that are no longer worth maintaining, or do they accumulate as unmonitored costs and risks forever?

Business Value

This is the section most governance checklists omit, and it is the one that most determines whether the program still exists in three years. A program that cannot explain its value in the language leadership recognizes will be the first thing cut when budgets tighten — no matter how good its classification coverage is.

Can we point to specific incidents that governance prevented or contained in the last year, along with the blast radius and cost we avoided? “We had no major breach” is invisible. “We contained an incident in two datasets in four hours; the unbounded version would have cost an estimated 10x” is a number leadership understands.
Can we name specific use cases — products, analytics, models — that governance unblocks? Deploying on sensitive data requires classification, lineage, and consent handling that the use-case team cannot produce alone. When governance is already in place, those projects ship in days instead of months.
Can we state our regulatory exposure as a bounded, defensible number — not “we are compliant,” but “our maximum exposure is X, here is how we know, and here is how we reduced it from last year”?
Has the time-to-decision on recurring analyses improved, and can we show the evidence? Consistent definitions and trustworthy data shrink the hours spent relitigating whose number is right.
Can we quantify the cost that governance keeps in check as AI scales — the runaway automated-system spend, the compounding storage and compute from AI-generated data — that an ungoverned program silently absorbs?
If asked to justify the governance budget in terms a CFO would recognize, could we do it on one page?
Does leadership have a clear, current view of what governance has delivered, or is the program a black box they fund on faith? Faith-based funding is the funding most easily withdrawn.

What to Do with the Answers

The output of this exercise is a list of gaps — questions we could not answer, or could answer only with a number worse than we expected. Do not try to close all of them at once. That is the fastest way to make no real progress on any of them.

Triage along two axes.

Risk — What is the potential impact of leaving the gap open? Missing a lineage graph for a high-traffic production dataset that supports executive dashboards poses significant risks. In contrast, missing a description on a low-traffic internal table is less critical.

Leverage — How much does closing the gap enable everything else? Fixing ownership in the catalog is highly impactful because all downstream activities—such as alert routing, access review, quality responses, and incident handling—depend on knowing the correct contacts. Addressing this high-impact gap, along with several others, becomes more straightforward as a side effect.

Close the high-risk, high-leverage gaps first. Let the low-risk, low-leverage ones wait until they climb in risk, or until the high-leverage fixes free up enough capacity to reach them.

A practical cadence is to run the full checklist once or twice a year and conduct quarterly follow-ups on any identified gaps. Over time, which gaps remain open becomes a useful diagnostic. Gaps that close quickly indicate strong attention and ownership, while those that persist may stem from structural issues or genuine difficulty. Recognizing the difference is valuable.

The checklist isn’t meant to make anyone feel bad about the current state of the program. Its goal is to make the program’s status clear to us, the team, and stakeholders who rely on governed data. A program that cannot see itself cannot improve. Clear vision and documentation are the first steps toward improvement.

This checklist is a companion to the Demystifying Data Governance series:

Demystifying Data Governance – Do We Really Know Our Data? A Self-Evaluation Checklist