If your software holds records that an FDA-regulated company relies on, someone in their quality team will eventually ask whether you are "Part 11 compliant." The question sounds binary. It isn't, and a good answer starts with knowing what the regulation says and what it leaves out.
21 CFR Part 11 is short. Most of the confusion comes not from its text but from how far it reaches, and from the FDA guidance that narrowed that reach in 2003.
This article covers what Part 11 is for, when it applies, how it is structured, and where responsibility sits between a regulated company and the vendors whose systems hold its records.
What Part 11 is for
Part 11 sets the conditions under which the FDA treats electronic records and electronic signatures as trustworthy, reliable, and generally equivalent to paper records and handwritten signatures. The FDA issued it as a final rule in 1997, and it took effect on August 20 of that year.
It does not create record-keeping obligations of its own. The duty to keep a batch record, a training record, or a complaint file comes from somewhere else. Part 11 governs how you keep those records, and sign them, when you do it electronically.
That framing matters. A team that reads Part 11 as a general security standard will try to apply it to every system it owns. A team that reads it as a rule about regulated records asks a better first question: which of our records are regulated, and where do they live?
Predicate rules decide whether it applies
The underlying requirements are called predicate rules. They are the record and signature requirements in the Federal Food, Drug, and Cosmetic Act, the Public Health Service Act, and the FDA's own regulations. Familiar examples include the drug manufacturing rules in 21 CFR Parts 210 and 211, the device quality system rules in Part 820, and the good laboratory practice rules in Part 58.
Section 11.1 says Part 11 applies to records in electronic form that are created, modified, maintained, archived, retrieved, or transmitted under any records requirement in FDA regulations. It also covers electronic records submitted to the FDA under those two Acts, even where no regulation names the record. It does not apply to paper records that are merely transmitted electronically.
The FDA's guidance for industry, "Part 11, Electronic Records; Electronic Signatures: Scope and Application" (2003), made a narrow reading explicit. It describes Part 11 as applying in four situations:
A predicate rule requires the record, and you keep it electronically in place of paper.
You keep the record on paper and electronically, but you rely on the electronic version to perform regulated activities.
You submit the record to the FDA in electronic form under a predicate rule.
An electronic signature is intended to be the equivalent of a handwritten signature, initials, or other signing a predicate rule requires.
The guidance also recommends that you decide, and document in advance, whether you rely on the paper or the electronic version of a record kept both ways. That decision is easy to make in a procedure. It is hard to reconstruct during an inspection.
How the rule is structured
Part 11 has three subparts, and most of the operational detail sits in two sections.
| Subpart | Sections | What it covers |
|---|---|---|
| A. General provisions | 11.1 to 11.3 | Scope, implementation, definitions |
| B. Electronic records | 11.10 to 11.70 | Controls for closed and open systems, signature manifestations, linking signatures to records |
| C. Electronic signatures | 11.100 to 11.300 | General requirements, signature components, controls for identification codes and passwords |
Section 11.10 lists the controls for closed systems in paragraphs (a) through (k). In plain terms they are:
(a) validation of the system
(b) the ability to produce accurate and complete copies, in human-readable and electronic form, for FDA inspection
(c) protection of records so they can be retrieved throughout the retention period
(d) limiting system access to authorized individuals
(e) secure, computer-generated, time-stamped audit trails
(f) operational system checks that enforce the permitted sequence of steps
(g) authority checks on who can sign, alter records, or perform an operation
(h) device checks on the validity of data input sources
(i) education, training, and experience for the people who build, maintain, and use the system
(j) written policies that hold individuals accountable for actions taken under their electronic signatures
(k) controls over system documentation, including revision and change control
Closed and open systems
Section 11.3 defines a closed system as one where access is controlled by the people responsible for the content of the records on it. In an open system, those people do not control access. Section 11.30 asks open systems for everything a closed system needs, plus additional measures such as document encryption and appropriate digital signature standards.
The classification belongs to the regulated company, which documents its reasoning. A vendor can describe how access works in its product. It cannot assign the label on its customer's behalf.
What the 2003 guidance changed
Before 2003, the agency's reading of Part 11 was broad, and industry found the requirements hard to apply to every computerized system. The scope guidance announced a narrow interpretation while the FDA re-examined the rule. It also said the FDA intended to exercise enforcement discretion in five areas:
validation, 11.10(a)
audit trails, 11.10(e)
legacy systems that were operational before August 20, 1997
copies of records, 11.10(b)
record retention, 11.10(c)
The discretion extends to the corresponding open-system requirements in 11.30. Two points get lost when people summarize this.
First, enforcement discretion is not an exemption. The guidance says you must still comply with the predicate rules, and it recommends a documented, risk-based approach to validation and audit trails. Several predicate rules expect the things an audit trail provides, such as attributable and dated changes, so the practical effect is often smaller than it sounds.
Second, the rest of Part 11 stays enforced. That includes access limits, operational, authority, and device checks, training, written accountability policies, documentation controls, and all of the signature requirements in 11.50, 11.70, and Subpart C.
Guidance documents describe the FDA's current thinking and are not binding in the way the regulation is. The FDA has issued further guidance on related topics since 2003, so check which documents are current for your product area.
Where responsibility sits
Part 11 obligations fall on the regulated company: the manufacturer, sponsor, laboratory, or other organization keeping records under FDA rules. The FDA does not certify software as Part 11 compliant. No vendor can make a customer compliant by selling it a product.
What a vendor can do is supply a system whose features let the customer meet the technical controls, plus evidence that the vendor builds and operates it under control. A regulated customer will usually look for:
Technical controls: unique user accounts, role-based authority checks, a computer-generated audit trail, and signatures that show the signer's name, the date and time, and the meaning of the signature.
Record access: accurate and complete copies in human-readable and electronic form, available for the full retention period.
Evidence of control: a documented development and change process, testing records, release notes, and advance notice of changes.
Cooperation: answers to supplier questionnaires, and support for a supplier audit if they request one.
The procedural controls stay with the customer. They decide who is trained, write the policy that holds people accountable for their signatures, send the FDA the certification that their electronic signatures are legally binding, and validate the system for their intended use.
What teams commonly get wrong
Treating "Part 11 compliant" as a product feature. A feature can support a control. Compliance depends on the customer's records, procedures, and validation, none of which the vendor controls.
Applying it to everything, or to nothing. Over-scoping drags systems that hold no regulated records into validation work. Under-scoping leaves a spreadsheet of batch data outside any control.
Confusing an application log with an audit trail. A debug log written for engineers is not a record of who changed a regulated value, from what, to what, and when.
Forgetting the retention period. Records must stay retrievable for as long as the predicate rule requires, which can outlast the vendor contract. Plan the export before you need it, as you would for audit evidence generally.
Assuming a security report answers the question. A SOC 2 report or ISO 27001 certificate helps a customer assess a supplier. Neither addresses signature manifestation or predicate-rule records. Expect Part 11 questions on top, and see what auditors actually ask for for how supplier evidence is read.
How TrustLynce helps
TrustLynce maps the Part 11 controls on our framework page alongside the other frameworks you run, so evidence for access limits and change control is collected once and reused (compliance automation). Evidence is gathered on a schedule from your cloud, identity, and code systems, with a timestamp and an attributed source, which gives your customers' supplier assessments something concrete to review.