What Makes an Audit Trail a Part 11 Audit Trail
Most SCADA platforms generate some form of change log by default. InTouch, WinCC, Ignition, FactoryTalk — they all have built-in event logging. The gap between that default logging and a Part 11 compliant audit trail is wider than engineers usually expect, and getting it wrong at the design stage means rework after the FAT or deviations during the OQ.
21 CFR Part 11 §11.10(e) requires that audit trails be computer-generated, use secure, date and time-stamped entries that record operator actions, and that they be retained for a period at least as long as required for the associated electronic records. The word "secure" carries weight: it means the audit trail must be protected from modification after the fact — including by system administrators. A log file that an admin can edit, overwrite, or delete is not a Part 11 audit trail regardless of how comprehensive its contents are.
The design requirements flow from this: write-once architecture enforced at the database level, NTP-synchronised timestamps on every entry, individual user attribution on every entry, complete field capture for every GMP-critical action, and seven-year retention. Each of these must be specified in the FDS, implemented in the software as described in the SDS, and proven by specific OQ test cases. This article covers how to do each one.
ALCOA+ — The Design Checklist
The ALCOA+ framework is the cleanest way to structure the audit trail design requirements because it maps directly to Part 11 and Annex 11 obligations, and it gives the FDS author a specific function to describe for each principle. The full audit trail checklist covers all requirements in detail; here we focus on the implementation.
| ALCOA+ Principle | Design Requirement | FDS Function |
|---|---|---|
| Attributable | Every GMP action attributed to the authenticated individual who performed it — not a role, not a workstation, a named person | FUNC-DI-001 — unique accounts, user ID in every audit entry |
| Legible | Records stored in engineering units with labels — no raw A/D counts; exports preserve all fields including units and timestamps | FUNC-DI-003 — EGU labels, certified copy export format |
| Contemporaneous | NTP-synchronised timestamps ±30 seconds; NTP loss alarm within 60 seconds; parameter changes locked on sync loss | FUNC-DI-004 — NTP sync, drift lock, manual change controls |
| Original | Write-once SQL architecture — INSERT-only permission on AuditTrail table; no UPDATE or DELETE permitted by any account; no clear function in HMI | FUNC-DI-002 — write-once architecture, separate from process tables |
| Accurate | Calibrated instruments with traceable certificates; sensor cross-validation for critical measurements; calibration due date management | FUNC-DI-006 — calibration controls, OOT procedure |
| Complete | No data gaps; PLC buffer during historian outage; gap detection alarm; UPS power continuity | FUNC-DI-005 — data buffering, gap detection, backup integrity |
| Consistent | All timestamps from same NTP-synchronised source; all records use same field structure; same engineering units throughout | FUNC-DI-004 + typ_AuditEntry_GxP UDT enforces consistent structure |
| Enduring and Available | 7-year total retention; online for 2 years; archived with full query capability; export function with no field omission | FUNC-DI-007 — retention, accessibility, export |
The Six Required Fields — No Exceptions
Every audit trail entry for a GMP-critical action must contain exactly six fields. This is not arbitrary — these six fields are what a QA reviewer or FDA inspector will look for when they query the audit trail during an inspection. A record missing any one of them is an incomplete record.
- User ID — the authenticated individual's unique identifier, not their role and not a generic account name. This is what "attributable" means in practice. If the user ID is "Operator" rather than "jsmith," the record is non-attributable.
- NTP-synchronised timestamp — in DD-MMM-YYYY HH:MM:SS format, generated by the system at the moment of the action, from the NTP-synchronised clock. Not user-entered. Not the workstation clock that may drift. From the server time source that is verified during qualification.
- Tag or parameter name — which specific parameter, setpoint, or system function was acted upon. "Conductivity High alarm setpoint" is a parameter name. "Setpoint" is not.
- Old value — the value before the change, in engineering units. This is what enables a reviewer to reconstruct the history of a parameter without cross-referencing other systems.
- New value — the value after the change, in engineering units with the unit label.
- Reason — for setpoint changes and other high-impact actions, a mandatory free-text entry by the user explaining why the change was made. The system must enforce this field — not optional, not skippable. Minimum character count (10 characters) enforced at the software level to prevent one-character placeholder entries.
The six-field requirement is verified in OQ. The test case makes a setpoint change and then exports the audit trail entry for that change. The verifier confirms all six fields are present with the correct values. This is not a visual check — the exported data is attached as OQ evidence and each field is explicitly verified in the test record.
Write-Once Architecture — How It Actually Works
The "write-once" requirement is the one most likely to be misunderstood and most likely to generate a finding. A log file on disk is not write-once. A SCADA event log that an Administrator can clear is not write-once. Even a database table with no user-facing delete button is not write-once if an administrator can execute a DELETE query via a SQL client.
Write-once means enforced at the database engine level by SQL permissions. The SCADA application service account — the database user that the SCADA software uses to connect to the historian — has INSERT-only permission on the AuditTrail table. It can write new records. It cannot execute UPDATE or DELETE on existing records. No account that the SCADA application uses can alter a record after it has been written. Even the Database Administrator account on the SQL Server should not routinely have modification access to the GMP audit trail table — if that level of access is ever needed for legitimate maintenance, it requires a deviation, QA approval, and a complete audit trail of the access itself.
What Actions Must Generate Audit Trail Entries
The FDS must explicitly list every action category that generates an audit trail entry. "All GMP-critical actions" is not a specification — it is an invitation for gaps. The following categories must be explicitly listed:
- Setpoint changes — every modification to any GMP-critical setpoint, with old value, new value, tag name, user ID, timestamp, and mandatory reason.
- Mode changes — transitions between Auto, Manual, and Maintenance modes, with reason.
- Sequence initiations — sanitization start, divert release, any operator-initiated automated sequence, with initiating user and reason.
- Alarm acknowledgements — every alarm acknowledgement, recording which alarm, who acknowledged it, and when.
- Alarm suppression — suppression activation and expiry, with suppressing user, reason, alarm tag, and suppression duration.
- User session events — login, logout, session timeout, failed login attempt, concurrent login block, account lockout.
- User account management — account creation, modification, role change, deletion, unlock.
- I/O force activation and removal — any PLC force applied, with the tag forced, forced value, applying user. Forces must clear before OQ closure.
- System events — NTP sync loss and restoration, backup failure, historian communication loss and recovery, CPU restart.
- Blocked actions — denied attempts must also be audit-trailed. An Operator attempting to modify a setpoint generates an audit trail entry recording the attempt, the denial, and the Operator's user ID. This is evidence that role enforcement is working.
The Adversarial OQ Test — Why It Matters
The write-once architecture must be proven, not assumed. The OQ includes a mandatory adversarial test that most engineers have not encountered before their first pharma qualification: connect to the historian database using SQL Server Management Studio, identify a specific audit trail record created during earlier OQ testing, and attempt to modify it with a SQL UPDATE command.
The expected result is a permission error. The SQL UPDATE command fails. The record is unchanged. The test evidence is a screenshot of the error message and a screenshot confirming the record is unmodified.
The OQ also verifies that no clear or delete function exists in the SCADA HMI for any user role — including Administrator. The verifier navigates through all Administration screens while logged in as Administrator and confirms there is no "Clear Audit Trail," "Delete Records," or "Archive and Delete" button. The absence of this function is documented with screenshots of the Administrator screens. This closes the loop: write protection is enforced at both the database level (SQL permissions) and the application level (no delete UI for any role).
Separation from Process Data — A Critical Design Decision
The audit trail must be stored in a separate database table from the process data historian. This is not a nice-to-have — it is an architectural requirement that prevents several failure modes.
If the audit trail records are interleaved with process historian records in the same table, a legitimate operation on the historian data — archiving old process data, purging records beyond the online retention window — could inadvertently affect audit trail records for the same time period. Keeping them separate means: process data can be managed according to its retention and archiving policy; audit trail records are subject to their own retention policy and can never be deleted as a side effect of process data management operations.
The SDS must explicitly state that the AuditTrail table is separate from the ProcessHistory table, define the separate SQL permission sets for each, and document that the retention management procedures (automated purge, archive) operate on ProcessHistory only and never touch AuditTrail.
The Historian vs Windows Event Log — Where Records Live
A common architectural mistake is to route security events — failed logins, account lockouts — to the Windows Event Log rather than the GMP historian. Windows Event Log is not a validated record store. It is not subject to the same retention requirements. It can be cleared by an Administrator. It is not queried by the same tools that QA uses to review audit trail data. And critically, it is typically on a different retention cycle from the GMP audit trail.
All security events — logins, failed logins, account lockouts, role changes — must be written to the same immutable GMP historian that captures setpoint changes and alarm acknowledgements. They should be queryable by the same interface, subject to the same seven-year retention, and protected by the same write-once architecture. The SDS must specify this explicitly; "security events are logged to Windows Event Log" is not an acceptable design for a Part 11 system.
The FDS (FDS-SYS-001) Section 9 maps all seven ALCOA+ principles to specific functional descriptions (FUNC-DI-001 through FUNC-DI-007). FUNC-DI-002 specifies the audit trail architecture: computer-generated, write-once, separate from process data tables, with the six required fields defined. The SDS (SDS-SYS-001) Section 7 specifies the SQL permission model for the SCADA service account (INSERT-only on AuditTrail) and the typ_AuditEntry_GxP UDT enforcing a consistent eight-field record structure including NTP-synchronised timestamp, user ID, tag name, old value, new value, engineering units, reason text, and event type. The OQ (OQ-SYS-001) contains OQ-020 (audit trail complete event capture — five distinct actions with all six fields verified) and OQ-021 (write-once adversarial test — SQL UPDATE attempt generating permission error, plus Administrator HMI screen verification confirming no delete function exists). Both are classified High risk. The historian tag configuration specifies that AuditTrail records are retained for the full seven-year period and are excluded from the automated process data purge job.