What Makes an E-Signature Platform FDA Compliant? The Complete Technical Checklist

Every e-signature vendor in life sciences calls their product "FDA compliant." It's on their homepage, their sales deck, and the first line of their security page. But FDA doesn't issue compliance certifications. There's no badge, no audit, no approval letter. Every vendor who makes that claim is self-certifying. And most buyers have no idea what the claim actually requires them to verify before they go live.

This guide explains what "FDA compliant" means for an e-signature platform in technical terms — not marketing language. We'll walk through Part 11 Subpart B and Subpart C, what FDA looks for during inspections, why claiming compliance and being verifiably compliant are two very different things, and what a genuinely compliant platform has to do at the code level. At the end, there's a technical checklist you can run against any vendor.

What "FDA Compliant" Actually Means

21 CFR Part 11, promulgated in 1997, is the regulation that lets FDA accept electronic records and electronic signatures as equivalent to paper records and handwritten signatures. It applies whenever a predicate rule — meaning any other FDA regulation — requires a record and you keep that record electronically.

The regulation has three subparts. Subpart A defines scope and terms. Subpart B defines what electronic record systems must do. Subpart C defines what electronic signatures must do. When someone calls their platform "FDA compliant for e-signatures," they're claiming both Subpart B and Subpart C are satisfied. Many meet neither, or only satisfy part of one.

The 2003 FDA guidance on Part 11 scope and application took a risk-based approach to enforcement, narrowing which Subpart B records controls FDA would actively enforce. But Subpart C was never narrowed. The signature requirements — two-component identification, signature manifestation, non-repudiation certification — remain fully in effect. And with the 2024 final guidance on electronic systems in clinical investigations, FDA has moved back toward fuller enforcement of Subpart B controls for clinical trial records specifically.

Subpart B: What Electronic Record Systems Must Do

Section 11.10 lists the controls required for closed systems — which is what most FDA-regulated organizations use. A closed system is one where access is controlled by the persons responsible for the records. That covers virtually every SaaS e-signature platform where the vendor manages access controls on behalf of the customer.

The 11 controls under Section 11.10 are:

Validation (11.10(a))

Systems must be validated "to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records." This isn't a one-time activity — it means the vendor must have IQ/OQ/PQ documentation, and you as the regulated organization must have your own validation protocols that include the e-signature platform. FDA's CSA guidance, finalized in September 2025, provides a risk-based approach to validation effort, but doesn't eliminate the requirement. If your vendor can't give you vendor-supplied validation documentation that maps functions to Part 11 requirements, that's a gap.

Audit Trails (11.10(e))

This is the most-cited and most-failed requirement in FDA 483 observations. The system must use "secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records."

Four words in that sentence carry huge compliance weight:

• Secure — the audit trail must be protected from modification. Not just by access controls, but architecturally. SHA-256 cryptographic hash chains are the current standard for making audit trail tampering detectable. Without them, a database administrator could modify an audit entry and no one would know.
• Computer-generated — the system generates the entry, not the user. A user cannot edit the timestamp or the recorded action.
• Time-stamped — every entry needs a system-controlled timestamp, not a client-side timestamp that users can manipulate.
• Independently — the audit trail is separate from the record itself. Deleting the record doesn't delete the audit trail.

The audit trail must be retained for as long as the record it covers, must be available for review during that entire retention period, and must be readable (not just binary or encoded in a format requiring special software to interpret).

Access Controls and Unique Credentials (11.10(d), (g))

The system must limit access to authorized individuals. Each user must have a unique identifier that cannot be shared. Systems must use "authority checks" to verify that the person attempting to access or sign has the authority to do so. If the system allows shared logins, shared passwords, or a single generic account for multiple users, it fails Subpart B.

Record Protection (11.10(c))

Signed records must be protected from unauthorized modification, browsing, or deletion. This means records must be stored in a format that prevents post-signature alteration. Storing signed documents as writable PDFs with no tamper-evidence seal is a Subpart B failure. Storing them in a system where the record can be overwritten after signing is worse.

Operational System Checks and Device Checks (11.10(f), (h))

The system must enforce sequencing of steps where required, and device checks must confirm the validity of input sources. In e-signature workflows this typically means the signing sequence can't be bypassed, and signature fields can't be pre-populated by an unauthorized source.

Subpart C: Electronic Signature Requirements

Subpart C has three sections, and all three must be met for an electronic signature to be legally equivalent to a handwritten signature under Part 11.

General Requirements (11.100)

Each electronic signature must be unique to one individual. Signatures cannot be reused by or reassigned to others. Before using electronic signatures on FDA-required records, organizations must certify in writing to FDA — at 1 Center Drive, Rockville MD 20850 — that their electronic signatures are the legally binding equivalents of traditional handwritten signatures. This is the non-repudiation letter. FDA's 2024 guidance confirmed that one letter per organization is sufficient to cover all studies. But if you've never sent this letter, your electronic signatures aren't compliant, regardless of what your platform does.

Electronic Signature Components and Controls (11.200)

Non-biometric electronic signatures — meaning the username/password/2FA type that virtually all regulated organizations use — must employ at least two distinct identification components. These must be used together for a single signing event, but can be used sequentially for continued use during a single session if the system is designed to protect against misuse.

The two-component requirement is not just "log in once and stay logged in." For signing events specifically, Part 11 expects the authentication to happen at the moment of signing. A platform that lets you authenticate once when you open the application and then sign 50 documents over the next four hours without re-authenticating at each signature is arguably not meeting 11.200(a)(1). This is an area where FDA's 2024 clinical investigations guidance introduced specific expectations: authentication at signing is required for high-risk signature events in clinical trials.

Signature Manifestations (11.50)

Signed electronic records must display specific information with the signature. Section 11.50 requires: the printed name of the signer, the date and time the signature was executed, and the meaning associated with the signature (approval, review, responsibility, or authorship).

Platforms that capture a signature but don't embed meaning into the record — or that allow "meaning" to be left blank — fail this requirement. If the PDF you download after signing doesn't show the signer's name, timestamp with time zone, and the specific reason they signed, the platform isn't meeting 11.50.

Signature-to-Record Linking (11.70)

Electronic signatures must be linked to their respective electronic records to ensure that signatures cannot be excised, copied, or otherwise transferred to falsify another document. This is typically achieved through cryptographic binding — the signature is mathematically tied to the content of the document at the time of signing, and any modification to the document after signing breaks the binding.

Closed vs. Open Systems: Why It Matters for SaaS

When regulated organizations moved to SaaS platforms, FDA had to address whether those systems were "closed" under Part 11. A closed system, under 11.3(b)(4), is an environment where access is controlled by persons responsible for the content of electronic records. An open system is one where such control is not exercised — like the public internet.

Most SaaS e-signature platforms are closed systems because the regulated organization controls who has access through user management. But open system controls (11.30) add requirements for additional security including encryption and digital signatures to ensure authenticity and confidentiality. If your platform has any pathway for external parties to access records that aren't under your direct access control, you may be in open system territory and need to confirm the platform meets 11.30, not just 11.10.

The 2024 FDA guidance on clinical investigations specifically addressed cloud and SaaS systems. It confirmed that Part 11 applies to cloud platforms, and that sponsors remain responsible for validating those platforms even when they don't control the physical infrastructure. Vendor-supplied validation documentation doesn't replace your own qualification — it supplements it.

What FDA Investigators Actually Check

During a data integrity inspection focused on electronic signatures and electronic records, FDA investigators typically request:

• Audit trail exports — filtered by date range and by specific record or user. Can your platform export the audit trail in a human-readable format in under 30 minutes? If it takes days or requires vendor assistance, that's a problem inspectors notice.
• User access logs — including failed login attempts and administrator actions. Administrator actions must be in the audit trail. If admins can make configuration changes without leaving an audit entry, that's a common 483 finding.
• Validation documentation — IQ/OQ/PQ protocols, executed test scripts, and the traceability matrix mapping system functions to Part 11 requirements. If you can't produce this on day one of the inspection, you've already lost the opening argument.
• Signature manifestation examples — investigators will pull 2-3 signed records from the system and verify that the name, timestamp, and meaning appear correctly. They'll also check that the timestamp is in UTC or a specified time zone with offset shown.
• User account management records — who has access, what their roles are, when accounts were created or revoked, and whether any terminated employees still have active credentials.
• The SOP for periodic audit trail review — and evidence that reviews were completed per that SOP. If your SOP says quarterly reviews and there are six months with no review record, investigators will note it.

Claiming Compliance vs. Being Verifiably Compliant

The difference comes down to documentation and architecture. A vendor that claims FDA compliance but can't provide validation documentation, can't show you a hash-chained audit trail, and doesn't require authentication at signing is marketing, not compliance.

Verifiable compliance means:

• Validation documentation exists and is yours to keep — not locked in the vendor's portal, not available only if you pay for a "validation package" add-on. IQ/OQ/PQ protocols, traceability matrices, and executed test scripts should be part of what you receive when you start using the platform.
• The audit trail is hash-chained — SHA-256 (or stronger) cryptographic chain means any modification to a historical audit entry breaks the chain and the discrepancy is detectable. Without this, your audit trail's "security" is just an access control that a DBA can bypass.
• Authentication happens at signing, not just at login — 2FA at the moment a signature is applied, not 2FA once when you opened the platform two hours ago. This is the technical implementation of 11.200's two-component requirement as it applies to individual signing events.
• Signature meaning is captured and embedded — the reason the person signed (Approved, Reviewed, Authored, etc.) is captured at signing and embedded in the record. It can't be changed after the fact.
• Records are tamper-evident after signing — cryptographic binding ties the signature to the document hash at signing. If one pixel of the document changes after the signature is applied, the binding breaks and the platform detects it. This satisfies 11.70 and is the standard that FDA's 2024 guidance implicitly expects.

IQ/OQ/PQ and Why It's Not Optional

Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ) are the three stages of system qualification under FDA's validation frameworks. Under the newer Computer Software Assurance (CSA) guidance, these stages have been reframed as "intended use" and "confidence level" driven, but the underlying concept is the same: you must test that the system does what you need it to do, document those tests, and keep the documentation available for inspection.

IQ confirms the system was installed correctly in your environment. OQ tests that the system functions as specified. PQ confirms it performs correctly in actual use conditions. For an e-signature platform, OQ testing would include verifying that the audit trail captures the correct fields, that 2FA is enforced at signing, that signature manifestation appears correctly on the completed record, and that the audit trail can't be modified without detection.

Purpose-built Part 11 platforms typically provide vendor-supplied documentation that significantly reduces your OQ burden — pre-written test scripts that verify the platform's compliance controls, traceability matrices, and summary validation reports. General-purpose e-signature tools rarely provide any of this. You'd be writing test scripts from scratch and running them yourself, with no guarantee the vendor's platform was even designed with these tests in mind.

The Technical Checklist: 14 Questions for Any Vendor

Before signing a contract with any e-signature platform for regulated use, ask these questions and require written answers:

1. Does the audit trail use SHA-256 cryptographic hash chains? How would your system detect if an audit entry was modified directly in the database?
2. Is 2FA enforced at the moment of signing, or only at login? Can a user authenticate once and then sign multiple documents hours later without re-authenticating?
3. What signature meaning options are available? How is meaning captured in the audit record and embedded in the signed document?
4. Are signed records cryptographically bound to the document content? Can your system detect if a document was modified after signing?
5. Do administrator actions appear in the audit trail? If an admin changes user permissions, deletes a document, or modifies system settings, is that in the audit trail?
6. What validation documentation do you provide? Can I receive IQ/OQ/PQ protocols, executed test scripts, and a Part 11 traceability matrix as part of my subscription?
7. Can I export the full audit trail in a human-readable format on demand?How long does it take? Does it require vendor assistance?
8. What is the audit trail retention period? Is it at least as long as the retention period for the records it covers? Can I configure it for 25-year retention for EU CTR records?
9. How are timestamps generated? Are they server-side with NTP sync? Are RFC 3161 trusted timestamps available for records requiring non-repudiation?
10. What happens when a user's employment terminates? How quickly can their access be revoked? Can historical records signed by that user still be accessed?
11. Is the system validated under your own quality management system? Can you provide evidence of your own internal validation activities for the platform?
12. Does the signature manifestation on the signed record include the time zone?Is the time zone offset displayed on the completed document?
13. What security certifications does the platform hold? SOC 2 Type II is the minimum for a SaaS platform handling regulated data. ISO 27001 is a plus.
14. Has the platform ever been used in an FDA inspection? If so, were there any Part 11-related 483 observations attributed to the platform's functionality?

A vendor who hesitates on questions 1, 2, 4, 5, or 6 is telling you something important. Those five questions cover the most commonly failed Part 11 requirements — and they're the ones inspectors check first.

Where General-Purpose Tools Fall Short

The most popular general-purpose e-signature tools were designed for commercial contracts, HR documents, and real estate closings. They had Part 11 compliance bolted on later — usually as a paid add-on module. The architecture wasn't designed for regulated use.

The gaps that typically appear when general-purpose tools are forced into regulated workflows:

• No authentication at signing — you log in once and stay logged in. The "electronic signature" is applied with a single click, with no re-authentication at the moment you sign. This is the most common Part 11 gap in commercial platforms.
• No signature meaning — you sign, but the record doesn't capture whether you were approving, reviewing, or authoring. The audit trail shows "document signed" without the regulatory-required meaning component.
• Audit trail that users can influence — platforms designed for general use sometimes allow document owners to delete records or modify metadata that appears in the audit trail. None of that should be possible for regulated records.
• No validation documentation — when you ask for IQ/OQ/PQ documentation, the answer is "we're SOC 2 certified." SOC 2 is a security certification, not a validation of compliance functionality under 21 CFR Part 11.
• Retention limits incompatible with predicate rule requirements — a general-purpose platform might retain records for 5 or 7 years by default. EU CTR 536/2014 Article 58 requires 25 years. You may have to fight the vendor to get even close to that.

What a Purpose-Built Platform Looks Like

A platform designed for regulated use embeds the compliance controls into the core architecture, not onto the surface. The difference shows up in three places:

At the signing event: The signer re-authenticates with their password and a second factor (TOTP or similar). The system captures: who signed, when (server-side timestamp), from which IP address and device, what they signed, and why (signature meaning). All of that goes into an immutable audit entry with a SHA-256 hash linking it to the previous entry in the chain.

In the document: The completed record shows the signer's full name, the timestamp with time zone, and the specific signature meaning they selected. The document is cryptographically bound — if the content changes after signing, the binding breaks and the system flags it.

In the audit trail: Every action — from document creation to field placement to signing to download — is logged with who, when, what, and any previous values. Administrator actions are logged identically to user actions. The chain is verifiable: you can run a hash verification against the stored entries to confirm no entry has been modified since it was written.

That's what "FDA compliant" should actually mean when an e-signature vendor uses the phrase. If their documentation, demo, and technical responses back up those three areas, you're on solid ground. If they can't demonstrate those three points with specifics, the compliance claim is a marketing statement, not a technical reality.

See the Certivo compliance page for how Certivo satisfies each Part 11 requirement technically, or read the complete Part 11 guide for a deeper walkthrough of all three subparts. The free Part 11 compliance checklist maps every Subpart B and Subpart C requirement to specific implementation controls.

For a side-by-side look at how purpose-built platforms compare to general-purpose tools with compliance add-ons, see FDA inspection readiness and audit trail requirements and the ALCOA+ audit trail software requirements guide.