21 Cfr Part 11

21 CFR Part 11 Electronic Records and Signatures

Purpose

Provide implementation guidance for electronic records/signatures (ER/ES) compliance: access control, audit trails, data integrity, and validation expectations in medical device software and supporting tools.

When to Apply

• Systems creating, modifying, storing, or transmitting electronic records subject to FDA records.
• Implementing electronic signatures or approvals in software lifecycle tools (e.g., QMS, ALM, CI/CD approvals).
• Handling PHI/PII or regulated data with retention requirements.

Requirements (testable)

1. Access Control: Unique user identities; role-based permissions; no shared accounts. Rationale: accountability.
2. Authentication Strength: Enforce strong auth (password policy or MFA for remote) appropriate to risk; session timeout and lockout. Rationale: prevent unauthorized use.
3. Electronic Signatures: Link signatures to unique user IDs; include printed name, date/time, and meaning of signature (e.g., review/approval) per §11.50. Rationale: non-repudiation.
4. Signature Controls: For open systems, require two distinct factors at signing or equivalent control; log signature attempts; prevent reuse of credentials without re-auth (§11.200). Rationale: signature integrity.
5. Audit Trails: Computer-generated, time-stamped, secure, and independent audit trail for create/modify/delete; capture user, timestamp, action, before/after where feasible; no alteration by users (§11.10(e)). Rationale: record integrity.
6. Record Integrity: Protect records from alteration; use checksums/hashes, versioning, and controlled storage; backups with integrity checks. Rationale: data reliability.
7. Time Synchronization: System clocks synchronized (e.g., NTP) for audit and signature timestamps. Rationale: reliable timing.
8. Validation: Validate systems for intended use; document requirements, test protocols/results, and deviations (§11.10(a)). Rationale: fitness for use.
9. Training & Policies: Users trained on ER/ES use; policies for credentials and signatures documented. Rationale: procedural control.

Recommended Practices

• Use tamper-evident logging (hash chaining, sealed storage).
• Require step-up authentication for high-risk signatures or remote access.
• Implement per-event reason codes for critical record changes.
• Store signature meaning as a controlled vocabulary (e.g., APPROVE, REVIEW).
• Periodically review accounts/roles; disable dormant accounts automatically.

Patterns

Audit log with hash chaining:

// LOG-11: hash-chained audit entry; TEST-AUD-04 validates integrity
typedef struct {
    uint8_t prev_hash[32];
    uint8_t entry_hash[32];
    audit_event_t ev;
} audit_record_t;

Signature capture (conceptual):

// SIG-11: enforce re-auth + meaning capture
int sign_change(const user_t *u, const char *meaning, const char *record_id) {
    if (!reauthenticate(u)) return -1;            // MFA or password re-prompt
    audit_log("SIG_ATTEMPT", u->id, record_id);
    if (!is_allowed_meaning(meaning)) return -2;  // controlled vocab
    return persist_signature(u, meaning, record_id, timestamp_now());
}

Record integrity with checksum:

// REQ-11-INTEGRITY: checksum stored with record
uint32_t checksum_record(const void *buf, size_t len) {
    return crc32(buf, len);
}

Anti-Patterns (risks)

• Shared or generic accounts for approvals -> risk: noncompliant signatures.
• Editable audit logs or logs stored with app-level delete rights -> risk: tampering.
• No re-authentication for signatures -> risk: repudiation and misuse.
• Unsynchronized clocks -> risk: unreliable audit trails.
• Unvalidated tools generating submission records -> risk: invalid evidence.

Verification Checklist

• Unique user IDs; RBAC applied; no shared accounts.
• Authentication policy enforced (complexity/MFA as applicable); session timeout/lockout configured.
• Signature records include user, timestamp, meaning; re-authentication enforced.
• Audit trail implemented, immutable/tamper-evident; captures create/modify/delete.
• Record integrity controls (hash/checksum/versioning) in place; backups validated.
• System time synchronized and monitored.
• System validated for intended use with documented test evidence.
• Policies and training documented; access/role reviews performed.

Traceability

• Link ER/ES requirements (REQ-11-###) to design elements, code, and tests (TEST-11-###).
• Keep validation artifacts in configuration control; associate signatures with requirement/test IDs.
• Store audit log integrity verification results with release artifacts.

References

• 21 CFR Part 11 (notably §§11.10, 11.50, 11.200).
• FDA guidance on Part 11 scope and application (2003).
• NIST SP 800-63 (for authentication strength considerations; informative).

Changelog

• 1.0.0 (2026-01-04): Initial skill covering ER/ES access control, signatures, audit, integrity, and validation expectations.

Audit History

• 2026-01-04: Regulatory audit performed. Verified:
  • 21 CFR Part 11 section references (§§11.10, 11.50, 11.200) are accurate
  • FDA 2003 guidance "Part 11, Electronic Records; Electronic Signatures — Scope and Application" correctly referenced
  • Scope of Part 11 relative to predicate rules correctly explained
  • NIST SP 800-63 reference appropriate as informative guidance for authentication strength