Audit trail

An audit trail, in the regulated sense, is the secure, computer-generated, time-stamped electronic record that allows the reconstruction of the course of events relating to the creation, modification or deletion of an electronic record. That definition comes almost verbatim from 21 CFR Part 11.10(e) and is echoed in EU Annex 11 §9, MHRA's 2018 GxP Data Integrity guidance, PIC/S PI 041 and WHO TRS 1033 Annex 4.

Read carefully, three properties matter. The audit trail must be computer-generated — not written by the user, not edited by the user, not bypass-able by the user. It must be time-stamped — with a clock the user cannot adjust. And it must allow reconstruction — not just listing changes, but allowing an investigator to rebuild the state of the record at any prior point in time.

The MHRA guidance is the bluntest on what counts: 'the audit trail must capture the original entry, all changes made, the identity of the person making the change, the date and time, the reason where applicable, and must be linked to the source record such that the source record cannot be reviewed without the audit trail being available'.

Part 11.10(e) is one of the shortest sub-sections of the rule and one of the most-cited. It requires, for open and closed systems handling electronic records, the use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify or delete electronic records. Record changes must not obscure previously recorded information. Audit-trail documentation must be retained for a period at least as long as that required for the subject electronic records and must be available for agency review and copying.

Four operational consequences fall out:

1. Audit trail must be secure — not editable by users, not editable by admins under normal operation, surviving privileged-account compromise to the maximum extent practical.
2. Audit trail must be computer-generated — the system writes the entry as a side effect of the change, not by asking the user to fill in a 'reason' afterwards (though the reason is captured separately).
3. Audit trail must be time-stamped with a trustworthy source — usually a network time service (NTP) synchronised to a national time standard, with the time-source itself qualified.
4. Record changes must not obscure previously recorded information — the original value, the new value and the reason must all be visible. Overwriting with the new value alone fails this.

The retention rule (audit trail retained at least as long as the record) is more aggressive than it sounds. A BMR retained for one-year-past-expiry under 211.180 means the BMR's audit trail is retained for the same period. A complaint file under 820.198 retained for the longer of the device design life or two years means the complaint-file audit trail is retained for the longer of those.

EU GMP Annex 11 §9 reads: 'Consideration should be given, based on a risk assessment, to building into the system the creation of a record of all GMP-relevant changes and deletions (a system generated audit trail). For change or deletion of GMP-relevant data the reason should be documented. Audit trails need to be available and convertible to a generally intelligible form and regularly reviewed.'

Three additional obligations relative to Part 11:

• Risk-based scoping — audit trail is required for GMP-relevant data, which is a risk decision the system owner makes and documents. A field that does not affect product quality or compliance may legitimately be out of audit-trail scope; the determination must be traceable to a risk assessment.
• Reason for change must be documented — explicit in the EU rule, implicit in Part 11. In practice both regulators expect the reason to be captured at the moment of change, not retro-fitted.
• Audit trails must be regularly reviewed — Annex 11's most operationally consequential clause. The trail is not a sleeping safety net; it is a record that someone must look at, with a documented frequency and a documented finding.

The FDA caught up to the review requirement in the 2018 Data Integrity guidance Q&A 7: 'Audit trails subject to regular review should include, but are not limited to, the following: the change history of finished product test results, changes to sample run sequences, changes to sample identification, and changes to critical process parameters.'

The single biggest shift in regulator expectations over the past decade is that audit-trail review has moved from 'good idea' to 'cited if missing'. The FDA's Inspections Database shows a steady increase in Part 11 audit-trail observations since 2018, almost all of them on the review side, not the existence side.

The expectation is now: every system that creates GMP-relevant records has a documented audit-trail review SOP; reviewers are independent of the people whose changes they review; the review happens with a documented frequency proportionate to risk (typically before batch release for batch-release-relevant data, periodically otherwise); and findings — including 'no findings' — are documented.

Common audit-trail review patterns:

• Per-batch review by Quality before batch release — every audit-trail entry on the BMR since release of the WO, focused on edits, deletions, e-signatures, deviations.
• Per-shift review by the Quality Unit of LIMS audit-trail entries on samples and results.
• Periodic risk-based review of system-wide audit trails for high-impact systems (MES, eBMR, eDHR, ERP for GMP-relevant fields).
• Exception-based review using anomaly-detection queries — repeated edits, edits outside business hours, edits by users in roles that should not be editing, e-signatures within unrealistically short time windows.

Annex 11 §9's 'GMP-relevant data' phrasing makes audit-trail scope a documented risk decision. The principle: anything that affects product quality, patient safety, batch release, regulatory submission, or the manufacturer's defensibility under inspection is in scope. Anything purely operational and not regulated may be out.

Typical in-scope fields:

• Every field on the master records — MMR, DMR, formula, specification, label artwork, recipe, SOP.
• Every step execution on the batch records — BMR, DHR, eBMR step result, dispense weight, in-process test result.
• Every lab result — LIMS sample status, result value, OOS flag, retest decision.
• Every quality event — NCR, deviation, CAPA, complaint, recall.
• Every supplier and material status — approval, qualification, lot release, reject, recall.
• Every user-role permission change.
• Every e-signature event — signer, role, meaning, timestamp, the hash of what was signed.
• Every configuration baseline change to the validated system itself — workflow definition, role matrix, calculation formula, alarm trip-point.

Typical out-of-scope (with documented risk justification):

• User-personalisation preferences (dark mode, list density, default view) — no GMP impact.
• Non-regulated UI state (saved searches, dashboard layout).
• Performance telemetry, error logs, infrastructure metrics — kept separately for ops/security reasons.

An audit-trail implementation that survives FDA, MHRA, EMA, ANVISA, PMDA and Notified Body scrutiny has these properties:

• Captured at the data layer — database trigger, ORM hook, or service-layer middleware that fires on every INSERT, UPDATE, DELETE — not application-layer code that the developer can forget to add.
• Per-row, per-field — every changed field on every changed row is recorded, with the previous value, the new value, the user, the timestamp, the session, the IP/device and the reason-for-change.
• Immutable — append-only, with checksum or hash-chain protection so an admin with database access cannot retro-edit without detection.
• Time-stamped from a qualified clock — server-side timestamp from a NTP-synchronised source, not the user's browser clock.
• Reason-for-change required at the UI layer for any modification to a previously-saved value, free-text or controlled-vocabulary depending on field criticality.
• Reviewable in human-readable form — the audit trail can be rendered as a chronological narrative, filtered by record, user, time-window or change-type, exported to PDF or CSV for the inspector.
• Linked to the source record — opening a record exposes the audit-trail entries; the trail cannot be reviewed in isolation from the data it pertains to.
• Retained as long as the underlying record — under a retention policy that survives system migration, vendor change, schema evolution.

1. Audit trail exists but is never reviewed — Annex 11 §9 and FDA 2018 guidance finding.
2. Audit trail can be disabled by an admin — usually by a 'maintenance mode' flag. Inspection finding the moment the flag is discovered.
3. Audit trail uses the client's clock instead of the server's. Time-zone drift, deliberate clock-skew, summer-time bugs.
4. Reason for change is optional or free-text 'correction' / 'typo' / '.' — meaningless content.
5. Original value is overwritten in the audit-trail entry by a later 'corrective' edit. Reconstruction impossible.
6. Audit trail of the audit trail does not exist. The audit-trail table itself is editable by anyone with database access.
7. Multi-system architectures with audit trails on each system but no cross-system reconstruction. A batch that touches ERP, LIMS and MES has three trails that cannot be joined.
8. Backup-restore loses the audit trail. The trail is in a different schema or different database that does not back up on the same schedule.
9. Audit trail is dumped to flat files and then 'archived' to a folder that is not under the same retention controls as the production system.

A practical audit-trail review programme has three tiers — per-batch, per-cycle, per-system — with documented frequency, scope, reviewer role and finding format.

1. Per-batch (event-driven): For every batch released, Quality reviews the BMR audit-trail entries since WO release. Focus on edits, deletions, e-signatures and deviations. Output: signed review record attached to the BMR before release.
2. Per-cycle (calendar-driven): Daily or per-shift for high-throughput systems (LIMS); weekly or monthly for moderate-impact systems (document control, supplier qualification). Scope: exception queries (after-hours edits, role-anomaly edits, repeated edits to the same field). Output: signed review log with findings or 'no findings'.
3. Per-system (periodic, risk-based): Quarterly or annually for the whole system. Scope: full audit-trail coverage of GMP-relevant data, configuration-baseline diff, user-role change history, e-signature integrity check. Output: periodic-review report under Annex 11 §11.

Independence matters. The reviewer must not be the same person whose changes they are reviewing. For per-batch review, the BMR reviewer (already independent of the preparer under 211.186) typically does the audit-trail review at the same time.

Audit trail in V5 is a data-layer feature, not an application feature. There is no path to write to a regulated table without producing an audit-log row. The application layer enforces the reason-for-change capture at the UI, but the trail itself is written by the database.

• Every regulated table has a paired audit_log table — same schema family, append-only, no UPDATE / DELETE permissions for any role.
• JSONB diff captures changed columns only — both previous and new values are recorded.
• Actor is auth.uid() from the Supabase session; session ID, IP and user-agent are attached.
• Reason-for-change is captured at the UI as a controlled-vocabulary selection (typo, miscalculation, deviation correction, etc) for high-risk fields, and free-text for general changes; the application layer rejects the save if the reason is missing.
• Server-side timestamp from the qualified Lovable Cloud time source; client clocks are never trusted.
• Hash chain links sequential audit_log rows so retroactive editing of audit_log itself is detectable.
• Audit-trail review UI in the Quality module: filter by record, by user, by time-window, by change-type; narrative render; PDF / CSV export.
• Per-batch review is wired into the BMR / DHR release workflow — the reviewer cannot release without acknowledging the audit-trail review.
• Configuration-baseline diff report supports Annex 11 §11 periodic review.