21 CFR Part 11 Compliance for Software Vendors: What Your Pharma and Biotech Customers Will Ask For

Your pharma customer just sent a supplier questionnaire asking about 21 CFR Part 11 compliance, and you're not sure what you actually owe them. Part 11 doesn't regulate your software. It regulates the electronic records and signatures your customer keeps under FDA predicate rules like GLP, GCP, and GMP. Your job is to build product controls that let them comply, and to prove you develop and change the software under control so they can validate it for their intended use.

There is no FDA 21 CFR Part 11 certification. No government body issues one. Any third-party certificate has no standing with FDA. A vendor that claims to be "Part 11 certified" reads as uninformed to any pharma quality team that has run a supplier audit. What that quality team actually wants is evidence: your architecture, your development practices, your audit trail design, and a clear statement of which Part 11 requirements your product supports versus which stay with the customer's own procedures.

Key Points

• Part 11 does not regulate your software directly; it regulates the electronic records and signatures your pharma customer keeps under FDA predicate rules like GLP, GCP, and GMP, so your job is to build product controls that let them comply and to prove you develop software under control so they can validate it for their intended use.
• No FDA 21 CFR Part 11 certification exists because FDA does not issue one and a third-party certificate has no standing with FDA, and claiming to be "Part 11 certified" signals to any experienced pharma quality team that you do not understand the regulation.
• The audit trail must be secure, computer-generated, and time-stamped, and section 11.10(e) requires it to record entries and actions that create, modify, or delete records without obscuring earlier values. Pharma customers also expect it to be attributed to specific people, log configuration changes, stay on permanently, and be readable without a developer interpreting raw database logs.
• You provide validation support documentation including user requirements, functional specifications, risk assessments, and qualification protocols, but the customer owns the validation conclusion because they define their intended use, perform their own risk assessment, write the SOPs, execute acceptance testing, and decide whether the system is validated for their regulated process.
• A good Part 11 statement specifies which requirements your product's technical controls support and which depend on the customer's configuration and operational controls. It must never claim your software "is 21 CFR Part 11 compliant" as a blanket statement or reference a Part 11 certification, because compliance depends on the customer's intended use, configuration, SOPs, and validation.

What is 21 CFR Part 11?

Part 11 is a regulation about trust in electronic records.

When an FDA predicate rule (such as the GLP, GCP, and GMP regulations) requires a company to keep records or apply signatures, and that company uses a computer system instead of paper, Part 11 sets the controls that make those electronic records trustworthy.

The regulation has three subparts. Subpart A defines scope. It specifies which records and signatures fall under Part 11, and when the rule applies versus when it doesn't. Subpart B covers electronic records, including controls for closed systems, the additional requirements for open systems, how signatures appear on a record (11.50), and how they link to it (11.70). Subpart C covers the signatures themselves: uniqueness and the certification to FDA that they are the legal equivalent of handwritten signatures (11.100), signature components (11.200), and controls for IDs and passwords (11.300).

Scope decides whether Part 11 applies at all.

Part 11 applies when an FDA regulation requires the record or when the record is submitted to FDA. If neither is true, Part 11 doesn't kick in.

Closed vs. open systems under Part 11

Many SaaS products serving pharma are treated as closed systems, and the customer's risk assessment is where that call gets made.

In a closed system, access is controlled by the people responsible for the records on it. Closed systems require controls like access restrictions, audit trails, and authority checks. Open systems carry those controls plus added measures, such as document encryption and digital signature standards where appropriate, because the people responsible for the records don't control who can access the system.

If you run a multi-tenant cloud application, many customers still classify it as closed when they control user accounts and your quality agreement restricts and logs your own staff's access. Others treat internet delivery as open and ask for encryption in transit too.

Your Part 11 statement should say which classification your controls assume.

Is your software "Part 11 compliant"? Who the rule actually applies to

The question your pharma customer is really asking is: "Can we use your software and still meet our Part 11 obligations?"

Part 11 applies to the FDA-regulated company.

It applies to the entity that creates, modifies, maintains, archives, or transmits electronic records that a predicate rule requires. Your customer bears that responsibility.

You are a supplier. Your customer uses your product as part of their regulated process, and they need to validate that the product works for their intended use. Your role is to give them the controls and the evidence that make validation possible.

A laboratory balance manufacturer doesn't comply with GMP on behalf of the lab. The manufacturer builds a reliable instrument. The lab qualifies it, calibrates it, and operates it within their quality system.

FDA does not issue a 21 CFR Part 11 certification for software. The FDA's own Scope and Application guidance is addressed to the regulated firm. It says FDA will exercise enforcement discretion on some Part 11 requirements, including validation and audit trails, and expects the firm to base its approach on a justified, documented risk assessment. The predicate rules still apply in full, and so do the rest of Part 11's controls.

The product controls your customers will test

When a pharma or biotech quality team evaluates your product against 21 CFR Part 11 requirements, they're checking whether your software gives them what they need to keep trustworthy electronic records.

They'll test specific controls, and they won't take your word for it.

Audit trail design

Section 11.10(e) sets the audit trail requirement.

Your system needs to generate a secure, computer-generated, time-stamped trail that records who did what and when, and why where the customer's procedures require a reason. Each entry should identify the person who made it, and a change must not obscure the earlier value. Customers will expect it to capture configuration changes, data changes, and deletions.

Customers test two audit trail details closely.

First, the audit trail can't have an off switch. If an admin can disable it, your customer can't demonstrate that their records are trustworthy.

Second, it needs to be human-readable. A raw database log that only a developer can interpret will not satisfy a pharma quality team.

We've seen a pharma customer's pre-purchase data integrity questionnaire ask specifically whether you can switch the audit trail off, whether each entry includes the person and a reason for the change, and whether the trail captures all three categories: configuration, data, and deletions.

Access controls and account management

Your system needs unique user accounts with separate access levels.

Password complexity and forced password changes. Automatic logout after inactivity. Account lockout after failed attempts.

One question that catches vendors off guard is whether you keep any backdoor accounts. If your engineering team has a shared admin account that bypasses normal access controls, expect it to become a finding.

Another question is whether you deactivate users rather than delete them. Deleting a user can break the audit trail's attribution chain. Deactivation preserves the record while revoking access.

Electronic signatures and record copies

If your product includes electronic signature workflows, those signatures must show the signer's printed name, the date and time, and the meaning of the signature (such as review, approval, responsibility, or authorship).

The signature must be linked to the record so it can't be separated or reassigned.

A signature not based on biometrics needs two distinct components, such as a user ID and a password. The first signing in a continuous period of access uses both, and each later signing in that period uses at least one component only the signer can use (11.200).

We supported a life sciences AI company through a two-day supplier qualification audit where the vendor's initial risk assessment treated the records its platform holds as electronic records under Part 11 but classified electronic signatures as not applicable. No workflow in the product asked a user to sign a record.

The auditors accepted that position.

If your product doesn't include signing workflows, say so explicitly in your risk assessment rather than leaving it ambiguous.

Your system also needs to produce accurate and complete copies of electronic records, in both human-readable and electronic form (11.10(b)). If an FDA inspector or your customer's quality team asks for a copy, the system should produce one that's complete and legible.

Time stamping and system time

Every audit trail entry and every electronic signature must carry a time stamp.

The system must use a reliable time source. If your application runs in a cloud environment, document how you synchronize time across instances and what happens if time drift occurs.

Pharma auditors will ask whether you documented the time source, whether it's traceable to UTC, usually through NTP, and whether users can alter the system clock.

If a user can change the system time and backdate an action, the audit trail loses its integrity.

Data integrity

Every Part 11 control exists to protect data integrity.

The acronym ALCOA+ summarizes what auditors look for. Attributable, legible, contemporaneous, original, accurate, plus complete, consistent, enduring, and available.

Your audit trail must show who made the change (attributable). The record must be readable (legible). The time stamp must reflect when the action happened (contemporaneous). The system must preserve the original record (original). The data must be correct (accurate).

The "plus" adds completeness (no missing entries), consistency (entries follow in the expected order, with time stamps that agree), endurance (records don't degrade or disappear), and availability (you can retrieve them when needed).

A pharma quality team will test your design against each of these.

Backup, disaster recovery, and record retention

Your customer needs assurance that electronic records will survive a system failure.

Document your backup procedures, your recovery time objective, and your recovery point objective. Describe how you test restores. Explain how long you retain records and whether the customer can export their data in a usable format if they leave your platform.

Pharma companies keep regulated records for years, and the predicate rule sets how long.

If your standard contract deletes customer data shortly after termination, that's a problem. The customer needs either extended retention or a way to export everything, with audit trails and metadata, in a readable format before the contract ends.

What a pharma supplier questionnaire or audit asks a software vendor

The supplier questionnaire and the supplier audit are two stages of the same evaluation.

The questionnaire is the screening round. The audit goes deeper.

A typical pre-purchase questionnaire covers the controls described above, often in a checklist format. One pharma customer's questionnaire to the life sciences AI company we support asked about access levels, password policies, logout and lockout, backdoor accounts, user deactivation, audit trail scope, e-signatures, record copies, and the system's time source. They want specifics.

What the audit actually looks like

A full supplier qualification audit goes beyond the product.

We helped that same life sciences AI company prepare for the two-day remote audit its pharma customer ran. The audit criteria listed 21 CFR Part 11 alongside EU Annex 11, GAMP 5, and ISO 27001.

The auditors walked through the architecture, development procedures, validation practices, the quality management system, backup and recovery, access controls, incident handling, the audit trail, and contract terms for notifying the customer of software changes.

No certificate came out of that audit.

The audit closed as acceptable after the customer accepted written responses to its findings. The one recommendation on the audit trail was to show evidence of periodic audit-trail review by the next audit.

That's a normal outcome. The customer determines whether you're an acceptable supplier for their regulated use.

If you're used to responding to healthcare security questionnaires, the process will feel familiar in structure but different in substance. The pharma quality team cares about how you build, test, and change the software.

Common audit findings

An administrator can disable the audit trail. Changing a record overwrites the old value instead of keeping it beside the new one. The system doesn't log configuration changes. There's no documented procedure for notifying customers of software changes that might affect their validated state.

Backdoor accounts are another finding auditors look for.

If your support team uses a shared admin login to troubleshoot customer issues, replace it with individual accounts with higher privileges, so every action is attributed to one person and logged.

How to prepare for an audit

Start by reading the audit criteria the customer sends.

They'll usually reference Part 11, EU Annex 11, GAMP 5, and possibly information security standards. Map each requirement to the evidence you have. If you don't have it, create it or document why it doesn't apply.

Organize your evidence in a folder structure the auditors can use.

Quality management system procedures, change control records, validation documentation, architecture diagrams, access control configurations, audit trail samples, backup and disaster recovery procedures, and training records for the people who build and support the system, because 11.10(i) covers developers too.

Run a mock audit internally. Have someone outside the development team ask the questions a pharma auditor would ask. Where you stumble, that's where you need better documentation or a clearer answer.

The audit may be remote, as the one we supported was. Expect screen shares, document reviews, and follow-up questions in writing. The auditors will take notes and issue a report with observations and findings.

The labels vary from one company to the next. Findings need a written response; observations and recommendations usually do not, though the auditor may check them next time.

You'll write a response to each finding, describing what you'll do and by when. The customer reviews your response and decides whether it's acceptable.

Validation: what you provide and what the customer still owns

21 CFR Part 11 validation is the area where responsibility splits most sharply between vendor and customer.

What you supply

Your customer expects a validation package they can use as input to their own qualification.

That typically includes functional specifications, a supplier risk assessment, installation and operational qualification protocols with executed results, and a traceability matrix. Some customers also ask the vendor to draft user requirements, performance qualification protocols, and a validation summary report for their own review and approval.

For that same vendor, we built the full package for its customer's intended use. We ran operational and performance qualification as one combined protocol and documented it as a planned deviation, with the traceability matrix showing that no requirement was dropped.

When a second pharma customer asked that vendor for its Part 11 and validation documentation, we set up the folder and filled it the same day.

Change control, the initial risk assessment, the validation plan, user and functional requirements, and the qualification protocols. Keep these documents current so the next request means sharing a folder.

What stays with the customer

The customer owns the validation conclusion.

They define their intended use. They perform their own risk assessment of the system in their environment. They write the SOPs that govern how their people use the software. They execute acceptance testing and decide whether the system is validated for their regulated process.

You can write the package, even for their intended use, as we did. The decision that the system is fit for that use is still theirs.

If your Part 11 statement says your software is validated, you're overclaiming. Say instead that your software supports the customer's validation.

Following a clear life sciences compliance roadmap helps you prepare the right documentation before the customer asks.

The validation plan

The validation plan is the roadmap for the entire validation effort.

It defines the scope (which system, which version, which intended use), the approach (risk-based, following GAMP 5 or another framework), the roles and responsibilities, and the acceptance criteria.

As a vendor, you can provide a template validation plan that the customer adapts to their use case. Include sections for system description, intended use, risk assessment summary, validation activities, roles, and references to supporting documents.

The customer fills in their specific intended use, their risk assessment, their SOPs, and their acceptance criteria.

User requirements and functional specifications

User requirements describe what the system must do from the user's perspective.

Functional specifications describe how the system implements those requirements. Together, they form the basis for testing.

Write user requirements as testable statements. "The system shall generate an audit trail entry when a user modifies a record." "The system shall keep the previous value visible in the audit trail when a user changes a record." "The system shall export the audit trail for a selected record in human-readable form."

Each functional specification should trace back to one or more user requirements.

The traceability matrix shows that every requirement has a specification, every specification has a test, and every test has a result.

Risk assessment

The risk assessment identifies which functions are GxP-relevant and what could go wrong.

Use a structured approach. List each function. Determine whether it's GxP-relevant (does it affect patient safety, product quality, or data integrity?). Identify potential failure modes. Assess the severity and probability. Assign a risk level. Define mitigation controls.

High-risk functions get more testing. Low-risk functions get less.

Document the rationale. If you classify a function as low risk, explain why. If you decide a function doesn't need validation testing, explain why.

Qualification protocols

Qualification protocols are the test scripts.

Installation Qualification (IQ) verifies that you installed the system correctly. Operational Qualification (OQ) verifies that the system operates according to its specifications. Performance Qualification (PQ) verifies that the system performs as intended in the customer's actual use.

For SaaS, you typically execute IQ on your own infrastructure and provide OQ protocols and results the customer can review or rerun in their tenant.

PQ involves the customer because it tests their specific workflows and data.

Each protocol should include the objective, the scope, the prerequisites, the test cases, the acceptance criteria, and the signatures of the people who executed and reviewed the tests.

Traceability matrix

The traceability matrix links requirements, specifications, tests, and results.

It shows that every user requirement has a functional specification, every specification has a test case, and every test case has a result. If a requirement isn't tested, the matrix shows the gap. If a test fails, the matrix shows which requirement is at risk.

Build the matrix in a spreadsheet or a requirements management tool. Columns for requirement ID, requirement text, specification ID, test case ID, and test result.

Update it as you go. By the end of validation, the matrix should show complete coverage with all tests passed or deviations documented and accepted.

Change control for SaaS releases

A SaaS vendor that releases weekly cannot run a full change control package for every release.

GAMP 5 supports scaling the effort to the risk of each change.

We classify each change as patch, minor, major, or emergency and scale the documentation and approvals to the class. One change record per release lists what's in it, so the customer can see what changed and decide whether it touches their validated use.

If you're working toward GxP compliance alongside Part 11 readiness, this change control structure serves both.

Revalidation triggers

Define revalidation triggers in your change control procedure. Major changes that affect GxP-relevant functions trigger revalidation. Minor changes and patches usually don't, as long as regression testing confirms no impact.

Document the rationale for each classification. If you release a new feature that doesn't touch the audit trail or access controls, explain why it doesn't require customer revalidation. If you patch a security vulnerability, explain why regression testing is sufficient.

The customer reviews your change notes and decides whether they need to revalidate. Your job is to give them enough information to make that decision confidently.

Where SOC 2 helps and where it stops

If you already have a SOC 2 report, you have a head start.

SOC 2 tests your controls against the AICPA trust services criteria: security, plus availability, processing integrity, confidentiality and privacy where you include them. Pharma supplier questionnaires often ask for it.

But SOC 2 answers the information security section of a Part 11 assessment and stops there.

Part 11 covers the regulated record itself.

It asks whether the system produces a trustworthy audit trail, whether the electronic signature links to the record, whether you can produce an accurate copy, and whether your development and change control practices are documented and auditable. SOC 2 doesn't cover audit trail design for FDA purposes. It doesn't evaluate your qualification protocols or your traceability matrix. Its change management criterion shows changes are authorized and tested, but it doesn't assess whether your QMS supports GxP development practices or whether a change touches the customer's validated use.

Most security firms work only on the information security side.

Part 11 work also needs quality management system skills, because the customer's quality team audits how you build, test, and change the software. That's why companies selling into life sciences often need both tracks running at the same time.

If you haven't started SOC 2 yet, grab the free SOC 2 Readiness Checklist to see where you stand on the security side, and plan Part 11 work as a parallel effort. Our SOC 2 compliance services cover the security side end to end.

Your pharma customer will check the reports and certificates you cite the same way any buyer checks vendor certifications, so confirm each one's scope covers the product they're buying.

The reverse gap exists too: companies that pass FDA inspections still fail life sciences security audits. A vendor with a SOC 2 report should expect its Part 11 gaps to sit in quality system documentation and product-level controls.

ISO 27001 and Part 11

ISO 27001 is an information security management system standard that covers how you assess risk, apply security controls, manage incidents, and improve continuously. Like SOC 2, it addresses the infrastructure and operational security side.

ISO 27001 and Part 11 overlap in areas like access control and audit logging. But ISO 27001 doesn't cover the product-level controls Part 11 requires, like audit trail design for GxP records or electronic signature linkage.

If you hold ISO 27001, mention it in your Part 11 statement as evidence of your security posture. Then address the Part 11-specific controls separately.

GAMP 5 and validation

GAMP 5 (Good Automated Manufacturing Practice) is the ISPE guide life sciences quality teams use to validate computerized systems.

Its full title is A Risk-Based Approach to Compliant GxP Computerized Systems.

GAMP 5 classifies software into categories by how much it is configured or custom-built. Category 1 is infrastructure software (operating systems, databases). Category 3 is non-configured products (off-the-shelf software used as installed). Category 4 is configured products (such as a configurable SaaS application). Category 5 is custom software.

Many SaaS platforms land in Category 4, though customer-specific development can add Category 5 elements.

For Category 4, GAMP 5 centers the work on assessing the supplier and verifying the configuration against the user's requirements. You provide evidence that you developed the product under a quality system. The customer validates their configuration and use.

If your customer references GAMP 5 in their audit criteria, they're signaling that they follow a risk-based validation approach. That's good news. They are less likely to ask for source code review or exhaustive testing of every function, and more likely to focus on the GxP-relevant functions and the controls that matter.

How to write a Part 11 statement that will not backfire

Your pharma customers will ask for a Part 11 statement, sometimes called a statement of compliance or a Part 11 position paper.

What you write here sets expectations. Get it wrong and you either overclaim (which loses credibility) or underclaim (which creates unnecessary friction in the sales process).

What your statement should include

A good Part 11 statement is specific about boundaries.

It says which 21 CFR Part 11 requirements the product's technical controls support, and it says which requirements depend on the customer's configuration and operational controls.

Structure it around the control areas.

• The system generates a secure, computer-generated, time-stamped audit trail that cannot be disabled, attributes each entry to a user, and keeps previous values visible.
• The system supports unique user accounts, role-based access, password policies, and automatic logout, with user provisioning and role assignment being the customer's responsibility.
• If applicable, signatures display signer identity, date, time, and meaning, linked to the signed record; if signatures are not applicable, say the product has no signing workflows.
• The system can produce accurate, readable copies of electronic records.
• You maintain documented change control procedures and provide release notes for the customer to assess the impact on their validated state.

What your statement must not claim

Never say your software "is 21 CFR Part 11 compliant" as a blanket statement.

Compliance depends on the customer's intended use, their configuration, their SOPs, and their validation. Your software supports compliance. It doesn't achieve it independently.

Never reference a Part 11 certification. It doesn't exist. The only certification in Part 11 is one your customer sends: under 11.100(c), it certifies to FDA that the electronic signatures in its system are intended to be the legally binding equivalent of traditional handwritten signatures. Calling your product Part 11 certified tells any experienced quality professional that you don't understand the regulation.

Never claim you've validated the system for the customer's use.

You can provide validation support documentation. The customer performs and owns the validation.

A well-written statement shows the pharma quality team that you understand the shared responsibility model.

Example structure

Start with a brief introduction explaining that Part 11 applies to the customer's use of the system and that this statement describes the technical controls the product provides.

Then address each major control area in a separate section.

Audit trail. Describe what the system logs, how it's secured, whether you can disable it, and what format the customer can export it in.

Access control. Describe user account management, role-based access, password policies, and session management.

Electronic signatures (if applicable). Describe how you capture signatures, what information they include, and how they link to records.

Record copies. Describe how the system produces readable copies and what formats are available.

Change control. Describe your release process, how you classify changes, what documentation you provide, and how you notify customers.

Validation support. List the documents you provide and clarify that the customer owns the validation conclusion.

End with a clear statement of shared responsibility. You provide the technical controls and the documentation. The customer configures the system, writes the SOPs, performs the validation, and owns the compliance outcome.

Frequently asked questions

What does 21 CFR Part 11 mean?

21 CFR Part 11 is an FDA regulation that defines the controls needed for trustworthy electronic records and electronic signatures when a predicate rule (such as GLP, GCP, or GMP) requires those records. In practice, it sets expectations for things like audit trails, access controls, and signature-to-record linkage.

Who is required to follow 21 CFR Part 11?

The FDA-regulated company that creates, modifies, maintains, or transmits required electronic records is responsible for Part 11 compliance. Software vendors typically support their customers with product controls and documentation, but the regulated firm owns the compliance outcome.

What does 21 CFR stand for?

21 CFR stands for Title 21 of the Code of Federal Regulations. It is the set of U.S. federal regulations related to food and drugs, including FDA requirements for regulated industries.

What is a 21 CFR Part 11 compliance checklist?

A 21 CFR Part 11 compliance checklist is a structured way to confirm the needed controls exist for regulated electronic records and signatures. It is commonly used in supplier questionnaires and audits to verify items like audit trails, access control, and signature requirements.

What evidence should a software vendor provide to support a customer's Part 11 audit?

Provide audit-ready documentation that shows how you design, build, test, and release the system, plus objective evidence for key controls.

Access control configuration options and audit trail outputs, for example. Quality teams typically want artifacts they can review quickly.

How should we handle Part 11 expectations when we ship frequent SaaS releases?

Use a risk-based release classification model.

Patch, minor, major, emergency, for example. Produce consistent release notes with a clear summary of changes. This helps customers assess validation impact without forcing a heavyweight package for every weekly deployment.

If a customer asks for a Part 11 statement, what should we include to avoid overcommitting?

Include a clear scope, list the specific technical controls your product supports, and state what depends on the customer's configuration and procedures.

Keep it precise and bounded so it reads like an engineering and quality position.

Prepare for Part 11 questions before they arrive

The vendors who handle Part 11 well prepare before the questionnaire arrives. They have the documentation ready, the Part 11 statement written, and the validation support package built before the first customer asks.

This week, map each question in the customer's questionnaire to a document you already have, and list the ones you don't.

If you're selling into pharma and biotech and you haven't prepared for this, get a Part 11 readiness assessment to see where the gaps are. Cycore works as an embedded team alongside software vendors. We build the procedures, prepare the validation packages, and sit beside you during the audit. Cancel anytime. If you're not saving 100+ hours, you don't pay.

Talk to an expert and get your Part 11 documentation ready before your next customer asks for it.