Computer System Validation & Data Integrity: Proving Your Records Deserve Trust
Every batch record, chromatogram and validation report in this series now lives on a computer system. If that system isn't validated and the data can't be trusted, none of the paper trail behind it means anything.
01Why this sits underneath everything else
Process validation, cleaning validation and method validation all produce one thing in common: data. If the system that captured, stored or calculated that data isn't itself validated — and if the data can't be shown to be complete, consistent and accurate — every other validation exercise in this series rests on an unproven foundation.
Regulators have been explicit that data integrity failures aren't a new category of risk so much as a long-standing CGMP expectation finally getting dedicated attention, driven by an increase in inspection findings involving disabled audit trails, unreported failing results, and records signed by people who didn't actually perform the review.1,5
Computer system validation (CSV) is the discipline that proves a system does what it's supposed to do, reliably, before it's trusted with GMP data. Data integrity is the ongoing assurance that once data exists, nothing — deliberately or accidentally — has quietly changed its meaning.
GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems
The industry-standard framework this article's risk categories are drawn from — essential if you're building or auditing a CSV program rather than just reading about one.
Find it on Amazon →02The regulatory foundations
| Framework | Issuing body | Core contribution |
|---|---|---|
| 21 CFR Part 11 — Electronic Records; Electronic Signatures | U.S. FDA | Requirements for electronic records and signatures to carry the same weight as paper and handwritten equivalents |
| Data Integrity and Compliance With Drug CGMP: Q&A | U.S. FDA (CDER/CBER/CVM, 2018) | Clarifies how existing CGMP expectations apply to electronic data, audit trails and system access1,5,6 |
| EudraLex Vol. 4, Annex 11 — Computerised Systems | European Commission / EMA | EU GMP requirements for validation, access control and audit trails on computerised systems |
| GXP Data Integrity Guidance and Definitions | UK MHRA (Revision 1, March 2018) | Defines data governance, data lifecycle, and the risk-based control expectations behind ALCOA+2,3,4 |
03The CSV lifecycle
Like process and cleaning validation, computer system validation follows a lifecycle model rather than a one-time sign-off. Click each stage to expand it.
Define user requirements, assess the system's GAMP risk category, and write a validation plan proportionate to that risk. A high-risk custom application warrants far more rigor than a low-risk, unmodified commercial tool.
- User Requirements Specification (URS) agreed before build or configuration
- Supplier assessment for any vendor-provided system
Install and configure the system, then execute installation, operational and performance qualification testing — the same IQ/OQ/PQ logic used for equipment, applied to software.
- Test scripts traced back to each requirement
- Access controls, audit trail function and data backup verified as part of testing, not assumed
Once live, the system is maintained under change control, with periodic review confirming it remains in its validated state — and audit trails are actually being reviewed, not just switched on.
- Scheduled periodic review, risk-based on system criticality
- Change control assessment for patches, upgrades and configuration changes
Computer Systems Validation: Quality Assurance, Risk Management, and Regulatory Compliance for Pharmaceutical and Healthcare Companies — Guy Wingate
A detailed, applied companion covering how the lifecycle above translates into an actual URS, test protocol and periodic review program.
Find it on Amazon →04Risk-based categories (GAMP 5)
Not every computer system needs the same level of validation rigor. GAMP 5 groups software into categories that scale effort to risk — switch tabs to compare them.
Category 1 — Infrastructure software. Operating systems, database engines, network components. Validated as part of the applications that run on them, generally through IT infrastructure qualification rather than a standalone GxP validation exercise.
Category 3 — Non-configured (or default-configured) products. Off-the-shelf software used as-is. Requires verification that it works as intended for its actual use, leaning on supplier documentation and risk-based testing.
Category 4 — Configured products. Commercial software configured to a specific business process (a LIMS or MES, for example). Requires validation of both the underlying product and the configuration applied to it — this is where most CGMP systems live.
Category 5 — Custom applications. Bespoke code written for a specific purpose. Warrants the highest rigor: full software development lifecycle documentation, source code review where relevant, and the most extensive testing.
05ALCOA+ in practice
Data integrity expectations are commonly summarized with the ALCOA(+) acronym — a shorthand for the attributes regulators expect of GxP data.3
Attributable
Traceable to the person or system that generated it.
Legible
Readable and permanent, not obscured or erased.
Contemporaneous
Recorded at the time the activity happened.
Original
The first record, or a verified true copy.
Accurate
Correct, complete, and reflecting what actually occurred.
Complete
Includes all data, including repeats and reprocessing.
Consistent
Timestamped and sequenced in the expected order.
Enduring
Retained for as long as required, not just convenient.
Available
Accessible for review or inspection throughout its retention period.
Data Integrity and Data Governance: Practical Implementation in Regulated Environments — R.D. McDowall
Written by a widely respected voice on lab data integrity; particularly strong on audit trail review practices and electronic record governance beyond the acronym.
Find it on Amazon →06Data integrity self-check
Readiness checklist
07Where programs fail inspection
- Audit trails technically on, functionally unreviewed. Enabling the feature isn't the requirement — someone needs to actually look at it, on a defined schedule.6
- Shared logins. If multiple people can sign in as "QC1," no individual action is genuinely attributable, which undercuts the entire audit trail.
- Treating validation as a go-live event. A system validated once at installation and never periodically reviewed drifts out of its validated state the same way an unmonitored manufacturing process does.
- Printouts as the "original" record. A paper printout of electronic data is a copy, not the original — and can strip away metadata (timestamps, audit trail entries) an inspector will expect to see.
08References
- U.S. Food and Drug Administration. Data Integrity and Compliance With Drug CGMP: Questions and Answers — Guidance for Industry. December 2018. fda.gov
- UK MHRA. GXP Data Integrity Guidance and Definitions. Revision 1, March 2018. assets.publishing.service.gov.uk
- Lachman Consultants. "MHRA March 2018 GXP Data Integrity Guidance and Definitions." lachmanconsultants.com
- gmp-compliance.org. "MHRA GxP Data Integrity Definitions and Guidance for Industry: New Draft Version for Consultation." gmp-compliance.org
- Federal Register, Vol. 83, No. 239 (December 13, 2018). Notice of guidance availability. govinfo.gov
- Alston & Bird. "New Guidance Refines FDA's Thinking on Data Integrity." alston.com
No comments:
Post a Comment