In this article a data quality checklist means a set of tests a leader can run on one key data set to see whether the records behind a key report or an AI tool’s answer are accurate, complete, consistent, recent and owned by a named person. This one has ten checks, arranged in five groups. Each check has a pass test and names the proof to put on file, and the marks add up to a score out of 20. Taken together, the marking amounts to a small data quality assessment that you run yourself. A full score tells you the sample passed each test, and nothing about records you left out. The wider goal, records you can trust, has its own use case.
Last reviewed 2026-11-02 by Manish Sharma.
Data Quality Checklist: Accuracy to Ownership in Ten Checks
Use this list on one data set per round. It is your own self-check, and nobody should mistake it for an audit. Two terms come up throughout. A data set here means the records behind one report or one AI use. Key field means a column whose errors would change that report or answer.
Within Signisys’ working method, there are ten checks in five groups, and each asks one question:
Key Takeaway A mark counts for what its dated proof line can show, and an undated line caps it.
Some published lists call groups like these data quality dimensions, and those lists differ. The UK government’s Government Data Quality Framework, published on 3 December 2020, sets out six core dimensions, taken from DAMA UK, and says that list is not prescriptive and that other organisations define the dimensions slightly differently. The groups and tests used here are our own work and no standard.
Data Quality Checklist: How Each Check Is Marked
Each check gets one mark. Within Signisys’ working method, marks rise only as far as the proof line allows.
Solid (2): each record in your sample passes, and a dated proof line sits beside the mark. Patchy (1): part of the sample passes and part fails, or the sample passes but nobody dated the proof line. Faulty (0): the sampled records fail the pass test.
Without a dated proof line, Patchy is the top mark, whoever vouches for the check. When a check has no bearing on your data set, write N/A and the reason, and take two off the maximum of 20.
First, pick the sample before you start and write it down. One sensible choice is the records behind the last three figures someone questioned. Mark what the sample shows rather than guessing about the records outside it.
For example, picture an invented tour operator. Its finance head runs the data quality checklist over the bookings list, one check at a time. Check 7 asks whether anyone can tell when each key field last changed. Here are three ways her mark could land:
- Solid: she opens five bookings, reads a change date on each, and writes today’s date beside the mark.
- Patchy: she finds a change date on three bookings and none on the other two.
- Faulty: she finds no change date on any of the five.
Do the Values Match What Really Happened?
Accuracy comes first in the list. One wrong value can mislead each reader of the report. Two checks test it.
| Check | Proof to put on file | Solid when |
|---|---|---|
| Check 1: Sampled values match their source document | The sample laid beside the booking form, supplier confirmation or other source | The person comparing them finds each value matches and dates the comparison |
| Check 2: Impossible values are listed | The report’s totals and ranges, read by the person who uses them | That person has written what an impossible value looks like and lists each one found, or writes that none turned up |
For instance, at the tour operator an impossible value might be a return date before the departure date, or a group of zero travellers. When someone writes such rules down, a hunch turns into a test anyone can repeat.
Next, keep the comparison for check 1 small enough to finish in one sitting. A small sample read closely can reveal more than a bigger one read in haste. Other faults a sample can turn up are set out in how repeated records and out-of-date or mixed-format ones show up.
Is Anything Missing From the Records?
Completeness asks whether the values you rely on are filled in at all. Start by agreeing which fields matter. If a column goes unused, a blank in it changes nothing.
| Check | Proof to put on file | Solid when |
|---|---|---|
| Check 3: The key fields are named | A written list of the key fields behind the report | The report’s owner has agreed the list |
| Check 4: Blanks in those fields are looked for in the sample | The sample, with each named field read one by one | Each blank is listed with the place its value should have come from |
For the bookings list, for example, the finance head might name the travel date, the agent and the number of travellers as key fields. Then she reads the sample one booking at a time. Beside each gap, she notes where the missing value should have come from, such as the booking form or the agent’s email.
A short agreed list keeps check 4 honest. Agree the list with the report’s owner first, and nobody can later argue that a blank sat in a field that did not count.
Do Two Places Tell the Same Story?
Consistency asks whether one fact reads the same wherever your firm keeps it. Two checks cover the way a fact is written and whether two copies agree.
| Check | Proof to put on file | Solid when |
|---|---|---|
| Check 5: One item is written one way in each place | The same few items read in two systems or two files | The reader can match each pair without guessing |
| Check 6: A fact held in two places agrees in both | A short list of paired facts, with both sources named | Each pair agrees, or a written note says which place wins |
For example, dates make a good first test for check 5. One file may write 03/04 for 3 April while another reads it as 4 March, and nobody notices until a traveller turns up on the wrong day. Similarly, names of agents and hotels deserve a second look.
For check 6, for instance, a customer’s address in the sales list and in the finance list makes a fair pair. When the pairs come from lists joined together, a shared view of sales and finance records is a wider job with its own use case.
How Recent Are the Records You Rely On?
Timeliness covers two points: when a value last changed, and whether the newest entries made it into the report.
| Check | Proof to put on file | Solid when |
|---|---|---|
| Check 7: Anyone can tell when each key field last changed | One record opened with its change date, or a note of why no date exists | A colleague outside the owner’s team opens the record and reads the date |
| Check 8: The report’s period is written, and the newest entries inside it are in | The stated period beside the latest entries | The two agree, and the person who checked dated the note |
A report on last month’s bookings that misses the final week’s entries can look complete while telling the wrong story. Check 8 catches that gap.
Ask whoever runs check 8 to note the date of the latest entry found. The next round then starts from a known point instead of a memory.
Who Is Named for This Data Set?
Ownership affects whether anyone acts on what the other eight checks find.
Key Takeaway Name who acts on a finding before you score the other checks.
| Check | Proof to put on file | Solid when |
|---|---|---|
| Check 9: One named person answers for the data set | The name, written where users of the report can see it | That person can say what the data set serves and who may change it |
| Check 10: A route for correcting a bad value is written down | The route, with the name of whoever receives reports of bad values | A colleague outside the owner’s team has sent one bad value down it, and dated that test |
Test check 10 on purpose. Pick one known wrong value, send it down the route, and note when the owner replies. If nobody replies, the route exists only on paper, and the check is Faulty.
At the tour operator, the finance head might make the reservations lead the owner of the bookings list. She then writes that name at the top of the report, where each reader sees it.
Data Quality Checklist: Where Repairs Begin
Add the marks inside each group, then write the number of Faulty marks beside each group total, and note the sample and the date on the same sheet.
Within Signisys’ working method, repairs start with Faulty marks under Ownership and Accuracy. Completeness, Consistency and Timeliness all lean on a named person and on values that match their source, and fixing those two groups first gives later repairs firm ground. Completeness, Consistency and Timeliness then follow, in that order.
Clear each Faulty before you spend time lifting a Patchy to Solid. A Patchy mark points to a gap in proof, while a Faulty one points to a fault in the records themselves. Whether the marking is redone by hand or by software is compared in who or what should run each check on records.
The total has no pass line and no band, and it does not compare you with other firms. A path from the first doubtful report to a fix is set out in five steps from the chosen figures to a named owner for each field. After a repair, run the data quality checklist again and write the new date beside the old one.
When you score again, use the same sample, or write down how it changed. A higher total from an easier sample shows nothing.
What You Tested and What You Did Not
Three decisions stay with you after the score. You choose which data set to test next. You decide who else should read the proof lines. And you judge whether the sample was wide enough to stand for the whole list.
Signisys is open to a conversation if two people give the same check different marks and still disagree on which one stands, or if one key field scores Faulty in three groups.
Signisys provides data and AI services. Its analytics and business intelligence solution and its data and AI service page describe that work. What follows in the box is a Signisys offer, not neutral advice, and it promises no result. Please bring your scored sheet, the sample you chose and the checks two people marked differently, and the call can then start from those.
Data Quality Checklist FAQ: Samples, Marks and Missing Checks
Which parts of our records does the data quality checklist test?
Who reads the proof lines in the data quality checklist?
Can two people mark the data quality checklist differently?
Can we leave out a check that has no bearing on our data set?
How big should the sample be?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.