21 CFR Part 11 is the FDA regulation that defines how electronic records and electronic signatures must be implemented to be considered trustworthy, reliable, and equivalent to paper records. It applies to any software system used to create, modify, maintain, archive, retrieve, or transmit records required by FDA predicate rules.

The regulation was finalized in 1997 when organizations began moving from paper-based systems to electronic ones. Before this shift, laboratory notebooks were handwritten, signatures were ink on paper, and batch records were physical documents. Part 11 established the requirements needed to maintain the same level of integrity and accountability in digital form.

Part 1: When Part 11 applies

Part 11 applies when electronic records substitute for paper records required by FDA regulations. These underlying rules are called predicate rules. If a predicate rule says you must maintain a record or apply a signature, and you do it electronically, Part 11 applies.

Common systems subject to Part 11

• Laboratory information management systems tracking sample testing and results
• Electronic lab notebooks documenting experiments and observations
• Manufacturing execution systems recording batch production
• Quality management systems handling deviations and CAPAs
• Clinical trial data management systems

Not every piece of data in these systems falls under Part 11. Informal calculations, draft documents, and reference materials typically do not. The regulation covers records that document compliance with FDA requirements. Work with quality and regulatory teams to identify which records in your system are regulated.

According to recent FDA data, the agency issued 529 warning letters in 2024, with 8% directed at manufacturers for issues including data integrity concerns. Many of these citations involved inadequate electronic record systems.

Part 2: Core technical requirements

Part 11 establishes requirements in several key areas. Understanding these is fundamental to building compliant software.

What does a Part 11 audit trail require?

Part 11 mandates secure, computer-generated, time-stamped audit trails that independently record who did what, when, and why. This goes beyond standard application logging.

A compliant audit trail captures:

• The original value before any change
• The new value after the change
• Who made the change (unique user identifier)
• Timestamp of the change
• Reason for the change (user must provide this)

The "independently recorded" requirement matters. Users who can modify data cannot modify their own audit trail entries. If someone changes a test result from 5.2 to 5.3, that action gets logged in a way they cannot erase or edit.

Implementation approach: Build audit trails into your data model from the start. Use database triggers, event sourcing patterns, or dedicated audit tables. Retrofitting audit trails typically requires hundreds of consulting hours at $150 to $300 per hour (based on industry estimates), plus internal development costs.

How do electronic signatures work under Part 11?

When someone signs a record electronically in a Part 11 system, that signature must include their printed name, the date and time, and the meaning of the signature (review, approval, authorship).

For non-biometric signatures, Part 11 requires two distinct identification components. Typically this means username (something that identifies you) and password (something you know). Each signature execution requires both components. A user cannot sign by clicking a button while already logged in. They must re-enter credentials at the moment of signing.

The signature becomes part of the record. If you print or export the record later, the signature information must travel with it.

What is computer system validation?

Computer system validation (CSV) is documented evidence that your software performs as intended and meets predetermined specifications. FDA expects this evidence before a system goes into production use. The 2024 State of Validation Report shows that 61% of organizations experienced an increase in validation workload, and nearly half plan to increase validation budgets.

Implementation requirements differ depending on whether your system is classified as closed (§11.10) or open (§11.30) under Part 11. Closed systems have limited access within your organization. Open systems - including most cloud-based and SaaS products - require additional controls for data transmission and identity verification. This distinction affects architecture decisions from day one.

Validation demonstrates that the system consistently meets predetermined specifications and quality requirements.

Validation includes:

• Requirements traceability (linking user needs to system capabilities)
• Design documentation (how the system works)
• Test protocols and results (evidence that features work correctly)
• Traceability matrix (showing every requirement was tested)

Modern validation practices rely on automation. Automated test suites can generate documentation as they run. Requirements management tools link user stories to test cases. The goal is validation that happens continuously rather than as a one-time event before go-live.

The GAMP 5 framework provides risk-based validation guidance. A configurable commercial product requires less validation effort than custom-developed software because the vendor has already validated core functionality. Your validation focuses on configuration and custom extensions.

Part 3: Managing validated systems

How do you maintain validated state?

Once a system is validated and in production, changes require careful management. You cannot simply push updates when ready. Each change must be assessed for impact on validated state.

A regulated change control process includes:

• Impact assessment: does this change affect validated functionality?
• Documentation: what changed, why, who approved it
• Testing: evidence the change works and did not break existing functionality
• Documentation updates: keeping validation packages current
• User training: if workflows changed

This creates friction. A critical bug fix that would take 30 minutes to deploy in a typical SaaS product might take days in a validated environment because of documentation and testing requirements.

For software vendors serving regulated customers, this challenge multiplies. Your customers must validate your software updates before accepting them. When you release a new version, customers need time to assess impact, test in their environment, and update their validation documentation.

A diagnostic lab may face a three-month postponement of a platform upgrade if its validation team is backlogged and the vendor has not provided adequate validation documentation. Even when the upgrade eventually proceeds, both sides lose time and resources.

To prevent situations like this, vendors should adopt a validation-aware release strategy.

Practical approaches for validation-aware releases

• Provide detailed release notes with validation impact assessments
• Separate bug fixes from feature releases so customers can prioritize critical updates
• Offer sandbox environments where customers can test before production deployment
• Maintain backward compatibility to reduce validation burden
• Consider offering long-term support versions that receive only security patches

Vendors who design their release process with validation in mind reduce friction, build trust, and make upgrades predictable rather than disruptive.

Part 4: Practical implementation

Building Part 11 into your architecture

If you design lab software for FDA-regulated customers, build compliance into architecture from the start.

Design immutable audit trails: Use append-only data structures. Consider event sourcing where every state change is an event in an immutable log. This makes audit trails tamper-proof by design rather than by access control alone.

Implement signature workflows with required metadata capture: When a user signs, the system must capture and permanently associate their identity, timestamp, and signature meaning with the signed record. Build forms that require users to select signature meaning from predefined options (Review, Approval, Authorship, Responsibility).

Plan for validation: Write clear, testable requirements. Build automated test suites that can generate validation documentation. Maintain traceability between requirements, code, and tests in your development tools. When an auditor asks how you know feature X works correctly, you should be able to show test evidence quickly.

Structure your release process for change control: Version control is not optional. Your release notes should document what changed, why, and what validation testing you performed. Consider semantic versioning where the version number signals the magnitude of change (major, minor, patch).

Document everything: Auditors will ask for evidence of your development practices, your validation approach, and your change history. Build documentation into your workflow rather than creating it retroactively before audits.

Working with regulated customers

Part 11 compliance is a shared responsibility between software vendor and customer. You provide compliant capabilities. Your customer validates the system for their specific use.

During procurement, regulated customers will ask detailed questions:

• How do you implement audit trails?
• What validation evidence can you provide?
• How do you manage changes to the software?
• Can you provide validation templates or packages?
• What is your release schedule and process?

Having clear answers accelerates sales cycles. Providing validation support packages (test protocols, traceability matrices, validation reports) differentiates you from competitors who expect customers to figure it out themselves.

Be transparent about limitations. If your system does not capture reason for change automatically, document that customers must implement this through procedures. If certain features are not validated, be clear about what those are.

For more on building compliant lab systems, see our article on HIPAA Compliance for Lab Software.

Conclusion

Part 11 requires proving your software is trustworthy through audit trails, validated electronic signatures, and documented validation evidence. Build these capabilities into your architecture from the start. Audit trails cannot be retrofitted easily. Validation requires upfront planning. Change control affects how you release updates. Companies that treat Part 11 as a design constraint rather than a compliance checklist build better software and move faster than those who bolt it on later.

Planning a LIMS or lab software project? Part 11 requirements affect architecture decisions from day one. We help pharmaceutical and biotech companies design validation-ready systems that pass FDA scrutiny. Let us discuss your requirements.

References

• 21 CFR Part 11: Electronic Records; Electronic Signatures - Code of Federal Regulations
• Guidance for Industry: Part 11, Electronic Records; Electronic Signatures - Scope and Application - FDA
• General Principles of Software Validation - FDA Guidance

Frequently asked questions

When does 21 CFR Part 11 apply to my software?

Part 11 applies when your software creates, modifies, maintains, or transmits electronic records required by FDA predicate rules. If a healthcare organization, pharmaceutical company, or medical device manufacturer uses your system to maintain records required by FDA regulations, Part 11 likely applies.

What are the audit trail requirements for Part 11?

Part 11 audit trails must capture the original value, new value, who made the change, when, and why. The audit trail must be independently recorded (users cannot alter their own audit entries), tamper-evident, and retained as long as the records they document.

What is the difference between 21 CFR Part 11 and EU Annex 11?

Both regulations govern electronic records in pharmaceutical contexts. Part 11 is the FDA regulation for the United States. EU Annex 11 is the European Medicines Agency guidance for the European Union. They have similar requirements but different enforcement frameworks. Many companies must comply with both.

Do SaaS products need to comply with 21 CFR Part 11?

Yes, if your SaaS product handles electronic records required by FDA regulations. Cloud-based systems are not exempt from Part 11. You need the same audit trails, electronic signature controls, and validation as on-premises systems.

What is computer system validation?

Computer system validation (CSV) is documented evidence that software performs as intended and meets predetermined specifications. It includes requirements documentation, design specifications, test protocols, test results, and traceability matrices linking requirements to tests.

How often do systems need revalidation?

Systems require revalidation when changes affect validated functionality. Minor bug fixes may not require full revalidation. Major feature additions, infrastructure changes, or modifications to core functionality typically do. A risk-based assessment determines the scope of revalidation needed.

Last updated: March 5, 2026