TL;DR
Data integrity vs data quality is a split between content and history. Quality means the data is right for the job. Integrity means nobody changed it without approval and a record. One can fail while the other holds. Fix integrity first when totals, keys or change history disagree, then fix quality where values are wrong. Check values with rules, guard changes with controls, and give each its own owner and target.
Key Takeaways
Data quality means data is fit for a specific use, while data integrity means data has changed only through authorized, traceable steps.
The two fail independently: clean values can lack an audit trail, while a wrong value can be preserved perfectly.
Quality is tested with rules on content, such as validation and data tests, across six common dimensions.
Integrity is protected with keys, constraints, reconciliation, access control, audit logs and tested backups.
Fix integrity first when totals, keys or change history cannot be trusted, then clean the values.
Give each property its own owner and its own metrics, because a blended score hides which one failed.
Watch on YouTube
Revolutionizing Data Governance for a Bank with Microsoft Purview
See how Kanerika approached data governance for a bank on Microsoft Purview, the catalog, ownership and policy groundwork that both quality rules and integrity controls rely on.
When a Reconciled Report Is Still Wrong
Picture the Monday after a warehouse migration at a regional distributor, a cutover planned for months. Before lunch, the finance team runs its reconciliation, and every row count and revenue total matches the legacy system to the cent. The migration lead then signs off, and the old system is scheduled for shutdown.
By Thursday, the logistics team has a different story. Hundreds of deliveries have bounced because customer addresses in the new warehouse are years out of date. Soon the support queue fills with calls about missing parcels. Nothing broke in transit. Instead, the addresses were stale in the source, and the migration copied them faithfully.
That one report holds both problems this guide is about. The matching totals prove the data arrived complete and unaltered, which is integrity. The bounced deliveries prove the data was never fit for routing, which is quality. One check passed, and the other was never run.
The mix-up is common because the two words get used as synonyms in meetings, product pages and even some standards. So this guide settles the data integrity vs data quality question with one working model. It then covers how each is measured, who owns it, where its controls sit and which one to fix first when both are failing.
What Is the Difference Between Data Integrity and Data Quality?
Data quality and data integrity answer two different questions about the same records. Quality asks whether the data is fit for a specific use. Integrity asks whether the data has stayed complete, consistent and unaltered, except by authorized and traceable change.
Quality is about the content of a value, while integrity is about the history of that value. A customer’s phone number can be perfectly formatted and still belong to someone else, which is a quality failure. The same number can be correct and then silently overwritten by an unlogged script, which is an integrity failure.
This guide uses that split throughout. Quality is enforced with rules on content, whereas integrity is enforced with controls on change. Because the two fail independently, a team needs evidence for both before anyone trusts a dashboard.
Case Study
60% Less Manual Reconciliation via Snowflake Migration
Kanerika moved a North American beverage manufacturer and distributor from legacy SSAS and hybrid systems to one Snowflake source, cutting manual data reconciliation by 60% and speeding reporting cycles by 40%.
Read the Case Study → What Data Quality Means
Data quality describes how well data serves the job in front of it. For example, the same table can be good enough for a quarterly trend chart but far too sparse for a credit decision. Quality is always judged against a use, so the bar moves when the use changes.
IBM groups data quality into six common dimensions: accuracy, completeness, consistency, validity, uniqueness and timeliness . Each dimension can then become a rule that a pipeline tests on every load. The table below shows the question each one asks, with an example rule.
Dimension Question it asks Example rule
Accuracy Does the value match the real world? Shipping address matches the postal reference file Completeness Are the required fields filled? Email is present on every active customer row Consistency Do systems agree on the same fact? Customer status matches between CRM and billing Validity Does the value follow the expected format and range? Order date is a real date and not in the future Uniqueness Is each entity recorded once? One row per customer ID Timeliness Is the data fresh enough for the decision? Inventory feed is less than 15 minutes old
Some frameworks add further dimensions, such as relevance or accessibility, although the core set rarely changes. The UK Government Data Quality Framework, published in December 2020, lists the same six core dimensions, as defined by DAMA UK . The six above cover what data teams test day to day, and each maps cleanly to an automated check.
What Data Integrity Means
NIST defines data integrity as a property whereby data “has not been altered in an unauthorized manner ” since it was created, transmitted or stored. That definition says nothing about whether the data was right to begin with. Its focus is protection, from creation through storage and transfer.
Regulated industries define it more broadly. The FDA’s December 2018 guidance for drug manufacturers defines data integrity as “the completeness, consistency, and accuracy of data ” and asks for ALCOA records. ALCOA stands for attributable, legible, contemporaneously recorded, original or a true copy, and accurate.
The FDA wording overlaps with quality, since it includes accuracy. ALCOA still works mostly as a set of controls on who recorded what, and when. So integrity work leans on audit trails, access control, checksums and data lineage , which shows where each value came from and what changed it.
Types of Data Integrity: Physical and Logical
Integrity splits into two layers. Physical integrity protects stored data from hardware faults, power loss, corruption and disasters. Logical integrity keeps data correct in relation to other data inside a database, and it comes in four types.
Each logical type maps to a database feature that blocks a bad write before it lands. That is the main reason integrity problems are cheaper to prevent than to find.
Type What it protects Typical enforcement
Entity integrity Every row is unique and identifiable Primary key with no null IDs Referential integrity Links between tables stay valid Foreign key constraints Domain integrity Values stay inside an allowed set or range Data types and CHECK constraints User-defined integrity Business rules specific to the organization CHECK rules, triggers and stored procedures
The SQL below shows one constraint for each type on a simple pair of customer and order tables.
CREATE TABLE customers (
customer_id INT PRIMARY KEY, -- entity integrity
email VARCHAR(255) NOT NULL UNIQUE
);
CREATE TABLE orders (
order_id INT PRIMARY KEY, -- entity integrity
customer_id INT NOT NULL
REFERENCES customers (customer_id), -- referential integrity
status VARCHAR(20) NOT NULL
CHECK (status IN ('placed', 'shipped', 'returned')), -- domain integrity
order_total DECIMAL(12,2) NOT NULL,
discount DECIMAL(12,2) NOT NULL DEFAULT 0,
CHECK (discount <= order_total) -- user-defined rule
);Constraints like these stop an orphan order or an unknown status at write time, so bad rows never land. In PostgreSQL , any attempt to store data that would violate a constraint raises an error, even when the value came from a column default. Constraints still cannot tell you whether a valid status is the true one, so quality checks take over there. Automated suites that run these rules across a whole warehouse are covered in our guide to data integrity testing .
Why Sources Draw the Line Differently
When you search this topic, you will find the line drawn in opposite directions. CastorDoc treats integrity as one part of quality. Precisely and IBM go the other way. IBM writes that “data quality is essentially the measure of data integrity,” which makes integrity the wider idea. This guide keeps the two separate, because the fix differs.
None of these views is wrong, since each serves a different audience. A vendor selling quality software has reason to fold integrity in, while a database team has reason to do the reverse. The split in this guide is practical. If the fix is a rule on content, it is quality, whereas a control on change means integrity.
Security sits beside both rather than inside either. In IBM’s words, “data security is the means while data integrity is the goal,” which makes a handy test. Encryption, access policies and data security tooling protect integrity, but they do not replace it.
Checklist
Data Governance Checklist
Confirm that owners, policies, quality rules and change controls are all in place before you scale checks across more data, using Kanerika’s Data Governance Checklist.
Get the Checklist → Data Integrity vs Data Quality: Side-by-Side Comparison
A side-by-side view helps when two teams argue over whose problem a broken report is. Each row below names one concrete difference, from the first control to the regulation that cares about it.
Use the table as a diagnostic tool. When a symptom fits the integrity column, start with logs, constraints and reconciliation. When it fits the quality column, start with profiling and rules.
Aspect Data quality Data integrity
Question answered Is this data fit for this use? Has this data changed only through authorized, traceable steps? Scope The content of values, judged against a use Completeness and consistency across the data’s life Failure signal Wrong, missing, stale or duplicate values Mismatched totals, orphan records, unexplained edits Typical cause Poor entry, weak source systems, no standards Failed loads, broken keys, unlogged scripts, loose access First control Validation rules and data tests Constraints, reconciliation and audit logs How it is measured Rule pass rate, completeness, freshness Count and checksum variance, orphan keys, unauthorized changes Usual owner Business data owner and data steward Data engineering, DBA and platform teams Regulation hook GDPR accuracy principle FDA ALCOA; GDPR integrity and confidentiality Typical tooling Data tests, Purview Unified Catalog data quality, observability Database constraints, checksums, backups, audit trails
The rows also show why one tool rarely covers both. A data test can flag a null email, but it cannot prove who changed a price last night. An audit log can prove who changed the price, but it cannot say whether the new price is right.
Can Data Have High Quality but Poor Integrity?
Yes, and the reverse happens just as often. Plotting the two properties against each other gives four conditions, so each one calls for a different response.
High quality with high integrity is the goal. For example, a product catalog with validated prices, a primary key on every SKU and an audit trail on price edits sits here.
High quality with low integrity looks fine today but cannot be trusted tomorrow. For instance, imagine an accurate patient allergy list kept in a shared spreadsheet that anyone can edit, with no history. Nobody can prove the values have not drifted, so an auditor would reject it.
Low quality with high integrity, in contrast, is the trap from the opening scenario. The stale addresses were copied with perfect fidelity, every checksum passed and the logs were clean. The integrity controls preserved a wrong value exactly as it was.
Low quality with low integrity is the worst case. Duplicate supplier records, edited by several teams with no log, give wrong answers and no way to trace how they got that way. The fix starts with integrity, as the section on which to fix first explains.
Real data estates, though, rarely sit in one quadrant. A finance mart may be strong on both while the CRM that feeds it is weak on both. So it pays to score each set of critical data separately instead of the whole estate at once.
Where Each Control Sits in the Data Lifecycle
Quality and integrity controls belong at different points in a pipeline. Data gets captured, moved, transformed, stored and served, and each step fails in its own way.
At capture, quality leads, because a wrong value typed into a form is cheapest to stop before it spreads to every system downstream. Our guide to data validation covers rule design in more detail.
During transfer, integrity takes the lead, because the values are already set and the risk is losing or mangling them. Each hop through data ingestion jobs or a wider data pipeline architecture can drop rows, duplicate them or truncate fields. A quality rule run on the rows that survive would still never notice the loss.
Transformation needs both at once. A join can silently drop records, which breaks integrity, while a wrong business rule can produce a valid-looking but incorrect metric. Tests on each data transformation step should check keys and values together.
In storage, integrity carries most of the weight, since stored data is what scripts, users and hardware faults can alter. When data is served to reports and models, quality leads again: freshness and completeness decide whether a dashboard can be trusted that morning.
Stage Quality rule Integrity control
Capture Format, range and required-field validation Source logging of who entered what, and when Transfer Schema checks on arrival Row counts, checksums and load logs Transform Business-rule and accepted-value tests Key and relationship tests; no dropped rows Store Duplicate detection Constraints, access control, backups and restore tests Serve Freshness and completeness checks Lineage and change history on published metrics
Tools by Control Type
Tooling follows the same split, with some overlap. dbt ships four generic data tests: unique, not_null, accepted_values and relationships . The first two guard entity integrity, accepted_values checks domain validity and relationships checks referential integrity. The YAML below applies all four to the orders table from the SQL example. Since dbt v1.10.5, test inputs sit under an arguments block.
models:
- name: orders
columns:
- name: order_id
data_tests:
- unique
- not_null
- name: status
data_tests:
- accepted_values:
arguments:
values: ['placed', 'shipped', 'returned']
- name: customer_id
data_tests:
- relationships:
arguments:
to: ref('customers')
field: customer_idOne tool can cover parts of both properties, as long as the team knows which test protects which.
On the quality side, data quality in Microsoft Purview Unified Catalog applies no-code and low-code rules at column level, including out-of-the-box and AI-generated rules. Its out-of-the-box rules cover six dimensions under slightly different names: completeness, consistency, conformity, accuracy, freshness and uniqueness. Conformity and freshness are close cousins of IBM’s validity and timeliness. Scores then roll up to data assets, data products and governance domains. Our Microsoft Purview overview explains how that fits a wider governance setup.
On the integrity side, ledger tables add tamper-evidence in SQL Server 2022 and later, Azure SQL Database and Azure SQL Managed Instance. Microsoft’s ledger overview explains that changed rows are SHA-256 hashed into a chain, while previous values stay in a history table. The sketch below creates a ledger table for prices, then asks who changed a price and when.
-- SQL Server 2022+, Azure SQL: updatable ledger table
CREATE TABLE dbo.price_list
(
sku VARCHAR(20) NOT NULL PRIMARY KEY CLUSTERED,
list_price DECIMAL(10,2) NOT NULL
)
WITH
(
SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.price_list_history),
LEDGER = ON
);
-- Who changed each price, and when
SELECT t.commit_time, t.principal_name,
l.sku, l.list_price, l.ledger_operation_type_desc
FROM dbo.price_list_Ledger AS l
JOIN sys.database_ledger_transactions AS t
ON t.transaction_id = l.ledger_transaction_id
ORDER BY t.commit_time DESC;For ongoing monitoring of freshness, volume and schema drift, data observability tools sit on top of both. A wider shortlist of platforms, as well as their trade-offs, appears in our review of data governance tools .
How to Measure Data Quality and Data Integrity
Each property needs its own numbers. A single “data health” score that blends quality and integrity hides which one failed, and so it hides who should fix it.
Quality metrics count how often values pass the rules for a use. Integrity metrics instead count breaks in the chain of custody: rows lost between systems, keys that point nowhere and changes nobody approved. Data profiling gives the baseline for both before anyone sets a threshold.
The thresholds below are illustrative starting points rather than industry benchmarks. Set your own per dataset, based on what the downstream decision can tolerate.
Property KPI Formula Example threshold (illustrative)
Quality Rule pass rate Rows passing all rules ÷ rows tested 99% or higher on critical tables Quality Completeness Filled required fields ÷ total required fields 98% or higher Quality Duplicate rate Duplicate entity rows ÷ total rows 0.5% or lower Quality Freshness lag Current time minus last successful load 1 hour or less for daily reporting Integrity Reconciliation variance (Target total minus source total) ÷ source total 0% on financial totals Integrity Orphan-key count Child rows with no matching parent row 0 Integrity Unauthorized changes Changes made without an approved role or ticket 0 Integrity Restore-test pass rate Successful restore tests ÷ scheduled restore tests 100% each quarter
Track the integrity numbers per load rather than per month. A reconciliation gap found the next morning means a rerun, while one found at quarter close can mean a restatement. For a wider view of trust signals across pipelines, see our post on data reliability .
On-Demand Webinar
On-Demand Webinar: Data Strategy with Microsoft Purview
Watch Kanerika’s on-demand session on building a data strategy with Microsoft Purview, the platform behind the column-level quality scores described earlier.
Watch the Webinar → Who Owns Data Quality and Data Integrity?
Ownership is where many programs stall, because quality and integrity fail in different hands. A business team knows whether a value is right for its use. A platform team controls how that value is stored, moved and changed.
That split argues for shared but separate accountability. The data owner decides what fit for use means and then signs off on thresholds. Engineers and DBAs build the controls that keep data whole, while security decides who may change what.
The table below is a starting RACI, where R is responsible, A is accountable, C is consulted and I is informed. Each property gets exactly one accountable role.
Role Data quality Data integrity
Data owner (business) A: defines rules and thresholds C: approves who may change the data Data steward R: monitors rules and triages issues C: reviews change exceptions Data engineering R: builds tests into pipelines R: builds reconciliation and load checks DBA or platform lead C: supports profiling A: keys, constraints, backups and restore tests Security I: told of quality incidents R: access control and audit logs Compliance C: maps rules to regulation C: confirms audit evidence
Write these roles into policy rather than a slide deck. Our posts on data stewardship and data governance principles cover the steward role in more depth. For where the wider policy sits, see data governance vs information governance .
Kanerika Service
Data Governance Services
Kanerika sets up data ownership, cataloging and controls with KANGovern, powered by Microsoft Purview and Databricks Unity Catalog, so quality rules and integrity checks have clear owners.
Explore Data Governance What Poor Quality and Broken Integrity Cost
The two failures cost money in different ways. Poor quality produces confident wrong answers, such as bounced deliveries, wrong invoices and forecasts built on duplicate records. Broken integrity produces answers nobody can defend, which shows up as rework, restatements and failed audits.
Integrity failures are harder to price than quality failures. Their cost often lands later, when an auditor or a customer asks how a number was produced. At the extreme, a destructive event can leave data unusable. NIST’s practice guide SP 1800-25 , published in December 2020, treats ransomware as a data integrity attack and explores backups and secure storage as defenses.
The biggest hidden cost is time. Analysts who cannot trust a figure rebuild it by hand from source extracts, and that work grows with every new system. Manual reconciliation of this kind is the kind of work the case study later in this guide cut by 60%.
Regulated Data: Where the Rules Name Both
Some regulations ask for both properties by name. GDPR Article 5 requires personal data to be “accurate and, where necessary, kept up to date ” under its accuracy principle. The same article sets a separate principle of “integrity and confidentiality” for protecting that data.
Drug manufacturers also face the FDA’s ALCOA expectations described earlier. In the UK, the MHRA’s GxP data integrity guidance , first published in March 2018, sets out data integrity expectations for regulated organizations. For these teams, an accurate record with no audit trail is still a finding, and so is a perfect audit trail on a wrong record. Regulated programs should be able to show evidence for both columns of the comparison table.
Why Both Decide Whether AI Projects Ship
AI systems are less forgiving than dashboards. A person reading a report may notice a strange number, but a model trained on it absorbs the error and repeats it at scale.
In February 2025, Gartner warned that through 2026, organizations will abandon 60% of AI projects unsupported by AI-ready data . The same release said 63% of organizations either lack the right data management practices for AI or are unsure whether they have them.
Both properties feed that readiness. Quality decides whether training data and retrieval sources are accurate and current. Integrity decides whether you can prove which version of the data a model saw, which matters when a prediction is challenged.
Retrieval-augmented generation makes this concrete. If an outdated policy document sits in the search index, the assistant answers wrongly, and that is a quality failure. If someone later edits the document with no version history, nobody can explain yesterday’s answer, which is an integrity failure.
Teams adopting generative AI for data analytics should budget for both controls from the first pilot. The same goes for AI platforms for data management , which automate profiling and matching but still need clean inputs and logged change.
Data Integrity vs Data Quality: Which Should You Fix First?
Start with integrity when you cannot trust how data moves or changes. Start with quality when the plumbing is sound but the values are wrong for the job. A leaky pipeline undoes a cleanup by the next load. Cleaning data that can still be silently dropped or altered is work you will end up repeating.
The symptoms users report usually point the way. Match what you are seeing to the rows below, then read the first fix from the right-hand column.
Symptom Likely cause Fix first
Totals differ between the source and the report Failed or partial loads Integrity: reconciliation and load checks Report rows have no matching parent record Broken keys Integrity: referential constraints and tests A value changed and nobody knows who changed it Loose access or no logging Integrity: audit trail and access review The same customer appears three times No matching or entry standards Quality: deduplication and uniqueness rules Dashboards show last week’s data Late or failed refresh Quality: freshness monitoring Values are in the wrong format or out of range No validation at capture Quality: validation rules at entry
When symptoms from both halves show up together, fix the integrity rows first and then clean. Quality scores also mean little until you know every load is complete.
Thresholds make the call less of a debate. Using the illustrative targets from the measurement table, any reconciliation variance on financial totals or any orphan key puts integrity first. If both read zero and the rule pass rate on critical tables sits below 99%, quality comes first. When every number is on target, keep both checks running and fix whichever one slips.
Worked Example: Controls During a Cloud Migration
Migrations are where the two properties most often get confused, because reconciliation feels like proof of everything. A sound order of work looks like this:
Profile the source first, so known quality issues are logged before anything moves.
Decide which issues to clean before the move and which to carry and fix later, with an owner for each.
Reconcile each load with row counts and checksums on key tables, and block sign-off on any variance.
Rebuild primary keys, foreign keys and check constraints in the target, then test for orphan records.
Run the quality rules from step 1 on the target, then compare the scores with the source baseline.
Turn on audit logging and role-based access before users get write access.
The reconciliation in step 3 needs only a short query. This sketch compares row counts and an order-total sum, then counts orphan orders in the target.
-- Step 3: counts and control totals must match before sign-off
-- (on two different engines, run each half separately)
SELECT 'source' AS side, COUNT(*) AS row_count, SUM(order_total) AS total_value
FROM legacy.orders
UNION ALL
SELECT 'target', COUNT(*), SUM(order_total)
FROM warehouse.orders;
-- Step 4: orphan orders with no parent customer (expect 0)
SELECT COUNT(*) AS orphan_orders
FROM warehouse.orders AS o
LEFT JOIN warehouse.customers AS c
ON c.customer_id = o.customer_id
WHERE c.customer_id IS NULL;Step 3 proves integrity, while steps 1 and 5 prove quality. The opening scenario skipped steps 1 and 5, so a fully reconciled warehouse still shipped stale addresses. Our enterprise data migration guide covers the wider plan, while data cleaning explains the quality fixes behind step 2.
Best Practices That Protect Both
The eight practices below fall into three groups. Practice 1 is shared, because both rule sets should start with the data that matters most. Practices 2 and 8 are quality work, while practices 3 to 7 are integrity controls on keys, loads, logs, access and backups.
Start with critical data, then add constraints and reconciliation, which is the same order the migration example follows. None of these steps needs a new platform before it can start.
Name your critical data elements first, because not every column deserves a rule.
Write quality rules with the business owner, so thresholds match real decisions.
Enforce keys and constraints in the database, since a blocked write costs less than a cleanup.
Reconcile every load with counts and checksums, so lost rows are caught the same day.
Log every change with who, what and when, so disputes become simple lookups.
Limit write access by role, so fewer people and scripts can alter data.
Test backups by restoring them, because an untested backup is only a hope.
Report quality and integrity scores separately, so each owner sees their own number.
Practice 6 is where security and integrity meet, so our guide to data security best practices goes deeper on it. To turn the whole list into a repeatable cycle, our data quality framework guide walks through the build.
Three Misconceptions About Data Integrity and Data Quality
A few beliefs keep the two properties tangled long after a team has learned the definitions. Each one below sounds reasonable, yet it leaves a gap that only shows up later.
1. Clean Data Stays Clean
Data decays as customers move, products change and systems get added. Take a customer table that is 98% complete after a cleanup. Within a year, people have moved house and changed email, but nothing flags the drift.
A one-time cleanup fades within months unless rules run on every load. Treat quality as a check that repeats rather than a project that ends.
2. Security Tools Guarantee Integrity
Access control and encryption reduce the risk of unauthorized change. They still do not catch a failed load, a broken key or an authorized user running the wrong script.
An engineer with full rights passes every access check, even when the UPDATE they run has no WHERE clause. One statement can still overwrite a whole column, which is why integrity also needs logs, reconciliation and tested backups.
3. Validation at Entry Fixes Everything
Validation stops badly formatted values at the door. It cannot judge whether a well-formed value is true. For example, a form will happily accept a valid postal code that belongs to a different street.
It also does nothing about errors added later in the pipeline. A nightly join that drops rows does its damage long after every entry check has passed.
How Kanerika Improves Data Quality and Integrity
Kanerika treats quality and integrity as two workstreams under one plan. The work usually moves through four stages, each with its own evidence.
The team first assesses the critical data that drives revenue, compliance or AI use cases, and profiles it for both kinds of failure. After that, the team sets quality rules and integrity controls, each with a named owner and a threshold. The third stage automates those checks in the pipeline and the platform, a pattern we describe in our post on Snowflake data governance . The last stage reports both scores separately, so owners can see progress.
What the Case Studies Show
A beverage manufacturer and distributor supporting bottling operations across North America shows the pattern. Its legacy SSAS and hybrid systems caused outages and allowed only hourly refresh. Kanerika moved it to a unified Snowflake architecture, with Fivetran ingestion and Power BI reporting on Snowflake.
The case study reports 60% less manual reconciliation, 40% faster reporting cycles and $130K a year in license and maintenance savings. Read through this guide’s lens, the drop in manual reconciliation is an integrity result, because one reconciled source replaced several. Fresher, near-real-time data is the quality side of the same move.
Two other engagements show each side on its own. In an insurance premium reconciliation project, Kanerika used UiPath bots and Python scripts to match bank statements against insurance system records. The case study reports reconciliation time cut by 85%, with the monthly cycle down from five days to a few hours. It also reports 99% accuracy in data extraction and premium status updates. Automated Excel reports also served as audit-ready logs, which is integrity evidence beside a quality gain.
For a bank running Microsoft Purview , the work was mostly integrity. Kanerika automated data classification and lineage, and set sharing rules by data type and sensitivity to prevent unauthorized access.
Our data governance services use KANGovern, powered by Microsoft Purview and Databricks Unity Catalog, to catalog data and set ownership and controls. Teams earlier in the journey can start with data strategy consulting to rank which data to fix first.
Talk to Kanerika
Find Out Where Your Data Breaks First
Talk to Kanerika about profiling your critical data, setting quality rules and integrity controls, and reporting both scores to the people who own them.
Schedule a Demo → Data Integrity vs Data Quality: The Bottom Line
Data quality and data integrity are different properties with different owners. Quality asks whether data is fit for a use and is enforced with rules on content. Integrity asks whether data stayed complete and unaltered except by authorized change, and it is enforced with controls on change.
Measure each with its own numbers and give each a named owner. Then answer the data integrity vs data quality question in order. Fix integrity first wherever totals, keys or change history cannot be trusted. Then fix quality where the values fail the job.
Frequently Asked Questions
What is the difference between data quality and data integrity?
Data quality asks whether data is fit for a specific use, judged on accuracy, completeness, consistency, validity, uniqueness and timeliness. Data integrity asks whether data has stayed complete and unaltered except by authorized, traceable change. Quality is enforced with rules on content, and integrity is enforced with controls on change such as constraints, reconciliation and audit logs.
What are examples of data integrity?
A primary key that stops two customers sharing one ID is an example. So is a foreign key that blocks an order pointing to a missing customer. Others include row counts and checksums that prove a load arrived whole, audit logs recording who changed a record, and restore tests showing backups bring data back exactly as it was.
How do you ensure data integrity and data quality?
Start by naming your critical data and an owner for each dataset. Enforce keys and constraints in the database, reconcile every load, log every change and limit write access by role. Then write quality rules with the business owner, test them in the pipeline, and report quality and integrity scores separately so gaps stay visible.
Can data have high quality but poor integrity?
Yes. An accurate, complete patient allergy list kept in a shared spreadsheet with no change history has good quality today but poor integrity, because nobody can prove the values have not been altered. The reverse also happens, when a wrong value is copied perfectly through every system and passes every checksum along the way.
What is the difference between data integrity and data security?
Data security covers the means of protecting data, such as encryption, access control and threat monitoring. Data integrity is the goal that data stays complete and unaltered except by authorized change. IBM describes security as the means and integrity as the goal, and integrity also needs keys, reconciliation and backups that security tools do not provide.
What is an example of data integrity in SQL?
A foreign key is the classic example. Declaring that orders.customer_id references customers.customer_id makes the database reject any order for a customer that does not exist. A primary key enforces entity integrity, a CHECK constraint keeps a status column inside an allowed list, and NOT NULL stops a required field from being left empty.
Why does data integrity matter during data migration?
Every hop in a migration can drop, duplicate or truncate records, so integrity checks prove the data arrived whole. Teams reconcile row counts and checksums on each load, rebuild keys and constraints in the target, and test for orphan records. Integrity alone is not enough, because stale source values can migrate perfectly and still be wrong.
How do data quality and data integrity affect AI projects?
Models and retrieval systems repeat whatever their data contains, at scale. Poor quality gives them wrong or outdated facts to learn from. Weak integrity means nobody can prove which version of the data a model used when a prediction is challenged. Gartner warned in 2025 that many AI projects lacking AI-ready data will be abandoned.
Does data validation guarantee data integrity?
No. Validation checks that a value has the right format, type and range when it enters a system, which supports quality. It does not stop a later load from dropping rows, a script from overwriting records, or a user from changing data without a log. Integrity needs constraints, reconciliation, access control and audit trails as well.
Should you fix data quality or data integrity first?
Fix integrity first when totals disagree between systems, records lose their parents, or nobody can say who changed a value. Cleaning data that can still be silently altered or dropped only lasts until the next load. Once loads are complete and changes are logged, fix quality issues such as duplicates, stale values and bad formats.
Who is responsible for data quality and data integrity?
Data quality is usually owned by the business data owner, who defines what fit for use means, with stewards monitoring the rules. Data integrity usually sits with the DBA or platform lead, supported by data engineering for reconciliation and security for access control. Each property should have exactly one accountable role, written into governance policy.
What are the 4 types of data integrity?
The four types of logical data integrity are entity, referential, domain and user-defined integrity. Entity integrity keeps every row unique, usually through a primary key. Referential integrity keeps links between tables valid with foreign keys. Domain integrity keeps values inside an allowed type or range, and user-defined integrity enforces business rules specific to the organization.
What are the 5 pillars of data integrity?
The five pillars usually refer to ALCOA, which the FDA uses for regulated records. Data should be attributable to the person who created it, legible, contemporaneously recorded, original or a true copy, and accurate. The FDA describes data integrity itself as the completeness, consistency and accuracy of data, so ALCOA turns that idea into checkable record controls.
How do you identify data integrity issues?
Compare row counts and totals between source and target after every load, since a mismatch signals lost or duplicated data. Look for orphan records whose foreign keys point nowhere. Review audit logs for changes with no approved user or ticket. Restore a backup on a schedule and confirm that the restored data matches the original exactly.
How do you measure data integrity?
Track reconciliation variance between source and target totals, the count of orphan keys, and the number of changes made without an approved role or ticket. Add a restore-test pass rate for backups. Measure these per load rather than per month, because a gap caught the next morning is a rerun while one caught at quarter close is a restatement.
What are the dimensions of data quality?
IBM lists six common dimensions of data quality, namely accuracy, completeness, consistency, validity, uniqueness and timeliness. Each one can become a rule that a pipeline tests on every load. Some frameworks add more, such as relevance, accessibility or integrity, which is why you may see lists of seven, eight or nine dimensions.
What are the 7 data quality metrics?
A practical set of seven covers rule pass rate, completeness percentage, duplicate rate, validity rate, consistency between systems, freshness lag and the number of open data issues. Each should be measured per dataset against a threshold the business owner sets. Report them apart from integrity metrics so each owner can see the number they are accountable for.
What is the ISO standard for data quality?
ISO 8000 is the international standard series for data quality, published by the International Organization for Standardization. Organizations use it as a shared reference when they write internal data quality policies, set terms with suppliers or agree on data exchange with partners. In practice, teams pair it with their own rules, owners and thresholds for each critical dataset.
What is the difference between QA and data quality?
Quality assurance usually means testing software or processes to confirm they work as designed before release. Data quality is a property of the data itself, judged against how it will be used. A well-tested application can still store stale or duplicate records, so data quality needs its own rules, owners and monitoring after go-live.
