Test Script: Audit Trail and Data Integrity

This is a ready-to-use test script for verifying the audit trail and data integrity controls of a GxP computerized system. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and run it under an approved validation plan or protocol. A worked filled specimen follows the template so you can see how a completed version reads. A test script is contemporaneous GxP evidence: write each actual result as you observe it, in ink or in the validated tool, never reconstructed later. Verify each cited regulation against the current source before you rely on it.

What this script proves, and what it does not

This script demonstrates that the system’s audit trail and data integrity controls behave as specified for the high-risk operations an inspector cares about: that every change to a record captures who made it, what changed, when, the old value, the new value, and why; that the audit trail cannot be turned off or edited by ordinary users; that time stamps are accurate and protected; that an electronic signature is bound to the specific record it signs and cannot be transferred or repudiated; and that records satisfy the ALCOA+ attributes. It is a functional verification, run in a qualified non-production environment, not a review of live production data. Periodic audit trail review of real records is a separate control, governed by your audit trail review SOP. Decide the risk of each function first, then keep the scripted depth below for the functions that affect a result, a decision, or product quality.

Document control header

1. Requirements traced

State exactly which requirements this script verifies, so the traceability matrix links each requirement to its evidence in both directions. Every requirement listed here must be exercised by at least one numbered step in section 6.

2. Objective

In one or two sentences, state what passing this script demonstrates.

<<FILL: objective, e.g. this script verifies that the system maintains a complete, attributable, time-stamped, tamper-evident audit trail for all GxP record changes, that the audit trail cannot be disabled or altered by ordinary users, that time stamps are accurate and protected, and that electronic signatures are bound to the records they sign, so that electronic records satisfy ALCOA+ and meet 21 CFR Part 11 and EU GMP Annex 11.>>

3. Prerequisites

List everything that must be true before execution starts. If any prerequisite is not met, do not execute; record the gap as a deviation and stop.

4. Test data and accounts used

5. Execution conventions

Read these before executing, then follow them for every step. They are the rules an inspector expects to see applied consistently.

• Record each actual result contemporaneously, as you observe it, in the actual result cell. Do not pre-fill, do not batch at the end.
• “Meets expected result” is not an actual result. Write what you actually saw: the value, the exact message text, the screen state, the time stamp shown.
• When a step checks a time stamp, also record the controlled reference time at that moment so the two can be compared.
• Use one unambiguous mark for pass or fail. A blank cell is incomplete, not a pass.
• For any single-line correction, strike through once, initial, date, and add a brief reason. Never obliterate the original entry.
• Capture objective evidence (screenshot, audit trail export, signature manifestation printout) for every step whose pass depends on a system output, and give that evidence a unique reference recorded in the step.
• The moment any step does not meet its expected result, mark it Fail, stop if instructed, and open a deviation per section 9. Do not retest a failed step in place without a documented disposition.

6. Test steps

For each step give the action, the precise expected result, the actual result as observed, pass or fail, and the evidence reference. The expected result must be written before execution and must be specific enough that two people would agree on whether it was met. The blocks below cover change capture, audit trail protection, time stamp correctness, e-signature binding, and the ALCOA+ attributes.

6A. Change capture: who, what, when, old, new, why

6B. Audit trail protection: cannot be disabled or edited by users

6C. Time stamp correctness

6D. Electronic signature binding

6E. ALCOA+ attribute checks

These steps confirm the record carries each ALCOA+ attribute. The attribute names are taken from the data integrity framework cited in section 12; the test expectations below are written for this script. Map each to evidence already captured above where possible.

Add or remove rows so every requirement in section 1 is exercised. Number steps continuously; do not reuse a number after a revision.

7. Acceptance criteria

This script passes only when all of the following are true:

• Every step required to verify the requirements in section 1 is marked Pass, with a recorded actual result and, where applicable, an evidence reference.
• The audit trail captured who, what, when, old value, new value, and reason for every change (block 6A).
• No ordinary-user path could disable, edit, or delete the audit trail (block 6B), and any audit trail or clock configuration change was itself audited.
• Time stamps were accurate against the controlled reference within the stated tolerance and were unambiguous as to time zone (block 6C).
• Electronic signatures were bound to the specific record signed, carried name, date, time, and meaning, and could not be copied or transferred (block 6D).
• All nine ALCOA+ attributes were demonstrated (block 6E).
• Every deviation raised during execution is resolved with a documented disposition, and any retest is recorded under its own step or attachment.
• The completed script is reviewed and approved per section 11.

A script with one or more open Fail steps, or unresolved deviations, does not pass and cannot support the conclusion in the parent report.

8. Evidence index

List every piece of objective evidence captured, so a reviewer can find each one without hunting.

9. Deviations raised during execution

Any step that does not meet its expected result, any departure from the written steps, and any prerequisite not met is recorded here and managed per the parent protocol and <<FILL: deviation / test-incident SOP-ID>>. Cross-reference the deviation number on the failing step.

A failed step is not a finding against the tester. It is data. The discipline an inspector looks for is that the failure was captured honestly, classified, dispositioned, and that any retest is traceable to the original failure, not quietly overwritten. A data integrity failure (for example an audit trail an ordinary user can disable) is almost always critical.

10. Execution summary

11. Sign-off

The tester executes and signs; an independent reviewer who did not execute the test confirms the record is complete, the evidence supports each pass, and deviations are resolved. The reviewer should not be the same person who executed the script.

12. References

21 CFR Part 11 (electronic records and electronic signatures), in particular 11.10(e) on secure, computer-generated, time-stamped audit trails, and 11.50, 11.70, and 11.200 on signature manifestation, signature-to-record linking, and signature uniqueness. 21 CFR 211.68 (automatic, mechanical, and electronic equipment) and 211.194 (laboratory records). EU GMP Annex 11 (Computerised Systems), section 9 (audit trails), section 12 (security and access control), and section 14 (electronic signatures). EU GMP Annex 11 and Chapter 4 (Documentation) for record integrity principles. MHRA GxP Data Integrity Guidance and Definitions (ALCOA and ALCOA+ attributes). PIC/S PI 041, Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments. ICH Q9 (Quality Risk Management), for the risk basis of test depth. GAMP 5, Second Edition (a risk-based approach to compliant GxP computerized systems). FDA Guidance, Computer Software Assurance for Production and Quality Management System Software, issued 3 February 2026 (superseding the 24 September 2025 final) (risk-based scaling of test rigor). For medical device software: 21 CFR Part 820 (QMSR, effective 2 February 2026, incorporating ISO 13485:2016) and IEC 62304.

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

13. Revision history

Filled specimen

The following shows the script executed for an example laboratory information management system, verifying the core audit trail, time stamp, and e-signature controls. The company, system, accounts, and numbers are illustrative; replace them with your own.

Header (extract)

Requirements traced

Test steps (executed, extract)

ALCOA+ extract

Execution summary

Sign-off

In this example the tester recorded the exact values, message text, and time stamps seen, paired every time check against the NTP reference, captured a screenshot for each output-dependent step, and confirmed a modification after signing invalidated the prior signature. Had step 6.7 instead shown an analyst could switch off the audit trail, or step 6.19 shown a signature could be copied to another record, the tester would have marked the step Fail, opened a critical test incident, and held the conclusion, which is the behavior section 9 is built to capture.

Common inspection findings this script prevents

• An audit trail that ordinary users can switch off, pause, or that is shipped disabled by default, with no test proving who can change that setting.
• Changes saved with no captured reason, or old values overwritten so the prior value cannot be reconstructed.
• Time stamps that drift from real time, carry no time zone, or come from a clock any user can change, undermining the “contemporaneous” attribute.
• Electronic signatures that are not bound to the record signed, that survive a later change to the record, or that can be copied or attributed to the wrong person.
• Shared or generic logins, so audit entries are not attributable to one individual.
• Audit trail captured only in volatile memory or not retrievable in a readable form on demand, failing “enduring” and “available”.
• A test script that ticks “audit trail present” but never exercises the negative cases (user cannot disable, cannot edit, cannot transfer a signature), which is where data integrity actually fails.
• One uniform level of scripted detail applied regardless of risk, with no documented basis, which is hard to defend now that test rigor is expected to scale with risk.

How to adapt this script

1. Set your test script ID, parent protocol, system version, and effective date in the header, and confirm you are testing in a qualified non-production environment.
2. List your real requirement IDs in section 1 and confirm each is exercised by at least one numbered step; keep the script and your traceability matrix in agreement in both directions.
3. Set the time stamp tolerance in block 6C to your specification (a tight tolerance such as plus or minus 1 minute is common) and name your controlled reference time source.
4. Trim block 6A’s delete step if your system does not permit deletion, and adjust block 6D to your signature design (two-component login, biometric, or token), keeping name, date, time, and meaning.
5. Map the ALCOA+ steps in block 6E to evidence already captured in 6A to 6D rather than duplicating actions, but keep a recorded result for each attribute.
6. Point the cross-references in sections 3, 9, and 11 to your real protocol, deviation or test-incident procedure, and review and approval process.
7. Confirm every regulation in section 12 against the current published version before issue.