21 CFR Part 11 Software Validation Checklist

21 CFR Part 11 does not provide a universal certificate that makes software “FDA compliant.” Section 11.10(a) addresses validation of closed systems for accuracy, reliability, consistent intended performance, and detection of invalid or altered records. FDA's 2003 Scope and Application guidance, however, describes enforcement discretion for specific Part 11 validation provisions and recommends a justified, risk-based approach that also considers predicate rules, record integrity, product quality, and safety.

This checklist is therefore a practical risk-assessment and validation framework, not a claim that every SaaS tool requires the same validation package. For the broader regulatory context, start with our FDA 21 CFR Part 11 electronic signatures guide.

1. Confirm that Part 11 applies

Begin with the record, not the application. Identify the FDA predicate rule that requires the record to be created, maintained, submitted, or retained. Then determine whether the electronic record is being used in place of a required paper record or relied on to perform a regulated activity.

Document:

• the regulated process and predicate rule;
• the official record and its retention period;
• the system of record;
• whether an electronic signature is used;
• connected systems that create, transform, transmit, or archive the record.

This scope assessment prevents two common failures: validating every business tool without regard to risk, or overlooking an integration that materially changes the regulated record.

2. Define intended use and system boundaries

Validation should show that the system performs consistently for its intended use. Write that intended use in operational terms: who uses the system, which records it handles, which decisions it supports, and what must happen when a transaction fails.

Map the complete workflow, including:

• identity and access management;
• document or form creation;
• review and approval sequence;
• signature execution;
• audit-trail generation;
• API calls and status callbacks;
• storage, retrieval, export, and retention;
• administrative configuration and change management.

A cloud service may be supplied by a vendor, but the regulated organisation still owns its intended-use decision, configuration, procedures, and validation evidence. The access boundary should also be documented using the practical distinction between open and closed systems under 21 CFR Part 11.

3. Build traceable requirements

Translate regulatory and business needs into testable requirements. Each requirement should have an owner, risk rating, acceptance criterion, and evidence location.

At minimum, evaluate:

• accuracy and consistent intended performance;
• detection of invalid or altered records;
• accurate and complete human-readable and electronic copies;
• authorised access and authority checks;
• time-stamped audit trails;
• signature manifestation and signature-to-record linking;
• operational sequencing;
• record retention and retrieval;
• credential management and account deactivation;
• backup, recovery, and business continuity.

Create a traceability matrix linking requirements to risks, test cases, results, deviations, and approvals. This is more useful during an inspection than a generic vendor feature list.

4. Apply a risk-based testing strategy

Not every function requires the same testing depth. Prioritise functions that could affect product quality, patient safety, data integrity, or the reliability of a regulatory decision.

Test normal, negative, and boundary conditions. Examples include:

• an unauthorised user attempts to sign;
• a signer uses an expired or disabled account;
• a required signing reason is omitted;
• the signing sequence is broken;
• a record is amended after approval;
• an integration retries or duplicates a request;
• the network fails during signing;
• an archived record and its audit evidence are restored;
• timestamps are viewed across time zones;
• an administrator changes a workflow or permission.

Record expected results before execution. Investigate deviations and document their disposition rather than editing test evidence to make it appear successful.

5. Verify electronic-signature controls

Where electronic signatures are used, test the controls in Subpart C as they apply to the implementation. This includes unique signature ownership, identity verification before assignment, signature components, credential controls, and protection against unauthorised use.

Also verify that each signed record displays the signer’s printed name, signing date and time, and meaning of the signature, and that the signature remains linked to the corresponding record. See the detailed guide to electronic signature identity and record-linking requirements.

6. Assess vendor and cloud-service evidence

Supplier documentation can reduce duplicated work, but it does not replace customer validation. Review:

• product architecture and security documentation;
• release and change-control practices;
• test summaries and known limitations;
• service availability and incident processes;
• data location, subprocessors, and retention options;
• export formats and migration support;
• audit-log coverage;
• integration and API documentation.

Decide which supplier evidence you can rely on and which tests must be performed in your configured environment.

7. Approve, operate, and revalidate

Validation is not complete when testing ends. Before production use, approve the validation report, unresolved-risk assessment, operating procedures, training, access model, and support process.

After go-live, control:

• releases and configuration changes;
• new integrations and document types;
• user-role changes;
• audit-trail review;
• incidents, deviations, and corrective actions;
• periodic review;
• backup and restoration testing;
• retirement and record migration.

Revalidation should be triggered by risk-relevant changes, not by an arbitrary calendar alone.

How eSign.AI supports a validated workflow

eSign.AI supports electronic and digital signature workflows with configurable signer authentication, signing order, signature-event capture, audit evidence, document status, and business-system integration. These capabilities can form part of a regulated organisation’s control framework.

The customer remains responsible for determining Part 11 applicability; deciding, from predicate rules and a documented risk assessment, whether and to what extent validation is warranted; maintaining procedures and training; and confirming that the complete process satisfies applicable requirements.

Sources and further reading

• 21 CFR Part 11 — Electronic Records; Electronic Signatures
• FDA Guidance: Part 11, Electronic Records; Electronic Signatures — Scope and Application