Checklist: Audit Trail Configuration and Go-Live Readiness

This is a ready-to-use go/no-go checklist for the point between qualification and real use: the moment a system is about to start holding genuine GxP data and someone has to confirm the audit trail is actually ready, not merely tested once in a clean environment. It is not a replacement for a scripted qualification test script on a high-risk system; it is the summary gate a named owner signs to authorize go-live, and it doubles as the record of an unscripted, risk-based configuration check on lower-risk systems where a full formal test script is not proportionate. Replace every <<FILL: ...>> placeholder, set your document numbers, and route the checklist through your normal document control. A filled specimen follows. Verify each cited regulation against the current source before you rely on it, and adapt this to your own processes rather than treating it as legal or regulatory advice.

The single rule that shapes the whole checklist: a clean qualification run is not the same as a ready system. Configuration can drift between the day a test script was executed and the day real data starts flowing, and the items below exist to catch exactly that gap.

Document control header

When to use this checklist

Run it once per system, or per major upgrade of an existing system, at three points: before go-live of a new system holding GxP data; before go-live following a software upgrade, migration, or reconfiguration that could touch audit trail settings; and, on lower-risk systems where a full scripted qualification test script is not proportionate to the risk, as the unscripted verification record itself, consistent with a risk-based assurance approach. For High-criticality systems under your audit trail criticality tiering risk assessment, run this checklist in addition to, not instead of, a scripted test script; treat this checklist as the final gate that confirms the script’s results are still true on the day you actually go live.

Before you start

Have all of the following in hand. If any item is missing, stop and record the reason; a readiness check performed without qualification evidence is an opinion, not a check.

How to complete

1. Enter the record identification block.
2. Work sections A to H in order. Do not skip forward; the criticality tier confirmed in section A sets what “Pass” requires in every later section.
3. Mark each item Pass, Fail, or NA. NA requires a reason on the same line. A blank is not an answer.
4. Verify by direct observation of the system wherever the item says so. A configuration described in a specification but not observed live is not confirmed.
5. Any Fail routes to the exception log. Continue the remaining items so the full picture is captured, but do not sign section H authorizing go-live while an unresolved Fail remains on a High-criticality system.
6. Complete the exception log, the disposition, and the signoff.

Record identification

Section A: criticality and requirements

Section B: capture configuration

Section C: protection against tampering

Section D: time integrity

Section E: backup, retention, and availability

Section F: review readiness

Section G: roles, training, and documentation

Section H: final gate

Exception log

Record every Fail. One row per item.

Escalation triggers

Do not authorize go-live while an unresolved significant or potential data integrity gap remains open on a Medium or High-criticality system.

Disposition and signoff

Acceptance criteria

• Every item applicable to this system and its criticality tier is marked, with no blank cells.
• Every Fail is logged, classified, and either corrected or carries an accepted exception with a named approver.
• No unresolved significant or potential data integrity gap exists on a Medium or High-criticality system at the time of signoff.
• The qualification evidence referenced in section G3 exists, is retrievable, and matches the version/build recorded in the record identification block.
• The review frequency named in section F traces to the criticality tier named in section A.
• A named business or system owner has signed authorizing go-live, and QA has approved where required.

References

21 CFR Part 11.10(e) (secure, computer-generated, time-stamped audit trails); 21 CFR 211.68, 211.194. EU GMP Annex 11, section 9 (audit trails) and general principles on validation. A substantially expanded draft revision was issued for consultation on 7 July 2025 (consultation closed 7 October 2025); an EMA stakeholder workshop on the draft followed on 30 June to 1 July 2026, and adoption of the final revision has slipped to 2027 or later. Confirm the in-force version before issue. FDA guidance, Computer Software Assurance for Production and Quality Management System Software, issued 3 February 2026 (superseding the 24 September 2025 final), for risk-based scaling of verification rigor. GAMP 5, Second Edition, for the risk-based validation lifecycle this checklist sits within. MHRA GxP Data Integrity Guidance and Definitions; PIC/S PI 041, Good Practices for Data Management and Integrity.

Confirm the current version and clause numbers of each reference before issue.

Filled specimen

The following shows the checklist completed for an example laboratory information management system going live after a version upgrade. Only the items with something to say are reproduced in full; the remainder passed with the evidence noted. Names, systems, and numbers are illustrative.

Record identification

Selected item results

Exception log

Disposition

What makes this specimen useful is that it held go-live rather than waving through a regression the vendor introduced. A checklist that always shows a clean Pass row on every upgrade is not evidence the system is ready; it is evidence the checklist is not being run against the live system.

Common inspection findings this checklist prevents

• A system goes live on the strength of a qualification test script executed weeks earlier, with no confirmation the same configuration is still true on the day real data starts flowing.
• A software upgrade silently resets audit trail granularity or re-enables a disable option, and nobody re-checks before the new version is used for GxP work.
• Backup processes are assumed to cover the audit trail because they cover the record, with no restore ever tested to confirm it.
• Review-by-exception filters are carried over to a new version without re-validation, so a rule that worked in the old build silently stops firing in the new one.
• Roles are named in a procedure but nobody confirms training was completed before the system went live.
• Go-live is authorized by whoever finished testing, with no named business owner accountable for the decision.

How to adapt this checklist

1. Set your document number and confirm the criticality tiering risk assessment this checklist relies on in section A1.
2. For High-criticality systems, keep this checklist as the final gate in addition to a scripted qualification test script; for Low-criticality systems, this checklist can serve as the sole, unscripted verification record where that is proportionate to risk.
3. Add or remove items in sections B through E to match what your systems can actually be configured to do; do not delete an item because a particular system fails it, log the exception instead.
4. Point the deviation and CAPA references in the escalation table at your real procedures.
5. Confirm every regulation in the references section against the current published version before issue, including the pending Annex 11 revision.