In short: A data readiness check is a structured review you run before using a dataset for a report, model, dashboard, or decision. It surfaces quality, ownership, and governance gaps before they become trust issues. Most problems that make data “feel wrong” to stakeholders could have been caught at this stage.

Why this check is worth doing every time

Most data trust problems are not discovered early. They surface when a stakeholder spots a number that doesn’t match, when an AI model produces a suspicious output, or when an audit reveals that no one can explain where a figure came from.

Running a readiness check takes 15 to 30 minutes for a familiar dataset. It takes longer for new or high-stakes ones. Either way, it is faster than rebuilding trust after a bad report lands in front of a leadership team.

The checklist below is tool-agnostic. Use it in a spreadsheet, a data catalog, a governance platform, or just a shared document. The format does not matter. The questions do.

Is there a named owner?

Someone must be responsible for this data. If the answer is “the data team” or “the platform,” that is not an owner. Write down a specific name or role. Without an owner, there is no one to call when something is wrong.

Is the definition of every key field agreed and documented?

The most common source of dashboard arguments is undefined terms. What counts as a “customer”? When does an “order” exist — at placement, at payment, at shipment? Write one sentence per critical field, confirm it with the business, and store it somewhere findable. A business glossary entry is ideal. A shared document is better than nothing.

Is the grain of the dataset clear?

One row = one order line? One row = one daily snapshot per customer? If you cannot answer this in one sentence, the dataset is not ready. Undefined grain is the root cause of most double-counting and aggregation errors.

Are known quality issues documented?

Every real dataset has known issues. The problem is not the issues — it is the ones that are known but undocumented. Run at least a basic completeness check (null rates on required fields) and a validity check (values outside expected ranges or lists). Document what you found. A dataset with known limitations that are visible is more trustworthy than one with hidden problems.

Is the data fresh enough for the intended use?

A weekly report can tolerate data that is 48 hours old. A daily operations dashboard cannot. Confirm the actual refresh cadence and compare it against what the consumer needs. If there is a gap, flag it explicitly before shipping.

Is the source system and the transformation logic documented?

Where did this data come from? What transformations were applied? If neither you nor a colleague can answer this from existing documentation within 10 minutes, the lineage is missing. Lineage documentation does not need to be elaborate — a single paragraph describing source, transformation, and destination is enough to start.

Is access to the data appropriate?

Who can read this data? Who can write to it? Are there personal or sensitive fields that require restricted access? Run a quick access review for any dataset containing personal data, financial data, or anything flagged as confidential. Verify the classification matches the access controls in place.

Have the critical checks been tested — not just defined?

Defining that “completeness must be above 99%” is not the same as measuring it. Before shipping, confirm that any quality rules you have defined have actually been run and passed. If automated checks are not in place, run them manually for this release and document the result.

Data that is fine for one use case can be wrong for another. An aggregate table built for monthly reporting may not have the grain needed for a daily analysis. A dataset approved for internal dashboards may not be approved for model training. Ask: was this dataset built and verified for this specific use? If not, flag the gap before proceeding.

Is there a point of contact if something goes wrong?

Separate from the data owner: who do you call in the next 24 hours if a downstream report or model produces an unexpected result? This should be a named person or a team with a monitored channel — not a generic email alias that gets checked once a week.

Get the checklist for free



    Sign up to the newsletter for free and receive the ready to use template checklist for free.

    Plus: Every month I send one practical checklist or template.

    No noise, no ads – just something you can use.

    Note: You will also receive the download link if you have already subscribed to the newsletter!

    Frequently Asked Questions

    Not always. For a familiar dataset you work with weekly, checks 1, 5, and 8 are the minimum. Run all 10 for new datasets, high-stakes use cases (executive reporting, model training, regulatory submissions), or after any significant upstream change.

    A: Close to the dataset. In a data catalog like Microsoft Purview, attach it as a note or a data product attribute. In a project environment, a shared document linked from the dataset’s metadata record is sufficient. The goal is that anyone who picks up this dataset later can find the check results without having to ask you.

    Not necessarily. A failed check should trigger a documented decision: either fix the issue before proceeding, or proceed with the gap explicitly documented and communicated to the consumer. “The data is 3 days old but the business accepted this limitation for this release” is a valid outcome if it is written down.

    A data quality framework defines the rules and thresholds at scale. This checklist is a lighter-weight gate you run for a specific dataset before a specific use. Think of the framework as the policy and this checklist as the pre-flight check.

    Keep your BI skills sharp – follow for more insights!

    Leave A Comment