Data quality assessment is the piece of work everybody agrees is essential and almost nobody schedules. The reporting project gets a budget, the migration gets a plan, the AI pilot gets a steering group — and the underlying records get a shrug and a hope. Then the first dashboard disagrees with the finance pack, the migration drags an extra two months, and the pilot returns confident answers built on customer records that were last touched in 2019.
None of that is a tooling failure. It is what happens when nobody measured the raw material before building on it. A structured data quality assessment takes days, not months, and it converts a vague sense that “our data is a bit of a mess” into a scored, prioritised, costed list you can actually work through. This guide is the working detail: what to measure, the checks to run, how to score them, what the numbers usually look like, and what to do next. It sits alongside our data management and analytics and data science practice.
It is written for mid-sized organisations, where there is no dedicated data team and the work lands on an analyst, a finance manager and a busy IT lead. If you have not yet decided which system is authoritative for each entity, read our single source of truth guide first, because a data quality assessment scored against the wrong master tells you very little. If you have no governance structure at all, our data governance framework guide covers the roles that make remediation stick.
Table of contents
- What a data quality assessment actually measures
- Scope the data quality assessment before you profile anything
- The six dimensions your data quality assessment scores
- The data quality assessment checklist: the checks that find real problems
- How to profile data during a data quality assessment
- Score the data quality assessment so results are comparable
- What a data quality assessment usually finds
- Turn the data quality assessment into a remediation plan
- Tooling for a data quality assessment
- Data quality assessment and UK GDPR
- Data quality assessment before AI and analytics
- A ninety-day data quality assessment and remediation plan
- What a data quality assessment costs
- Data quality assessment mistakes that waste the effort
- Frequently asked questions about data quality assessment
- References
What a data quality assessment actually measures
A data quality assessment is a structured measurement of how far a defined set of records departs from the rules that the business relies on. It is deliberately narrow. You are not auditing the estate, ranking systems, or writing policy. You are producing evidence about specific fields in specific tables against specific tests.
Six dimensions, not one number
Quality is not a single property. The discipline splits it into dimensions — completeness, validity, accuracy, consistency, uniqueness and timeliness — because each has a different test, a different owner and a different fix. Collapsing a data quality assessment into a single percentage feels tidy and destroys the only information that would tell you where to start. The dimension model is standard practice and is set out in detail in the DAMA DMBOK body of knowledge.
Fitness for purpose, not abstract purity
There is no absolute standard for a good record. A postcode that is 92% complete is a disaster for a direct mail campaign and completely irrelevant to a revenue report. Every threshold in a data quality assessment should be traceable to a decision or a process that breaks when the field is wrong. If you cannot name what breaks, do not measure it.
It is a measurement, not a project
The output of a data quality assessment is a scorecard and an evidence pack, not a cleansed database. Remediation is the project that follows. Keeping the two separate matters because it stops the assessment expanding into an eighteen-month cleanse with no baseline, and it means you can re-run the same tests later and prove the number moved.
Where it sits against governance
Governance decides who owns a field and what the rules are. A data quality assessment tells you whether reality currently matches those rules. Governance without measurement is a policy nobody can enforce; measurement without governance produces a report nobody acts on. They are complementary, which is why this work usually reports into the same forum as IT governance.
Scope the data quality assessment before you profile anything
The single most common way to waste this effort is to point a profiling tool at an entire database and drown in output. Scope is the discipline that turns a data quality assessment from an academic exercise into something that finishes.
Start from decisions, not from tables
Write down the three to five decisions or processes that depend on the data: the monthly revenue pack, the renewals campaign, the service desk routing rule, the model that scores leads. Then work backwards to the fields those depend on. That list is the scope of your data quality assessment, and it is usually far shorter than the table list you would have started from.
Choose five to eight critical data elements
A critical data element is a single field whose failure has a named consequence: customer email, VAT number, contract end date, product code, site postcode. Five to eight is enough for a first data quality assessment and small enough to finish inside two weeks. Two hundred elements is not a scope, it is a wish.
Name the system of record for each element
For every element, write down which system is authoritative. If two systems both claim it, you have found a governance problem before you have run a single query, and the assessment result will be ambiguous until it is settled. Our master data management business case guide covers what to do when that answer is genuinely contested.
Agree the sample window and the row count
Decide up front whether the data quality assessment covers all records or an active subset — for example, customers with activity in the last 24 months. Measuring everything including a decade of dormant records produces a frightening headline number that nobody can act on, because most of the failures are in rows nobody uses.
Write the scope on one page and get it signed
One page: the elements, the systems, the window, the tests, who signs off the thresholds. It takes an hour and it is the difference between a data quality assessment that lands and one that gets relitigated in the readout.
The six dimensions your data quality assessment scores
Each dimension answers a different question and needs a different kind of test. A complete data quality assessment runs all six against every critical element in scope, because a field can be 100% complete and entirely wrong.
Completeness
Is the value present when the business rule says it must be? Completeness is measured conditionally, not absolutely — a delivery address is mandatory for a physical order and meaningless for a software licence, so the test has to carry the condition.
Validity
Does the value conform to its format, type, range or reference list? Validity is the cheapest dimension to test and usually the largest source of easy wins: malformed email addresses, dates in the future, negative quantities, country codes that are not in ISO 3166.
Accuracy
Does the value match reality? This is the expensive one, because it needs an external reference — a postcode file, a company register, a bank validation service — or human verification against a sample. Accuracy is the dimension people mean when they say the data is wrong, and the one a data quality assessment most often skips.
Consistency
Does the same fact agree across systems and within a record? Consistency covers cross-system checks (the CRM and the finance ledger disagree on the account name) and intra-record logic (contract end date precedes start date).
Uniqueness
Does each real-world thing appear exactly once? Duplication is the defect with the widest blast radius, because it inflates counts, splits history, and sends two of everything to the same customer.
Timeliness
Is the value current, and did it arrive when it was supposed to? Timeliness covers both staleness of the record and lateness of the feed. A perfectly accurate figure delivered nine hours after the decision is a failed record.
| Dimension | Question it answers | Typical test | Starting threshold |
|---|---|---|---|
| Completeness | Is the value there when it must be? | Null or blank rate on mandatory fields | 98% |
| Validity | Does it match the expected format? | Pattern, range and reference-list checks | 99% |
| Accuracy | Does it match the real world? | External reference or 50-row manual sample | 95% |
| Consistency | Do systems and fields agree? | Cross-system reconciliation, logic rules | 97% |
| Uniqueness | Does each thing appear once? | Exact and fuzzy duplicate detection | 99% |
| Timeliness | Is it current and on time? | Record age, feed arrival versus SLA | 98% |
Failures do not spread evenly across those six. In the estates we review, validity and uniqueness account for well over half of everything a first data quality assessment finds, which is useful because they are also the two cheapest dimensions to fix.
Accuracy sits at the bottom of that list only because it is the dimension least often tested, not because records are accurate. Where teams do run an external reference check, the failure rate typically jumps well above the completeness figure.
The data quality assessment checklist: the checks that find real problems
This is the working data quality assessment checklist. Run the structural and completeness blocks first because they are fast and they tell you whether the rest of the checks will even be meaningful. Nothing here needs a specialist product; every one of these can be expressed as a SQL query.
Structure and schema checks
Confirm the row count matches the source system’s own count. Confirm no column has been silently retyped since the last extract. Check for columns that are 100% null, which usually means a field the business swears it uses is populated somewhere else entirely. Look for encoding damage — mojibake in names and addresses is common after any migration and is invisible in a report until it reaches a customer.
Completeness checks
Measure the null and empty-string rate on every mandatory element, then repeat it conditionally on the rule that makes the field mandatory. Separately, count the placeholder values people type to get past a required field: “N/A”, “none”, “test”, “aaa”, “unknown”, a single full stop, and the office’s own phone number appearing on four hundred contacts.
Validity and format checks
Email addresses that parse, phone numbers with a plausible country prefix, postcodes matching the national pattern, dates inside a sensible range, numeric fields that are actually numeric, and every coded field checked against its reference list rather than against itself. A dropdown that allowed free text five years ago will still be carrying the evidence.
| Check | What it catches | Effort |
|---|---|---|
| Row count versus source | Broken or partial extracts | Minutes |
| Column type drift | Silent schema changes upstream | Minutes |
| All-null columns | Fields the business thinks it uses | Minutes |
| Encoding damage | Corrupted names and addresses | Low |
| Conditional null rate | Missing values that actually matter | Low |
| Placeholder value scan | “N/A”, “test”, repeated dummy numbers | Low |
| Format and pattern tests | Malformed emails, phones, postcodes | Low |
| Range and boundary tests | Future birth dates, negative quantities | Low |
| Reference-list conformance | Codes not in the controlled vocabulary | Medium |
Consistency and referential checks
Every foreign key resolves to a parent that exists. Cross-field logic holds: end dates follow start dates, a closed account has no open orders, a child site belongs to a parent that is still active. Then reconcile the same fact across two systems — customer name, account status and contract value between CRM and finance is the classic trio, and the classic source of a boardroom argument.
Uniqueness and duplication checks
Exact duplicates on the natural key first, then fuzzy matching on normalised name plus postcode, then domain-level matching on email. Expect three populations: true duplicates, legitimate near-matches such as two branches at one address, and records that merged badly in a previous cleanse. Only the first is safe to auto-merge, and this is where a good data migration checklist and a quality assessment overlap most.
Timeliness and freshness checks
Distribution of record age since last update. Count of records untouched beyond the retention period. Feed arrival time against its expected schedule for the last thirty runs. A staleness histogram is often the single most persuasive slide in the readout, because “41% of your active customer records have not been touched in three years” needs no explanation.
| Check | What it catches | Effort |
|---|---|---|
| Orphan foreign keys | Children with no surviving parent | Low |
| Cross-field logic rules | Impossible date and status combinations | Low |
| Cross-system reconciliation | CRM and ledger disagreeing on a fact | Medium |
| Exact duplicate keys | Straightforward double entry | Low |
| Fuzzy name and address match | The duplicates that inflate every count | Medium |
| Email domain clustering | One organisation held as many accounts | Medium |
| Record age distribution | Stale records still counted as active | Low |
| Retention breach count | Data held beyond its lawful period | Low |
| Feed arrival versus schedule | Late loads that quietly skew reports | Medium |
How to profile data during a data quality assessment
Profiling is the mechanical half of a data quality assessment. Do it in a fixed order, because each stage tells you what the next one should look for.
Column profiling comes first
For every column in scope, produce the count, distinct count, null count, minimum, maximum, mean where numeric, and the ten most frequent values. That last one earns its keep repeatedly — the top-ten list on a “customer type” column is where you discover eleven spellings of “Reseller” and a value called “temp – do not use”.
Rule-based checks come second
Now run the checklist above as explicit pass or fail rules. The distinction matters: profiling describes what is there, rules test it against what should be there. Only rules produce a score, and only a score produces a trend you can show a board.
Compare against an external reference
Wherever an authoritative external source exists, use it. Postcode and address files, Companies House identifiers, VAT number checksum validation, bank sort code directories. This is the only route to a genuine accuracy number, and it is usually cheaper than teams expect.
Read fifty rows by hand
Pull a random fifty rows and read them properly, end to end. Every automated pass has blind spots, and a human reading real records finds the pattern the rules were never written to catch — the sales note pasted into the address line, the contract value entered in pence, the two-year-old “call back next week” that is still the latest activity.
Record every finding as a reproducible query
Every number in the data quality assessment report should have a query behind it that anyone can re-run. If a finding cannot be reproduced, it will be argued away in the readout, and you will have no baseline to measure improvement against three months later.
Score the data quality assessment so results are comparable
An unscored data quality assessment is a list of complaints. Scoring converts it into something that can be tracked, targeted and compared between systems.
One score per dimension, zero to one hundred
For each element, score each dimension as the percentage of records passing that dimension’s rules. Roll up to an element score, then to a domain score. Keep the dimension detail visible at every level — the roll-up is for the summary slide, the detail is what remediation actually works from.
Weight the dimensions by use case
A weighting is a business statement, not a technical one. For a marketing campaign, completeness and validity of contact fields dominate. For statutory reporting, accuracy and consistency dominate. For an AI training set, uniqueness and representativeness matter more than anything. Agree weights before you see the scores, not after.
Set green, amber and red thresholds
Without thresholds, a score is decoration. Green means fit for its stated purpose, amber means usable with a documented caveat, red means do not build on this. Setting them before profiling stops the thresholds quietly migrating downwards to meet the results.
A worked scoring example
The example below is a customer domain in a services business with roughly 40,000 active records — a realistic shape rather than a flattering one. Two dimensions are green, three amber, one firmly red, and the red one is where the whole remediation budget should go.
What a data quality assessment usually finds
Data quality assessment findings repeat across organisations with striking regularity. Knowing the pattern up front helps you scope sensibly and stops the readout feeling like an accusation.
Duplicate customer and supplier records
Between 8% and 20% of customer records in a CRM that has never been deduplicated are duplicates or near-duplicates. The causes are mundane: no unique key at entry, a web form that never checks, an acquired list loaded wholesale, and a sales team incentivised to create rather than search.
Missing or undeliverable contact details
Email bounce rates on an unmaintained list run at 15% to 30% after two years. Mobile numbers decay more slowly but silently. Neither shows up in any report until a campaign runs, which is why contact fields are the highest-value element in a first pass.
Reference codes that drifted apart
Product, cost centre and category codes fork whenever two systems maintain their own list. The symptom is a report that nearly reconciles, and the fix is a controlled vocabulary with one owner — the same discipline that underpins metadata standards such as Dublin Core.
Records nobody ever retires
Without a retirement rule, everything accumulates. Closed accounts stay open, former employees stay in the directory, and leavers’ data sits well past its lawful retention period. This is a compliance exposure as much as a quality one, which is why it belongs in the same conversation as data protection.
Free text where a picklist belongs
Any field that allowed free entry at some point still contains the evidence, and every downstream grouping is quietly wrong because of it. Fixing the input control without cleansing history leaves you with two eras of data that cannot be grouped together — do both, or neither is worth doing.
Turn the data quality assessment into a remediation plan
A data quality assessment that produces no plan is an expensive way to feel bad. The conversion is mechanical if you keep four rules in mind.
Fix at source, not in the report
A cleanse applied in the reporting layer solves the symptom for one dashboard and leaves the defect flowing into everything else. Fix the record in the system of record, and fix the process that created it. Anything else is rework with a deadline attached. Our dashboard governance guide covers what happens when teams patch numbers in the presentation layer instead.
Triage by impact and effort
Score every finding on business impact and remediation effort, then take the high-impact, low-effort block first. That block is usually validity rules and exact duplicates, and clearing it inside the first month buys the credibility you will need for the harder work.
Separate the cleanse from the prevention
Every defect needs two answers: what do we do about the existing rows, and what stops it recurring. Teams routinely fund the first and skip the second, which is precisely why the same assessment run two years later produces the same numbers.
Give every element a named owner
Not a team, not a function — a person, in the business rather than in IT, who decides what the field means and signs off its rules. Unowned elements never improve, regardless of how good the tooling is.
Move the checks into the pipeline
Once a rule is agreed, it belongs in the data pipeline as an automated test that fails loudly, not in a quarterly report that observes the failure after the fact. Retiring a manual check by automating it is the clearest sign the programme is working.
| Factor | Fix at source | Cleanse downstream |
|---|---|---|
| Time to first visible result | Weeks | Days |
| Benefits other systems | Yes, all of them | No, one consumer only |
| Recurring cost | Falls to near zero | Permanent, and grows |
| Needs business change | Usually yes | Rarely |
| Risk of silent divergence | Low | High |
| Right choice when | The defect recurs | The source is being retired |
Tooling for a data quality assessment
Tooling is the last data quality assessment decision, not the first. A team that cannot articulate its rules will not be rescued by a product that is very good at running rules.
SQL and a spreadsheet go further than you think
A first data quality assessment on five to eight elements is entirely achievable with queries and a spreadsheet, and doing it that way forces you to write the rules down in plain terms. Most organisations should start here and only move on when repetition, not capability, becomes the constraint.
Open-source rule engines
When the checks need to run on a schedule, an open-source framework earns its place. Great Expectations and Soda both express checks declaratively and produce a machine-readable result, and if your transformations already run in dbt, its built-in data tests cover a useful share of the checklist with no new tooling at all.
Platform-native catalogue and quality features
If your estate is already on one cloud, the native catalogue usually includes profiling and rule features that are good enough and already licensed — Microsoft Purview, the AWS Glue Data Catalog and Google Dataplex all do. Check the licence you hold before buying anything.
When a dedicated tool earns its licence
A specialist product pays off when you need matching and survivorship at scale, a stewardship workflow for business users, or auditable lineage for a regulator. Below that, it is an expensive way to run queries you could have written. The maturity model in the EDM Council DCAM framework is a reasonable way to judge whether you are at that point.
| Tier | Best for | Typical annual cost | Limit you will hit |
|---|---|---|---|
| SQL and spreadsheet | First pass, up to 10 elements | Nil | Nobody re-runs it |
| Open-source rule engine | Scheduled checks in a pipeline | Engineering time only | No business-user workflow |
| Platform-native catalogue | Single-cloud estates | Often already licensed | Weak across clouds |
| Dedicated quality platform | Matching, stewardship, audit | £25k to £120k | Needs an owner to run it |
Data quality assessment and UK GDPR
A data quality assessment is not only a commercial exercise. Several of the checks above map directly onto statutory obligations, which is worth stating explicitly because it changes who will fund the work.
Accuracy is a statutory principle
The UK GDPR accuracy principle requires personal data to be accurate and, where necessary, kept up to date, with reasonable steps taken to erase or rectify inaccurate data. The ICO’s guidance on the accuracy principle sets out what “reasonable steps” means in practice, and a documented, repeatable measurement is a large part of demonstrating them.
Storage limitation retires stale records
The staleness checks in the checklist are also a storage limitation control. Records held beyond the period you defined for them are a breach exposure, and the count of them is one of the easiest numbers an assessment produces.
Data minimisation shrinks the surface
Fields that are entirely null or filled with placeholders are often fields nobody needed. Removing them improves the score, reduces the surface area to protect, and supports the minimisation principle at the same time.
Document the assessment for accountability
The accountability principle expects you to be able to show your working, and a data quality assessment produces that working as a by-product. Scope, rules, scores, dates and owners are exactly the evidence pack the ICO’s accountability and governance guidance describes, so file the assessment where a regulator or an auditor could actually find it.
Data quality assessment before AI and analytics
Every AI programme reaches the same discovery in its second month: the data quality assessment it skipped at the start was the actual project. Doing the measurement first is considerably cheaper than discovering it live.
AI amplifies every defect you leave in
A duplicate record in a report inflates a count by one. The same duplicate in a training set teaches a pattern that is not real, and in a retrieval system it returns two contradictory answers to the same question with equal confidence. The defect does not stay the same size when you put a model on top of it.
Representativeness is a quality dimension for AI
For training and evaluation data, coverage of the population matters as much as correctness of individual rows. A dataset that is 99% valid but drawn entirely from one region or one customer segment will produce a model that fails quietly on everyone else — a risk the NIST AI Risk Management Framework treats as first-order.
Grounding data needs freshness and lineage
Retrieval-augmented systems answer from whatever documents they are given, so a stale document is a confidently wrong answer with a citation attached. Freshness and provenance become functional requirements rather than hygiene, which is the practical implication of the retrieval-augmented generation architecture. Our guide on how to prepare business data for AI covers the preparation steps in detail.
The EU AI Act names data governance explicitly
For high-risk systems, Article 10 of the EU AI Act requires training, validation and testing datasets to be relevant, sufficiently representative and, as far as possible, free of errors and complete. That is a legal restatement of four of the six dimensions, and it applies to UK organisations selling into the EU.
A ninety-day data quality assessment and remediation plan
Ninety days is enough to measure a domain properly, fix the worst of it and prove the score moved. It is not enough to fix everything, and a data quality assessment plan that promises otherwise will not survive contact with the first duplicate-merge decision.
Weeks 1 to 2: scope and baseline
Agree the decisions in scope, the five to eight critical elements, the systems of record and the sample window. Write the one-page scope. Get read access to the sources — this is reliably the step that slips, so start it on day one.
Weeks 3 to 5: profile and score
Run column profiling, then the rule checklist, then the manual fifty-row read. Produce the scorecard with dimension detail and a reproducible query behind every figure. Present findings as evidence, never as blame; the people in the room did not create the defects on purpose.
Weeks 6 to 9: remediate the top defects
Take the high-impact, low-effort block. Typically that is validity rules at the point of entry, exact duplicate merges, and retiring records past their retention date. Fix the process alongside the data every single time.
Weeks 10 to 13: automate and re-score
Move the agreed rules into the pipeline as automated tests, stand up a simple trend view, and re-run the full scorecard against the same queries. The comparison against week 5 is the deliverable that funds the next domain.
| Phase | Main activity | Effort | Deliverable |
|---|---|---|---|
| Weeks 1 to 2 | Scope, elements, access | 3 to 5 days | Signed one-page scope |
| Weeks 3 to 5 | Profile, rules, manual read | 6 to 10 days | Baseline scorecard |
| Weeks 6 to 9 | Remediate top defects | 8 to 14 days | Cleansed records, changed process |
| Weeks 10 to 13 | Automate checks, re-score | 4 to 7 days | Pipeline tests and trend view |
What a data quality assessment costs
The numbers below are the realistic shape of a data quality assessment for a mid-sized organisation running it internally with light external support, and they are small enough that the business case rarely turns on cost.
The first assessment: fifteen to thirty person-days
Scoping takes three to five days, profiling and rules six to ten, the readout and scorecard two to three. Add days rather than weeks for each additional domain after the first, because the rules and the harness are reusable.
Monitoring: about half a day a week
Once checks are automated, the standing cost is reviewing exceptions and maintaining rules — roughly half a day a week for a single domain. Budget it explicitly, because an unowned rule set decays into noise within two quarters and gets switched off.
Tooling is usually already paid for
Most organisations complete a first data quality assessment with the database, the spreadsheet and the catalogue features in a cloud licence they already hold. Treat a dedicated platform as a later decision, justified by matching, stewardship or audit needs rather than by the assessment itself.
The saving is rework, and it is measurable
The recoverable cost is the time people currently spend reconciling, correcting and re-sending. Count it before you start: hours per week spent chasing bad records, campaign spend on undeliverable contacts, and the delay a migration incurs when it discovers the problem late. HM Treasury’s approach in the service manual guidance on measuring success is a reasonable model for tracking it honestly.
Data quality assessment mistakes that waste the effort
These are the failure modes that turn a good data quality assessment into a document nobody opens. All six are avoidable at the scoping stage and expensive to unwind afterwards.
Profiling everything
Pointing a tool at the whole estate produces thousands of findings, no priority order and a report that gets skimmed once. Scope narrowly, finish, then widen — the second domain always costs a fraction of the first.
Scoring with no threshold
A score with no green, amber and red bands is a number without a decision attached. Worse, thresholds set after the results are known drift to wherever the data happens to sit, which defeats the point entirely.
Cleansing without preventing
A one-off cleanse with no change to the process that caused the defect buys you about a year. This is the single most common way organisations end up running the same assessment twice and getting the same answer.
No owner, no fix
Findings assigned to a department are findings assigned to nobody. Every element in scope needs one named person who can decide, and that person should be in the business rather than in IT.
Running it once
Quality decays continuously as systems change and staff turn over. A data quality assessment repeated on a schedule with the same queries produces a trend line; one run in isolation produces an anecdote.
Confusing it with a migration audit
A migration audit asks whether data will survive a move. A data quality assessment asks whether the data is fit for the decisions it supports — a different question with different tests. The two share techniques and are often run together, but conflating them means one of the two questions goes unanswered. Legacy platforms complicate both, which the government’s guidance on moving away from legacy systems sets out well.
Frequently asked questions about data quality assessment
How long does a data quality assessment take?
Two to four weeks for a first domain of five to eight critical elements, assuming access to the source systems is granted promptly. Access is almost always the long pole, so request it before scoping is finished rather than after.
How often should we repeat the data quality assessment?
Score the critical elements quarterly and re-run the full assessment annually, or after any material change — a system replacement, an acquisition, or a new regulatory requirement. Once checks are automated, the quarterly score costs almost nothing to produce.
Who should run it, IT or the business?
Both, with distinct roles. IT runs the profiling and the queries; the business defines the rules, sets the thresholds and owns the elements. A data quality assessment run entirely by IT produces technically correct findings nobody acts on.
What counts as a good data quality assessment score?
There is no universal figure, which is why thresholds are set per element and per use case. As a working start, 98% completeness and 99% validity on critical fields is reasonable, while uniqueness below 95% almost always warrants immediate attention.
Do we need a tool before we start?
No. A first pass runs on SQL and a spreadsheet, and starting that way forces the rules to be written down in plain language. Buy a platform when repetition and stewardship workflow become the constraint, not before.
How is this different from a data audit?
An audit typically checks compliance against a policy or standard and is often performed by an independent party. A data quality assessment measures fitness for purpose against business rules and is normally run by the team that owns the data. They complement each other, and the evidence from one usually feeds the other.
References
DAMA International — Data Management Body of Knowledge (DMBOK)
EDM Council — Data Management Capability Assessment Model (DCAM)
Dublin Core Metadata Initiative
ICO — Principle (d): Accuracy
ICO — Principle (e): Storage limitation
ICO — Principle (c): Data minimisation
ICO — Accountability and governance
ICO — Advice for small organisations
EU AI Act — Article 10: Data and Data Governance
NIST AI Risk Management Framework
NIST SP 800-30 Rev. 1 — Guide for Conducting Risk Assessments
Microsoft Purview documentation
AWS Glue Data Catalog and crawlers
Google Cloud Dataplex introduction
Microsoft — Understand star schema and the importance for Power BI
GOV.UK Service Manual — Measuring success
GOV.UK — The Technology Code of Practice
GOV.UK Service Manual — Moving away from legacy systems
Martin Fowler — Strangler Fig Application
Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
