21 CFR Part 11 Compliance: What It Means for Your EDC
A practical guide to FDA 21 CFR Part 11 requirements for electronic records and signatures in clinical trials, and how modern EDC platforms implement them.
What Is 21 CFR Part 11?
If you work in clinical trials, you have heard the phrase “Part 11 compliant” on every vendor slide deck. But what does it actually mean, and how do you know whether your EDC system truly meets the requirements?
21 CFR Part 11 is the FDA regulation that establishes the criteria under which electronic records and electronic signatures are considered trustworthy, reliable, and equivalent to paper records and handwritten signatures. Published in 1997 and enforced across all FDA-regulated industries, it applies to any electronic system that creates, modifies, maintains, archives, retrieves, or transmits records required by FDA regulations.
For clinical trials, this means your EDC system — the software where site staff enter patient data, investigators sign off on CRFs, and data managers review queries — must meet specific technical controls. Not aspirationally. Not partially. The requirements are prescriptive, and FDA inspectors check them during site audits and sponsor inspections.
Here is what Part 11 actually requires, in plain language.
The Part 11 Control Framework at a Glance
┌─────────────────────────────────────────────────────────┐
│ 21 CFR Part 11 — Key Requirements │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────────────┐ │
│ │ §11.10(e) AUDIT TRAILS │ │
│ │ Immutable, timestamped, field-level tracking │ │
│ │ Retained as long as the electronic records │ │
│ └──────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────┐ │
│ │ §11.10(d),(g) ACCESS CONTROLS │ │
│ │ RBAC, site-scoped isolation, API enforcement │ │
│ │ Authority checks at every layer │ │
│ └──────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────┐ │
│ │ §11.50, §11.100, §11.200 E-SIGNATURES │ │
│ │ Printed name + date/time + meaning │ │
│ │ Re-authentication at moment of signing │ │
│ └──────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────┐ │
│ │ §11.300 PASSWORD CONTROLS │ │
│ │ 12+ chars, Argon2id hashing, lockout, timeout │ │
│ │ Unique IDs, no shared accounts │ │
│ └──────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────┐ │
│ │ §11.10(a) SYSTEM VALIDATION │ │
│ │ IQ/OQ/PQ, continuous compliance testing │ │
│ │ Automated verification in CI/CD │ │
│ └──────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘Audit Trails: Section 11.10(e)
The requirement: Systems must use 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. Audit trail documentation must be retained for at least as long as the electronic records and must be available for FDA review and copying.
What this means in practice: Every time anyone changes a data value in a CRF, the system must automatically record who made the change, when it happened, what the old value was, what the new value is, and why the change was made. This record must be immutable — no one, not even a system administrator, should be able to modify or delete audit trail entries.
┌────────────────────────────────────────────────────────┐
│ Audit Trail Entry Structure │
├────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ WHO │ │ WHAT │ │ WHEN │ │
│ │ User ID │ │ Table + Field │ │ Server-side │ │
│ │ User role │ │ Old value │ │ timestamp │ │
│ │ IP address │ │ New value │ │ (not client) │ │
│ └─────────────┘ └──────────────┘ └──────────────┘ │
│ │
│ ┌─────────────┐ ┌──────────────┐ │
│ │ WHY │ │ PROTECTION │ │
│ │ Reason for │ │ No update │ │
│ │ change │ │ No delete │ │
│ │ (mandatory) │ │ Append-only │ │
│ └─────────────┘ └──────────────┘ │
│ │
└────────────────────────────────────────────────────────┘What to look for in your EDC: The audit trail model should be append-only by design. The system should enforce that no user — regardless of role — can update or delete audit records. Each entry should capture the user identity, server-side timestamp, the specific field changed, old and new values, IP address, and an optional reason for change. Look for platforms that implement defence in depth: multiple layers of change tracking so that if one mechanism is bypassed, the other still captures the event.
Access Controls: Section 11.10(d) and 11.10(g)
The requirement: Systems must limit access to authorised individuals. Authority checks must ensure that only authorised individuals can use the system, electronically sign records, access the operation or device input/output, alter records, or perform operations.
What this means in practice: Users must authenticate before accessing any clinical data. Each user should only see and modify data relevant to their role and their assigned site. A nurse at Site A should not be able to view patient data from Site B. An auditor should be able to read data but not modify it.
┌────────────────────────────────────────────────────┐
│ Role-Based Access Control │
├────────────────────────────────────────────────────┤
│ │
│ Role Can View Can Edit Can Sign │
│ ───────────── ──────── ──────── ──────── │
│ Clinician Own site Own site Yes │
│ Nurse Own site Own site No │
│ Data Manager All sites Queries No │
│ Auditor All sites Nothing No │
│ Statistician All sites Nothing No │
│ PII Viewer PII fields Nothing No │
│ │
│ All queries scoped by study + site at API layer │
│ │
└────────────────────────────────────────────────────┘What to look for in your EDC: The platform should implement role-based access control (RBAC) with predefined clinical trial roles. Permissions should be enforced at the API layer — not just the user interface — so that even direct API calls are subject to the same access rules. All data queries should be scoped by study and site, meaning the database itself returns only the data the authenticated user is authorised to see. There should be no public endpoints for clinical data, and no implicit permissions.
Electronic Signatures: Sections 11.50, 11.100, and 11.200
The requirement: Electronic signatures must include the printed name of the signer, the date and time when the signature was executed, and the meaning associated with the signature (such as “review,” “approval,” or “responsibility”). Each signature must be uniquely linked to a specific individual. Signing must require re-authentication at the time of signing.
┌────────────────────────────────────────────────────┐
│ E-Signature Record Components │
├────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────────────┐ │
│ │ Printed Name: Dr. Sarah Johnson, MD │ │
│ │ Date/Time: 2026-03-09T14:23:07Z (server) │ │
│ │ Meaning: "I have reviewed this data and │ │
│ │ confirm its accuracy" │ │
│ │ Record: CRF Entry #SITE-001-PT-042-V3 │ │
│ │ Re-authenticated: Yes (username + password) │ │
│ │ Cryptographically bound to record hash │ │
│ └──────────────────────────────────────────────┘ │
│ │
│ Signature cannot be separated from the record │
│ Signature cannot be reused on another record │
│ │
└────────────────────────────────────────────────────┘What to look for in your EDC: The signing workflow should require the signer to re-enter their username and password at the moment of signing. The signature record should store the signer’s identity, a server-side timestamp, and the stated meaning. The signature must be cryptographically linked to the record it attests to — it should not be possible to separate the signature from the data.
Password Controls: Section 11.300
The requirement: Persons who use electronic signatures based on use of identification codes in combination with passwords must employ controls to ensure their security and integrity.
| Control | Industry Standard |
|---|---|
| Minimum length | 12+ characters |
| Complexity | Multiple validators (similarity, common password, numeric) |
| Hashing algorithm | Argon2id (memory-hard, brute-force resistant) |
| Account lockout | After 5 failed attempts, 30-minute lockout |
| Session timeout | 15 minutes of inactivity |
| Unique identification | One account per person, no shared credentials |
System Validation: Section 11.10(a)
The requirement: Systems must be validated to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.
What to look for in your EDC: The platform should include automated compliance tests that run continuously in CI/CD pipelines. These tests should verify audit trail immutability, electronic signature completeness, password policy enforcement, session timeout behaviour, and RBAC enforcement. Every release should produce a traceable record of compliance test results. This approach serves as continuous operational qualification — not a one-time checkbox.
What Part 11 Does Not Require
Part 11 compliance is often over-interpreted. A few clarifications:
- Part 11 does not require biometric authentication. Username plus password is explicitly permitted under Section 11.200(a) for non-biometric signatures.
- Part 11 does not require blockchain. Immutable audit trails can be implemented with conventional database controls. Append-only tables with restricted permissions are sufficient.
- Part 11 does not require specific technology. The regulation is technology-neutral. It defines outcomes (immutable trails, unique signatures, access controls) not implementations.
- Part 11 does not apply to all electronic records. The FDA’s 2003 guidance on scope clarifies that Part 11 applies to records required by predicate rules and records submitted to the FDA. Internal planning documents and non-regulatory data are out of scope.
Compliance Is Continuous, Not a Checkbox
The biggest misconception about Part 11 is that it is a one-time certification. It is not. Compliance is a continuous state maintained through validated processes, change control, training, and ongoing testing. Every software update, every configuration change, and every new user role must be evaluated against Part 11 requirements.
Modern EDC platforms embed compliance testing directly into the development pipeline. When a code change is submitted, the compliance test suite runs automatically. If any Part 11 control is broken by the change, the build fails before the code is deployed. Compliance is not a quarterly audit — it is enforced on every release.
You Already Know Your EDC Has Gaps. Here Is What to Do About It.
Let us cut through the noise. If you are reading this article, you probably suspect your current EDC is not fully Part 11 compliant. Maybe the audit trail misses some events. Maybe access controls only work in the UI. Maybe the e-signature workflow does not actually re-authenticate. Maybe you have never seen a compliance test result.
Here is what that costs you:
- FDA 483 observations during site inspections that delay your submission
- Warning letters that become public record and damage your reputation
- Remediation projects that cost 10x what prevention would have cost
- Lost time — every week spent fixing compliance gaps is a week your drug is not on the market
The average cost of a one-day delay in drug launch is estimated at $600,000 to $8 million in lost revenue, depending on the therapeutic area. A single Part 11 finding can delay a submission by months.
PharmaTrialsCortex SmartEDC was built with Part 11 compliance as the architectural foundation — not a feature bolted on after the fact:
- Immutable audit trails — append-only by database design, no user can update or delete
- E-signatures with re-authentication — printed name, timestamp, meaning, cryptographically bound
- 8 predefined RBAC roles with site-scoped data isolation at every layer
- Argon2id password hashing, 12-character minimum, 5-attempt lockout, 15-minute session timeout
- Automated compliance tests running on every single deployment — if a control breaks, the build fails
Every one of these controls is deployed, tested, and verified in production today. Not planned. Not in progress. Running.
Start your 14-day free trial — every Part 11 control active from day one. No credit card required. Or book a compliance walkthrough and bring your QA team. We will show you every control, every test, every piece of evidence.
The question is not whether you can afford a compliant EDC. The question is whether you can afford the FDA finding you used a non-compliant one.
For questions about PharmaTrialsCortex’s compliance posture or to request our validation documentation, contact us at security@pharmatrialscortex.com.