Data Integrity × Computerized System Validation
A validated system does not guarantee trustworthy data — validation proves the controls exist, governance makes them operate. In a LIMS, ALCOA+ is either engineered and tested into the system or it is a procedural fiction.
What this page does not claim
An intersection covers what happens only where two axes overlap. It does not restate what either parent page says, and it is not a substitute for reading them.
WHAT ONLY EXISTS IN THE OVERLAP
- Procedures can demand ALCOA+; only the system can deliver it. Whether records are attributable, contemporaneous, and protected from undisclosed change is decided by configuration — unique accounts, enforced workflows, a clock users cannot move — and configuration claims are only true if validation tested them.
- Validation and governance fail separately, and hide each other. A perfectly validated system operated with shared logins has integrity on paper only; a rigorous governance programme running on a system whose audit trail was never verified is trusting a control nobody tested.
- The audit trail is qualified once and relied on forever. CSV proves the trail captures what it claims to capture; data governance decides who reviews it, how often, and against what risk — and an unreviewed trail protects nothing, however thoroughly it was validated.
- In a LIMS the record is dynamic — reprocessable, reintegratable, recalculatable — so "original" means the complete first capture plus every parameter and prior version. What validation must prove is not storage but reconstructability.
- The riskiest data path is usually the least validated one: the instrument interface. Flat files, orphaned workstation data, and manual transcription between instrument and LIMS are where data-integrity expectations meet the validation scope decision head on.
ALCOA+ is a system property before it is a behaviour
Data-integrity guidance is often read as a code of conduct — do not share passwords, record at the time of the activity, never obscure an original value. In a computerized environment, every one of those behaviours has a technical twin that either enforces it or quietly permits its opposite. Attributable resolves to unique credentials and a role model that makes shared accounts impossible, not discouraged. Contemporaneous resolves to records timestamped at capture by a synchronized clock no user can adjust. Original resolves to a first capture that survives every later action. Accurate resolves to interfaces and calculations that demonstrably do not corrupt what they carry. Each of these is a requirement, and a requirement is only real when something verified it — which is why the same regulations that demand integrity demand validation in the same breath. Part 11 and Annex 11 both bind the two together: audit trails, access controls, and validation obligations sit side by side because neither works alone.
The practical consequence is that data-integrity requirements belong inside the validation deliverables, written as testable statements. A user requirement that never says "the system shall prevent an analyst from deleting raw data" produces a validation package that cannot claim the system does. The risk-based logic of GAMP 5 then cuts in the opposite direction from habit: the functions that carry integrity — audit-trail capture, privilege enforcement, raw-data protection, interface fidelity — are precisely the ones that warrant the deepest verification, while cosmetic functionality can be assured lightly. A programme that tested report formatting as thoroughly as audit-trail behaviour has spent its rigour where rigour was cheap, and the gap will surface in the one place it cannot be argued away: the records.
Validated once, reviewed forever
The audit trail crosses the boundary between the two practices twice, in different roles. During validation it is an object of testing: does it capture creation, modification, and deletion; does it record the actor, the timestamp, the prior value, and the reason; can it be disabled, and by whom, and does disabling it leave a trace? After go-live it becomes an instrument of governance: MHRA's 2018 guidance expects audit-trail review to be risk-based, routine, and directed at the data that matters most. The two roles are severable, and each fails on its own. A trail that was validated and is never reviewed collects evidence nobody examines — the control exists and does not operate. A trail that is reviewed diligently but was never verified may be silently missing whole event types, and the review inherits the blindness.
Governance also owns the questions validation cannot answer, because they are questions about drift rather than design. Periodic evaluation of the validated state — an explicit Annex 11 expectation — has a data-integrity reading that is easy to miss: have privileged accounts multiplied since go-live; has time synchronization quietly broken; has an administrator accumulated analyst duties that collapse segregation; was audit-trail functionality suspended during an incident and never formally restored? WHO's guidance on good data and record management practices frames exactly these as governance duties, owned by named roles on a cadence. The intersection point is that the object of that review is the validated configuration itself — governance is what notices when the system being operated is no longer the system that was tested.
The LIMS is where the overlap gets sharp
A LIMS holds the most contested records in the facility: results that can be reprocessed, chromatograms that can be reintegrated, calculations that can be re-run against revised specifications. Here "original data" stops meaning a static file and starts meaning the complete first capture — raw signal, acquisition metadata, processing parameters — together with an unbroken account of every subsequent version. What validation must therefore prove is reconstructability: that the system can show the result as it was first generated, and every reprocessing event with its actor, its reason, and its effect. Reprocessing and reintegration privileges are the classic inspection target at this junction, because unconstrained reprocessing is how results are tested into compliance — and whether the system constrains it is a validated configuration fact, not a policy hope.
The other sharp edge is the interface. Instruments feed the LIMS through exports, middleware, and — still, in many laboratories — flat files that carry no audit trail of their own and can be edited in transit. Data that never leaves an instrument workstation lives outside the validated environment entirely, on a machine whose operating-system account model was never assessed. This is where the scope decision becomes the integrity decision: the chain of custody is only as strong as its least validated link, so the boundary of the validated system should be drawn where the data is born, not where it becomes administratively convenient. A LIMS validation that starts at the LIMS has certified the vault and ignored the courier.
Governance decides; validation proves; neither substitutes
Many of the properties that decide integrity are configuration choices with no technically forced answer: whether the audit trail is enabled at the deepest level, what each electronic-signature event legally means, how the role matrix divides analyst from reviewer from administrator, what the system retains and for how long. These are governance decisions — they belong to the data-governance function, because they encode the organisation's risk posture — and they acquire force only when they are carried into the validated configuration and tested there. Where governance is silent, vendor defaults decide instead, and defaults are chosen for saleability across a customer base, not for any one site's risk. An unexamined default is a decision the organisation made without noticing.
The maturity signature of this overlap is whether the two practices exchange documents. At the low end, validation is an IT project and data integrity is a QA campaign, and neither cites the other: the risk assessment never shaped the test plan, and the audit-trail review SOP was written without knowing what the trail actually records. At the high end the loop is explicit — the data-integrity risk assessment feeds the user requirements, the validation evidence defines the review scope, and periodic review reads both against the live system. The inspection tell is a single question: who owns the role matrix? If the answer is "IT", the site has an administration process where it believes it has a control.
Derived from the 5 standards SPEQ maps to this intersection, across 5 regulatory bodies: FDA, EMA, ISPE, MHRA, WHO.
FREQUENTLY ASKED
Does a validated system guarantee data integrity?
No — validation proves that the controls existed and worked when they were tested; integrity depends on those controls operating every day since. Shared credentials, a quietly disabled audit trail, an administrator doing analyst work, or a review SOP nobody executes will defeat a flawlessly validated system without leaving a mark on the validation package. The converse is equally true: a conscientious governance programme running on a system whose integrity functions were never verified is built on an untested assumption. The defensible position needs both legs — controls proven by validation, and operation evidenced by governance records such as access reviews and audit-trail review logs.
Is audit-trail review part of computerized system validation?
Verifying the trail is; reviewing it is not. Validation must demonstrate that the audit trail captures the right events with the right content — actor, timestamp, prior value, reason — that it cannot be altered, and that disabling it is controlled and visible. Ongoing review is a governance activity that begins where validation ends: a risk-based decision about which data warrants routine trail review, at what frequency, looking for what patterns, evidenced by records of the reviews performed. The two are connected by scope — a review procedure written without knowing what the validated trail actually records is reviewing an imagined system — but they are distinct activities with distinct owners.
How much of the instrument-to-LIMS data path belongs in the validated scope?
All of it — the scope boundary should follow the data, not the purchase order. A result acquired on an instrument, processed on its workstation, exported as a flat file, transformed by middleware, and loaded into the LIMS has crossed four environments before it reaches the validated one, and its integrity claim is only as strong as the weakest crossing. That means interfaces verified for fidelity and completeness, transfer failures that alert rather than silently drop records, workstation data protected and retained where the raw data legally lives, and any manual transcription treated as the high-risk step it is. Drawing the validated boundary at the LIMS login screen certifies the destination and ignores the journey.
Do Part 11 and Annex 11 ask for different things at this intersection?
They are two expressions of the same architecture, with different emphases worth knowing. Both require validation, secure computer-generated audit trails, and controls limiting system access to authorized individuals — the fusion of validation and integrity that defines this overlap. Part 11 is more elaborate about electronic signatures: their uniqueness, their binding to records, and what a signature legally means. Annex 11 is more explicit about the operational life of the system — periodic evaluation, supplier assessment, data storage checks and printouts — which is where the governance half of this page lives. A programme designed to the union of the two, rather than the letter of either, satisfies both without duplication.