Part 11 reaches fewer records than most teams assume, and holds them to a higher standard
21 CFR Part 11 applies to records in electronic form that are created, modified, maintained, archived, retrieved or transmitted under any records requirement set out in agency regulations, and to electronic signatures executed on those records (§11.1). Two consequences follow from reading the scope clause closely. The rule does not reach every file in a quality system; it reaches the records a predicate rule already requires, together with records submitted to the agency. For those records it is exacting: the electronic version must be as trustworthy and reliable as the paper it replaces, and §11.10 lists the procedures and controls that make it so.
The order of the questions matters. "Is this system Part 11 compliant?" is not a question the rule answers. The questions it does answer are: which records in this system does a predicate rule require, and can each of them carry the same weight as paper? An inspection tests the second question on a record the investigator selects, not one the site has rehearsed. 21 CFR Part 11 is therefore best read as a records rule, not a software standard. This post sets out what the rule says and does not say, what the 2003 guidance narrowed, the five control points tested in practice, the signature provisions most teams skim, and how validation expectations stand in 2026.
What Part 11 says, and what it does not
Part 11 has been in force since August 1997. It is short, and most of what people attribute to it isn't in it.
- Scope, §11.1. It applies to records in electronic form that are created, modified, maintained, archived, retrieved or transmitted under any records requirement in FDA regulations, and to electronic records submitted to FDA. It also covers electronic signatures on those records.
- The key phrase is "under any records requirement". Part 11 doesn't tell you which records to keep. Your predicate rule does that: Part 211 for finished pharmaceuticals, Part 820 (now the QMSR, which incorporates ISO 13485) for devices, Part 606 for blood, and so on. Part 11 says: if that record is electronic, here is what makes it trustworthy.
- It doesn't mandate a technology. No clause says "buy an eQMS", "use a database" or "disable spreadsheets". It describes properties of a record and a signature. How you get there is yours to justify.
- Equivalence, §11.2. Meet the requirements and the electronic record or signature is considered equivalent to paper and handwritten. Fall short and, legally, you may not have the record the predicate rule requires at all.
That last point is why Part 11 findings rarely arrive as "Part 11" citations. They arrive as a §211.68 or §211.192 observation: the predicate-rule record was inadequate because the electronic controls behind it were.
The 2003 guidance that narrowed the rule
If you've heard that FDA "relaxed" Part 11, this is what happened. In 2003 FDA issued Part 11, Electronic Records; Electronic Signatures — Scope and Application, and it is still current thinking in 2026. It did three things:
- Narrow interpretation of scope. Part 11 applies to records required by predicate rules, records you choose to rely on to perform regulated activities, and records submitted to FDA. Incidental electronic files are out.
- Enforcement discretion on four specific requirements: validation (§11.10(a)), audit trails (§11.10(e)), record retention, and copies of records. FDA said it does not intend to take enforcement action on those Part 11 requirements as such.
- Legacy systems operational before 20 August 1997 get discretion too, provided they meet the predicate rule and the firm has documented justification.
Here's the part teams skip. The discretion is on the Part 11 clause, not on the underlying expectation. The guidance says plainly that you must still comply with predicate-rule requirements and that your decisions about validation and audit trails should be based on a justified, documented risk assessment. For a GMP batch record, §211.68(b) already requires controls so that changes are made only by authorised personnel, and §211.180 already requires the record to be retained and readily available. The discretion buys you almost nothing there. Where it genuinely helps is in low-risk records the predicate rule barely mentions.
The practical reading: decide by predicate rule and risk, document the decision, and expect the audit-trail and validation questions anyway for anything that touches product quality.
Your predicate rule decides which records count
Before any control discussion, make the list. For a finished-pharmaceutical site the map looks like this:
| Quality record | Predicate-rule basis (Part 211) | Typically electronic today? |
|---|---|---|
| Deviation and investigation records | §211.192 — investigation of discrepancies, written record of conclusions and follow-up | Yes: tracker, eQMS or spreadsheet |
| CAPA records | §211.192 (follow-up) and §211.100 (procedures and deviations from them) | Yes |
| Batch production and control records | §211.188 — including signatures of persons performing and checking each step | Increasingly (MES/EBR) |
| Laboratory records | §211.194 — complete data from all tests, including raw data and calculations | Yes (LIMS, CDS) |
| Change records to master records | §211.68(b) — changes to master production and control records only by authorised personnel | Yes |
| SOPs and their approvals | §211.100(a) — written procedures, drafted, reviewed and approved by the quality unit | Yes (document control) |
| Training records | §211.25 — training, and records of it, in the operations employees perform | Yes (LMS, spreadsheet) |
| Record retention | §211.180 — retention periods, records readily available for inspection | Applies to all of the above |
Everything on that list, if held electronically, is a Part 11 record. Everything on it also has a clause that inspectors can cite without ever mentioning Part 11.
The five control points, mapped to the clauses
Part 11 reduces to five properties of a trustworthy record. Each one lives in a specific clause, and each one has a question an inspector can ask in under a minute.
| Control point | Where it lives | What it proves | The one-minute question |
|---|---|---|---|
| Validation | §11.10(a) | The system does what it's meant to, consistently, and can detect invalid or altered records | "Show me the evidence this system is fit for this use." |
| Audit trail | §11.10(e) | Changes are captured with who, when and what, without obscuring the earlier entry | "Show me every change to this record." |
| Access and authority | §11.10(d), (g) | Only authorised people can use the system, and only for the actions their role allows | "Who could have edited this, and how do you know?" |
| Copies and retention | §11.10(b), (c) | The record can be produced accurately and completely, in human-readable and electronic form, for its retention period | "Give me a copy I can read." |
| Electronic signatures | §11.50, §11.70, §11.100–§11.300 | The signature is a real person's, shows what was meant, and stays with the record | "Who approved this, when, and what did approving mean?" |
There are more sub-clauses (§11.10 runs (a) through (k), including training and documentation controls for the system itself), but a team that can answer those five questions for its critical records is most of the way there.
Where the evidence is usually thin
These are the patterns that show up again and again on 483s and warning letters. None of them involve bad intent. All of them involve mistaking a feature for a control.
- A password is treated as compliance. A password addresses one line of §11.10(d). It says nothing about the audit trail, signature manifestation or the fact that the file can be copied and edited elsewhere.
- A timestamp is treated as an audit trail. "Last modified 14:32" tells you when. §11.10(e) wants who, what, when, and the previous value preserved. A file-system timestamp fails on three of four.
- Shared logins. One "QA_lab" account used by six people. FDA's Data Integrity Q&A is explicit: the system must be able to attribute actions to individuals. Shared credentials break attributability for every record that account touched.
- The audit trail is on and no one has ever read it. The same guidance expects audit trails that capture changes to critical data to be reviewed with the record, by the people who review the record. An unreviewed trail is a log, not a control.
- "Validated" spreadsheets. Cell protection is not validation, and a change to a formula is a change to a validated system that nobody raised under change control. The failure modes are well worn; why spreadsheets fail in regulated quality systems walks through them.
- A typed name is treated as an electronic signature. Under §11.200 a non-biometric signature needs at least two distinct components, and the first signing in a session must use both. A name typed into a cell is neither.
- Backups mistaken for retention. §11.10(c) is about protecting records so they can be accurately and readily retrieved for the retention period. A backup you can't restore to a readable form, or one that loses the audit trail, doesn't satisfy it.
The records an inspection requests first
Forget the compliance statement. Investigators verify Part 11 the way they verify everything else: pick a record, walk the chain.
A typical sequence on a deviation:
- The record itself, opened live, not a printout prepared for the audit.
- Who created it and who approved it, with the approval visible on the record, not inferred from an email.
- The audit trail for that record, read on screen. Was anything changed after approval? Was the original value preserved? Who changed it and why?
- Evidence the audit trail was reviewed, and by whom, before the record was closed or the batch released.
- The user list: are these individual accounts, are they current, and who has administrator rights?
- A copy, produced on request, complete and readable.
Then they widen out. §211.68(b) requires appropriate controls over computer or related systems to assure that changes are instituted only by authorised personnel, and that input and output are checked for accuracy. Under the QMSR-era approach on the device side the questions are the same; the clause numbers differ. The citation is not the point. The point is that the electronic record has to hold together when it is read by a reviewer with no memory of the event.
If any step above depends on a person rebuilding the story from several files, the record is weaker than it looks, whatever the tool.
Audit trails: what "secure, computer-generated, time-stamped" really means
§11.10(e) is one sentence and it does a lot of work. The audit trail must be secure, computer-generated and time-stamped; it must independently record the date and time of operator entries and actions that create, modify or delete records; and record changes must not obscure previously recorded information. It must be retained at least as long as the record and be available for FDA review and copying.
In practice that translates to three tests:
- Independent. The user can't switch it off, edit it or choose not to log an action. If the trail lives in the same editable file as the record, it fails here.
- Complete. Creation, modification and deletion, with the before and after values. "Field updated" without the old value doesn't let you reconstruct anything.
- Readable and reviewable. Someone with the right to review the record can read the trail in context, and there is evidence they did. A trail that has to be exported and decoded by IT isn't reviewable in the sense the 2018 guidance means.
Digital systems fail this more often than teams expect, usually at the seams between systems rather than inside any one of them. The companion post on why audit trails fail even in digital systems covers the seam problem; the ALCOA+ principles are the frame inspectors use to judge it.
Electronic signatures: the part most teams skim
Subparts B and C are where Part 11 stops being philosophical. The signature rules are specific, and gaps here are easy to find because the evidence is on the face of the record.
§11.50, signature manifestation. A signed electronic record must show the printed name of the signer, the date and time of signing, and the meaning of the signature (review, approval, responsibility, authorship). If your approval screen shows a green tick and a user ID, that's a finding waiting to happen. Meaning matters: "reviewed" and "approved" are different acts with different accountabilities.
§11.70, signature/record linking. Signatures must be linked to their records so they can't be excised, copied or transferred to falsify another record by ordinary means. A signature image pasted into a document fails this on sight.
§11.100, general requirements. Each electronic signature is unique to one individual and never reused or reassigned. The organisation verifies the person's identity before assigning it. And, the one almost everyone misses: before or at the time you first use electronic signatures, you must certify to FDA in writing that they are intended to be the legally binding equivalent of handwritten signatures. It's a letter to the agency. Ask whether your company ever sent it; many haven't.
§11.200, components and controls. Non-biometric signatures use at least two distinct components (typically user ID and password). In a continuous session the first signing uses both and later signings may use one, but any signing after a break uses both again. Signatures are used only by their genuine owner, and using someone else's requires collaboration of two or more people, so the system has to make that hard, not just forbidden.
§11.300, identification codes and passwords. Uniqueness of the ID and password combination, periodic checking and revision, loss-management procedures for compromised credentials, and transaction safeguards that detect and report unauthorised use.
Every one of these is a question that can be asked of any system on the site in five minutes, from the document-control tool to the spreadsheet with a "sign here" column. Line them up before someone else does.
Validation in 2026: CSA changes how much you test, not whether
Validation under §11.10(a) has always been the most expensive clause, largely because "validate" was read as "script and execute every function". That reading is out of date.
FDA finalised Computer Software Assurance for Production and Quality Management System Software on 24 September 2025. It is formally a device guidance, but the approach is being adopted well beyond devices because it answers the question pharma teams had anyway: how much assurance does this function need? The core moves:
- Risk first. Identify the intended use of each software feature, then ask whether a failure could affect patient safety, product quality or the integrity of the quality system. High-process-risk features get more rigorous assurance; low-risk ones get less.
- Assurance activities scale. Unscripted and exploratory testing, ad-hoc testing and vendor evidence are all legitimate where the risk justifies them. Scripted testing is reserved for where it earns its cost.
- The record is the objective evidence, not the volume of the binder.
None of this removes §11.10(a). It changes the answer to "show me the evidence this system is fit for this use" from a shelf of protocols to a documented, risk-based rationale plus the testing that rationale called for. The CSV vs CSA comparison goes deeper on what to keep from the old model.
One caution: no approach makes validation automatic. A vendor's test evidence reduces your work; it does not replace your documented intended-use assessment.
Evaluating a system: five questions and the artifact to demand
If you're choosing or re-assessing a system, don't score the marketing answer. Score the artifact. These five questions cover the control points above; the answer is only a pass if the vendor produces the thing in the second column.
| Ask | Demand | Disqualifying answer |
|---|---|---|
| Can the system show who approved what, when, and with what meaning? | A signed-record export or screen showing name, date-time and meaning together | "The approval is logged" with no meaning shown |
| Can you produce the full change history of one record, live, in under a minute? | A timed retrieval on a record you pick | A report that has to be requested from support |
| How do individual identity and signature components work day to day? | The e-signature SOP and a walkthrough of the first-signing / re-signing behaviour | Shared accounts, or a signature that is a single click |
| Is there a Part 11 traceability matrix for the product? | The matrix, mapping §11.10, §11.50–§11.70 and §11.100–§11.300 to system behaviour and test evidence | "We're Part 11 compliant" with nothing behind it |
| What happens to records and the audit trail at offboarding or migration? | The retention and export procedure, including audit-trail export in readable form | "Your data is always available" |
The sixteen-row version of this table, with Pass / Partial / Fail scoring for three vendors, is the 21 CFR Part 11 RFP scorecard. Download the 21 CFR Part 11 readiness checklist to walk the twenty-eight controls on a system you already run — one row per control, with evidence and a verdict.
How Complere supports Part 11 records
Nothing changes without leaving a mark. Every create, edit, approval and deletion on a quality record carries who did it, when, and what it was before, and that history stays with the record for as long as the record exists. When an investigator asks "show me every change", the answer is on screen, not in an export request.
Approvals say what they mean. Sign-off shows the person's name, the date and time, and what the signature stands for, on the record itself. Reviewing and approving are separate acts with separate accountability, so the meaning question answers itself.
One person, one identity. Each user acts under their own credentials, with the actions their role allows and nothing more. There's no shared account for the record to be attributed to, so the attributability question doesn't come up.
The record and its history travel together. A deviation stays tied to the investigation it produced, the actions that followed and the change it triggered, so the chain from record to approval to closure can be followed without reconstruction.
Evidence you can hand over. Records and their histories can be produced as complete, readable copies on request, for the whole retention period, so "give me a copy I can read" is a minute's work.
The judgements remain the site's: which records are critical, how much assurance a function needs, who is authorised to approve what. The system's contribution is that each of those judgements leaves an attributable record that can be produced on request without reconstruction.
