Data Maturity Checklist

A consistent location is the first sign of storage maturity. Retention rules and version history come next.

Pick the three datasets the organisation relies on most and record where the authoritative copy of each lives. That list is the start of a catalogue.

Further reading: What is data maturity?

Start here. Until the current version can be found, every other question on this list is hard to answer.

Further reading: What is data maturity?

Then reports update with the data, and everyone reads the same numbers.

Each manual export is a copy that stops updating the moment it is made. Automate the one that is repeated most often.

Further reading: What is data engineering?

Reports built from exported copies drift from the source and from each other. A shared, queryable store is the fix.

Further reading: Bronze, silver, gold: a layered data architecture

Retention rules and an audit trail let you say what a record looked like last year, with confidence.

Write the retention rules down, then keep raw records unchanged so that later changes can be traced.

Further reading: Bronze, silver, gold: a layered data architecture

Keep raw records as they arrive and never overwrite them; the raw record is the audit trail.

Further reading: Bronze, silver, gold: a layered data architecture

Then your dependencies are visible. Check that each service allows a full export.

List them, with what each holds and who administers it. The list often turns up a service nobody remembers signing up for.

List them first. Data you cannot locate cannot be backed up, moved or joined to anything else.

Further reading: What is data maturity?

Then changing provider is a planned project with a known cost.

Test a full export from the service you depend on most. What comes out, and in what shape, is the real measure.

Further reading: What is data maturity?

Then the provider controls both the data and the terms. Plan an export route before you need it.

Then a change in a trend reflects the data, with the method held constant.

Start with the numbers the board sees. Record the source, the steps and the definitions behind each one.

Further reading: What is data engineering?

Without a trace, a change in a number could be a change in the world or a change in the method. Record how each key number is produced.

Further reading: What is data engineering?

Then collection is part of a pipeline, and comparisons over time hold.

Write down the collection steps and the definitions they use, and keep them with the data.

Further reading: What is data maturity?

Data treated as the one-off result of someone's effort is hard to compare or scale. Script the collection you repeat most.

Further reading: What is data maturity?

Then the knowledge lives in the process, where it survives staff changes.

Pair someone with the current owner on the next run, and write each step down as they go.

Further reading: What is data maturity?

A common single point of failure in small teams. Capture the steps now, while the person is still there.

Further reading: Don't build models, build measurements

Then shared definitions are doing their job.

Where the answers differ, the definitions differ. Agree one definition per metric and keep it next to the data.

Further reading: SQL schema documentation for RAG pipelines

Metrics open to interpretation turn meetings into arguments about numbers. Define each key metric once, in one place.

Further reading: What is data engineering?

Then anyone can read what a field means without asking.

Start with the fields people ask about most often.

Further reading: SQL schema documentation for RAG pipelines

Definitions held in people's heads leave with them. Document the schema where the data lives.

Further reading: SQL schema documentation for RAG pipelines

Then access can grow with the organisation without growing the risk.

Review who can see personal and confidential data first, and remove access nobody needs.

Start with personal and confidential data: who can see it, and why. UK GDPR expects access to be limited to what each purpose needs.

Further reading: What is NER and why does it matter for PII?

Then data problems surface as alerts before they surface in a decision.

Add checks to the feeds behind key reports: row counts, arrival times, and values out of range.

Further reading: Bronze, silver, gold: a layered data architecture

Silent loss is found only when something breaks. Start with an alert on missing or late data for the most important feed.

Further reading: Bronze, silver, gold: a layered data architecture

Self-service access means the data is organised for use.

Note which requests recur, and publish those as a standing report or dataset.

Further reading: What is data engineering?

Every request that needs a person creates a queue and another copy. Publish the requests that recur.

Further reading: What is data maturity?

Then the data model has room for new questions, and the history you have accumulated may answer more of them than the current reports show.

Further reading: What your data already knows

A new metric should be a query. When it takes a project, the data usually lacks a shared model.

Further reading: What is data engineering?

Then the data answers only the questions it was set up for. A shared, well-defined data model is what changes that.

Further reading: Bronze, silver, gold: a layered data architecture