Why Audit Trails Fail Inspections
The audit trail is the most inspected Part 11 requirement and the most frequently cited deficiency in FDA warning letters. It's not usually because the system has no audit trail โ most modern SCADA and DCS platforms have one built in. It's because the audit trail doesn't capture all required event types, can be disabled, or generates records that can't be exported in a readable format during inspection.
This article gives you a practical checklist to design, implement, and test a Part 11-compliant audit trail on your SCADA system โ with real examples of what each requirement looks like in practice.
21 CFR Part 11 ยง11.10(e) requires: "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 shall not obscure previously recorded information." Each element of that sentence is a separate testable requirement.
The Six Required Fields Per Audit Trail Entry
Every audit trail entry must be able to answer six questions. If any one is missing, the record is incomplete and fails Part 11 compliance. These are the six fields your OQ must verify are present and correct for every event type:
The Event Types Your Audit Trail Must Capture
A common gap is an audit trail that captures some event types but not all. The OQ must verify each event type independently โ not just that the audit trail mechanism exists. Here is the complete list your system must capture for a Category 4 SCADA in a pharmaceutical environment:
- Setpoint and parameter changes โ every change to an alarm limit, PID setpoint, or control parameter, with old and new values
- Mode changes โ manual/auto/cascade transitions, with the loop or control block identifier
- Alarm acknowledgements โ which alarm, acknowledged by whom, at what time, whether the excursion was still active
- Recipe or batch parameter changes โ any modification to batch parameters, with version reference
- User login and logout โ successful logins, failed login attempts, and session timeouts
- Account management changes โ account creation, deletion, role changes, password resets
- Configuration changes โ any modification to the SCADA application, screen, or tag configuration
- Electronic signature events โ where e-signatures are used, each signing event with meaning of signature
- System events โ startup, shutdown, communication failures, NTP sync loss
The Tamper-Evidence Requirement
Part 11 requires audit trails to be "secure" โ meaning operators cannot modify or delete audit trail entries. This is not just a policy requirement; it must be enforced technically and verified in your OQ. The standard OQ test for tamper evidence is an adversarial SQL test:
The Independent Timestamp Requirement
Part 11 requires timestamps to be "computer-generated" and "independent" โ meaning the timestamp cannot be set or influenced by the operator performing the action. This has two practical implications for your system design and OQ testing:
- The SCADA system clock must be synchronised to a trusted time source โ typically the site NTP server, which should itself sync to an authoritative external source
- Operators must not be able to change the system clock without it being recorded, and ideally should not have access to the clock settings at all
- Your IQ must record the NTP server configuration and the system's sync status at the time of installation
- Your OQ must test what happens when NTP sync is lost โ does the system continue operating with the local clock, and is the sync loss event recorded in the audit trail?
The Audit Trail Review Requirement
EU GMP Annex 11 ยง9 adds a requirement that Part 11 doesn't explicitly state: audit trails must be reviewed regularly as part of the quality process. This typically means periodic review of the audit trail for GMP-critical operations โ checking for unusual patterns, failed login attempts, or out-of-hours configuration changes.
The SOP for your system should define the audit trail review frequency and what the reviewer is checking for. This is also something a QA auditor will ask about during an inspection: "Who reviews your audit trail, how often, and what do they do if they find something unexpected?"
The Audit Trail OQ Test Checklist
Use this as a pre-execution checklist before your OQ sign-off to confirm every audit trail requirement is covered by a test case:
- All six required fields present for setpoint change event
- All six required fields present for alarm acknowledgement event
- All six required fields present for mode change event
- All six required fields present for login and logout events
- All six required fields present for configuration change event
- SQL UPDATE command rejected on audit trail table
- SQL DELETE command rejected on audit trail table
- NTP sync loss detected and logged
- Audit trail export produces complete, accurate, human-readable report
- Audit trail cannot be disabled by operator-level user
The OQ protocol template includes nine pre-written audit trail test cases (OQ-020 through OQ-028) covering all six fields, tamper evidence (SQL adversarial test), NTP sync loss, export completeness, and operator disable attempt. Each test case includes the expected result, the rejection evidence format, and the regulatory clause reference. The audit trail review SOP is included in the SOPs pack.