21 CFR Part 11 Compliant Software: How to Evaluate and Validate It (2026)

Search for “21 CFR Part 11 compliant software” and you will find hundreds of products that say they are. FDA has not certified any of them, because FDA does not certify software. Part 11 compliance is a property of a system as you configure, validate and operate it, and the obligation sits with the regulated company, not the vendor. This guide is for the quality, regulatory and operations people choosing an eQMS, LIMS, ELN, EDC or a no-code platform for GxP work: what the software has to do, how to test those claims in a demo, and how to validate a system you did not write. If you are building the software yourself, our Part 11 engineering guide covers the implementation side.

1. Does Part 11 Apply to You?

21 CFR Part 11 applies when you keep, in electronic form, a record that another FDA regulation requires you to keep, or when you submit electronic records to FDA. Those other regulations are called predicate rules, and they are where the obligation really comes from:

• Drug and biologics manufacturing: current good manufacturing practice, 21 CFR 210/211 and 600-series.
• Medical devices: the Quality Management System Regulation (21 CFR 820, which since February 2026 incorporates ISO 13485 by reference).
• Nonclinical lab studies: good laboratory practice, 21 CFR 58.
• Clinical investigations: 21 CFR 50, 56, 312 and 812, including informed consent and case report forms.

FDA’s 2003 guidance Part 11, Electronic Records; Electronic Signatures — Scope and Application narrowed how the agency reads this. If you print a record and the paper is what you actually rely on, the electronic copy is generally not a Part 11 record. If you rely on the electronic version to do regulated work, it is.

2. “Part 11 Compliant” Is a Claim About Your System, Not a Product

A vendor can build features that make compliance possible: an audit trail, signature controls, role-based access. Whether you are compliant depends on things only you control:

• How you configured it. An audit trail that an administrator can switch off, and did, is not an audit trail.
• Whether you validated it for your intended use and kept the evidence.
• Your procedures: who gets accounts, who reviews audit trails and how often, what happens when someone leaves.
• Whether people share logins. Shared accounts break attributability no matter what the software does, and they appear in FDA warning letters year after year.

So read “Part 11 compliant software” as “software with the technical controls Part 11 needs.” The useful question for a vendor is not “are you compliant?” but “show me each control, and give me evidence I can put in my validation file.”

3. What the Software Itself Must Do

Part 11 has a short list of technical requirements. These are the ones the software has to support; the rest are procedures you write.

Behind all of this is the data-integrity standard FDA inspects against, usually summarised as ALCOA+: records must be Attributable, Legible, Contemporaneous, Original and Accurate, plus Complete, Consistent, Enduring and Available. When a feature is unclear, ask which of those letters it protects.

4. Testing an Audit Trail in a 15-Minute Demo

The audit trail is the first thing an FDA investigator asks to see, and it is the feature vendors most often describe more generously than they built it. Don’t accept a screenshot. (If you are designing one rather than buying one, the fields are the same ones we cover in our audit logging guide.) Ask the vendor to do these live, in a test environment, while you watch:

1. Change a value on a record, then show the trail. You should see the user, a server-generated timestamp with its time zone, the field, the old value and the new value. A trail that says only “record updated” fails.
2. Make the same change where a reason is required. GMP records need a reason for change. Check that the system prompts for one and stores it on the audit entry.
3. Log in as the highest-privilege administrator and try to edit or delete an audit entry. It should be impossible from the application. Then ask what a database administrator at the vendor could do, and what would show if they did.
4. Try to turn the audit trail off. If a setting allows it, that setting needs to be locked down, and changing it should itself be audited.
5. Change the configuration: add a field, edit a workflow step, change a role’s permissions. Configuration changes affect regulated records, so they need an audit trail too, and many products don’t keep one.
6. Delete a record. The record should be marked deleted or retired, and the record plus its history should still be retrievable. Hard deletion of a GxP record is a finding.
7. Review the trail the way your reviewers will. FDA’s 2018 data-integrity Q&A expects audit trails that capture changes to critical data to be reviewed with each record, for example before batch release. Filter the trail to one record or one batch. If that takes an export and a spreadsheet, reviews won’t happen on schedule.
8. Export the record with its trail as you would hand it to an investigator.

For mobile or offline data capture, common in labs and on manufacturing floors, add one more test: create a record offline, change it, then sync. The trail should show the original capture time and the device, not just the sync time.

5. Testing Electronic Signatures

Electronic signatures fail evaluation more often than audit trails, because many products have “e-signature” features that were designed for contracts, not GxP records. Check:

• Identity at signing. Sign a record. The system should ask for your password (and user ID, at the first signing in a session) at the moment of signing. A typed name, a drawn squiggle, or a button clicked while already logged in is not a Part 11 signature.
• Meaning. The signature should state what it means, such as “Reviewed” or “Approved,” and that meaning should show on the record and on every printout or PDF of it.
• Linking. Edit the record after it is signed. The signature should be invalidated or the record should be locked, and the trail should show both events. A signature that silently carries over to the edited version fails 11.70.
• Uniqueness. Ask how the system stops an account from being renamed and handed to someone else. Signature IDs must never be reused or reassigned.
• Lockout. Enter the wrong password repeatedly. The account should lock and someone should be alerted.

One procedural item belongs on your project plan, not the vendor’s: before your staff’s electronic signatures count, your organisation sends FDA a one-time letter certifying that it intends them to be the legally binding equivalent of handwritten signatures (21 CFR 11.100(c)).

6. Validating Software You Didn’t Write: CSV, CSA and GAMP 5

Section 11.10(a) requires validation, and this is where purchase projects most often stall. The traditional approach, computer system validation (CSV), produced binders of scripted test steps with screenshots for every function, important or not. FDA has spent several years steering industry away from that.

Computer Software Assurance (CSA) is FDA’s risk-based approach, set out in its guidance Computer Software Assurance for Production and Quality Management System Software. It was first finalised in September 2025 and reissued in February 2026 to line up with the new device quality regulation. The core ideas are simple:

• Decide what the software is for and which functions could affect product quality or patient safety if they failed.
• Spend your testing effort on those high-risk functions, with scripted tests and recorded evidence.
• Test lower-risk functions with lighter, unscripted or exploratory testing, recorded briefly.
• Use the vendor’s own testing and certifications where you can, rather than repeating them.

CSA formally covers device-manufacturing production and quality-system software, but its reasoning matches the risk-based approach in GAMP 5, which pharma and biotech teams already use. The same thinking works for most Part 11 systems.

GAMP 5 (Second Edition, 2022) sorts software into categories, and the category decides how much validation effort is reasonable:

A proportionate validation package for a configured SaaS product usually comes down to:

1. Validation plan stating the intended use and the risk approach.
2. Supplier assessment: a questionnaire, the vendor’s SOC 2 Type II or ISO 27001 report, their quality system and release process, and for higher-risk systems an audit.
3. Requirements, written as what you need the system to do, each with a risk rating.
4. Configuration specification: exactly how you set it up.
5. Testing, scaled to risk per CSA.
6. Traceability from each requirement to the test that covers it.
7. Validation summary report, and a release decision.
8. Change control and periodic review, so the system stays validated after go-live.

The last item is the one teams under-plan. Validation is not a one-time project, and with SaaS the changes arrive whether or not you scheduled them.

7. SaaS, No-Code and AI-Built Systems: The Extra Risks

None of these are disqualifying. Each needs a specific control in your validation approach.

The vendor ships updates on its own schedule

Multi-tenant SaaS products update every tenant at once. Ask for advance release notes, a preview or sandbox environment that gets each release first, and a commitment to notify you of changes that affect GxP functions. Your change-control procedure then assesses each release and re-runs the tests for any high-risk function it touches. FDA’s 2024 Q&A guidance on electronic systems in clinical investigations expects sponsors to have this kind of oversight of their IT service providers.

Configuration changes bypass change control

The selling point of a no-code or low-code platform is that anyone can change a form or a workflow in minutes. In a validated system, that is a change made outside change control. Restrict configuration rights in production to a small group, make all changes in a development copy first, and choose a platform that versions and audits configuration as well as data.

“No-code” often contains code

Formulas, scripts, custom actions and integrations inside a configured product are custom logic: GAMP Category 5, inside a Category 4 system. Inventory them and validate them as code, even when the platform calls them “rules.”

The audit trail may stop at the platform’s edge

Data that leaves through an integration to a spreadsheet, a BI tool or another app usually leaves its audit trail behind. Map where GxP data flows, and treat every system that can change it as in scope.

AI-generated software is custom software

An application generated by an AI coding tool, ours included, is Category 5 custom code from a validation standpoint. That it was generated quickly does not reduce the testing it needs; it only moves the effort from writing code to reviewing and testing it. The same applies if you use AI features inside a GxP system: a person must review AI output before it becomes a signed record, and the audit trail should keep the AI draft and the human edits as separate events. Our HIPAA-compliant AI guide covers that architecture.

8. Twelve Questions to Send a Vendor

1. Can any user, including your own staff with database access, edit, delete or disable audit trail entries? What evidence would that leave?
2. Does the audit trail record old and new values and a reason for change? Does it cover configuration changes, not only data?
3. Does signing require re-entering credentials, and does every signature carry a meaning shown on the record and its printouts?
4. What happens to a signature when a signed record is edited?
5. Can we export a complete record with its audit trail and signatures, in readable and electronic form, without your help?
6. What validation documentation do you provide: test protocols, results, a traceability matrix? Can we see a sample now?
7. How much notice do we get before a release, and is there a sandbox that receives it first?
8. Which independent reports can you share (SOC 2 Type II, ISO 27001, ISO 13485), and will you support a supplier audit?
9. Where is our data hosted, how is it backed up, and how quickly have you actually restored from backup?
10. How are time stamps generated and synchronised, and which time zone is shown?
11. If we leave, in what form do we get our records and audit trails back?
12. Which FDA-regulated customers run the product in production for a use like ours, and can we speak to one?

The answers to 1, 3 and 6 will usually tell you most of what you need. Vague answers to those three are a reason to keep looking.

9. Where VertiComply Fits, and Where It Doesn’t

VertiComply generates healthcare applications from templates. We are not a validated GxP platform, and nothing we generate arrives validated. Here is the honest position for Part 11 work.

What our e-signature template gives you as a starting point. The consent and e-signature template records the exact template version signed, the signer’s affirmed intent, the time, IP address and user agent, an optional witness, and revocation with a reason. A signed record is never deleted, only marked revoked, and each of those actions is written to an audit log.

What it does not do yet, measured against the table in section 3:

• Signers are not authenticated at signing. The public signing form takes a typed name and email, which is fine for routine clinic consents but does not meet 11.100 and 11.200.
• Signature meaning is recorded as a role (patient, guardian, participant), not as a GxP meaning such as reviewed or approved.
• The audit log is append-only in the application, but it has no tamper-evidence mechanism such as a hash chain, and it does not store old and new values for field edits.
• There is no validation package. If you use generated code for a GxP purpose, you validate it as custom (Category 5) software.

Those gaps are closable, and closing them is the kind of work our custom build team scopes. Our free FDA compliance checker gives a quick first-pass score, which is useful for finding gaps but is not validation evidence. For FDA requirements beyond Part 11, see our FDA compliance overview.

10. Frequently Asked Questions

Is there FDA-certified 21 CFR Part 11 software?

No. FDA does not certify, approve or endorse software for Part 11. Vendors who say their product is “Part 11 compliant” mean it has the technical controls Part 11 requires, such as audit trails and electronic signatures. Compliance depends on how the regulated company configures, validates and operates the system, and the responsibility stays with that company.

What are the FDA requirements for an audit trail?

Under 21 CFR 11.10(e), the audit trail must be secure and computer-generated, time-stamped, and must record the date and time of operator entries and actions that create, modify or delete electronic records. Changes must not obscure previously recorded information, the trail must be kept at least as long as the record, and it must be available to FDA for review and copying. GMP practice also expects the reason for each change, and regular review of the audit trail as part of record review.

Do medical device companies need Part 11 audit trails?

Yes, for electronic records required by device regulations, such as design history, device history and complaint records under the Quality Management System Regulation (21 CFR 820). If those records are kept and relied on electronically, Part 11’s audit-trail, signature and validation controls apply to the systems that hold them.

What is the difference between CSV and CSA?

Computer system validation (CSV) is the traditional approach, often producing extensive scripted tests and screenshots for every function. Computer Software Assurance (CSA) is FDA’s risk-based approach: concentrate rigorous, documented testing on functions that could affect product quality or patient safety, use lighter testing for low-risk functions, and rely on vendor evidence where it is sound. CSA aims for confidence in the software rather than volume of documentation.

How do you validate a SaaS system for Part 11?

Define the intended use and risks, assess the supplier (including its quality system, security reports and release process), write requirements and a configuration specification, test the configured system in proportion to risk, trace requirements to tests, and record a release decision. Then keep it validated with change control: review every vendor release, retest affected high-risk functions, and run periodic reviews.

Can I use a no-code platform for GxP records?

Yes, if the platform has the required technical controls and you validate it like any configured system. The extra risks are configuration changes made outside change control, scripts and formulas that are really custom code, and integrations that move data outside the audit trail. Restrict who can change production configuration, version every change, and validate custom logic as code.

Is a typed name a valid electronic signature under Part 11?

Not for a Part 11 record. A non-biometric Part 11 signature needs at least two distinct identification components, such as a user ID and a password, with all components entered at the first signing in a session and at least one entered at each later signing. A typed name may be a valid signature under the ESIGN Act for an ordinary contract, but that is a different standard.

Does Part 11 apply to AI tools used in regulated work?

Part 11 applies to the records, not to the technology that helped produce them. If an AI tool drafts a record that becomes a regulated electronic record, the system must still attribute it, audit it and capture the required signatures. In practice that means a qualified person reviews and signs the final record, and the audit trail keeps both the AI draft and the human edits. AI models used inside a GxP process also need to be covered by your validation approach.

Last reviewed 1 October 2026. This guide summarises 21 CFR Part 11 and related FDA guidance for software selection. It is not legal or regulatory advice; confirm your obligations with your quality and regulatory team, and check current FDA guidance before relying on any specific point.