21 CFR Part 11 is the FDA regulation that governs electronic records and electronic signatures in pharmaceutical, biotech, medical device, and food manufacturing. If software creates, modifies, maintains, archives, retrieves, or transmits records that the FDA requires companies to keep, that software must comply with Part 11 — or the records it produces are not legally equivalent to paper records and can be rejected during an FDA inspection.
What does 21 CFR Part 11 actually require?
Part 11 has three categories of requirements: controls for closed systems (Subpart B), controls for open systems (Subpart B), and electronic signature requirements (Subpart C). Most enterprise software falls under closed systems — systems where access is controlled by the organisation that operates them.
The six technical requirements that matter for development teams are: complete audit trails, role-based access controls, electronic signature validation, system validation documentation, record integrity protections, and operational system checks. Each one has specific implementation requirements that go beyond what most enterprise software provides by default.
What does a Part 11-compliant audit trail look like?
A Part 11 audit trail is not a log file. It is a complete, tamper-evident record of every creation, modification, and deletion of regulated data. Every audit trail entry must include: who made the change (user identity, authenticated), what was changed (the specific field, the old value, and the new value), when the change was made (timestamp from a controlled, synchronised clock source), and why the change was made (a reason code or free-text justification entered by the user at the time of the change).
The "why" is where most software fails Part 11 inspections. Standard enterprise audit logs record who, what, and when. They rarely capture why. Part 11 requires that users provide a reason for every change to a regulated record — and that reason is stored as part of the audit trail, not as a separate annotation that can be edited later.
The audit trail must also be tamper-evident. An administrator should not be able to modify or delete audit trail entries. The technical implementation typically uses append-only storage, cryptographic hashing of sequential entries, or write-once database partitions. If an FDA inspector finds that audit trail entries can be modified by any user, the entire system's records are suspect.
How do electronic signatures work under Part 11?
An electronic signature under Part 11 is legally equivalent to a handwritten signature. It must include: the printed name of the signer, the date and time the signature was applied, and the meaning of the signature (e.g., "approved," "reviewed," "authored"). Each signature must be uniquely linked to one individual and must not be reusable by anyone else.
For non-biometric signatures (username + password, which is what most systems use), the first signing in a session requires both components. Subsequent signings in the same continuous session can use one component (password only) — but only if the system enforces continuous session monitoring. If the session times out or the user logs out, the next signature requires both components again.
Password policies under Part 11 require uniqueness (no two users share credentials), periodic revision (password expiration), and loss management (account lockout after failed attempts, not just a delayed retry). SSO and OAuth are acceptable if the identity provider enforces these controls — but the regulated system must verify that the identity provider's policies meet Part 11 requirements.
What access controls does Part 11 require?
Part 11 requires that system access is limited to authorised individuals and that authority checks prevent unauthorised use. This means role-based access control (RBAC) at minimum, with the ability to restrict specific users or roles from creating, modifying, viewing, or deleting specific record types.
The requirement goes beyond "can this user access this page." It extends to field-level access: can this user modify the batch release date? Can this user change the test result from "fail" to "pass"? Can this user override a quality hold? Each of these actions must be controlled by the system, not by policy alone. If the system allows a production operator to modify a QA-approved record, the system is non-compliant — regardless of whether the SOP says they shouldn't.
What validation documentation does Part 11 require?
System validation under Part 11 means documented evidence that the software does what it's supposed to do. This includes: an installation qualification (IQ) confirming the system is installed correctly, an operational qualification (OQ) confirming each function works as specified, and a performance qualification (PQ) confirming the system performs correctly under real-world conditions with real data volumes.
For the development team, this means writing test protocols that trace back to requirements, documenting test execution with screenshots and timestamps, and maintaining a traceability matrix that maps every requirement to the test that verifies it. This isn't optional documentation — it's what an FDA inspector reviews during an audit, and its absence is a finding.
Where do most development teams get Part 11 wrong?
Treating compliance as a feature instead of an architecture decision. Part 11 compliance can't be bolted on after the application is built. The audit trail architecture, the access control model, the electronic signature flow, and the validation documentation structure must be designed into the system from the beginning. Retrofitting a Part 11 audit trail into an existing application typically costs 2–3x what it would have cost to build it correctly from the start.
Assuming the cloud provider handles compliance. AWS, Azure, and GCP provide infrastructure that can support Part 11 compliance (encryption at rest, access logging, backup and recovery). But the cloud provider's compliance certifications cover the infrastructure, not the application. The application must implement Part 11 controls at the application layer — audit trails, electronic signatures, access controls, and validation — regardless of where it's hosted.
The development team that builds enterprise software for regulated industries needs Part 11 expertise from the requirements phase, not the testing phase. The regulation defines how the software must behave — and the architecture must enforce those behaviours, not just document them in an SOP.
Building something complex?
Start a project with Madgeek