21 CFR Part 11 E-Signature Vendor Selection Checklist: RFP Template & Evaluation Criteria

Selecting an e-signature vendor for FDA 21 CFR Part 11 compliance is one of the highest-stakes procurement decisions a life sciences organization will make. The wrong choice leads to costly remediation, SOP workarounds, validation rework, and in the worst case, regulatory citations that delay product approvals. A structured evaluation process built around the specific technical and procedural requirements of Part 11 eliminates guesswork and ensures that every vendor is assessed against the same objective criteria.

Why a Structured Vendor Evaluation Matters

Most vendor evaluation failures in regulated industries share the same root cause: the evaluation was driven by feature demos and pricing negotiations rather than by the specific requirements of the applicable regulations. The platform passes the demo. The contract is signed. Then, during IQ/OQ/PQ validation, the quality team discovers that the audit trail is a simple database log without tamper evidence, that two-factor authentication is only enforced at login, or that signature meaning is an optional metadata field. At that point, the organization faces expensive remediation or an even more expensive re-procurement.

Organizing the evaluation around the specific sections of FDA 21 CFR Part 11 ensures that every vendor is assessed against regulation-referenced criteria before the contract is signed, not after.

How to Use This Checklist

This checklist is organized into six sections that map to the structure of 21 CFR Part 11 and the broader compliance considerations for life sciences. Each section contains specific, actionable evaluation criteria with references to the applicable regulation sections.

To use this as an RFP template: copy the checklist items into your vendor questionnaire and ask each vendor to respond to every item with a description of how their platform addresses the requirement. To use it for internal scoring: assign weights to each section based on your organization's risk profile and score each vendor on a consistent scale. The scoring framework in Section 6 provides a starting template.

Section 1: Electronic Signature Requirements (Subpart C)

Subpart C of Part 11 defines what constitutes a valid electronic signature. These are non-negotiable requirements; if a vendor's platform can't satisfy them, it isn't suitable for FDA-regulated use. For a full walkthrough of Subpart C, see our complete Part 11 guide.

Signature Manifestations (Section 11.50)

Section 11.50 requires that every signed electronic record clearly display the printed name of the signer, the date and time when the signature was executed, and the meaning associated with the signature (such as "approval," "review," "authorship," or "responsibility").

• Does the platform capture and display the signer's full printed name on every signed record?
• Does the signature include a system-generated date and time stamp (not the signer's local clock)?
• Does the platform require the signer to select a signature meaning (e.g., approval, review, authorship) at the point of signing?
• Is all signature manifestation information included in the human-readable form of the record (PDF, printout, on-screen display)?
• Can the signature meaning options be configured to match your organization's SOPs and workflow types?

Signature/Record Linking (Section 11.70)

Section 11.70 requires that electronic signatures be linked to their respective records so that signatures can't be excised, copied, or transferred to falsify a record.

• Is each electronic signature cryptographically bound to the specific version of the record that was signed (e.g., via document hash)?
• Can a signature be detached from one record and reattached to another? (The answer must be no.)
• Does the platform make signed records immutable, preventing any modification after signing?
• If a signed record is modified, does the system invalidate the existing signature and require re-signing?
• Does the system use cryptographic hashing (e.g., SHA-256) to bind signatures to record content, enabling independent verification?

Non-Biometric Signature Controls (Section 11.200)

Section 11.200 requires that non-biometric electronic signatures employ at least two distinct identification components. Section 11.200(a)(2) requires that signatures be used only by their genuine owners, preventing one individual from using another's credentials to sign. Modern regulatory expectations, reinforced by FDA, EMA, and MHRA data integrity guidance, extend these requirements to include multi-factor authentication at the point of signing.

• Does the platform require at least two distinct identification components (e.g., user ID + password) for every signing event?
• Is a second authentication factor (e.g., TOTP code from an authenticator app) enforced at the point of signing, not just at login?
• For consecutive signings within a single controlled session, does the platform enforce at least one identification component per subsequent signing, per Section 11.200(a)(1)(i)?
• Does the system enforce that each electronic signature is used only by its genuine owner, per Section 11.200(a)(2)?
• Does the system prevent re-use of authentication tokens or codes across signing events?

Controls for Identification Codes/Passwords (Section 11.300)

Section 11.300 governs the controls for identification codes and passwords that underpin electronic signatures. These controls ensure that the authentication mechanisms remain secure and that compromised credentials are handled promptly.

• Does the system enforce password complexity requirements (minimum length, character types)?
• Does the system enforce periodic password changes on a configurable schedule?
• Does the system maintain a password history to prevent reuse of recent passwords?
• Are procedures in place to immediately deauthorize lost, stolen, or compromised credentials?
• Does the system lock accounts after a defined number of failed authentication attempts?
• Is each user ID unique and never reassigned to another individual?

Section 2: Electronic Record Controls (Subpart B)

Subpart B defines the technical and procedural controls that must be applied to electronic records. These requirements are addressed primarily in Section 11.10 for closed systems. For a detailed treatment of audit trails specifically, see our guide on audit trails in regulated industries.

Audit Trails (Section 11.10(e))

Audit trail deficiencies are the most frequently cited Part 11 finding in FDA 483 observations. Your evaluation must go beyond "does the vendor have an audit trail" to examine the specific characteristics that regulators scrutinize.

Access Controls (Section 11.10(d))

• Does the platform enforce role-based access control (RBAC) with granular permission levels (e.g., view, sign, approve, administer)?
• Is each user account unique to a single individual, with no shared or generic accounts?
• Does the system enforce session timeouts after a defined period of inactivity?
• Does the system limit concurrent sessions per user to prevent credential sharing?
• Are administrative actions (user creation, role changes, permission modifications) logged in the audit trail?
• Can the system enforce the principle of least privilege, ensuring users only have access to functions required for their role?

System Validation (Section 11.10(a))

Part 11 requires that systems be validated to ensure accuracy, reliability, consistent intended performance, and the ability to detect invalid or altered records. Validation is a shared responsibility between the vendor and the customer, but the vendor's support determines the effort required on your end. For the broader validation context, see our GxP compliance guide.

• Does the vendor provide validation documentation packages (IQ/OQ/PQ protocols, test scripts, expected results)?
• Does the vendor provide a requirements traceability matrix linking system features to Part 11 requirements?
• Does the vendor maintain a controlled change management process with documented release notes?
• Does the vendor notify customers in advance of system changes that could affect validated state?
• Does the vendor provide updated validation documentation when significant changes are released?
• Is there a system design specification or functional specification document available for review?

Record Integrity and Protection (Section 11.10(c))

• Are records protected from unauthorized modification, deletion, or destruction throughout their retention period?
• Does the system use cryptographic hashing to verify record integrity and detect unauthorized changes?
• Can the system generate accurate and complete copies of records in both human-readable and electronic form for FDA inspection, per Section 11.10(b)?
• Are records stored in non-proprietary formats (e.g., PDF) that remain accessible independent of the vendor's software?

Operational Checks and Authority Verification (Sections 11.10(f) and 11.10(g))

• Does the system enforce workflow sequencing, preventing steps from being executed out of order (e.g., approval before review)?
• Does the system verify that the person attempting to sign has the authority to do so for that specific document type and workflow step?
• Can the system prevent a single individual from both authoring and approving the same record (separation of duties)?

Training (Section 11.10(i))

• Does the platform include a mechanism to track and document user training acknowledgment?
• Can the system enforce training completion before granting access to signing functions?
• Are training records maintained as part of the system's audit trail?

Section 3: Security and Authentication

While Part 11 establishes the regulatory baseline, modern security expectations (driven by NIST guidelines, industry best practices, and data integrity guidance from FDA, EMA, and MHRA) go further. Evaluate vendors against both the regulatory minimum and current best practices.

Multi-Factor Authentication

• Is MFA enforced at the point of signing (not just at login)?
• What MFA methods are supported (TOTP authenticator app, hardware token, biometric)?
• Is MFA mandatory or optional? Can administrators enforce MFA policy across all users?
• Does the system support MFA for external signers (individuals without a permanent system account)?

Password and Session Policies

• Can the organization configure minimum password length and complexity requirements?
• Does the system enforce password expiration on a configurable schedule?
• Does the system prevent password reuse by maintaining a password history (minimum 5 prior passwords)?
• Does the system lock accounts after a configurable number of consecutive failed login attempts?
• Does the system enforce automatic session timeout after a configurable period of inactivity?
• Does the system limit the number of concurrent sessions per user?
• Are session termination events logged in the audit trail with the reason (inactivity, max duration, logout, admin termination)?

Encryption

• Is data encrypted in transit using TLS 1.2 or higher?
• Is data encrypted at rest using AES-256 or equivalent?
• Are encryption keys managed using a dedicated key management service (e.g., AWS KMS, Azure Key Vault)?

Section 4: Infrastructure and Compliance

The vendor's infrastructure and compliance posture directly affect your ability to maintain a validated, inspection-ready system. These items are especially important for organizations handling protected health information or data subject to cross-border transfer requirements.

Hosting and Certifications

• Is the platform hosted on HIPAA-eligible infrastructure (e.g., AWS, Azure, GCP with BAA)?
• Does the vendor hold SOC 2 Type II certification?
• Does the vendor hold ISO 27001 certification or equivalent?
• What cloud provider and region(s) are used? Does the vendor offer data residency options for organizations with geographic data requirements?

Business Associate Agreement and Privacy

If your organization handles any data that could constitute protected health information (PHI), HIPAA compliance requires a BAA with every vendor that processes, stores, or transmits that data.

• Is the vendor willing and able to sign a BAA?
• Does the BAA cover all subprocessors (hosting provider, email service, etc.)?
• For EU data: Does the vendor offer a Data Processing Agreement (DPA) and comply with GDPR transfer mechanisms?

Backup, Disaster Recovery, and SLA

• What is the vendor's backup frequency and retention policy?
• What is the Recovery Time Objective (RTO) and Recovery Point Objective (RPO)?
• Does the vendor provide a guaranteed uptime SLA (99.9% or higher)?
• Is there a published incident response procedure?
• What happens to your data if the vendor goes out of business or you terminate the contract?

Section 5: Vendor Qualification

A platform can have every technical feature and still be a poor choice if the vendor can't support you through validation, change management, and regulatory inspections. These qualification criteria assess the vendor as a long-term partner, not just a software provider. For a broader perspective on what separates regulated-industry platforms from general-purpose tools, see our buyer's guide for life sciences e-signature platforms.

Validation Documentation

• Does the vendor provide IQ/OQ/PQ protocol templates that can be adapted to your quality system?
• Does the vendor provide a regulatory traceability matrix mapping platform features to Part 11 sections?
• Does the vendor provide release notes and change impact assessments for every update?
• Is a system design specification or architecture document available under NDA?

Change Notification and Expertise

• Does the vendor provide advance written notification (minimum 30 days) before deploying changes that could affect validated state?
• Does the vendor categorize changes by impact level (major, minor, patch) with clear criteria for each?
• Can you opt to delay updates to maintain your current validated state during critical periods?
• Does the vendor's team include personnel with direct experience in FDA-regulated environments (pharma, biotech, medical devices)?
• Can the vendor support you during a regulatory inspection (provide documentation, answer technical questions from investigators)?
• Can the vendor provide references from current customers in FDA-regulated industries whose systems have passed FDA inspection?

Section 6: Scoring Framework

A quantitative scoring framework keeps vendor selection from becoming a subjective exercise. The following table provides recommended weights for each evaluation area. Adjust the weights based on your organization's specific risk profile, regulatory exposure, and operational priorities.

To illustrate: if Vendor A scores 1.8 on signature compliance (weight 25%), 1.5 on record controls (25%), 1.6 on security (15%), 1.4 on infrastructure (15%), 1.2 on vendor qualification (10%), and 1.7 on cost (10%), the weighted score is (1.8 x 0.25) + (1.5 x 0.25) + (1.6 x 0.15) + (1.4 x 0.15) + (1.2 x 0.10) + (1.7 x 0.10) = 0.45 + 0.375 + 0.24 + 0.21 + 0.12 + 0.17 = 1.565. Compare this composite against other vendors evaluated with the same framework.

Red Flags to Watch For

During the evaluation process, certain signals should raise immediate concern. Any of the following should prompt significant scrutiny or disqualification:

• "We are Part 11 compliant" — No vendor can be Part 11 compliant on your behalf. Part 11 compliance is achieved through a combination of the software's capabilities, your configuration, your SOPs, your validation, and your training program. A vendor that claims blanket compliance either misunderstands the regulation or is being deliberately misleading. The correct claim is: "Our platform provides the technical controls that support Part 11 compliance."
• No tamper-evident audit trail. If the vendor's audit trail is a simple database log without cryptographic integrity protection, it can be modified by database administrators without detection. This can't be fixed with SOPs.
• Login-only two-factor authentication is another disqualifier. MFA at login but not at the point of signing leaves a gap: once a user is authenticated, anyone with physical access to their workstation can execute signatures. Signing-time authentication is essential.
• No validation documentation available. A vendor that provides no IQ/OQ protocols, no traceability matrix, and no guidance on validation is shifting the entire validation burden to your quality team. This significantly increases both cost and risk.
• If the vendor can't or won't sign a Business Associate Agreement, they shouldn't be handling any data that might contain PHI. This is a HIPAA requirement, not a preference.
• Proprietary document formats create long-term accessibility risk and vendor lock-in. If signed documents require the vendor's software to view, you can't guarantee access over the 15+ year retention periods common in life sciences.
• No signature meaning capture. If the platform doesn't require the signer to declare the meaning of their signature (approval, review, authorship), it fails a basic Section 11.50 requirement.
• Shared account support is a fundamental problem. If the vendor's system allows or encourages shared user accounts, individual accountability is impossible. This directly violates Sections 11.10(d) and 11.100, and undermines the genuine-owner requirement of Section 11.200(a)(2).

The Bottom Line

Vendor selection for a Part 11 e-signature platform is a regulatory risk management decision. The checklist in this guide provides the specific, regulation-referenced criteria that separate platforms built for regulated use from general-purpose tools with compliance marketing.

Use this checklist as the foundation of your RFP. Score vendors objectively. Disqualify vendors that fail on non-negotiable requirements. And prioritize vendors that reduce your total compliance burden, not just your subscription cost, by providing validation documentation, tamper-evident audit trails, signing-time two-factor authentication, and the regulatory expertise to support you through inspections.

Certivo was purpose-built to meet every requirement in this checklist: SHA-256 hash-chained audit trails with independent RFC 3161 timestamps, TOTP two-factor authentication enforced at the point of signing, signature meaning capture on every signing event, immutable signed records on HIPAA-eligible AWS infrastructure with a BAA available, and training acknowledgment tracking per Section 11.10(i). Explore our compliance documentation, review the security architecture, or see our plans. For deeper coverage, see our guides on FDA 21 CFR Part 11, audit trails in regulated industries, ALCOA+ data integrity, GxP compliance, HIPAA-compliant e-signatures, and our buyer's guide for life sciences.