Guide
What 21 CFR Part 11 actually requires.
Part 11 is shorter and narrower than most vendor marketing implies — and it asks for several things no software can give you. This is the checklist we would use to evaluate any electronic record system, including ours.
Start with what Part 11 is for
It is not a standard you pass. It is the condition on which the FDA will accept an electronic record in place of a paper one.
Part 11 applies when you keep records electronically that a predicate rule already requires you to keep — the quality system regulation, the GMPs, the device regulations. It does not create the obligation to keep the record. It sets the terms on which an electronic version of that record, and an electronic signature on it, are treated as trustworthy and equivalent to paper.
That distinction matters when you are evaluating software, because it tells you where to look. The predicate rule decides what has to be recorded and for how long. Part 11 decides whether the system holding it can be relied on: whether changes are attributable and traceable, whether a signature is genuinely bound to the thing it signed, and whether the record can be produced later in a form someone can read.
The parts of the regulation worth reading
Part 11 is organized into three subparts. Most evaluation questions come from just a handful of sections:
- §11.10 — controls for closed systems: validation, audit trails, record retrieval, access limits, operational and authority checks
- §11.30 — additional controls where the system is open rather than closed
- §11.50 — signature manifestations: what a signature must display when you look at the record
- §11.70 — signature/record linking: a signature must be bound to its record so it cannot be excised or transferred
- §11.100 — general requirements: signatures are unique to one person and never reused or reassigned
- §11.200 — the components of an electronic signature and the controls around using them
- §11.300 — controls over identification codes and passwords
Compliance is shared, and the split is not subtle
A vendor can supply software capable of meeting Part 11. Only the regulated company can be compliant with it. The regulation asks for several things that live entirely outside any product: written procedures holding people accountable for actions taken under their signature, documented training and experience for the people operating the system, and validation of the system for your intended use in your environment.
Treat any vendor claim of the form “our software is Part 11 compliant” as a category error rather than a lie. Software can be Part 11 capable. Compliance is an attribute of your quality system — your procedures, your validation, your records — operating on top of it.
The practical consequence when you are buying: the useful questions are not “are you compliant?” but “show me the audit trail on a record I just changed”, “show me what a signature displays”, and “what do you give me to support validation?”. The table below is those questions, organized.
The checklist
Eight areas, and what to ask about each
Deliberately vendor-neutral — this is usable against any system you are evaluating, ours included. Take it into a demo.
| Requirement | What it means | What to ask a vendor |
|---|---|---|
| Audit trail | A secure, computer-generated, time-stamped record of who did what and when, that does not obscure the previously recorded value and outlives the record it describes. | Change a field in front of me and show the entry it produced. Can anyone — including an administrator or a database user — edit or delete an entry? What stops them? |
| Signature manifestation | A signed record must show the signer’s printed name, the date and time, and the meaning of the signature — approval, review, responsibility. | Show me a signed record as an auditor would see it, and as it prints. Is the meaning of each signature recorded, or is it implied by which button was pressed? |
| Record and signature linking | A signature must be bound to its record so it cannot be cut, copied or transferred to falsify another record. | Where is the signature stored relative to the record? What happens to it if the record is later revised — does it carry over, or does the new version need signing again? |
| Signature components | A non-biometric signature uses at least two distinct components, such as an identification code and a password. | What does a signer actually enter at the moment of signing? Is a session login treated as sufficient, or is identity re-verified at the point of signature? |
| Uniqueness and attribution | Each signature belongs to one individual, is never reused, and is never reassigned to anyone else. | Can two people share an account? What happens to the signature history when someone leaves and their account is deactivated? |
| Access and authority checks | System access is limited to authorized individuals, and the system checks that a given person is authorized to take a given action on a given record. | Show me the permission model. Can I restrict someone to their own records, their department or their site? Where is a permission change itself recorded? |
| Copies and retrieval | Records must be protected for the whole retention period and produceable in accurate, complete, human-readable and electronic form for inspection. | Produce the version of this procedure that was in force on a date I choose. How long does that take, and what does the output look like? |
| Validation | The system is validated to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records. | What do you supply to support my validation — specifications, test evidence, a change-notification process? Note that performing the validation remains mine. |
Summarized from 21 CFR Part 11 subparts B and C for evaluation purposes. It is a working checklist, not a substitute for reading the regulation or for your own regulatory assessment.
Where QAbility sits against this — including the limits
Stated at the same level of precision we would want from a vendor we were evaluating.
The audit trail is captured by a database trigger attached to every company-scoped table, rather than by application code someone remembered to call. It records the actor, the timestamp, the originating address and the field-level before and after values, and it is append-only. Retrieval is a per-record history view on the record itself.
Electronic signatures re-verify the signer’s identity at the moment of signing rather than relying on the session, and the signature is written against the specific record it applies to. Where a workflow step is configured to require one, the step cannot complete without it.
Two scoping limits worth knowing before you ask
The signature ledger — the table that holds a signature bound to its subject record — carries document versions, CAPAs, nonconformances, change requests and audits. Two areas of the product are deliberately not on it, and we would rather you heard that here than found it in a demo:
- Training completion is signed, and identity is re-verified at submission, but the signature is stored inline on the learner’s own assignment record rather than as a ledger entry.
- Complaint closure is gated by the owner’s PIN, and the act is recorded on the audit trail — but it does not write a signature ledger entry either.
Both are real controls with real attribution. Neither is a signature-ledger row, and we do not describe them as one. If a signature ledger entry on training or complaint closure is a requirement for you, raise it — it is a product question, not a marketing one.
On validation: we supply the software and the documentation to support your validation. Validating it for your intended use, under your procedures, in your environment, remains yours — as it does with any vendor.
In the product
The capabilities built against Part 11
Read from the capability catalog rather than written onto this page, so what appears here cannot drift from what the product actually claims.
Electronic Signatures
Identity re-verified at the moment of signing.
Audit Trail
Append-only, and we can prove it.
Document Control
One version in force. Provable on any past date.
CAPA
Close the loop, then prove the fix held.
Nonconformance
Deviations dispositioned, not just noted.
Change Control
Keep a validated state validated.
Roles & Permissions
Access decided per capability, per action, per scope.
These are the frameworks each capability is built against. They are not certifications held by QAbility, and they are not a statement that your use of the product is compliant.
Straight answers
The three questions this guide gets asked
Does using QAbility make us Part 11 compliant?
No, and be wary of any vendor who says otherwise. We can supply software capable of meeting the technical controls Part 11 describes — audit trails, signature manifestation and linking, access and authority checks, retrieval. Part 11 also requires written procedures holding people accountable for signatures made under their name, documented training for the people using the system, and validation of the system for your intended use. Those are yours, and they are the parts an inspector will ask you about.
What is the difference between a Part 11 signature and clicking Approve?
Two things: identity and meaning. A Part 11 signature re-verifies who you are at the moment you sign rather than trusting that a session belongs to you, and it records what the signature meant — approval, review, responsibility — so the record shows why you signed rather than only that you did. A button that records a user id against a timestamp does neither.
Do we need Part 11 at all if we are not FDA-regulated?
Not directly — Part 11 is an FDA rule and it only bites where a predicate rule already requires the record. But the controls it describes are close to what ISO 9001 and ISO 13485 expect of record control and traceability, so a system built for Part 11 generally answers those too. The reverse is not reliably true, which is why the checklist above is worth running even if your obligation comes from elsewhere.