- Data integrity addresses whether data was altered without authorization after creation, transmission, or storage.
- Deletion and destruction are related control concerns, but they are not part of the quoted NIST definition.
- Data integrity, data quality, and data security overlap, but each answers a different control question.
- Governance, lineage, observable pipelines, and defined quality measures give you more context for analytics and AI.
When a number changes without an authorized reason or a clear record, your team has more than a reporting problem. You need to know whether the data was altered without authorization, where the change occurred, and which records can explain it.
Data integrity addresses that specific risk. This guide separates integrity from quality and security, then offers a practical control checklist that also treats deletion and destruction as related operating concerns.
What Is Data Integrity?
Data integrity describes whether data remains protected from unauthorized alteration after it is created, transmitted, or stored. The National Institute of Standards and Technology (NIST) provides a precise definition. The NIST data integrity definition states: “A property whereby data has not been altered in an unauthorized manner since it was created, transmitted, or stored.”
That narrow definition gives you a clear control question: Was the change authorized? You can then examine who changed a record, when the change occurred, and which approval or system record applies.
Deletion and destruction are related operating concerns, but NIST does not include them in the quoted definition above. You can review deletion permissions, retention decisions, and overwrite processes without attributing those concerns to NIST.
Suppose a revenue field enters a system with the wrong value. If nobody later alters it without authorization, the field may pass an integrity check while still failing an accuracy test.
Calling all dependable data “high integrity” blurs the work your team needs to do. A narrower definition helps you separate authorization checks from quality measures such as accuracy, completeness, timeliness, or fitness for a specific use.
How Does Data Integrity Differ From Quality and Security?
ThoughtSpot's data reliability framework offers related context, but data integrity, data quality, and data security are not synonyms. Use the table below as a working distinction for assigning questions and reviews.
| Concept | Primary question | Practical review focus |
|---|---|---|
| Data integrity | Was data altered without authorization? | Change authorization, traceability, and the state of data across storage and transmission |
| Data quality | Does the data meet defined needs for this use? | Selected measures, which may include accuracy, completeness, consistency, timeliness, or validity |
| Data security | Is access or action authorized? | Authentication, authorization, access review, monitoring, and system protection |
Under this working model, integrity focuses on unauthorized alteration. Security has a wider access scope, while quality depends on criteria your team defines for a specific use.
The boundaries can overlap. For example, a write-permission review can support security and integrity work, but it does not assess whether an approved value is accurate.
For analytics and machine learning (ML), the International Organization for Standardization (ISO) provides ISO/IEC 5259-2:2024. ISO says it defines a model and measurable data quality characteristics for assessing and reporting data quality. Treat it as a data-quality reference rather than an integrity standard or an outcome guarantee.
What Types of Data Integrity Controls Matter?
For planning purposes, you can group controls into logical, physical, and process categories. Use the categories as an operational checklist, then adapt them to your systems, ownership model, and risk review.
ThoughtSpot's enterprise data governance basics can help you connect that checklist to definitions, owners, and review steps. The point is to make each rule, exception, and decision visible to the people responsible for it.
Entity, Referential, Domain, and Business-Rule Integrity
As a practical checklist, entity integrity asks whether each record has a unique identifier. For a customer table, you might review whether updates can target one record without relying on an ambiguous match.
Referential integrity asks whether relationships between records follow your defined rules. If an order references a customer, your review can check whether the related record exists or an approved exception applies.
Domain integrity asks whether a value fits an accepted set, type, format, or range. A team might check date formats or compare a status field with its governed list of permitted values.
Business-rule integrity asks whether data follows organization-specific definitions and constraints. Examples could include a metric calculation, account classification, or approval state maintained outside basic database types.
These four categories can help you review identity, relationships, permitted values, and business-specific constraints. They are checklist labels, not proof that every stored value is accurate or fit for use.
Physical and Process Integrity
For a physical-integrity review, consider how data is stored, transmitted, overwritten, and deleted. Questions may cover write access, storage events, transfer records, and whether an authorized copy can be traced.
For a process-integrity review, examine how people and systems request, approve, validate, and record changes. Version history and approval records can give reviewers context when an update needs investigation.
Use logical, physical, and process checks together when that combination fits your environment. A database rule and an approval record answer different questions, so neither should be treated as a complete integrity verdict.
Where Does Data Integrity Break Down?
Use the data lifecycle as a review path rather than a universal threat model. At creation, ask whether identifiers, relationships, and domain rules match the design your team approved.
During transmission, check whether records changed, were truncated, or mapped to an unexpected field. Can your team trace a value from its source through each pipeline step?
For stored data, review who can write, overwrite, or delete records. Then check whether the current state can be compared with an authorized history or version record.
During use, ask whether calculations and joins follow the governed definition. If results differ, record whether the cause was a data change, a logic change, or a separate quality issue.
ThoughtSpot's data lineage tracking guide can help you plan how to document sources, movements, and dependencies. Your implementation will depend on the systems and review needs in scope.
At retirement, consider deletion authorization, dependencies, and documentation. Treat legal or regulatory requirements as a separate, sector-specific review rather than assuming one rule applies everywhere.
Across the lifecycle, unexplained change is a useful prompt for investigation. Ownership records, validation results, lineage, and approvals are examples of evidence your team can look for.
How Can You Protect Data Integrity Across the Lifecycle?
Build your lifecycle checklist around creation, transmission, storage, use, change, and retirement. For each stage, record the question you are testing, the owner, the review method, and the evidence you expect to retain.
At creation, your checklist might include schemas, domain restrictions, unique identifiers, and relationship checks. During transmission, you might review formats, pipeline records, and reconciliations that fit the workflow.
For stored data, consider role-based write and delete permissions, version history, and change records. Documented approval paths can give reviewers context when they compare two states.
During use, connect calculations and relationships to governed definitions. When logic changes, consider recording the reason, reviewer, effective date, and affected downstream assets.
Teams seeking analytics data quality management guidance can review the linked ISO resource as part of their own source assessment. Do not treat the resource as an integrity standard, certification, or outcome guarantee.
A broader operating model can draw from ThoughtSpot's practical data governance implementation steps. Adapt the sequence to your owners, definitions, review process, and escalation path.
Define Ownership and Governed Rules
Your ownership checklist can name people responsible for key entities, domains, relationships, metrics, and approval workflows. For each item, record who reviews changes, who approves them, and how exceptions are documented.
Keep integrity checks separate from quality measures in that checklist. Access rules and change history can address authorization questions, while selected measures assess whether data fits a particular use.
Governed business definitions also need a named decision path. If two groups calculate the same metric differently, the record state alone cannot decide which definition should guide a Liveboard or an AI answer.
Give analysts and data engineers a clear place to find current definitions, dependencies, owners, and change dates. That record becomes a review aid rather than a promise that every use is correct.
Monitor Changes, Pipelines, and Lineage
For monitoring, decide which source, movement, and change records your team needs to inspect. You can also map lineage from pipelines to reports, models, metrics, and other downstream assets.
Review change records separately from validation results. A completed pipeline run and a valid data value answer different questions, so your checklist can include both.
Use ThoughtSpot's data quality monitoring guide to select measures relevant to the use case. Keep those measures distinct from the authorization question at the center of integrity.
When a result changes, follow a repeatable investigation. Confirm the governed definition, trace lineage, inspect pipeline records, review authorized changes, and check the selected quality measures.
How Does Data Integrity Support Analytics and Agentic AI?
Analytics needs more than an authorization check on record changes. Your review can also cover governed definitions, relationships, selected quality measures, and a traceable path from source data to each metric.
Consider a revenue question asked in two departments. An integrity check can examine unauthorized alteration, but it cannot choose between approved revenue definitions or decide which exclusions apply.
That business context belongs in governance and semantic modeling. Shared definitions, calculations, relationships, access rules, and lineage give analysts reference points for reviewing a result.
In the Agentic Semantic Layer overview, ThoughtSpot describes centralized business definitions, metric calculations, relationships, governance, row-level security, and lineage. The same ThoughtSpot overview identifies Spotter, Analyst Studio, and Liveboards as experiences that use governed context for agentic analytics.
This framing connects governed context to how teams review analytics and agentic AI answers. It does not mean integrity alone makes an answer accurate, reliable, or fit for its intended use.
When an answer looks unexpected, your review can trace the source, inspect the definition, examine pipeline records, and check authorized changes. Separate quality measures can then address the use-specific questions that integrity does not answer.
Conclusion
Data integrity has a focused job: determine whether data was altered without authorization after creation, transmission, or storage. Treat deletion and destruction as related control concerns, then review governance, lineage, quality measures, and governed metric definitions separately.
Choose one high-value metric and map it from source data through its governed definition and analytical use. Where are the gaps in authorization records, lineage, validation, ownership, or quality measurement?
