21 CFR Part 11

21 CFR Part 11 is the section of the United States Code of Federal Regulations that lets a regulated manufacturer use electronic records and electronic signatures in place of paper and handwritten ink — provided the underlying system enforces specific controls. It was issued by the U.S. Food and Drug Administration in March 1997 and became effective on 20 August 1997. The rule has not been amended since, but the FDA's interpretation of it has, most importantly through the 2003 Guidance for Industry on Scope and Application.

Part 11 does not invent any new manufacturing obligation. It does not tell you what to make, how to make it, or what data to capture. Everything Part 11 controls is downstream of another predicate rule — 21 CFR 210/211 for finished pharmaceuticals, 21 CFR 111 for dietary supplements, 21 CFR 820 for medical devices, 21 CFR 117 for human food, 21 CFR 507 for animal food, and so on. Part 11 simply answers a different question: 'You already have to keep this record. Can you keep it on a computer?' The answer is yes, but only if the computer treats the record with the same trustworthiness the regulator would expect of a paper one.

That trustworthiness is operationalised in two halves. Subpart B (sections 11.10 through 11.70) governs electronic records — controls, audit trail, system documentation, validation, copies for inspection, and record retention. Subpart C (sections 11.100 through 11.300) governs electronic signatures — non-repudiation, two distinct identification components, binding the signature to its record, and how the system manages user IDs, passwords, and biometric devices. Subpart A defines what the rule applies to and a handful of terms that have specific Part 11 meaning, such as 'closed system' and 'biometric.'

Before Part 11, every FDA-regulated industry had a predicate rule that effectively assumed paper. CGMP records were signed by hand. Batch records were stored in binders. Production-floor entries were made in pen, with errors crossed out in a single line, initialled and dated. That model is unambiguous in court. It also makes data integrity easy to police: an inspector can see whether something was overwritten, post-dated, or torn out.

In the early 1990s industry began pressuring the FDA to recognise electronic systems. Distillation control systems, laboratory instruments, ERPs and shop-floor execution systems were already generating records that had no paper original. Operators were re-keying instrument readouts into paper batch records just so they could be signed; data was being lost in the copy step. Pharmacopoeia chromatography systems were producing terabytes of audit-trail data that nobody could replicate on paper. Part 11 was the FDA's structured 'yes' — yes you can use electronic records, here are the controls you must put in place so that the record is at least as trustworthy as the paper it replaces.

The original rule was deliberately broad. By 2003, however, the agency had observed that industry was interpreting Part 11 so widely that companies were validating spreadsheets used for travel expenses. The 2003 Scope and Application guidance tightened the lens: Part 11 applies to records the predicate rule already requires you to keep, and to signatures the predicate rule already requires you to capture. Records you keep voluntarily — internal KPIs, sales dashboards, an engineer's lab notebook used purely for R&D — are out of scope, even if you choose to store them electronically. The agency also committed to a risk-based approach to enforcement of legacy systems.

What did not change in 2003 is the core expectation. If a record is in scope, the FDA expects you to be able to demonstrate three things for it at any moment: who created or changed it, what they changed it from and to, and why. Everything else in Part 11 is a means to that end.

Section 11.3(b)(6) defines an electronic record as 'any combination of text, graphics, data, audio, pictorial or other information representation in digital form that is created, modified, maintained, archived, retrieved, or distributed by a computer system.' That is broad. The narrowing happens in 11.1(b): the rule applies to records 'required by the agency's regulations.' Read together, the test for whether something is a Part 11 record is two-stepped.

1. Does any predicate rule require you to keep this record? Examples: a Batch Production Record under 211.188, a Device History Record under 820.184, a Master Manufacturing Record under 111.205, a HACCP monitoring record under 117.135.
2. Is the record kept, used or relied on in electronic form? It is enough that the record exists electronically at any point in its life — including during creation. Printing it later does not make the electronic version disappear.

Records you generate voluntarily are not in scope, but the moment you start using an electronic record to satisfy a predicate-rule obligation it becomes a Part 11 record — even if the same data also lives on paper. Most regulators take a 'predominant copy' view: whichever version you actually use to make release decisions, train operators, or close batches is the one Part 11 applies to. Signatures follow the same pattern. If a predicate rule requires a signature — preparer and reviewer on a master record, person responsible for release, lab analyst on a test result — then the electronic version of that signature is in scope for Subpart C.

Section 11.10 is the workhorse of the whole rule. It lists the controls a 'closed system' must enforce to ensure the authenticity, integrity and, when appropriate, the confidentiality of electronic records. Memorise this list — every Part 11 audit you ever face will work its way through some version of it.

Validation (11.10(a))

The system must be validated to ensure accuracy, reliability, consistent intended performance and the ability to discern invalid or altered records. In practice this means a documented computer-system-validation lifecycle covering user requirements, functional and design specifications, installation and operational qualification, performance qualification, and traceable test evidence. The depth of validation is risk-based; GAMP 5 is the industry-standard framework for deciding how much rigour each component needs.

Accurate and complete copies (11.10(b))

The system must be able to generate accurate and complete copies of records in both human-readable and electronic form, suitable for inspection, review and copying by the agency. A paginated PDF of a batch record satisfies the human-readable half. The electronic half is the trickier one: inspectors increasingly ask for the underlying data export (CSV, XML, or a structured database extract) so they can independently re-run audit-trail queries.

Record retention and protection (11.10(c))

Records must be readable and retrievable for the full retention period defined by the predicate rule — typically the life of the product plus one year for finished pharmaceuticals, longer for medical devices. The system must protect records from intentional or accidental alteration during that period. Migrations between database versions, file formats, or media must preserve the meaning and audit trail of the original.

Access control (11.10(d), 11.10(g))

System access must be limited to authorised individuals. Authority checks must ensure that only authorised individuals can use the system, electronically sign a record, access the operation or device, alter a record, or perform the operation at hand. This is more than role-based access control — the system must enforce a check at the point of action, not just at login.

The audit trail (11.10(e))

Use of 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. Record changes must not obscure previously recorded information. Audit trail documentation must be retained for at least as long as that required for the subject record, and be available for agency review and copying. Section 11.10(e) is the most-cited Part 11 finding on FDA Form 483s.

Operational, device and authority checks (11.10(f), 11.10(g), 11.10(h))

Operational system checks enforce the permitted sequencing of steps and events — you cannot, for example, dispense a raw material before the batch has been released to the floor. Device checks confirm the validity of the source of data input or operational instruction — for example, that the scale reading really came from the certified weighing terminal. Authority checks are covered above.

Education, training and accountability (11.10(i), 11.10(j))

People who develop, maintain or use electronic record systems must have the education, training and experience to perform their tasks. There must be a written policy holding individuals accountable and responsible for actions initiated under their electronic signatures, to deter record and signature falsification.

Controls over systems documentation (11.10(k))

Adequate controls over the distribution of, access to, and use of documentation for system operation and maintenance, plus revision and change control procedures to maintain an audit trail of documentation modifications.

An electronic signature, per section 11.3(b)(7), is 'a computer data compilation of any symbol or series of symbols executed, adopted or authorised by an individual to be the legally binding equivalent of the individual's handwritten signature.' Subpart C defines what that compilation must look like to be acceptable.

Two distinct identification components (11.200(a)(1))

Non-biometric signatures must employ at least two distinct identification components — typically a user ID and a password. When an individual executes a series of signings during a single continuous period of controlled system access, the first signing requires both components and subsequent signings need supply at least one. When the signings are not performed during a single continuous period, each signing requires both components.

Manifest of signature (11.50)

Signed electronic records must contain information associated with the signing that clearly indicates the printed name of the signer, the date and time when the signature was executed, and the meaning (such as review, approval, responsibility or authorship) associated with the signature. This information must be subject to the same controls as for electronic records and must be included as part of any human-readable form of the electronic record.

Linking signatures to records (11.70)

Electronic signatures and handwritten signatures executed to electronic records must be linked to their respective electronic records to ensure the signatures cannot be excised, copied, or otherwise transferred to falsify an electronic record by ordinary means. In practice this means a cryptographic or database-level binding — not just a user ID printed at the bottom of a PDF.

User ID and password controls (11.300)

Each combination of identification code and password must be unique to one individual. Periodic checks, recalls or revisions of identification codes and passwords. Loss-management procedures so that potentially compromised tokens, cards or other devices are de-authorised. Transaction safeguards to prevent unauthorised use of passwords or identification codes, including the detection and reporting of any attempts at their unauthorised use to system security and management.

The certification letter (11.100(c))

Before, or at the time of, electronic signature use, each organisation must certify to the FDA in writing, in paper form with a handwritten signature, that the electronic signatures used in its system on or after 20 August 1997 are intended to be the legally binding equivalent of traditional handwritten signatures. The certification is sent to the FDA's Office of Regional Operations. It is a one-time letter that covers all signers in the organisation, and it is the single Part 11 obligation that companies most often forget exists.

Section 11.10(e) is two sentences long, but every word matters. The audit trail must be secure: an end user, an administrator, or a database query must not be able to alter or delete an entry. It must be computer-generated: a free-text 'reason for change' field is fine, but the entry itself must be created by the system, not typed by a person. It must be time-stamped, and the timestamp must come from a controlled, synchronised clock that the user cannot influence — wall-clock spoofing is one of the easiest ways to forge an audit trail.

What must be captured? The 2018 FDA Data Integrity guidance is now the operational reference. For every create, modify, or delete event on a regulated record, the audit trail must record at minimum the actor, the timestamp, the action type, the data element affected, the previous value, the new value, and (for changes after initial entry) the reason. Many regulators now expect the IP address or workstation identifier as well, and require the reason field to be free-text rather than a drop-down menu, on the basis that drop-downs encourage 'tick-box' falsification.

The audit trail must be reviewable. The FDA's expectation is no longer that the audit trail merely exists for an inspector to subpoena; it must be reviewed by the quality unit as part of routine batch release. Section 211.180(d) plus the 2018 guidance combine to require that audit trails for CGMP-relevant computerised systems be reviewed before release of the batch, lot or unit. A useful test: if a deviation occurred during a batch, can your quality reviewer find every action that touched that deviation without exporting a separate report? If not, the audit-trail review will fail.

Computer System Validation (CSV) is the umbrella discipline Part 11 implicitly requires. The international industry standard for CSV is ISPE GAMP 5 ('Good Automated Manufacturing Practice'), updated in 2022 to incorporate CSA (Computer Software Assurance), modern release practices, agile development, and cloud platforms. GAMP 5 is not a regulation, but every major regulator (FDA, EMA, MHRA, PMDA, Health Canada, ANVISA, TGA) recognises it as best practice.

GAMP 5 sorts software into five categories and prescribes the validation depth for each. Category 1 (infrastructure software like operating systems) needs only qualification of the underlying platform. Category 5 (custom-developed applications) needs the full lifecycle. Most modern SaaS shop-floor systems are predominantly Category 4 (configured products) with some Category 5 components — meaning the supplier provides the validated baseline and the customer validates only the configuration choices that affect GxP records.

ALCOA and ALCOA+

Data integrity is the umbrella term for whether a record can be trusted. The acronyms used by every regulator are ALCOA (Attributable, Legible, Contemporaneous, Original, Accurate) and its 2010-era extension ALCOA+ (adds Complete, Consistent, Enduring, Available). A Part 11 system that does not produce ALCOA+ records will fail an inspection regardless of how many of the Subpart B controls are technically present.

Section 11.3(b)(4) defines a closed system as 'an environment in which system access is controlled by persons who are responsible for the content of electronic records that are on the system.' An open system (11.3(b)(9)) is one in which system access is controlled by persons other than those responsible for the content. Section 11.30 adds extra encryption and digital-signature requirements for open systems.

In 1997 this distinction mattered — many companies were exchanging GxP data via FTP, modems, or unencrypted SMTP. In 2026 it is almost an anachronism. Modern SaaS platforms are universally treated as closed systems even though the infrastructure is provided by a third party (AWS, Azure, GCP, Cloudflare), because the responsibility for record content lies with the regulated organisation and access control is enforced at the application layer. What auditors actually look at is whether your access-control model, encryption-in-transit, encryption-at-rest, and supplier-qualification of the cloud provider satisfy the spirit of 11.30 — not whether you've ticked 'open' or 'closed' in a checklist.

An FDA Form 483 is the inspector's list of observations at the close of an inspection. Part 11 observations have been near the top of the agency's annual citation list every year for the past decade. The patterns are remarkably consistent.

• Shared user accounts on lab instruments, production HMIs, or weighing terminals — typically violating both 11.10(d) and 11.200(a)(1).
• Audit trails disabled in the application settings, or audit-trail review never performed before batch release.
• 'Reason for change' fields populated from a drop-down with options like 'data entry error' that obscure the actual root cause.
• System clocks not synchronised to a controlled NTP source, allowing timestamps to drift or be manipulated.
• Validation packs that exist for the initial install but were never updated through subsequent upgrades, patches or configuration changes.
• Hybrid records where a critical signature lives on paper attached to the batch and the link to the electronic record relies on a binder reference number.
• Backups that are demonstrably tested for restore, but the restored audit trail differs from the live one — a classic data-integrity finding.
• The 11.100(c) certification letter to the FDA never sent, or sent decades ago against a system that has since been replaced.

V5 Ultimate is built Part 11-native. The controls are not configuration options — they are properties of the database, the API and the rendering layer. The implications:

• Every regulated row in the database is append-only at the storage layer. There is no 'delete' verb available to the application or to a database administrator without going through a documented data-deletion procedure that itself writes an audit-trail entry.
• Every approving action triggers a re-authentication challenge, a controlled-vocabulary 'meaning' selector, and a free-text reason. The result is an immutable signature manifest stored on the same row.
• Master records — formulas, MMRs, device master records, work instructions, specifications — are versioned. Approving an edit creates a new version with two distinct e-signatures (preparer and independent reviewer) and supersedes the prior one without overwriting it.
• When a work order is released, V5 snapshots the current approved master into the work-order itself, so every action by the operator writes against a frozen copy. The batch record (BMR/eBMR, DHR/eDHR) is an accurate reproduction of the master as required by 211.188 and 820.184.
• The audit trail is surfaced in the quality-review queue, not buried in a SQL export. A reviewer can filter by user, action, time range, or specific data element and approve or reject the batch on the same screen.
• PDFs of regulated records are rendered server-side from the immutable snapshot, with the signature manifest embedded and a cryptographic hash printed in the footer.
• Validation evidence — URS, FS, DS, IQ/OQ/PQ scripts, traceability matrices, regression results — ships as part of the V5 release package and is updated automatically with every version.

Use this list when evaluating any system — V5 or anyone else's — against Part 11. Each item maps to a specific Subpart B/C section.

1. Validation pack covers URS through PQ with documented traceability (11.10(a)).
2. PDF and machine-readable export of every regulated record on demand, including the audit trail (11.10(b)).
3. Records retained for the predicate-rule retention period with verified restore from backup (11.10(c)).
4. Role-based access control plus an authority check at the point of every approving action (11.10(d), 11.10(g)).
5. Computer-generated, append-only, secure, time-stamped audit trail with a documented review process before batch release (11.10(e), 211.180(d)).
6. Operational sequencing enforced server-side — no out-of-order step submission possible (11.10(f)).
7. Device checks where applicable — scales, balances, instruments authenticated as the data source (11.10(h)).
8. Training records linking each system user to current SOPs and to the Part 11 accountability policy (11.10(i), 11.10(j)).
9. Change-control on the system itself, including configuration items, with a current configuration baseline (11.10(k)).
10. Two-component electronic signature with re-authentication, captured meaning, and tamper-evident binding to the signed record (11.50, 11.70, 11.200, 11.300).
11. 11.100(c) certification letter on file with the FDA Office of Regional Operations.

Most regulated manufacturers operate in more than one jurisdiction. Part 11 is the FDA's rule, but the European Medicines Agency's EU GMP Annex 11 (Computerised Systems), Japan's PMDA expectations, Brazil's ANVISA RDC 658/2022, the UK MHRA's GxP data integrity guidance, and Health Canada's GMP Annex 6 all cover the same ground. A system designed properly for Part 11 will, with very minor additions, satisfy all of them — the regulators have spent the last decade actively harmonising. The most common deltas are Annex 11's explicit requirement for a risk assessment up front (11.1) and its slightly stricter wording on supplier audits (11.3).

MoCRA (cosmetics, US), FSMA 204 (food traceability, US), DSCSA (drug supply chain, US), UDI (medical-device identification, US/EU) and the EU Medical Device Regulation 2017/745 all create new electronic records that fall under Part 11 the moment they are stored on a computer. None of them rewrite Part 11; they create new predicate-rule obligations whose electronic records the rule then applies to.