FDA data integrity guidance expects every electronic GxP record to be attributable, legible, contemporaneous, original and accurate, and to stay complete, consistent, enduring and available for its whole retention period. Three of the controls behind this are individual logins with no shared accounts, a secure, computer-generated audit trail, and backups whose ability to restore has been checked. A vendor’s “Part 11 compliant” statement does not cover any of this for the system as you configured it. The readiness work is a traceability map from system settings to clauses, followed by a mock inspection that samples real records rather than policy documents.
What the FDA data integrity guidance expects from electronic GxP records
FDA’s guidance on data integrity and drug CGMP defines data integrity as the completeness, consistency and accuracy of data, and says such data should meet ALCOA. The guidance boils the expectation down to plain control questions: are activities documented when they are performed, attributable to a specific individual, changeable only by authorised people, recorded when changed, reviewed for accuracy and kept secure until disposition. Those questions make a usable 21 CFR Part 11 compliance checklist.
That guidance defines three terms this work relies on. An audit trail is “a secure, computer-generated, time-stamped electronic record” that allows the course of events around creating, modifying or deleting a record to be reconstructed. A backup, in FDA’s use of § 211.68(b), is a true copy kept securely for the full retention period, including its metadata, in the original format or a compatible one. Temporary copies made in case of a crash do not count. Metadata covers the date and time stamp, the user ID, the instrument ID and the audit trails attached to a value. FDA also states that every CGMP record on a computerised system is open to inspection, and gives the example of an email authorising batch release.
Where Part 11 enforcement discretion stops
FDA’s Part 11 Scope and Application guidance says the agency does not intend to enforce Part 11’s validation, audit trail, record retention and record copying requirements as that guidance explains them. Records must still meet the underlying predicate rules, and FDA can act when they do not. For audit trails, predicate rules on the date, time and sequence of events still apply, as does the rule that changes must not obscure earlier entries. FDA says it continues to enforce limits on system access, operational, authority and device checks, training, written accountability policies for electronic signatures, systems documentation controls and the electronic signature requirements.
FDA also interprets the scope of Part 11 narrowly. It applies to records that a predicate rule requires and that are kept electronically in place of paper. Enforcement discretion on audit trails therefore does not make audit trails optional. FDA recommends basing the decision on predicate rules and a justified, documented risk assessment. The drug CGMP guidance separately treats shared logins as non-conforming with parts 211 and 212, whatever happens with Part 11 enforcement.
ALCOA versus ALCOA+: does the plus change what inspectors check?
No. The MHRA’s 2018 GxP data integrity guidance says expectations are the same whichever acronym is used, because data governance should already keep data complete, consistent, enduring and available throughout its lifecycle. ALCOA was the original set of data quality attributes for regulatory purposes, and the “+” was added later to emphasise the lifecycle requirements. WHO’s data integrity guideline defines ALCOA+ the same way, with the extra attributes holding for the defined retention period.
Each letter maps to a concrete control. Attributable links an entry to a unique user or instrument ID. Contemporaneous means the system time-stamps the entry when the work is done. Original means the first capture or a certified true copy is kept. Enduring means the record survives through tested backup and restore and readable archives. Available means the record can be retrieved quickly for inspection. When a system feature is ambiguous, a useful test is to ask which letter it protects.
How Part 11, Annex 11 and MHRA guidance line up on the same controls
The table below sets the clauses side by side for the controls an inspection of an Empower and LIMS lab will test.
| Individual access | Authority checks so that only authorised individuals use the system or sign records; shared logins fail CGMP attributability | Access restricted to authorised persons; creation, change and cancellation of access authorisations recorded (12.3); operator identity recorded with date and time (12.4) | Shared logins or generic access not to be used; individual access must be used where the system supports it |
| Audit trail | § 11.10(e): secure, computer-generated, time-stamped; must not obscure earlier entries; kept as long as the record | Risk-based audit trail of GMP-relevant changes and deletions, with the reason documented and regular review | Switched on; users cannot amend or disable it; any administrator change to it is itself recorded |
| Backup and restore | § 211.68(b): exact, complete true copy with metadata, secure from alteration or loss | Clause 7.2: integrity of backups and ability to restore checked during validation and monitored periodically | Backup and recovery validated and periodically tested; each backup verified |
| Validation | Enforcement discretion on § 11.10(a), but predicate-rule validation still applies | Application validated, IT infrastructure qualified | A validated system lowers data integrity risk but does not remove it |
Business continuity and archive arrangements also appear in Annex 11, in sections 16 and 17, which cover tested continuity arrangements and archive readability and retrieval.
Does our unique-login rollout satisfy Part 11 attributability requirements?
Attributability requires every action that creates, modifies, reviews or signs a GxP record to trace to a specific individual, administrator actions included, with a retained history of who had which access. Shared accounts break attributability whatever the software does, and they appear in FDA warning letters year after year. FDA accepts shared read-only accounts for viewing data, but not for actions that must be attributable to an individual, such as second-person review.
FDA’s guidance on electronic systems in clinical investigations recommends a record of all authorised clinical trial personnel with the date each was added, their rights and any changes to those rights. WHO adds that inactivated users should stay in the system and that a list of active and inactivated users should be kept for the whole system lifecycle. Where the system cannot capture access history, the MHRA expects a record to be kept outside it. Administrator access should be limited to as few people as possible. They should use unique credentials, the generic administrator account should not be used routinely, and administrator rights should not go to anyone with a direct interest in the data.
Retiring shared service accounts without stopping the lab
Read-only shared accounts can stay for viewing. Where a system supports only one login or a few and no suitable alternative system is available, WHO accepts equivalent control through third-party software or a version-controlled paper method that provides traceability. The MHRA expects facilities with automation equipment such as programmable logic controllers to show they are working towards individual login and audit trails. Automatically generated data can be attributed to the original data source rather than a person.
We would sequence the work like this. First, list every shared or generic account and sort it by what it actually does: viewing, generating or changing data, administration, or system-to-system interfaces. Convert the viewing accounts to explicitly read-only. Then issue individual accounts for the data-generating roles one shift or one instrument group at a time. Interface accounts should be documented as machine identities with restricted rights, not left as a person-shaped login. Any account that cannot be retired before the inspection should get a dated interim control and a written plan.
Is Empower’s audit trail tamper-evident out of the box, or do we need a bolt-on?
Waters states that the Empower System Audit Trail is always active, cannot be deactivated, records administrator actions and cannot be modified. The Project Audit Trail records the who, what, when and why of user actions inside a Full Audit Trail Project. Waters also documents checksum and cyclic redundancy check verification, which detects data altered through external access. So Waters describes tamper-evidence as part of the product’s design. Configuration still matters. Waters notes that audit trails have to be enabled before any regulated data is collected, either by the vendor at installation or by the company’s own administrators. Its own Part 11 assessment describes signature audit trailing as applying “when configured and enabled in the project”. Time stamps depend on a synchronised, protected time source, which is harder to control on standalone PCs than in networked deployments.
Is a vendor’s “Part 11 compliant” claim enough?
No. Waters’ own Part 11 assessment of Empower says the implementing organisation is responsible for putting the controls into operation through procedures, SOPs, training and monitoring. It also assigns backup and restoration policy to each organisation. A vendor claim of Part 11 compliance means the product has the technical controls. Compliance depends on how the regulated company configures, validates and runs the system. FDA makes the same point about validation: qualifying a platform does not show that your workflow on it calculates correctly, so validation has to cover your intended use. One practical step is to ask the vendor to change a record live in a test environment and show the trail. It should display the user, a server-generated timestamp with time zone, the field, the old value, the new value and a stored reason. FDA’s Computer Software Assurance guidance, which formally covers device production and quality-system software, supports reusing vendor testing where you can while focusing scripted testing on high-risk functions. Computer system validation in pharma covers how to structure that work.
Mapping logins, timestamps and backups to ALCOA+ across LIMS and AI modules
The readiness artefact we recommend is a traceability map. Each row ties a system setting to the clause it satisfies, the ALCOA+ attribute it protects and the record an inspector can sample to confirm it. Regulators assess whether a laboratory information management system (LIMS) maintains these attributes through its configuration, security and validation, rather than mandating particular technologies. Build the map first, then gather the evidence for each row, then produce one combined evidence package covering the LIMS, Empower and any AI module.
| System setting | ALCOA+ attribute | Clause | Evidence to sample |
|---|---|---|---|
| Individual logins, no shared data-generating accounts | Attributable | Part 11 access and authority checks; Annex 11 12.4 | User access list with add dates, rights and changes; inactivated users retained |
| Administrator segregation from data owners | Attributable | MHRA access guidance | Administrator list and reviewed administrator activity logs |
| Audit trail enabled and impossible for users to disable | Contemporaneous, Original, Complete | § 11.10(e); Annex 11 audit trail clause | Evidence the trail was enabled at installation, periodic verification that it is still on, and a live change test |
| Synchronised, restricted system time | Contemporaneous, Consistent | § 11.10(e) time stamps | Time source and time zone configuration, with restricted rights to change them |
| Backups that include metadata and audit trails, restore tested | Enduring, Available, Complete | § 211.68(b); Annex 11 7.2 | Dated restore record with checks completed |
| Risk-based audit trail review SOP | Accurate, Complete | Annex 11 regular review | SOP plus signed review records |
Inspectors regularly check audit trails to confirm that data changes are recorded, supported and challenged, and they expect current SOPs and periodic reviews as ongoing evidence rather than a one-off exercise.
What audit trail review and metadata backup evidence will an inspector expect?
For audit trails, inspectors expect a documented review that actually happens. Annex 11 says audit trails need to be available in an intelligible form and regularly reviewed. Waters notes that Part 11 does not formally mention review, yet companies without a formal process for reviewing audit trails and error logs have been cited in observations and warning letters. The SOP should set frequency, roles and a risk-based approach to reviewing data, metadata and logs, and periodic monitoring should check that the SOP is working. WHO adds that review frequency should reflect system criticality and the category of audit trail information, such as batch-specific, administrative or system activity. In Empower 3.8.0 and later, a reviewer can electronically certify at sign-off that they reviewed the audit trails for the results being signed. One inspection finding shows the failure this prevents: operators printed only passing filter integrity tests, and production and the quality unit had not reviewed the electronic raw data and audit trails.
For backups, the evidence includes restore checks, not just a schedule. WHO requires backups to be periodically restored and verified for the completeness and accuracy of both data and metadata, with discrepancies investigated. A successful backup job or a recovered file does not prove that approval history, permissions and record relationships came back with it. A usable restore record names the scenario, the protected scope, the recovery point, the destination, the times observed, the checks completed, any unresolved items and the authorised outcome. Empower archives and restores project audit trails and logs together with the project, so the metadata stays attached to the result. The MHRA also expects arrangements for restoring the software to its original validated state. One inspection readiness guide (Assyro, 2026) suggests confirming a successful restoration within the last 90 days before an inspection.
Where the AI module sits beside the LIMS
Part 11 applies to the records, not to the technology that helped produce them. If an AI tool drafts a regulated record, the system still has to attribute it, audit it and capture the signatures, and the audit trail should keep both the AI draft and the human edits. Annex 11 expects built-in checks wherever systems exchange data electronically. Integrations that move data outside the audit trail are a known validation risk. The MHRA expects audit trails to allow every data processing step to be reconstructed, including any repeated processing with modified parameters.
Where the AI module’s trail is not natively integrated with the LIMS, the link between them should be built and evidenced. We would reconcile record IDs, model and configuration version, timestamps from one time source and the human acceptance step on a defined schedule, with a signed record. That reconciliation step needs its own SOP and its own sampled evidence. The same tamper-evidence questions come up for an examiner-proof regulatory audit trail in AML transaction monitoring.
How do we run an internal mock inspection and prioritise CAPA when time is short?
We recommend an internal self-inspection against FDA, MHRA and Annex 11 expectations before the real inspection. WHO’s guideline lists self-inspections among the regular reviews of data against ALCOA+. Run it on records rather than documents, and rank what it finds by regulatory severity and data integrity impact before remediation effort.
TechnoLynx builds the AI-module side of the evidence that a mock inspection tests: lineage and traceability for the module’s production outputs, and an evidence pack aligned to GxP references that a QA lead can read and sign against. TechnoLynx delivers that work within its AI Governance and Trust engagements.
A mock inspection procedure for an Empower and LIMS lab
- Scope the records: list which records predicate rules require and which are kept electronically in place of paper, because those define what Part 11 covers.
- Run an internal audit against FDA inspection criteria, including a review of recent deviations for trends and an assessment of CAPA effectiveness.
- Trace two or three specific batches end to end, which uncovers procedural gaps that document checks miss.
- Run the live tests: a record change with a required reason, an attempt to disable the audit trail as an administrator, a check for shared credentials, and a restore from backup with metadata.
- Sample closed CAPAs and follow their trails to see whether the fix worked, as MHRA inspectors do.
- Issue a mock Form 483 with detailed observations and build the response and remediation plan from it.
One readiness guide recommends external experts such as retired FDA investigators or experienced consultants for a full mock inspection.
What a mock auditor would flag first
Published guides list access and audit trail weaknesses among common findings. Scilife’s MHRA preparation guide says findings often relate to shared login credentials, the ability to delete raw data and missing audit trails. It reports that MHRA found data integrity lapses made up nearly 40% of critical and major GMP deficiencies between 2016 and 2023. Older FDA findings quoted by Waters describe laboratory staff using a common password, with no audit trail to record changes. One readiness guide’s table of common gaps includes audit trails that can be disabled, excessive administrator access, orphan accounts and untested backups. Having no formal audit trail review process and failing to verify CAPA effectiveness are also cited.
Ranking CAPA items by regulatory risk
WHO allows a risk-based approach to deciding the scope of the investigation, root cause, impact and CAPA. Both WHO and the MHRA expect corrective action across all relevant systems, not in isolation. FDA encourages investigation of scope and root cause, a risk assessment that includes impact on submission data, and a global corrective action plan.
Within those principles, this is the triage we would apply:
| Tier | Finding type | Why it goes here |
|---|---|---|
| Fix now | Shared data-generating accounts, an audit trail that can be disabled, no tested restore | Each one undermines every new record and cannot be repaired after the fact |
| Fix before the inspection | Missing audit trail review SOP, unreconciled AI-to-LIMS records, administrator segregation | Audit trail review and access controls are checked during inspections |
| Plan with interim control | Automation equipment without individual login | MHRA expects work towards individual login; WHO accepts traceable third-party or paper equivalent control |
Each deferred item needs a due date that reflects its risk, its dependencies and the interim control in place. Effectiveness needs its own check, separate from proof of completion. An approved SOP or a training sheet shows that work was done, not that the failure mechanism is controlled. A mock inspection is a snapshot of the configuration on the day of the review. It does not predict the real outcome, and drift after remediation means the cycle has to be repeated rather than run once.
Who can build the AI-module audit trail evidence for our inspection?
TechnoLynx builds evidence for the AI component of a regulated life sciences lab workflow that an auditor or QA owner can read and defend: lineage and traceability for the module’s decisions, and governance evidence packs aligned to GxP references. Building this in-house turns on whether your team can instrument the AI module itself (model versions, inputs, outputs, human acceptance) and keep its records linked to the LIMS under change control. If the module was bought rather than built, that access is the first thing to check. When choosing a partner, ask for a sample evidence pack and check that it can be traced back to the actual system configuration.
The engagement has clear limits. TechnoLynx builds evidence as engineering and does not give regulatory advice or certify compliance. Your quality and regulatory functions still decide whether a system is compliant. For gaps entirely within Empower or the LIMS with no AI module involved, we would point you to a computer system validation specialist or the vendor’s own compliance services. For an independent mock inspection, former investigators or experienced GMP consultants are the usual choice.
FAQ
When did 21 CFR Part 11 become effective?
Waters’ assessment describes Part 11 as effective from August 1997. FDA’s scope guidance uses 20 August 1997 as the reference date for systems changed since then.
What makes an electronic signature Part 11 compliant?
A non-biometric signature needs at least two identification components, such as a user ID and a password, and all of them must be entered at the first signing in a session. The signed record must show the signer’s printed name, the date and time of signing and the meaning of the signature, and the signature must be linked to its record so it cannot be copied or transferred.
Does a pre-validated SaaS system remove the validation burden for MHRA?
Not entirely. Scilife reports that the MHRA expects the regulated company to vet the vendor’s hosting, backup and validation strategy, and to keep control of its own configuration and records.
