21 CFR Part 11 was published in 1997 to let FDA-regulated companies keep records electronically and sign them electronically, provided the records were as trustworthy as paper. It is short — about four pages — and most of it is a list of controls. A pharmacy that moves its quality and batch records off paper meets Part 11 or it does not; there is no partial credit for a PDF with a typed name at the bottom. This explainer goes section by section, says when the rule applies to a 503A or 503B, and describes what a compliant system does at the moment someone clicks Release.
When Part 11 applies to a pharmacy
Part 11 applies to records that an FDA regulation requires you to keep (a "predicate rule") when you keep them electronically, and to electronic signatures on those records. For a 503B outsourcing facility the predicate rule is 21 CFR 211: master and batch production records, laboratory records, distribution records, complaint files and the rest. A 503B's electronic batch record is squarely within Part 11. For a 503A pharmacy the position is narrower: its record-keeping obligations come mostly from state boards and USP, which are not FDA predicate rules, so Part 11 does not strictly apply to most of its records. In practice, boards, PCAB and hospital customers increasingly expect Part 11-grade audit trails and signatures, and a 503A that runs a 503B-style quality system gets them from the same mechanisms. FDA's 2003 guidance also narrowed enforcement: the agency exercises discretion on validation, audit trails, record retention and copying for legacy systems, and expects a risk-based approach rather than every control applied to every record.
§11.10: controls for electronic records
Section 11.10 lists the controls a closed system — one where access is controlled by the people responsible for the records — must have. In plain terms:
- (a) Validation
- The system must be validated to show it does what it is supposed to do, accurately and consistently, and can detect invalid or altered records.
- (b) Copies
- You must be able to produce accurate and complete copies of records, human-readable and electronic, for FDA inspection.
- (c) Retention
- Records must be protected so they can be retrieved accurately throughout the retention period the predicate rule sets.
- (d) Access
- Access limited to authorised individuals.
- (e) Audit trail
- Secure, computer-generated, time-stamped audit trails that record the date and time of operator entries and actions that create, modify or delete records, without obscuring previous values, retained as long as the record.
- (f) Sequencing
- Where it matters, the system enforces the permitted sequence of steps and events.
- (g) Authority checks
- Only authorised individuals can use the system, sign, access the operation, or alter a record.
- (h) Device checks
- Where relevant, checks that data came from a valid source device or terminal.
- (i) Training
- People who develop, maintain or use the system have the education, training and experience to do so.
- (j) Accountability
- Written policies holding individuals accountable for actions under their electronic signatures.
- (k) Documentation controls
- Controlled distribution and revision of system documentation, with an audit trail of changes.
Open systems — where access is not controlled by the record owner — add §11.30's requirements for encryption and digital signatures. A hosted platform with authenticated access, where your organisation controls who has an account, is treated as a closed system for this purpose.
The audit trail, specifically
§11.10(e) is where most "electronic" pharmacy systems fail. The audit trail must be generated by the system, not by the user; time-stamped; must capture create, modify and delete; must not overwrite previous values; and must be as durable as the record. A spreadsheet with a "last edited by" column is not an audit trail, because the column can be edited. A document management system that lets an administrator delete history is not one either. The test is simple: can anyone, including an administrator, change a record without the change being visible afterwards? If yes, it is not Part 11-ready. In Pharmacy Flow every material action writes an event row with actor, timestamp and summary; every order and lot status change writes a history row; and the events, approvals, audit-log and comments tables have update and delete revoked from the application roles at the database level. An administrator in the application cannot remove an entry because the database will not let them.
§11.50 and §11.70: what a signature must show and link to
§11.50 requires that a signed electronic record show the printed name of the signer, the date and time of signing, and the meaning of the signature — review, approval, responsibility, authorship. §11.70 requires that the signature be linked to its record so it cannot be excised, copied or transferred to falsify another record. In Pharmacy Flow a signature is a row in the approvals table with the entity type and id it applies to, the signer's name and role, the timestamp, and a meaning from a fixed list: Reviewed, Approved, Released, Verified, Witnessed or Rejected. The row is append-only, and the event log records the signing as well. Batch release, prescription verification, formulation approval, and sign-off on deviations, CAPAs, change controls and controlled documents are all captured this way.
§11.100–§11.300: identity, components, passwords
§11.100 requires that each electronic signature be unique to one individual and never reused or reassigned, and that the organisation verify the person's identity before assigning one. §11.200 sets the form: a non-biometric signature uses at least two distinct identification components, such as an ID and a password; the first signing in a continuous session uses both, later signings in the same session use at least one; and signatures may only be used by their genuine owners. §11.300 requires controls over ID codes and passwords: uniqueness, periodic checking and revision, loss-management procedures, and safeguards against unauthorised use. Pharmacy Flow implements the signature ceremony as identity from the authenticated session plus a fresh password entered at the moment of signing — both components, every time. If re-authentication fails, no signature is applied and the action does not proceed. Accounts are individual; new accounts are created with a random one-time password.
One organisational duty is easy to miss: §11.100(c) requires the organisation to certify to FDA, in a letter to the Office of Regional Operations, that its electronic signatures are intended to be the legally binding equivalent of handwritten signatures, before or at the time it first uses them. That is your letter, not your vendor's.
Validation: whose job is which part
§11.10(a) validation is where responsibility divides. The vendor supplies the system, its documentation, its change history, and evidence that it was tested. You perform validation for your intended use: an installation qualification (the system is what the vendor says it is, configured as you require), an operational qualification (the functions you rely on work as specified — the release interlock refuses a lot with a failed test, the signature refuses a wrong password), and a performance qualification (it works in your process with your people). FDA's risk-based posture means you concentrate on the functions that affect product quality and record integrity. Pharmacy Flow provides the mechanisms and their test evidence; the validation package for your site is your quality unit's work, and we say "designed to support Part 11" rather than "Part 11 certified" because there is no such certificate.
Why a signed PDF on a shared drive fails
The most common way a pharmacy goes electronic is to turn paper forms into PDFs, type a name in the signature box, and save them to a shared folder. Against the sections above: there is no computer-generated audit trail (11.10(e)); the file can be edited and re-saved without trace; access is by folder permission rather than by individual authority for the action (11.10(g)); the signature has no second component and is not verified at the moment of signing (11.200); the signature can be copied between documents (11.70); and there is no enforced sequence — nothing stops the release form being signed before the test results exist (11.10(f)). It is paper with the physical safeguards removed. Electronic signing tools fix the signature and not the sequencing; a general document system fixes access and not the interlocks. A purpose-built quality system fixes all of them at once because the signature is part of the workflow rather than an attachment to it.
See a Part 11 signature refuse a wrong password
We will open a lot with a failed QC test, try to release it, watch the database refuse; pass the test, sign with a wrong password, watch it refuse again; then sign properly and show the append-only record.
What a compliant release looks like
- 1The record exists before the signature
The finished lot is in Quarantine with its QC tests recorded. Release cannot be signed on a lot with no tests or with any test not Pass — the database rejects the transition (11.10(f)).
- 2The signer is authorised
The release function checks that the caller holds the qa.release permission; Technician does not (11.10(g)).
- 3Two components at the moment of signing
The signer, already authenticated, re-enters their password. A wrong password applies no signature (11.200).
- 4The signature manifests and links
An approvals row is written with entity, signer, role, time and the meaning Released (11.50, 11.70).
- 5The audit trail records it
An event row records the signing; a lot history row records the status change with actor and time. Neither can be updated or deleted by application users (11.10(e)).
- 6It can be produced on demand
The lot's page shows tests, signature and history; lists export; the record is retrievable for the retention period (11.10(b),(c)).
Section-by-section map to Pharmacy Flow
| Part 11 section | Requirement | Mechanism in Pharmacy Flow |
|---|---|---|
| 11.10(a) | Validation | Vendor documentation, change history and test evidence to support your IQ/OQ/PQ |
| 11.10(b),(c) | Copies and retention | Record pages and list exports; hosted Postgres with retention under your policy |
| 11.10(d),(g) | Access and authority | Individual accounts; role permissions as database rows checked by status functions |
| 11.10(e) | Audit trail | Event log, order and lot status history; append-only events, approvals, audit log, comments |
| 11.10(f) | Sequencing | Transition tables with triggers; QC-gated release; pack-verify ship interlock; Rx must be Filled |
| 11.50 | Signature manifestation | Signer name, role, timestamp and fixed meaning on every approval |
| 11.70 | Signature/record linking | Approval rows reference entity type and id; append-only |
| 11.100 | Unique signatures, identity | One account per person; random one-time password on creation; your identity verification procedure |
| 11.200 | Two components | Session identity plus password re-entry at signing; failure applies no signature |
| 11.300 | Password controls | Individual credentials; your password policy and loss-management procedure |
Part 11 is one of several record standards a compounding operation lives under. See 503A vs 503B for which predicate rules apply to you, the USP <800> checklist and sterile compounding for the USP record sets, serialization and DSCSA for distribution records, the 503B software page for the batch record, and the 503B launch playbook for the whole document set. The platform overview and resources index cover the rest.
Frequently asked questions
Does Part 11 apply to compounding pharmacies?+
It applies to electronic records and signatures kept to satisfy FDA regulations. For a 503B outsourcing facility under 21 CFR 211, yes, squarely. For a 503A pharmacy, most record obligations come from state boards and USP rather than FDA predicate rules, so Part 11 does not strictly apply to most of its records — but boards, accreditors and customers increasingly expect the same controls, and a 503A running a Part 11-grade system loses nothing.
Is a PDF of a signed form Part 11 compliant?+
Generally no. It lacks a computer-generated audit trail, can be edited without trace, has no two-component signature verified at signing, the signature can be copied to another document, and nothing enforces that the record existed before it was signed.
What does 'two distinct identification components' mean in practice?+
For a non-biometric signature, something like a user identity plus a password, both used at the first signing in a session and at least one at later signings. Pharmacy Flow requires both — session identity plus password re-entry — at every signing.
Can a vendor be 'Part 11 certified'?+
No. There is no FDA certification for software. A vendor can design to the rule and supply evidence; compliance is a property of your validated system, procedures and training as a whole.
Does Part 11 require audit trails on every record?+
§11.10(e) requires them for records subject to the rule. FDA's 2003 guidance says the agency takes a risk-based view and concentrates on records where the audit trail matters to trustworthiness — batch, release and quality records in a 503B certainly qualify.
Who validates the system?+
You do, for your intended use, with the vendor's documentation and test evidence. Installation, operational and performance qualification are performed by your quality unit or a validation partner against your procedures.
Do we have to tell FDA we use electronic signatures?+
Yes. §11.100(c) requires an organisation to certify to FDA in writing that its electronic signatures are intended as the legally binding equivalent of handwritten signatures, at or before first use.