Data Integrity

This topic is part of the SG Systems Global regulatory & operations guide library.

Data Integrity: ensure records are trustworthy—ALCOA evidence, audit trails, controlled access, and defensible decisions.

Updated Jan 2026 • data integrity, ALCOA, audit trails, Part 11, Annex 11, CSV, record retention, access control • Cross-industry

Data integrity is the discipline of ensuring that records are trustworthy—complete, accurate, attributable, and protected from improper change—across the entire data lifecycle. In regulated manufacturing and quality systems, “integrity” is not a philosophical idea. It is the operational basis for batch release, product decisions, investigations, and patient/customer safety. If the data is not trustworthy, the decision built on it is not defensible.

Organizations often confuse data integrity with cybersecurity or data quality. Security protects against unauthorized access; quality focuses on fitness for use; integrity proves the record is what it claims to be and has not been manipulated, silently corrupted, or detached from its context. That context includes metadata (timestamps, user IDs, versions), audit trails, and the procedural controls that ensure people cannot rewrite history when something goes wrong.

Data integrity matters most when pressure is highest: a deviation investigation, an out-of-spec event, a supplier dispute, a batch disposition decision, or an audit. In those moments, the organization either has a reliable evidence chain—or it has arguments. Integrity is what prevents “we think it happened this way” from replacing “we can prove it happened this way.”

“If the record can be rewritten, it isn’t evidence.”

1) What data integrity actually means

Data integrity means that your records can be trusted as evidence. In practical terms, integrity proves that:

• Records are attributable: you can reliably answer “who did what, when, and why.”
• Records are complete: there are no missing results, missing batches, missing audit trail entries, or missing attachments.
• Records are consistent: timestamps, versions, and state transitions are coherent and reproducible.
• Records are protected: unauthorized changes are prevented and detectable, including attempted deletion or backdating.
• Records remain usable: they can be retrieved, interpreted, and reviewed years later under retention rules.

Integrity is not limited to “data values.” It includes the context that gives values meaning: instruments, methods, units, versions, approvals, and trace links. A temperature reading without calibration status is not trustworthy evidence. A “pass” result without the test method revision is not defensible. A batch record without an audit trail is just a story.

In regulated environments—pharma, medical devices, food safety, and other high-consequence manufacturing—integrity is the bedrock that supports release decisions, investigations, and regulatory confidence. Break integrity, and everything else becomes negotiable.

2) Why data integrity is non-negotiable

There are four forcing functions that make integrity real:

The hard truth: integrity failures are expensive because they create “unprovable reality.” When data cannot be trusted, organizations respond by over-testing, repeating work, widening batch holds, and escalating to management review. Even when product is safe, the inability to prove it is safe becomes the operational bottleneck.

Integrity failures are also contagious. Once people believe records can be altered, they change behavior: “capture it later,” “fix the value,” “update the spreadsheet,” “we’ll reconcile after.” That cultural drift destroys evidence quality faster than any technical weakness.

3) Data integrity vs quality vs security

Teams often mix these concepts and design the wrong controls.

Security without integrity is common: strong perimeter controls, weak internal governance, and privileged users who can rewrite history. Integrity without security is also possible: great audit trails, weak access controls, and high likelihood of unauthorized access. In regulated work, you need both—but integrity is the piece that makes records defensible.

4) The data lifecycle: where integrity is won or lost

Integrity is not a single control. It is the outcome of controls across the data lifecycle:

• Creation: how data is generated (instrument, system, manual entry), including method and version.
• Processing: calculations, transformations, and derived results—where hidden manipulation often occurs.
• Review: approval workflows, exception handling, and escalation pathways (see approval workflow).
• Reporting: summaries, dashboards, and PDF reports that can detach from underlying truth.
• Storage: where records live, how they are protected, and how audit trails are preserved.
• Retrieval: ability to reproduce the record context during audits and investigations.
• Retention/archival: long-term preservation under record retention rules.
• Disposition: controlled destruction when retention ends, with documented rationale.

Most integrity programs fail because they focus on storage and ignore creation and processing. That is backwards. If the record is compromised at capture, no amount of retention policy can fix it later.

5) Define scope: what counts as a record

Integrity begins with a ruthless scope definition. If you don’t define what is a controlled record, people will define it for you—usually in a way that reduces accountability.

A practical scope map includes:

• Quality records: deviations, investigations, approvals, CAPA (see deviation management and CAPA).
• Manufacturing records: batch documentation such as BMR and electronic equivalents like EBR.
• Device records: device history evidence (DHR / eDHR).
• Laboratory records: results, calculations, and review history (often linked to LIMS).
• Master data: controlled recipes, BOMs, specifications, and parameter limits (see master data control).
• Metadata: timestamps, user IDs, versions, and the audit trail itself.
• Attachments: PDFs, images, raw data files, instrument exports—often the easiest place to hide manipulation.

Scope must also include “shadow systems”: spreadsheets, local folders, shared drives, and ad-hoc databases. If critical calculations happen in Excel outside controlled systems, your integrity risk lives there—not in the validated application you proudly show auditors.

6) ALCOA in practice: evidence, not slogans

ALCOA is the most common shorthand for integrity expectations. The value of ALCOA is not the acronym—it’s the testable behaviors it forces:

• Attributable: unique identity, controlled access, and reliable user attribution.
• Legible: records must be readable and interpretable long-term (including electronic readability).
• Contemporaneous: events are recorded when they occur, not reconstructed later.
• Original: preserve source data and the first capture of the record (and protect it from overwrite).
• Accurate: values are correct, calculations are controlled, and errors are detectable.

ALCOA breaks down when organizations treat it like training content. You can’t “train” your way out of a system where users can overwrite results, delete audit trails, or sign for actions they didn’t perform. ALCOA is enforced by controls, not posters.

7) Governance: ownership, procedures, and evidence

Integrity is not an IT project. It is a quality governance model. Without governance, controls decay and exceptions become normal.

Core governance anchors:

• Ownership: defined system/data owners accountable for integrity controls and periodic review.
• Document control: SOPs for data handling, review, corrections, and deviations.
• Revision control: controlled versions of methods, specs, recipes, and configurations.
• Change control: assessment of integrity impact for system changes, patches, and configuration updates.
• Training + competence: trained users, but also trained reviewers who know what “good evidence” looks like.
• Periodic review: audit trails, privileged access, and critical records are reviewed on a cadence.

Governance must also define “correction rules.” When an error occurs, how is it corrected? What is allowed, what is forbidden, and what must be captured in the audit trail? If the answer is “we just fix it,” you have an integrity gap.

8) Access control: UAM, RBAC, and SoD

Integrity fails fastest through access. If the wrong people can do the wrong actions—or if no one can prove who did what—records become negotiable.

Controls that must exist and be testable:

• Defined roles and permissions: controlled through user access management (UAM).
• RBAC enforcement: privileged actions are restricted and reviewable.
• Provisioning discipline: access created/removed under access provisioning controls.
• Segregation of duties: no self-approval or “I changed it and I approved it” (see segregation of duties).
• Periodic access review: access is reviewed, not assumed correct forever (see access review discipline in execution systems).

Privileged access is the highest-risk integrity weakness. Admins often have the power to modify master data, alter audit trail configuration, or restore backups that change history. Integrity programs must treat privileged access as a controlled quality risk, not a “necessary IT convenience.”

9) Audit trails and metadata: the integrity engine

Audit trails are not optional for critical electronic records. They are the mechanism that makes improper change visible, and makes legitimate change defensible.

Effective audit trails must prove:

• Completeness: critical actions are captured (create, modify, delete, approve, override).
• Attribution: unique user identity; shared accounts destroy attribution.
• Timestamps: reliable time and timezone handling (time drift creates “impossible” sequences).
• Reason for change: where appropriate, the system requires rationale, not silent edits.
• Reviewability: audit trails are queryable and routinely reviewed, not “available if needed.”

Metadata is often where integrity lives. If you can export values but lose metadata (who approved, what version, what device, what method), you lose meaning. This is why “report-only archives” are risky: they preserve a PDF but discard the structured context needed to prove truth.

10) Electronic signatures and approval meaning

Electronic signatures only matter if their meaning is preserved. A signature is not a graphic; it’s a controlled declaration.

Integrity expectations for e-signatures include:

• Identity assurance: signatures are tied to authenticated users, not shared logins.
• Intent clarity: what is being approved (and under what version) is explicit.
• Non-repudiation: users cannot plausibly deny the signature due to weak controls.
• Auditability: signature events are captured in audit trails with timestamp and meaning.

This is why integrity intersects with 21 CFR Part 11 and Annex 11: the control intent is to ensure electronic records and signatures are as trustworthy as paper—often more trustworthy—because they preserve event history.

11) Validation and system assurance: CSV and GAMP 5

Integrity is not guaranteed because you bought a popular system. It is guaranteed when the system is configured, validated, and operated to preserve critical records.

In regulated environments, this is usually addressed through:

• Computer System Validation (CSV): proving systems support intended use and preserve critical record integrity.
• GAMP 5: applying risk-based validation and focusing effort where integrity risk is highest.
• Change control-driven revalidation: when you patch, upgrade, migrate infrastructure, or modify configuration, integrity impact is assessed.

Validation must cover the control-path features that make records credible: audit trail generation and retrieval, access enforcement, e-signature behavior, time handling, report generation (and linkage to underlying data), and data export/import controls. If you validated workflows but not the evidence chain, you validated the wrong thing.

12) Retention and recoverability: archives and restores

Integrity is also a time problem. Records must remain trustworthy and retrievable for as long as retention requires. This is where retention, archiving, and disaster recovery become integrity controls—not just IT hygiene.

Integrity after restore is a common blind spot. A restored system that loses audit trail continuity or resets timestamps can become a compliance and evidence disaster—even if production resumes. This is why recovery exercises must verify integrity controls, not just uptime.

13) Operationalization: daily controls that actually work

Integrity programs succeed when controls are embedded in daily operations. The goal is to prevent silent failures and to detect drift early.

Operational controls that hold up under scrutiny:

• Audit trail review cadence: routine review of critical audit trails, not just “available.”
• Master data governance: controlled edits under master data control with approval and traceability.
• Deviation linkage: integrity issues are captured as quality events and investigated (see quality event management).
• Exception handling discipline: overrides and “temporary” privileges are logged, approved, and retired.
• Periodic access review: roles and permissions are re-validated against actual job functions.
• Time synchronization checks: system clocks are controlled; time drift is treated as an integrity defect.
• Data export controls: ensure exported data cannot become a parallel, editable truth.

14) KPIs and operating cadence

Data integrity should be managed like an operating control, with measurable outcomes.

Cadence should be risk-based. High-volume sites, high change rates, and software-driven operations require more frequent checks than stable environments. If your controls aren’t measured, they will drift until an inspection forces you to notice.

15) The “integrity block test” checklist

If you want a fast go/no-go integrity assessment, run a block test. The objective is to prove that the system prevents the wrong actions and preserves evidence when the wrong actions occur.

If the block test fails, treat it as a quality exception. Integrity controls are either operating or they aren’t—and “almost” is not a defensible position during an inspection.

16) Common failure patterns

• Shared accounts and generic logins. Attribution collapses, and audit trails become meaningless.
• Editable source files. “Original” data is overwritten or recalculated without trace.
• Audit trail not reviewed. The trail exists but no one looks—so manipulation is undetected.
• Admin overreach. Privileged users can change results, disable logging, or alter retention quietly.
• Time drift. Timestamps become unreliable; sequences become impossible to defend.
• PDF-only record strategies. Reports survive, but structured truth and metadata are lost.
• Spreadsheet “truth.” Critical calculations happen outside controlled systems.
• Restore breaks integrity. Systems come back online but audit trails or signature meaning are damaged.

17) Cross-industry examples

Integrity principles are universal, but the sharp edges vary by industry:

• Pharmaceutical manufacturing: integrity underpins batch release and investigation readiness; tied to GxP, 21 CFR Part 211, and electronic records controls.
• Medical devices: integrity supports design and production evidence chains such as DHF, DMR, and DHR.
• Food processing: integrity ties to traceability, recalls, and compliance controls; failures show up as reconciliation gaps and unverifiable decisions.
• Execution systems: MES and connected layers must preserve state truth and evidence; integrity intersects with MES controls and audit trails.
• Laboratories: integrity hinges on method control, raw data preservation, and review discipline; weak integration creates “copy/paste truth.”

The common lesson: integrity is not a department. It is the reliability of your evidence chain, end to end.

18) Extended FAQ

Q1. What is data integrity?
Data integrity is the discipline of ensuring records are trustworthy—complete, accurate, attributable, and protected from improper change—across the full data lifecycle.

Q2. Is data integrity the same as cybersecurity?
No. Security protects against unauthorized access; integrity proves the record is credible evidence, including audit trail, metadata, and controlled change history.

Q3. What does ALCOA mean in practice?
ALCOA means records are attributable, legible, contemporaneous, original, and accurate—enforced through controls like access governance, audit trails, and review discipline.

Q4. What are the most common integrity failures?
Shared logins, uncontrolled spreadsheets, unreviewed audit trails, weak privileged access controls, and loss of metadata during reporting/archiving.

Q5. How do we prove integrity after a system restore?
Restore testing must verify not only uptime but also audit trail continuity, timestamp correctness, access controls, and signature meaning (see backup validation principles).

Related Reading
• Core Integrity Concepts: ALCOA | Audit Trail (GxP) | GxP | Record Retention | Data Archiving | Data Retention
• Validation + Governance: CSV | GAMP 5 | Change Control | Document Control | Revision Control
• Access + Accountability: User Access Management | Role-Based Access | Access Provisioning | Segregation of Duties
• E-Records Context: 21 CFR Part 11 | Annex 11 | Electronic Signatures
• Systems Context: MES | Electronic Batch Record (EBR) | eQMS | MES Backup Validation