21 CFR Part 11 audit trail requirements: what to capture, design and review
What 21 CFR 11.10(e) asks of an audit trail: the fields to capture, how to design it so it can’t be altered, how to review it, and how to test it in validation.
- Section 11.10(e) asks for a secure, computer-generated, time-stamped trail of entries and actions that create, modify or delete electronic records.
- Changes must not obscure earlier values, and the trail must be kept as long as the record and be available for FDA review and copying.
- A useful trail records who, what, when, the old and new value and why; the reason is a data-integrity expectation rather than literal Part 11 text.
- An audit trail nobody reviews protects nothing. Design it so reviewers can find the entries that matter quickly.
Under 21 CFR 11.10(e), a system holding regulated electronic records needs a secure, computer-generated, time-stamped audit trail that independently records who created, changed or deleted a record and when. Changes must not hide earlier values, and the trail must be kept as long as the record and be available to the FDA.
That one sentence of regulation drives a lot of design work. This article goes deeper than our Part 11 checklist: what to capture, how to build a trail that cannot be quietly altered, how QA should review it, and how to test it during validation.
What the regulation and FDA guidance say
Part 11 is short on detail. Section 11.10(e) gives four requirements for closed systems:
- The trail is secure, computer-generated and time-stamped, and records operator entries and actions independently of the user.
- It covers actions that create, modify or delete electronic records.
- Record changes must not obscure previously recorded information.
- The trail is retained at least as long as the record itself and is available for agency review and copying.
FDA’s 2003 guidance on the scope and application of Part 11 said the agency would apply enforcement discretion to some requirements, including audit trails, while expecting companies to meet their predicate rules and use risk assessment. That is not a licence to skip them. FDA’s 2018 guidance on data integrity and CGMP describes an audit trail as a record that lets you reconstruct the history of an electronic record, and recommends that audit trails capturing changes to critical data are reviewed with each record before it is finally approved.
What each audit-trail entry should capture
The test of a good entry is simple: could an inspector reconstruct exactly what happened from the trail alone, without asking anyone?
| Field | Why it matters |
|---|---|
| User identity | Attributable: the unique account that acted, never a shared or system login for user actions |
| Date and time | From a synchronised server clock, with the time zone, so sequences can be trusted |
| Action | Create, modify, delete, approve, reject, status change |
| Record and field | Which sample, result, specification or case, and which attribute changed |
| Old value | Needed so the change does not obscure what was recorded before |
| New value | What the record says now |
| Reason for change | Expected by data-integrity guidance and Annex 11 for GxP data; picked from a list or typed |
| Context | Linked signature, instrument, workstation or batch where relevant |
Part 11 itself does not use the words “reason for change”. EU Annex 11 does, and so do MHRA, WHO and PIC/S data-integrity guidance. A system sold to both markets should ask for a reason on every change to GxP data.
Which events belong in the trail
It helps to separate two kinds of trail. A record audit trail follows the GxP data itself: results, sample status, specifications, case data. A system audit trail follows the configuration and security around it: user and role changes, password policy, master data, calculation formulas, interface settings and the audit-trail settings themselves.
Both matter. A changed calculation formula can alter every result that follows, and a temporary role change can let someone approve their own work. Log-ins, failed log-in attempts and session time-outs are usually kept in a security log, which reviewers need alongside the record trail when they investigate.
Designing a trail that cannot be quietly altered
“Secure” is the word that shapes the architecture. In practice:
- Append-only storage. Entries are inserted, never updated or deleted, and no application role — including administrators — can edit them.
- Written by the system, not the user interface. Capturing changes at the data layer means a new screen or an API call cannot bypass the trail.
- Cannot be switched off for GxP data. If a product allows it, the setting itself must be controlled and trailed.
- Tamper-evident. Chaining a hash of each entry into the next lets you show the log has not been edited, even by someone with database access.
- Readable and exportable. Inspectors need human readable copies with the record’s metadata, which ties into 11.10(b).
- Retained with the record. Archiving and migration plans must carry the trail along, or the records lose their history.
Retrofitting this into a system that was not designed for it is expensive, which is why we design the audit trail into the data model on day one of a LIMS build and every other regulated system.
Audit-trail review: making it practical
Review is where most labs struggle. Nobody can read every entry for every result, and nobody should have to. A practical approach has two levels:
- Record-level review as part of result or case review, before approval. The reviewer checks changes to critical data for that record: re-integrations, edited results, deleted runs, late entries.
- Periodic system review on a risk-based schedule: user and role changes, configuration changes, failed log-ins and anything unusual since the last review.
The software can make this much easier:
- Filter the trail by record, user, date range and action type.
- Flag exceptions automatically: changes after review, deletions, repeated edits, changes by the approver.
- Show the trail beside the record on the review screen, not in a separate report.
- Record that the review happened, by whom and when, as its own trailed event.
Common audit-trail findings
These are the gaps that show up again and again in reviews of lab and quality software:
- Only the new value is stored, so the original result is lost.
- Time comes from the user’s PC, which the user can change.
- Administrators can disable the trail or purge old entries.
- Result data is trailed, but specification and formula changes are not.
- Deleted or aborted instrument runs leave no trace.
- The trail exists but there is no SOP or evidence of review.
- Exports drop the trail, so archived records lose their history.
Most of these are design decisions, not bugs. They are much cheaper to fix in the requirements than after go-live; the EU view of the same topic is in our EU Annex 11 guide.
Legacy systems without a proper audit trail
Many labs run older instruments or software whose audit trail is missing, incomplete or easy to switch off. Replacing them is not always possible straight away. Interim measures usually combine:
- A documented risk assessment of what the gap allows.
- Restricted access, with no shared accounts.
- Procedural controls such as logbooks or second-person checks.
- Moving the GxP record of truth into a system that does have a compliant trail.
- A dated plan to upgrade or replace the system.
Inspectors generally accept interim controls only when the gap is recognised, assessed and on a path to closure.
How to test an audit trail during validation
Because the audit trail protects every other record, it is almost always treated as high risk and tested with scripted tests and objective evidence. Typical operational tests:
- Create, modify and delete a record; confirm each entry shows user, server time, old value, new value and reason.
- Try to edit or delete trail entries as each role, including administrator, and through any API.
- Change the workstation clock and confirm entries still use server time.
- Export a record and confirm the trail travels with it in readable form.
- Restore a backup and confirm the trail is complete and matches.
These tests sit in the OQ part of the GxP validation life cycle, traced back to audit-trail requirements in the URS.
Frequently asked questions
What does 21 CFR 11.10(e) require?
It requires secure, computer-generated, time-stamped audit trails that independently record operator entries and actions that create, modify or delete electronic records. Changes must not obscure earlier information, and the trail must be kept as long as the record and be available to the FDA.
Does Part 11 require a reason for change?
The Part 11 text does not say so explicitly. EU Annex 11 and data-integrity guidance from regulators such as MHRA, WHO and PIC/S expect a documented reason for changes to GxP data, so most regulated systems ask for one.
How often should audit trails be reviewed?
FDA’s data-integrity guidance recommends reviewing audit trails that capture changes to critical data with each record, before final approval. System-level trails are usually reviewed periodically on a risk-based schedule set in your SOPs.
Can an administrator be allowed to edit the audit trail?
No. No user, including administrators, should be able to edit, delete or disable the audit trail for GxP data. Any setting that affects the trail must itself be controlled and recorded.
Do log-in records belong in the audit trail?
Log-ins and failed attempts are usually kept in a security log rather than the record audit trail. Both should be retained and available, because reviewers often need them together during an investigation.
How is an audit trail validated?
With scripted tests that create, change and delete records and check every field of the entries, attempts to alter the trail as each role, clock-change tests, export checks and a backup restore check, all traced to URS requirements.