FDA 21 CFR Part 11 was published in 1997, which makes it older than most of the software platforms it now governs. The regulation was written when "electronic records" meant a database on a server in a locked room and "electronic signature" meant a typed name in a field. The clinical technology landscape it applies to today includes cloud-hosted eCRF platforms, distributed mobile data capture tools, AI-assisted query resolution systems, and API-integrated CTMS environments. The regulation has not been rewritten. The interpretive burden falls on vendors to map their system architecture to requirements that were originally written for a different generation of technology. Getting that mapping right is not optional for vendors selling into regulated clinical research. FDA inspectors look for Part 11 compliance specifically, and findings generate warning letters.
What Part 11 Actually Requires
The regulation governs two categories of records: closed systems (where access is controlled by the person responsible for the content) and open systems (where access is not controlled by that person, such as a public network). Most clinical trial software operates as a closed system, which carries the baseline requirements. Open system requirements are more extensive and include additional encryption and authentication measures that most eClinical platforms address through HTTPS transport and token-based authentication.
For closed systems, Part 11 requires the following system properties:
| Requirement Category | Specific Obligation |
|---|---|
| System validation | Software must be validated to ensure accuracy, reliability, and consistent intended performance; validation documentation must be maintained |
| Audit trail | Computer-generated, time-stamped audit trail documenting creation, modification, and deletion of records; operator-independent and not modifiable by system users |
| Record protection | Records must be protected to enable accurate and ready retrieval throughout the records retention period |
| Access controls | System access limited to authorized individuals; controls to prevent unauthorized use |
| Operational checks | Operational system checks to enforce permitted sequencing of steps and events |
| Authority checks | Checks to ensure only authorized individuals can use the system, electronically sign records, access devices, or alter records |
The Audit Trail Requirement Is Not Flexible
The audit trail provision of Part 11 generates more inspection findings than any other requirement. The regulation requires that the audit trail be computer-generated (not manually maintained), time-stamped, and operator-independent. "Operator-independent" means a user of the system cannot modify or delete audit trail entries. This seems obvious, but in our review of eClinical platforms in the market, we've found meaningful variation in how this is implemented.
Some platforms maintain audit trails that are technically stored in a mutable database table, with access restricted through application-layer controls. The question inspectors ask is whether a database administrator with direct access to the storage layer could modify those entries. If the answer is yes, the system does not have a genuinely tamper-evident audit trail. Immutability must be enforced at the storage layer, not just at the application layer.
The audit trail must also capture specific information for each entry: the date and time of the action, the operator identity (not just a user ID, but a named user whose identity is verified), and, for record modifications, the prior value of the changed field. That last requirement is where many systems fall short. An audit trail that records "field modified" without preserving the pre-modification value does not satisfy Part 11's requirements. Regulators need to reconstruct the state of a record at any point in time during the trial. Without prior values, that reconstruction is impossible.
Electronic Signatures: What Counts and What Doesn't
Part 11's electronic signature requirements are frequently misunderstood. The regulation defines an electronic signature as "a computer data compilation of any symbol or series of symbols executed, adopted, or authorized by an individual to be the legally binding equivalent of the individual's handwritten signature." That definition covers a lot of ground. What it requires specifically is that electronic signatures be:
- Unique to one individual and not reused by or reassigned to anyone else.
- Verified as the signature of the person who applied it before any action based on the signature is triggered.
- Linked to their respective electronic records to prevent the signature from being removed, copied, or otherwise transferred to falsify another record by ordinary means.
The linking requirement is the one that generates the most technical complexity. An electronic signature that consists of a username and password entered at a specific point in a workflow is not inherently linked to the record being signed unless the system cryptographically binds the signature event to the record contents at the moment of signing. A signature applied to a document hash that changes if the document is modified is linked in the Part 11 sense. A workflow that records "user X confirmed at timestamp Y" without binding that confirmation to a specific record state may not satisfy the linking requirement.
System Validation: The Documentation Obligation
Part 11 requires system validation. The FDA's 2003 guidance document on Part 11 scope and application clarified that validation documentation should be commensurate with risk, which gave vendors some flexibility in the depth of their validation protocols. But "commensurate with risk" does not mean minimal. For a system that captures clinical trial data used in regulatory submissions, the validation documentation must be thorough.
What inspectors look for in validation documentation includes:
- Installation Qualification (IQ): Evidence that the system was installed correctly in the production environment, including software version verification and environment configuration documentation.
- Operational Qualification (OQ): Evidence that the system operates as intended across its functional requirements, including test scripts and pass/fail documentation for each function.
- Performance Qualification (PQ): Evidence that the system performs reliably under actual use conditions, including load testing if the system handles concurrent multi-site data entry.
- Change control: Documentation of any changes to the system after initial validation, with re-validation evidence proportional to the scope of the change.
Vendors who provide "validated platform" documentation must be transparent about what that validation covers. Platform-level validation covers the base software. Configuration-level validation covers the specific study setup within that platform. Sponsors and CROs cannot rely solely on a vendor's platform validation to satisfy their own Part 11 obligations for study-specific configurations.
Where Vendors Get This Wrong
In our analysis of Part 11 gaps in clinical technology platforms, three failure patterns appear most frequently.
First, audit trail gaps at system boundaries. Many eClinical environments connect multiple systems: an EDC for data capture, a CTMS for site management, a document management system for regulatory documents, and potentially a separate safety database. Each system may maintain its own audit trail. What is often missing is an audit trail that captures cross-system events: when data is exported from one system and imported into another, when a user accesses records from multiple systems within a single session, or when a protocol change in the CTMS propagates downstream to the EDC. The boundary events are the ones that get missed.
Second, user deprovisioning failures. Part 11 requires that electronic signatures be unique to individuals. When an investigator leaves a site or a CRA changes roles, their access to the system must be promptly revoked and their credentials must not be reassigned. Audit trail entries for that individual must remain attributable to them for the record retention period even after their access is revoked. Systems that handle this correctly archive the user record and maintain the attribution. Systems that fail often reassign user IDs or purge user records, breaking the audit trail linkage.
Third, inadequate reason-for-change capture. When a data field is modified after initial entry, Part 11 and ICH E6(R2) both require that the audit trail capture a reason for the change. Many systems present a reason-for-change field at modification time but do not enforce that it be completed with substantive content. "Correction" or "data entry error" entered in every field across thousands of modifications does not satisfy the substantive documentation requirement. The reason should explain why the value changed, not just that it did.
Part 11 compliance is not a certification event. It is an ongoing operational condition. A system that was compliant at validation and has since received software updates, user access policy changes, and configuration modifications without documented re-evaluation may not currently meet the regulation's requirements. Vendors who treat Part 11 as a one-time validation exercise rather than a continuous compliance obligation put their clients at inspection risk.
What Sponsors Should Ask Clinical Technology Vendors
When evaluating a clinical technology platform for Part 11 compliance, the questions that matter go beyond "is your platform Part 11 compliant?" The specific questions worth asking include: What is your audit trail storage architecture, and at what layer is immutability enforced? How do you handle electronic signature linkage to record contents? What does your change control process look like for post-validation software updates? Can you provide your current validation documentation package for review?
Platforms that cannot answer those questions directly, or that redirect to marketing materials rather than technical documentation, are presenting a compliance risk. The inspection risk is the sponsor's. Knowing what the platform actually does, rather than what the vendor says it does, is the only way to manage that risk before an FDA inspector asks the same questions on site.
