21 CFR Part 11 applies to automated test execution in GxP environments in the same way it applies to any other electronic record that supports a regulatory submission or a GxP activity. Many validation teams focus their Part 11 assessment on the application under test and treat the test automation tooling as infrastructure — outside the scope of Part 11. This is incorrect, and it is a recurring source of 483 findings. The test execution records are electronic records; the sign-offs on those records are electronic signatures; and both must meet the Part 11 requirements.
Which Part 11 requirements apply to automated test records
- §11.10(a) — Validation. The automated test system itself must be validated. This is the most commonly missed requirement: teams validate the application under test but not the automation tool generating the evidence. See 21 CFR Part 11.
- §11.10(b) — Accurate and complete copies. The test execution record must be producible in a human-readable, printable form that an inspector can review without access to the automation tool. An execution record that exists only in a proprietary database format fails this requirement.
- §11.10(c) — Record retrieval. Records must be retrievable throughout the retention period. If the automation tool is decommissioned before the retention period expires, the records must be migrated to an accessible format.
- §11.10(d) — Access control. Only authorised individuals may initiate, approve, or modify a formal test execution. Shared automation accounts — where multiple individuals can use the same credentials — make attribution impossible and are a Part 11 failure.
- §11.10(e) — Audit trail. A secure, computer-generated, time-stamped audit trail must record all operator actions that create, modify, or delete electronic records. For automated tests, this means: who initiated the run, any manual overrides or re-runs, and any changes to the test script version used.
Electronic signatures on test execution records
When a QA reviewer signs off on an automated OQ execution summary, that sign-off is an electronic signature under Part 11. It must include: the signer's full name, the date and time of signing (from a controlled time source), and the meaning of the signature ("I have reviewed this execution record and confirm it meets the acceptance criteria, with all deviations dispositioned"). The signer must re-authenticate at the time of signing — entering their password again, not just being logged in. And the signed record must be frozen: no path in the system can allow modification of the execution record after it has been signed. GxP Copilot enforces all of these requirements in its native signature workflow.
Audit trail for automated execution: what must be captured
The audit trail for automated test execution must capture: every initiation of a test run (who, when, which scripts, which environment); every pass and fail result (including timestamp and the exact expected vs actual values); any manual re-execution of a failed step (who authorised the re-run, what changed, what the new result was); any manual override of an automated result (who overrode, what the original result was, what the override was, and the justification); and every change to the test script version used in a formal execution. An audit trail that captures only the final execution summary — not the individual step-level events — does not meet the Part 11 standard for complete audit trail records.
The shared-account problem in CI/CD-integrated testing
Continuous integration pipelines commonly use a single service account to execute automated tests — a "ci-runner" or "automation" account that is shared across all automated jobs. In a GxP environment, this is a Part 11 §11.10(d) failure: the service account's actions cannot be attributed to a responsible individual when a discrepancy appears. The Part 11-compliant approach: each formal execution must be initiated by or under the authority of a named individual, and the automation account used must be non-shared and auditable. In practice, this means: CI/CD pipelines may run continuously in development environments without this constraint, but formal OQ/PQ executions must be initiated by a named, authenticated individual who accepts responsibility for the execution record.
Practical compliance steps for existing automation programmes
- Inventory every automated test execution that generates a formal validation record and check that the initiating identity is attributable to a named individual — not a shared account.
- Verify that every automated test execution record can be exported in a human-readable format without access to the automation tool.
- Check that sign-offs on execution summaries include re-authentication, meaning, and a frozen record — not just a click to "mark as approved."
- Review the audit trail scope: does it capture individual step results, or only the summary? Individual steps are required.
- Confirm that the automation tool itself has been validated under GAMP 5 and that the validation is current.
Where to go next
Explore GxP Copilot for AI-native validation, TraceDraft for source-traceable clinical documentation, or book a demo to see either on your own data.