Data Readiness Assessment for Mid-Market Firms: What a Good One Covers (and What It Costs You to Skip)
Read Time 18 mins | Written by: Vinayak Bhagat
Somewhere between the board asking about AI and the first pilot, someone proposes a data readiness assessment. It is usually a sensible idea, but two proposals with the same name can be very different purchases. One pulls real records from your systems and tells you which use cases your data can support today. The other runs interviews, scores your "data maturity" on a five-point scale and recommends a platform.
Both produce a report. Only one produces a decision. This guide is for the person who signs the order: the CIO, CTO, CDO, VP of Data or COO at a mid-market company, or the operating partner behind it.
A good data readiness assessment proves six things about your data, each against the use cases you actually plan to run, and each with evidence you can hold in your hand. We call them the Six Proofs. If a proposal cannot show how it will produce all six, it is selling something else.
What should a data readiness assessment cover?
It should name the use cases it measures against, map where the data for those use cases really lives, measure quality on real records rather than opinions, list the business terms that mean different things in different systems, confirm who owns each dataset and whether you may use it for this purpose, and end with a verdict per use case plus an ordered list of fixes with owners. Anything less is a survey.
What a Data Readiness Assessment Is, and What It Is Not
A data readiness assessment answers one question: can the data you have support the specific AI or analytics work you plan to fund, and if not, what has to change first? It looks at the data itself, in the context of named use cases.
That makes it narrower than two things it is often confused with. A broader AI readiness assessment also covers leadership, skills, process and culture; our seven-dimension AI readiness framework treats data as one dimension of seven. And a tech stack audit looks at the systems: what you own, what it costs and who can reach it. A data readiness assessment goes one level down, into the records those systems hold.
It is also not the fix. The assessment tells you what is missing; building it is separate work, covered in our guide to building the data foundation first. Keep the two purchases apart, even if you buy both from the same firm.
The Six Proofs
Each proof has a deliverable, and each deliverable has a quick test that separates the real thing from theatre. Use the table when you compare proposals, and the detail below when you read the final report.
| Proof | Deliverable | Real if | Theatre if |
|---|---|---|---|
| 1. Scope | Named use cases | Every finding traces to one | It scores "the enterprise" |
| 2. Sources | A source map | Each source was actually pulled | It copies your architecture diagram |
| 3. Quality | Quality readings per dataset | Measured on sampled records | Based on how people feel |
| 4. Meaning | A list of conflicting terms | Each conflict names the systems | It hands you a blank glossary |
| 5. Ownership and rights | An owner per dataset | Named people confirmed it | Every owner reads "IT" |
| 6. Verdict and sequence | Go, fix first or stop, plus an ordered fix list | "Stop" was a possible answer | Every road leads to a purchase |
Proof 1: Scope — the use cases it was measured against
Data is never ready in general. It is ready for something: forecasting demand, scoring leads, rolling up portfolio reporting. A good assessment starts by writing down the use cases you are actually considering, with the decision each supports, and measures everything against them.
Real vs theatre: pick any finding in the report and ask which use case it affects. If the answer is "all of them, generally," the scope was never set.
Proof 2: Sources — where the data really lives
For each use case, the assessment should list every system and file the data would come from, including spreadsheets that quietly became systems of record. Then someone should pull an extract from each one, through a path that could be automated later.
Real vs theatre: ask to see the extracts. A source map built from interviews and an old diagram tells you where people think the data is, which is the thing you were paying to check.
Proof 3: Quality — measured on real records
Quality should be read dataset by dataset from samples drawn during the assessment: duplicates, missing fields the use case needs, values that do not match reality, and how old the data is by the time anyone sees it. The people who run the process should review the samples, because they can spot a wrong record that looks fine to an outsider.
Real vs theatre: the report shows which records were sampled and what was found in them. A quality rating that came from a questionnaire measures confidence, not quality.
Proof 4: Meaning — the terms that disagree
The most expensive data problems are often words, not errors: "customer," "active" or "revenue" meaning one thing in the CRM and another in finance. Any model or dashboard built across those systems inherits the disagreement. A good assessment finds the conflicts that touch your use cases and names who can settle each one.
Real vs theatre: you get a short list of specific conflicts, each with the systems involved. A glossary template for you to fill in later is homework, not a finding.
Proof 5: Ownership and rights — who decides, and whether you may
Every dataset in scope needs a named owner who can approve changes and grant access, and a clear answer on whether your contracts, customer terms and consents allow this use. Teams skip the second question, and it is the one that can stop a finished pilot from going live.
Real vs theatre: each owner is a person who confirmed the role during the assessment. If the owner column says "IT" or "the business," nobody owns it.
Proof 6: Verdict and sequence — what to do on Monday
The assessment should end with a plain verdict for each use case: go now, fix these things first, or stop. Then it should give an ordered list of fixes, sequenced by dependency, each with an owner, and say what can safely wait. That list is what makes the assessment worth more than its report.
Real vs theatre: "stop" or "not yet" was a possible outcome, and at least one fix is something your own team could start without buying anything. If every recommendation ends in the assessor's product or platform, you bought a sales process.
The Data Readiness Scorecard
This article explains the six proofs. The scorecard is what you fill in: rate a vendor's proposal before you sign, or your own assessment once it is done. One page per proof with what good evidence looks like, a box for the evidence you were actually shown and the red flag to watch for, plus a verdict page per use case and a sign-off page.
Who Must Be in the Room, and What to Bring
An assessment is only as good as its access. Make sure these people have time set aside, not just a kickoff invite:
- The owner of each use case. The business leader who will act on the output. Without them, nobody can say what "good enough" data looks like.
- The people who run each source system. They know the workarounds, the manual fixes and the fields nobody trusts.
- Someone who can pull data. An engineer or analyst with read access, or the authority to grant it to the assessors.
- Someone who can answer usage-rights questions. Usually legal or the contract owner, for Proof 5.
- The executive sponsor, at the readout. A verdict is only useful if someone with budget hears it first-hand.
Bring three things to the first meeting: a written list of candidate use cases, the systems you believe are involved, and read access arranged for sampling. Each one you skip turns part of the assessment into slow, expensive discovery.
How the Effort Should Split
Length depends on how many use cases and systems are in scope, so compare proposals by how they split the effort, not by the calendar:
| Part | Share of the effort | Why |
|---|---|---|
| Setting scope | Small, done first | Everything after it is measured against the use cases |
| Interviews | Moderate | They tell assessors where to look, not what they will find |
| Pulling and reading data | The largest share | Proofs 2, 3 and 4 live here |
| Verdict and fix list | Moderate | Sequencing fixes takes judgment, not formatting |
| Report design | The smallest share | A short report you act on beats a long one you file |
If a proposal puts most of its effort into workshops and the final deck, and none into extracting data, it is a survey with a data label on it.
Three Mistakes When Buying a Data Readiness Assessment
Buying it after the AI budget is approved
Once the money is committed, a "fix first" or "stop" verdict becomes politically expensive, and the report gets read for reasons to proceed. Run the assessment while the decision is still open, so its verdict can change the decision.
Scoping the whole company
An assessment of "all our data" spreads the effort thin across systems no use case needs, and produces findings too general to act on. Name the use cases first. You can always run a second assessment for the next set.
Leaving the business owners out
When only IT and the assessors take part, the report describes the data accurately and misses what the business needs. The owner of each use case has to judge whether the sampled records are good enough.
What Skipping It Actually Costs
Skipping an assessment does not skip the problems. Duplicate customers, missing fields, conflicting definitions and data you are not allowed to use are already in your systems. The only choice is when you find them.
Found in an assessment, they are a list. Found inside a pilot, they are rework, a slipped date and a sponsor who now doubts the program. Found after launch, they are wrong answers someone already acted on. The assessment moves the discovery to the point where it is cheapest.
How to Read the Result
Start with the verdicts, not the scores. For each use case, check that the verdict follows from the evidence in Proofs 2 to 5. A "go" built on unsampled data is not a go.
Treat a "stop" as a good outcome: the cheapest way to learn a use case needs different data or a different year. Then read the fix list against the four layers in our data foundation guide: if the fixes jump straight to tooling while access and definitions are still open, ask why.
Once the fixes for a use case are done, take it to the funding decision with the AI readiness checklist, which adds the workflow, economics and control questions a data assessment does not answer.
When You Do Not Need One
Keep the money in four situations:
- You have no use case yet. Without one there is nothing to measure against. Decide what you want the data to do first; the AI readiness framework is a better starting point.
- The use case sits on one clean, well-owned system. If your team has already pulled it and the owner trusts it, an internal review will do.
- The real question is the systems, not the data. If you do not know what you own or what it costs, a tech stack audit comes first.
- The fixes are already known and funded. If a recent review named the problems and the work is under way, another assessment only restates them.
For transparency: Ontrac sells data and analytics services, including readiness reviews. The six proofs above are the standard we would expect a careful buyer to hold us to, and anyone else they are considering.
Find out what your data can support before you fund the work.
Our data and analytics team works with mid-market and private-equity-backed companies. Bring your use cases to a short call and we will tell you which of the six proofs you can already show, and which ones need work.
Book a call with usFrequently Asked Questions
What is a data readiness assessment?
It is a review of whether your data can support specific AI or analytics use cases. It maps where the data lives, measures its quality on real records, finds conflicting definitions, confirms ownership and usage rights, and ends with a verdict per use case and an ordered list of fixes.
How is a data readiness assessment different from an AI readiness assessment?
An AI readiness assessment covers the whole organization: leadership, skills, process, culture and data. A data readiness assessment goes deeper on the data alone, against named use cases. Run the broader one first if you have not chosen use cases yet.
What should you get at the end of a data readiness assessment?
Six things: the use cases it measured against, a map of the sources with extracts actually pulled, quality readings from sampled records, a list of conflicting business terms, a named owner and usage answer per dataset, and a go, fix-first or stop verdict per use case with an ordered fix list.
How do you tell a real assessment from a sales exercise?
A real assessment spends most of its effort pulling and reading your data, shows you the samples behind its findings, and could have told you to stop. A sales exercise relies on interviews and questionnaires, scores maturity without evidence, and ends with every recommendation pointing at the assessor's own product.
Keep Reading
→ Your Data Isn't AI-Ready: How to Build the Data Foundation First — how to fix what the assessment finds.
→ The AI Readiness Checklist: 25 Checks Before You Fund an AI Project — the funding gate that comes after.
→ AI Readiness Assessment for Mid-Market Firms — the broader organizational view.
This article is general information about evaluating data readiness services and is not legal or procurement advice. Questions about whether your contracts and customer terms allow a particular use of data depend on your own agreements; review them with appropriate advisors.
