
Reviews
Part of The honest guide to data governance as of 2027
Data governance questions beyond the obvious, updated for 2027
Data governance questions for an inherited dataset: what one row is, who is missing, where a field is defined, and what would make the answer wrong.
You have been handed a dataset. Somebody wants an answer from it by Thursday, and nobody who built it still works here.
These are the questions that decide whether the answer will be worth anything. They are ordered so that the ones that can stop the work entirely come first.
What to take away
- Ask what is missing before you ask what is in it. Absence is the failure that survives every other check.
- Four of these questions can only be answered by a person, not by looking at the data. Find that person early or say plainly that you could not.
- Write the answers down beside the analysis. They are the caveats, and they will be the first thing anyone asks about.
Questions that can stop the work
1. What does one row represent?
Row-level questions that stop work
- What does one row represent?
- Who or what is not in here?
- Snapshot or history?
- Coverage period complete at both ends?
The unit of analysis, stated precisely. One customer, one order, one order line, one snapshot of an order at a point in time. Getting this wrong invalidates every count downstream, and it is not always obvious from the column names.
2. Who or what is not in here?
Every dataset excludes something: canceled records, a region on a different system, a period before a migration, anything the collection mechanism could not see. Exclusions produce selection bias that no amount of careful arithmetic can undo, and they are almost never documented.
3. Is this a snapshot or a history?
If rows get updated in place, you have current state and cannot reconstruct the past. If rows are appended, you have history and must be careful not to double count. Many datasets are quietly both.
4. What is the coverage period, and is it complete at both ends?
The last period is nearly always partial. So, sometimes, is the first, for a different reason: a system went live mid-period. Both ends need a marker.
Questions about meaning
5. Where is this field defined, and by whom?
Four meanings of one blank cell
Meaning
- Not applicable
- Exclude from base
- Not collected
- Unknown coverage
- Collected, unknown
- Keep in base
- Deleted
- May bias results
Effect on denominator
- Not applicable
- Not collected
- Collected, unknown
- Deleted
Not what the column is called, but who decides what it means. If nobody can answer, the field is ungoverned and everything you build on it inherits that. A data dictionary is where the answer should live, and its absence is itself a finding worth reporting.
6. Has the definition changed during the period?
A level shift in a series is a definitional change until proven otherwise. Ask when the field was last modified and what happened around any visible break.
7. Which fields are entered by a person?
Free text, optional dropdowns, and anything a user can skip. These carry the meaning people care about most and the quality nobody guarantees, and their completeness usually varies by team.
8. What does an empty value mean here?
Not applicable, not collected, collected and unknown, or deleted. Four different meanings, one blank cell, and the choice between them changes your denominator.
Questions about provenance
9. Where does this come from, and how many hops away is it?
Provenance checks before use
- Trace back to originating system
- Count transformation hops
- Check refresh schedule and failure visibility
- Find existing published numbers
- Reconcile before publishing
Trace it back to the system where it originates. Each hop is a place a transformation can change the meaning, and knowing the chain is what data lineage is for. Three hops with no documentation is a reason to lower your confidence explicitly. A lineage record is one of the twelve governance records that make the chain visible.
10. How and when is it refreshed, and what happens when the refresh fails?
A dataset that silently keeps yesterday's rows when the load fails will look perfectly healthy while being wrong. Ask whether failures are visible.
11. Does anything else in the business already report from this?
If so, get their numbers first and reconcile. Producing a second, slightly different figure for a concept that is already published is the fastest way to lose an audience.
Questions about fitness for your specific purpose
12. Is the granularity fine enough for the decision?
Fitness checks for your purpose
- Is granularity fine enough for the decision?
- Are identifiers stable across merges?
- What would make this answer wrong?
- Could I detect that failure?
Weekly data cannot answer a question about days. This is the most common reason a technically clean dataset is useless, and it is discoverable in one minute.
13. Are the identifiers stable?
If a customer identifier is reissued or changes on a merge, joins will silently produce wrong groupings. Ask what happens to identifiers when records are merged or reopened.
14. What would make this answer wrong, and could I detect it?
The most useful question and the one nobody asks. Write down the two or three failure modes you could not detect with what you have. That list is your caveat section, already written.
Recording the answers
Keep them in a short block at the top of the analysis: unit of analysis, exclusions, coverage window, definitional changes, refresh behavior, and the undetectable failure modes. Six lines.
The value of the block is not for the reader. It is for you in four months, when the same dataset arrives for a different question and you can skip the whole interview.
When the answers are not available
Sometimes there is nobody left to ask. Say so explicitly rather than proceeding quietly: state which questions you could not answer, what you assumed instead, and how the answer would change if the assumption is wrong.
That is a more useful deliverable than a confident number, and it is the only honest one available.
Related reading on this site
The governance practice that would have answered most of these in advance is in data governance.
The records it produces are in twelve governance records, and scope decisions are in bounding governance work. For the analysis sequence these questions feed into, see how to work through a question.
For the questions to ask about a number already published, see asking about a number in the room.
Common questions
Fourteen questions before starting work sounds slow.
It is about twenty minutes, and the first four take five. Compare that to rebuilding an analysis after discovering that the last month was partial.
The dataset owner is unresponsive. How long do we wait?
Send the four blocking questions with a deadline and proceed on stated assumptions when it passes. Put the assumptions in the deliverable, in the same font as everything else.
What if the answers reveal the dataset cannot answer the question?
That is a successful outcome delivered early. Say what could answer it and roughly what it would take, so the conversation moves forward rather than stopping.
Should we fix the problems we find?
Report them to the owner and fix nothing in your own copy without saying so. A locally corrected dataset produces figures nobody else can reproduce, which creates the next dispute.







