Introduction

21 CFR Part 11 establishes the U.S. FDA’s requirements for the trustworthiness and reliability of electronic records and electronic signatures used to meet predicate rule obligations in FDA‑regulated industries. The FDA’s Scope and Application guidance clarifies that Part 11 applies when records are maintained or submitted electronically in fulfillment of FDA requirements, and it emphasizes a risk‑based approach to enforcement and validation.

What Part 11 requires (by control area)

• System validation: validate to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.

• Record copies and retention: be able to produce accurate and complete copies in human‑readable and electronic forms; protect records for the full retention period.

• Access controls and authority checks: limit system access to authorized individuals; enforce permitted sequencing of steps/events; ensure only authorized individuals can sign or alter records.

• Device checks and training: verify the validity of data sources; ensure personnel who develop, maintain, or use systems are trained and qualified.

• Audit trails: use secure, computer‑generated, time‑stamped audit trails to independently record who did what and when for record create/modify/delete events; changes must not obscure prior entries; retain audit trails for at least as long as the underlying records.

• Documentation control: maintain distribution/access controls and change control (including an audit trail) for system documentation. These controls are specified in 21 CFR 11.10 (closed systems) and 11.30 (open systems add encryption/digital signatures), with signature display and linking rules in 11.50 and 11.70.

Electronic signatures: manifestation and control

• Signature manifestation (11.50): every signed electronic record must clearly show the signer’s printed name, the date/time of signing, and the meaning of the signature (e.g., review, approval). These items must appear in any human‑readable view or printout of the record.

• Signature/record linking (11.70): signatures (electronic or handwritten to electronic records) must be bound to the record so they cannot be excised, copied, or transferred to falsify another record by ordinary means.

• General requirements (11.100): each e‑signature must be unique to one person; identity must be verified before assignment; firms must certify to FDA that e‑signatures are legally binding equivalents of handwritten signatures (via a Non‑Repudiation Agreement).

• Components and controls (11.200): non‑biometric e‑signatures must employ at least two distinct components (e.g., ID and password) with rules for continuous sessions vs. new sessions; signatures must be used only by their genuine owners and require collaboration for misuse; biometric signatures must prevent use by anyone other than the genuine owner.

• Identification codes/passwords (11.300): require uniqueness, periodic checks/aging, loss management, transaction safeguards, and device testing for tokens/cards that generate codes.

Audit trails: designing immutable, reconstructable histories

Audit trails must be computer‑generated and time‑stamped; they must independently record the date/time of operator entries and actions that create, modify, or delete electronic records; and they must preserve prior information (no obscuration). Audit trails must be retained for at least the same period as the records and be available for FDA inspection/review/copying. Practically, this implies append‑only storage semantics, comprehensive event coverage (create/edit/delete; sign/apply/withdraw signature; status changes; configuration changes affecting records), trusted time sources, and role‑based access that separates record modification from audit‑trail administration.

Validation pack for Part 11 systems (URS/IQ/OQ/PQ)

Regulators expect documentation that establishes fitness for intended use through a life‑cycle approach. A pragmatic “validation pack” typically includes:

Artifact	Purpose	Notes
URS (User Requirements Specification)	Defines intended use, regulated records, signature workflows, audit‑trail scope, risk ranking, and data integrity expectations.	Trace to design, tests, and SOPs.
Design/configuration specs	Map URS to system functions, configurations, access model, and integrations.	Include signature meaning fields and record‑linking design.
Risk assessment	Determines testing rigor and coverage based on impact to product quality/patient safety/data integrity.	Aligns with risk‑based regulatory guidance.
IQ (Installation Qualification)	Verifies installation in the target environment (versions, dependencies, security baselines, time sync).	Include environment and change control.
OQ (Operational Qualification)	Verifies functional controls: access, authority checks, e‑signature components, audit trails, copies, retention.	Negative testing for unauthorized actions.
PQ (Performance Qualification)	Demonstrates fitness in intended business process with trained users and SOPs.	Includes end‑to‑end workflows and e‑record lifecycle.
Traceability matrix	Proves end‑to‑end coverage from URS → test evidence.	Maintain under change control.
Procedures & training	SOPs for account management, signature use, audit‑trail review, backup/restore, change control.	Train and qualify users/admins.

Foundational references include FDA’s General Principles of Software Validation and FDA’s Process Validation guidance; ISPE’s GAMP 5 (2nd ed.) reinforces risk‑based CSV practices across modern, cloud/SaaS environments. The FDA’s Computer Software Assurance (CSA) guidance, finalized on September 24, 2025, further emphasizes risk‑based, critical‑thinking approaches and supersedes Section 6 of the 2002 Software Validation guidance.

QMS handoffs (Veeva, Master

Control, ETQ): integration patterns Part 11 compliance often spans multiple systems. When Parakeet orchestrates risk/compliance workflows that produce regulated evidence and signatures, handoffs to enterprise QMS are accomplished via standard, validated interfaces:

• Veeva Vault: REST and high‑speed Direct Data API enable system‑to‑system data exchange and replication into analytics platforms with referential integrity. Use field mappings that carry signature manifestation (name, date/time, meaning) and signature/record linking metadata.

• MasterControl: vendor‑supported web services/API toolkit supports loosely coupled integrations for exchanging documents, metadata, and status. Configure receiving objects to preserve audit‑trail continuity and retain signature meaning fields.

• ETQ Reliance: platform supports RESTful APIs and integration options; design payloads to maintain immutable linkage between the originating Parakeet record and the QMS record, including IDs, timestamps, and signer roles. Integration design should specify: data ownership, identifiers, time sources, retry/dupe handling, attachment formats (e.g., PDF “true copy” with visible signature manifestation), and responsibilities for audit‑trail retention across systems. Validate the interfaces (OQ/PQ) and document SOPs for change control and incident response.

How Parakeet Risk supports Part 11 programs

• Electronic records and auditability: Parakeet provides audit‑trail and documentation capabilities used to support regulatory audits in industrial environments (e.g., packaging), and its pharmaceutical solution set is positioned to help maintain data integrity and audit trails aligned to 21 CFR Part 11 expectations.

• Research, evidence, and automation: Rosella AI streamlines regulatory research, evidence generation, and audit preparation, reducing manual overhead while maintaining centralized, auditable records.

• Workflow connectivity: Prebuilt integrations (e.g., Trello for remediation tasks, Slack for alerts, Google Docs for document generation) enable controlled handoffs and “true copy” report packaging as part of validated processes. These must be configured and validated by the customer to meet Part 11 in their environment. Note: As with any vendor platform, customers are responsible for defining intended use, configuring controls, performing CSV/CSA activities, operating under SOPs, and maintaining letters of non‑repudiation for FDA‑bound e‑signatures where applicable.

Implementation checklist (practical)

• Determine scope: identify predicate‑rule records that will be electronic; classify open vs. closed system use and required controls.

• Author URS: define record types, signature meanings/states, retention, audit‑trail events, reportability, and QMS handoffs.

• Establish identity and e‑signature program: unique accounts, two‑factor e‑signature components, password/code controls, and certification letters to FDA.

• Validate the system and integrations: execute IQ/OQ/PQ with risk‑based depth (CSV/CSA), including negative testing of signature misuse, audit‑trail immutability, and copy/retention.

• Operate under SOPs: govern account lifecycle, signature use, audit‑trail review cadence, backup/restore, change control, and incident/CAPA.

• Maintain inspection readiness: demonstrate accurate/complete copies, visible signature manifestation, and signature/record linking; ensure audit‑trails are retained and accessible for FDA review.

FAQs

• Does Part 11 require “digital certificates” for all signatures? No. Part 11 permits multiple e‑signature types. For submissions via the FDA Electronic Submissions Gateway, firms must provide a Letter of Non‑Repudiation Agreement and meet PKI certificate requirements specific to the ESG program.

• What counts as an acceptable audit trail? A computer‑generated, time‑stamped, append‑only record of create/modify/delete/signing actions that does not obscure prior data and is retained at least as long as the record, available for inspection.

• Is CSV still required if CSA is final? Yes—CSA refines FDA’s risk‑based expectations for production/quality system software and supersedes part of the 2002 Software Validation guidance; the need to establish confidence/validation based on risk remains.

References

Primary law/regulation and guidance: 21 CFR Part 11 text (sections 11.10, 11.30, 11.50, 11.70, 11.100, 11.200, 11.300); FDA Part 11 Scope & Application (2003); FDA Data Integrity Q&A (2018); FDA General Principles of Software Validation (2002); FDA Process Validation (2011); FDA Computer Software Assurance (2025 final). Vendor QMS integration capabilities: Veeva (Vault APIs and Direct Data API), MasterControl (API toolkit), ETQ Reliance (RESTful APIs). Parakeet capabilities and integrations referenced from public product pages above.