Data integrity has been one of the most frequently cited themes in GMP inspections for more than a decade, and the QC laboratory is where many of those citations land. The reason is simple: release decisions rest on laboratory results, and laboratory results rest on records that are easy to create, easy to change and, in a poorly designed system, easy to hide. ALCOA+ is the shorthand regulators and quality teams use to describe what trustworthy records look like. This article explains each ALCOA+ principle in practical terms, summarizes the main regulatory guidance, describes the failures inspectors find most often, and shows how system design and disciplined audit trail review prevent them.
Key takeaways
- ALCOA+ describes the properties every GxP record should have: attributable, legible, contemporaneous, original and accurate, plus complete, consistent, enduring and available.
- The major regulators agree on the principles. FDA, MHRA, PIC/S and WHO guidance differ in emphasis and format, not in fundamentals.
- Most data integrity failures are design failures. Shared accounts, disabled audit trails and orphan data persist when systems make the wrong path easy.
- Audit trail review works best when it is risk-based and built into routine record review, not saved for investigations.
- Technology helps, but culture decides. Systems cannot fix pressure to pass results or a reluctance to report errors.
What data integrity means
FDA’s 2018 guidance describes data integrity as the completeness, consistency and accuracy of data, and says complete, consistent and accurate data should be attributable, legible, contemporaneously recorded, original or a true copy, and accurate. That last list is ALCOA, an acronym generally credited to FDA in the 1990s. ALCOA+ adds four further attributes that make explicit what was already implied: complete, consistent, enduring and available. Some organizations go further with “ALCOA++” variants that add traceability, but ALCOA+ is the form most commonly used in regulatory guidance and inspection practice.
Data integrity applies across the whole data lifecycle: creation, processing, review, reporting, retention, retrieval and eventual destruction. It also applies equally to paper, electronic and hybrid records.
The regulatory guidance landscape
| Guidance | Issuer | Year | Why it is useful |
|---|---|---|---|
| Data Integrity and Compliance With Drug CGMP: Questions and Answers | U.S. FDA | 2018 | Explains how existing CGMP regulations apply to data integrity, in Q&A form, covering audit trail review, shared logins, blank forms, test injections and more |
| ‘GXP’ Data Integrity Guidance and Definitions | UK MHRA | 2018 | Clear definitions of raw data, metadata, true copy, data governance and related terms, applicable across GxP disciplines |
| PI 041-1 Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments | PIC/S | 2021 | Written for inspectors; detailed expectations for paper, computerized and hybrid systems and for outsourced activities |
| Guideline on data integrity (Technical Report Series No. 1033, Annex 4) | WHO | 2021 | Updates WHO’s earlier guidance on good data and record management practices; widely referenced by national regulators |
None of these documents creates new legal requirements on its own. They explain how existing GMP regulations, such as 21 CFR Parts 211 and 212 or EU GMP Chapter 4 and Annex 11, apply to records. Where they differ, it is mostly in how prescriptive they are. PIC/S PI 041-1 is the most detailed and is a useful benchmark for a gap assessment.
ALCOA+ principle by principle
Attributable
Every record and every change can be traced to the person (or system) that created it, and when. In the lab, that means unique user accounts, no shared logins on instruments or workstations, and audit trails that capture the user behind each entry. Initials on paper must map to a signature log.
Legible
Records can be read and understood for their entire retention period. For paper, that means permanent ink and no obscuring corrections. For electronic data, it means data remains readable in context, with units, method version and specification limits, after software upgrades and migrations.
Contemporaneous
Data is recorded at the time the activity occurs. Writing results on scrap paper for later entry, or batch-entering a day’s observations at shift end, breaks this principle. Direct instrument capture and real-time electronic worksheets are the strongest controls. System clocks must be synchronized and protected from user changes.
Original
The original record, or a verified true copy, is preserved. For many instruments the original record is the electronic data file with its metadata, not a printout. A chromatogram printout is a static snapshot of a dynamic record; it cannot be reprocessed or interrogated, so it does not replace the electronic original.
Accurate
Records are correct, truthful and free from errors, and any edits are documented. Accuracy depends on validated calculations, qualified instruments, verified data transfers and second-person review of critical entries.
Complete
All data is retained, including repeat tests, failed runs, invalidated results and system suitability failures, together with the metadata and audit trail needed to reconstruct what happened. Reporting only the passing result is the classic completeness failure.
Consistent
Records follow a logical, time-ordered sequence, and timestamps agree across systems. Events appear in the expected order, and the same data has the same value wherever it is used. Inconsistent date formats, time zones or sequence gaps are warning signs.
Enduring
Records last for the required retention period on durable, controlled media. Thermal printouts that fade, data stored on local instrument PCs, and backups that have never been restored all fail this test.
Available
Records can be retrieved for review, audit and inspection throughout their retention period, in a reasonable time. Data locked in a decommissioned system or an unreadable proprietary format is not available in any useful sense.
Common inspection findings
Warning letters and inspection reports describe recurring patterns. In general terms, the most common are:
- Shared or generic accounts. Analysts log in to chromatography workstations or instrument PCs as “Lab1” or “Admin,” so no action can be attributed to a person.
- Audit trails disabled or never reviewed. The function exists but was switched off, was never configured, or is consulted only when something has already gone wrong.
- Excessive privileges. Analysts hold administrator rights that let them delete files, change system clocks, alter methods or turn off audit trails.
- Orphan data. Results exist on an instrument or local drive but never reach the official record. Examples include unreported injection sequences, data in temporary folders and runs aborted without explanation.
- Testing into compliance. Trial or “test” injections of samples before the official run, repeated reprocessing or reintegration until results pass, and out-of-specification results invalidated without a documented, scientifically sound root cause.
- Hybrid system weaknesses. Paper and electronic records that do not reconcile, printouts treated as the original record, unverified transcription into a LIMS or spreadsheet, and blank worksheets issued without control or reconciliation.
- Backup and retention gaps. Backups that are incomplete or untested, and data that cannot be retrieved from retired systems.
These findings rarely stem from a single bad actor. More often they reflect systems that allow uncontrolled shortcuts, combined with time pressure and weak oversight.
How system design prevents these failures
The most effective data integrity control is a system in which the compliant path is also the easiest path. The table below pairs common failure modes with design controls that address them.
| Failure mode | Design control |
|---|---|
| Shared or generic accounts | Unique named accounts with single sign-on and multi-factor authentication; individual login on instrument workstations |
| Audit trail disabled | Audit trail permanently on for GxP data and not configurable by lab users or administrators |
| Excessive privileges | Separate administrative and analytical roles; lab staff cannot change system clocks, delete records or alter configuration |
| Orphan data | Direct instrument capture into a scientific data management system; reconciliation of every instrument run against LIMS records |
| Silent retesting | Retests and reprocessing require documented authorization; all attempts stay visible in the record |
| Unjustified OOS invalidation | Out-of-specification results automatically open an investigation that must be closed before release |
| Transcription errors | Instrument interfaces and validated calculations replace manual entry and spreadsheets |
| Uncontrolled blank forms | Electronic worksheets in a lab execution system; where paper remains, uniquely numbered forms issued and reconciled |
| Unreadable archives | Open, documented export formats and retention controls that survive upgrades and migrations |
Design also includes what the system does not allow. A LIMS should make it impossible to delete a result, overwrite a value without a trace, back-date an entry or approve a record before its required steps are complete. Where a hybrid process cannot be avoided, the procedure must define which record is the original and how paper and electronic records are linked and reconciled.
Audit trail review practices
An audit trail is only a control if someone reviews it. FDA’s 2018 guidance recommends that audit trails capturing changes to critical data be reviewed with each record and before final approval of the record. Other audit trails, such as those covering system configuration and user access, are typically reviewed periodically. A practical program includes the following elements:
- Identify critical data and events. Results, integration parameters, specification and method changes, sample status changes, invalidations, deletions and reprocessing deserve the closest attention.
- Set review frequency by risk. Review data-level audit trails as part of result review; review system-level audit trails, such as permission changes and failed logins, on a defined schedule.
- Review by exception. Reviewers should not read raw logs line by line. The system should highlight events that need attention: changes after initial entry, reprocessing, out-of-sequence actions, activity outside normal hours and repeated failed attempts.
- Review in context. Show the audit trail alongside the record it describes, so the reviewer can follow the story the data tells.
- Document the review. Record who reviewed which audit trail, when, what scope was covered and what was found, ideally with an electronic signature.
- Escalate findings. Unexplained changes go into the deviation and CAPA process, not into an email thread.
- Train reviewers. Reviewers need to know what normal looks like for each system and which patterns suggest a problem.
- Check effectiveness. Periodically sample completed reviews to confirm they are meaningful and not a box-ticking exercise.
Culture and governance
MHRA, PIC/S and WHO guidance all stress that data integrity depends on data governance: management commitment, clear accountability, adequate resources and a culture in which people can report errors without fear. No system can compensate for pressure to release on schedule regardless of results. Quality metrics that reward first-time pass rates without context can encourage exactly the behaviors that controls are designed to stop. Treat a data integrity program as a combination of system design, procedures, training and leadership behavior, and assess all four. Our 21 CFR Part 11 checklist covers the technical controls in more depth, and the LIMS vs. ELN vs. LES vs. SDMS explainer shows where each system type fits in the data lifecycle.
How HDLIMS approaches this
HDLIMS is designed so that ALCOA+ is the default rather than a configuration project: direct instrument capture through the SDMS module, guided execution in the LES, and investigations and CAPA in the quality module. Exception-based audit trail review is part of the result review workflow. See our compliance overview or request a demo to see how it works with your own data.