21 CFR Part 11 Compliant Software: Vendor Claim vs. Reality

At a glance

• “21 CFR Part 11 compliant software” is a marketing claim about capabilities, not a switch you can buy. No system is compliant the moment you install it.
• Compliance is a shared responsibility. The vendor ships compliant-capable features and supporting documentation; you still own configuration, validation in your environment, SOPs, and training.
• A tool has to support a baseline of capabilities (audit trail, unique electronic signatures, access controls, record retention and export, accurate copies) just to be a candidate.
• The right buyer move is to evaluate the claim: ask what validation support the vendor provides, what documentation you get, and how configurable the controls are.
• Using compliant-capable software does not make your organization compliant. The procedural and operational half of the work stays with you, and that is where audits are usually lost.

You are being pitched “21 CFR Part 11 compliant software,” and you suspect the phrase is doing more work in the sales deck than in reality. You are right. The ranking pages do not help: they recite the technical requirements (audit trail, e-signature, access control, validation) and then quietly imply that buying “Part 11 software” makes you compliant. The mental model they leave out is the one that matters: the line between what the vendor ships and what you still own.

This guide is written from the buyer’s chair. It explains what “compliant software” really means, lays out the vendor-versus-user responsibility split, gives the baseline capabilities a tool must support to even be a candidate, and hands you a set of questions to take into a demo. It stays shallow on the rule’s full text, audit-trail internals, and validation methodology, which live in the Part 11 rule, audit-trail, and CSV guides respectively.

What “21 CFR Part 11 compliant software” really means (and what it doesn’t)

Part 11 is a rule about how regulated electronic records and signatures are kept trustworthy (see the Part 11 explainer for the rule itself). Software can provide the technical capabilities that Part 11-relevant records need, and a vendor may describe its product as “Part 11 compliant” on that basis. But the rule’s requirements attach to how a system is validated and operated in your environment, not to the software in the abstract.

Why no system is compliant the moment you install it

Consider what Part 11 actually asks for. It requires validation of systems to ensure accuracy, reliability, and consistent intended performance, and the ability to discern invalid or altered records (§ 11.10(a)). Validation is something demonstrated in your environment, with your configuration and your intended use, not something a vendor can complete for you before you have installed anything. The same is true of access controls (who, in your organization, gets which rights) and of the procedures around the system. So even a tool with every capability ships as compliant-capable, not compliant. The moment of installation is the start of your work, not the end of it.

The shared-responsibility split: vendor capabilities vs. your obligations

This is the model the marketing omits. Hold it clearly and the whole topic becomes navigable.

The vendor ships	You still own
Compliant-capable features (audit trail, e-signature, access control)	Configuration of those features for your use
Supporting documentation (validation packages, specs)	Validation in your environment (against your intended use)
A system designed to be operated under controls	SOPs, training, and the procedures that operate it
Security and infrastructure (for SaaS, in part)	Your access model, your record-retention practice, your oversight

What a vendor ships

A credible vendor provides two things: software with the compliant-capable features (a real audit trail, electronic-signature support, access controls, record export), and documentation that supports your validation (functional specifications, validation packages or evidence, security information). Good documentation is itself a buying criterion, because it directly reduces your downstream effort.

What stays yours

What no vendor can hand over: configuring the controls for your processes, validating the system in your environment against your intended use, writing and following the SOPs that govern how people use it, and training your people. This procedural and operational layer is precisely where organizations with “compliant software” still fail inspections, because the tool was capable and the operation was not.

The capability checklist: what software must SUPPORT to be a candidate

Before a tool is even worth evaluating, it has to support the baseline that Part 11-relevant records need. Use this as a gate, not a finish line:

• Audit trail. Secure, computer-generated, time-stamped audit trails that record the author, date, and time of entries that create, modify, or delete records, without obscuring previous information (§ 11.10(e)). If a “Track Changes” feature is the answer, it is not a candidate.
• Electronic signatures (if you need them). Signatures unique to one individual and not reused (§ 11.100), using at least two distinct identification components for non-biometric signatures (§ 11.200), with the signed record showing the signer’s name, the date and time, and the meaning of the signature (§ 11.50), and the signature linked to its record so it cannot be transferred to falsify it (§ 11.70).
• Access controls. The ability to limit system access to authorized individuals (§ 11.10(d)) and enforce authority checks (§ 11.10(g)).
• Record retention and export. Protection of records for ready retrieval throughout the retention period (§ 11.10(c)) and accurate, complete copies in human-readable and electronic form for inspection (§ 11.10(b)).

A tool missing any of these is not a Part 11 candidate, regardless of the badge on its website.

How to evaluate a vendor’s Part 11 claim before you buy

Turn the responsibility split into demo questions. Take these in:

1. “Show me the audit trail.” Is it secure, computer-generated, time-stamped, and impossible to edit or disable by users? Can you export it?
2. “What validation support do you provide?” Validation packages, IQ/OQ documentation, test evidence? The more they provide, the less you carry.
3. “What documentation do I get?” Functional specs, security documentation, a Part 11 capability matrix mapping features to requirements?
4. “How configurable are the controls?” Can access rights, signature meanings, and retention be configured to your processes, or are they fixed?
5. “What, explicitly, remains my responsibility?” A trustworthy vendor will name the user side of the split plainly. A vendor that claims the software alone makes you compliant is a red flag.
6. “Who owns validation when you push an update?” Changes can affect validated state; understand the re-validation implications.

The goal is to separate a genuinely Part 11-capable tool, with the documentation that supports your validation, from a checkbox.

As an illustration of the vendor-capability side of the split: TrialTrack, a clinical project management tool, describes itself as offering a 21 CFR Part 11-aligned audit trail on its plans. That is TrialTrack’s own claim about its capabilities, and it sits exactly where the model predicts, on the vendor side. It does not, and could not, make your organization compliant; the configuration, validation, SOPs, and training remain yours, as they would with any tool. (And evaluate any product only against the records it is built for; a clinical PM tool is not an EDC or eTMF.)

Where to go next

• For the rule itself and the predicate-rule scope, see the 21 CFR Part 11 explainer.
• For a runnable, section-referenced self-audit, see the Part 11 checklist.
• For how to actually validate a system in your environment, see the computer system validation guides.
• For the specific case of spreadsheets and SaaS, see the Part 11 for Excel and SaaS guide.

Frequently asked questions

Can software be “21 CFR Part 11 compliant” out of the box? No. A vendor can ship compliant-capable features and documentation, but compliance depends on validation in your environment, configuration, SOPs, and training. Out of the box, software is compliant-capable, not compliant.

What does the vendor provide vs. what do I remain responsible for? The vendor provides the capable features and supporting documentation. You provide configuration, validation in your environment, procedures, and training, the half where audits are usually lost.

What capabilities must software support to be a candidate? A real audit trail, unique multi-component electronic signatures (if needed), access controls, and record retention, export, and accurate copies. Missing any of these disqualifies it.

How do I evaluate a vendor’s Part 11 claim? Ask to see the audit trail, ask what validation support and documentation come with the product, probe configurability, and ask the vendor to name what stays your responsibility.

Does using compliant software make my organization compliant? No. The procedural and operational layer (validation, configuration, SOPs, training, oversight) is yours, and that is what determines whether you pass an inspection.

The bottom line

“21 CFR Part 11 compliant software” describes capabilities, not your compliance status. The useful mental model is the shared-responsibility split: vendors ship compliant-capable features and validation-supporting documentation; you own configuration, validation in your environment, SOPs, and training. Gate tools on the baseline capabilities, evaluate the vendor’s claim with hard questions, and never mistake a capable product for a compliant operation, because the second one is on you.

Sources

• 21 CFR Part 11, Electronic Records; Electronic Signatures