21 CFR Part 11 Software for U.S. Regulated Teams: From Clause to Code

21 CFR Part 11 requires that electronic records and signatures used under FDA predicate rules are authentic, complete, and protected against tampering through controls such as authenticated access, secure and time-stamped audit trails, and defined signature manifestations. If you manage or build regulated software, your first move is to identify which of your records fall under Part 11 and start a documented risk assessment for those systems.

TL;DR:

• Only records required by FDA predicate rules that are electronically submitted or relied upon for compliance are subject to Part 11 controls; internal, non-regulated records typically are not.
• Signature displays must include printed name, date and time, and the specific meaning, and audit trails must be secure, tamper-evident, and record every action with operator identity and timestamps.
• Validation efforts should be scaled based on the system’s impact on product quality, safety, and record integrity, focusing primarily on audit trail and signature workflows.
• When using cloud or SaaS platforms, companies remain responsible for validation by reviewing vendor documentation and ensuring controls are met, not re-validating the entire platform.
• Build compliance into the system from the start, including clear role separation, server-side audit logging, cryptographic hashing for critical records, and automated traceability testing to prepare for inspection.

Table of Contents

• Scope and applicability: when does Part 11 apply?
• Core regulatory controls mapped to engineering requirements
• Building compliance into the software: design, code, and test
• Scoping validation with a risk-based approach
• Managing vendor and cloud risk without losing control
• A practical checklist for launch and ongoing readiness
• How Wve Labs builds and supports Part 11-ready systems
• What recent FDA guidance means for software teams in 2026
• Get help scoping or building a Part 11-capable system
• Sources
• FAQ

Scope and applicability: when does Part 11 apply?

Part 11 does not apply to every electronic record your organization keeps. It applies when a predicate rule, meaning an existing FDA regulation such as those governing device history records or drug manufacturing, requires that a record be created, maintained, or submitted, and your organization chooses to keep that record electronically. The eCFR text for Part 11 sets this scope out in §11.1 and §11.2: the rule governs records required by predicate rules, records submitted to FDA in electronic form, and electronic signatures used in place of handwritten ones.

The regulation also distinguishes between closed systems, where the people responsible for record content control system access, and open systems, where they do not. Closed systems fall under §11.10, which lists controls like validation, audit trails, and access limits. Open systems fall under §11.30, which asks for those same protections plus additional measures such as encryption when the environment is not fully controlled by the record owner.

Before writing a line of code or signing a vendor contract, work through a short scope check:

• Is the record required by an FDA predicate rule, or is it purely internal and non-regulated?
• Will the record be submitted to FDA electronically, or relied on to demonstrate compliance?
• Does the system operate as closed (your organization controls access) or open (a third party or public network is involved)?

Document the answer to each question, because inspectors expect to see the reasoning, not just the conclusion.

Core regulatory controls mapped to engineering requirements

Part 11 reads like a legal document, but almost every clause translates into a specific, testable feature. Three areas carry the most engineering weight: signature manifestations, audit trails, and access control.

Signature manifestations, covered under §11.50, require that any human-readable form of a signed record display the printed name of the signer, the date and time the signature was executed, and the meaning associated with the signature (approval, review, authorship). These three fields must appear together, on screen and on any printout, not scattered across separate reports.

Audit trails fall under §11.10, which requires secure, computer-generated, time-stamped records that capture who did what and when for every create, modify, or delete action on a regulated record. That trail must be append-only and tamper-evident, meaning no user, including administrators, can alter or delete a prior entry without leaving evidence of the change.

The regulation’s audit trail and signature provisions are specific rather than aspirational: §11.10 and §11.50 require that audit trails record date, time, and operator identity for every create, modify, or delete action, and that signatures display printed name, date and time, and meaning. Treat these as fixed acceptance criteria rather than design suggestions.

Translate these clauses into a developer checklist:

• Assign every user a unique identifier; shared logins defeat the entire purpose of an audit trail.
• Store audit trail entries in a separate, append-only table or ledger, never editable through the application’s normal user interface.
• Capture UTC timestamps consistently across services to avoid time-zone disputes during an inspection.
• Enforce role-based access control (RBAC) so that only authorized roles can execute or witness a signature event.
• Build export functions that produce a complete, human-readable record, including its audit trail and signature block, for FDA review.

Session controls and password or multi-factor authentication policies round out the access-control picture; the goal is that every action in the system can be tied to one accountable, authenticated individual.

Building compliance into the software: design, code, and test

Compliance works best when it is designed in from the start rather than bolted on after a system is already live. A practical build sequence looks like this:

1. Write the user requirements specification (URS) before design begins, capturing which records are Part 11 records and what predicate rules apply.
2. Run a threat model against the audit trail and signature workflows specifically, since these are the components inspectors scrutinize most closely.
3. Define roles and separation of duties so the person who creates a record is not automatically the person who can approve or sign it.
4. Build server-side, append-only audit logging rather than relying on client-side or application-log capture that a privileged user could alter.
5. Apply cryptographic hashing to critical records so any post-hoc modification is detectable, and manage signing keys through a secure, access-controlled process if digital signatures (not just electronic signatures) are used.
6. Write automated traceability tests that confirm every requirement in the URS maps to a corresponding test case and passing result.
7. Run user acceptance test scripts specifically for signature manifestation display and audit trail retrieval, since these are the artifacts most often requested during inspection.
8. Version and gate every change through a formal change-control process, with regression tests confirming that audit trails and signature flows still behave correctly after updates.

Pro Tip: Build your audit trail export function early and test it against a real inspection scenario, since a system that can log everything but cannot produce a clean, human-readable report under time pressure will still fail you on the day it matters.

Operationally, pair this build sequence with written SOPs covering backup and restore procedures, data retention periods, and how staff should package validation evidence when a request for records comes from FDA or an internal quality audit. Keep this documentation current as the system evolves, since stale SOPs create as much inspection risk as missing ones.

Scoping validation with a risk-based approach

Not every system deserves the same depth of validation, and FDA’s own guidance agrees. The principle is straightforward: document your risk assessment first, then size your validation effort to the system’s potential impact on product quality, patient safety, or record integrity.

At minimum, your validation package should include:

• A validation plan describing scope, approach, and acceptance criteria.
• The URS and corresponding design specifications.
• Test scripts and a traceability matrix linking requirements to tests to results.
• Signed test evidence and a change-control log showing what changed and why.

A lightweight internal scheduling tool that never touches a regulated record needs far less rigor than software that generates or stores device history records or batch release data. For the latter, a full V-model approach, moving systematically from requirements through design, implementation, and verification, is appropriate. FDA’s guidance on Part 11 scope and application recommends documenting whether a record is relied upon as the record of truth or merely a convenience copy of a paper original, since that decision drives how much validation the system actually needs.

The 2025 Computer Software Assurance guidance reinforces this by recommending that teams put their heaviest testing effort where software most directly affects product quality, rather than applying uniform, exhaustive validation to every tool in the stack.

Managing vendor and cloud risk without losing control

Moving to SaaS or cloud infrastructure does not remove your Part 11 obligations, it redistributes them. In a self-hosted environment, your team owns validation of the full stack. In a SaaS arrangement, your vendor typically controls infrastructure and application code, but you remain responsible for demonstrating that the system, as you use it, meets Part 11 controls.

Before signing or renewing a vendor agreement, request:

• A system description covering architecture, data flows, and where records are physically or logically stored.
• Validation artifacts or a validation summary the vendor can share without exposing proprietary detail.
• Documentation of how the audit trail is designed and secured against tampering.
• Evidence of recent backup and restore testing.
• The vendor’s change-control policy and how they notify customers of updates that affect regulated functionality.
• Security attestations such as SOC 2 or ISO 27001 reports.

Contractually, push for right-to-audit clauses, data escrow provisions in case the vendor relationship ends, and defined change-notification timelines so a silent update never catches your quality team off guard.

Pro Tip: You do not need to re-validate a vendor’s entire platform. Sample-test the functions your regulated workflow actually touches, review the vendor’s own evidence, and repeat that verification periodically rather than treating it as a one-time gate.

A practical checklist for launch and ongoing readiness

Getting a system into a Part 11-ready state is a milestone, keeping it there is the harder discipline. Break the work into three phases:

1. Pre-launch: complete the risk assessment, finalize the URS, verify access controls and RBAC, test the full signature workflow end to end, and confirm backup and export functions produce complete, readable records.
2. Ongoing: review user accounts and privilege levels on a set schedule, log every software update through change control, and periodically verify that the audit trail has not been altered or lost data.
3. Inspection readiness: keep a packaged evidence set current, including the validation summary, traceability matrix, and recent audit trail samples, and rehearse pulling a signature manifestation and its corresponding audit trail on demand.

Treat this checklist as a living document rather than a one-time launch task, since privilege creep and undocumented changes are two of the most common findings in Part 11-related inspection observations.

How Wve Labs builds and supports Part 11-ready systems

Wve Labs designs secure architecture, engineers audit trail and signature flows, and supports validation documentation for teams building regulated software. Our engineering work spans backend development, cloud deployment, and system modernization, the same disciplines that underpin a defensible Part 11 implementation. Our Digital Watchdog case study reflects the kind of secure, production-grade system work regulated teams need, and our experience across video platforms and connected hardware projects informs how we approach access control, logging, and change management on complex builds. If your team is scoping a Part 11 system, Brian and the Wve Labs team are available to talk through your architecture and validation approach.

What recent FDA guidance means for software teams in 2026

FDA’s direction over the past year has leaned toward risk-based assurance rather than blanket, maximal validation. The Computer Software Assurance guidance asks teams to focus assurance activities where software most directly touches product quality, and FDA’s own Part 11 scope guidance has long signaled enforcement discretion in areas that pose lower record-integrity risk.

The practical effect for a software team in 2026 is not less work, it is different prioritization. Build and test your audit trails and signature manifestations first, since these are the controls inspectors examine most closely and the ones hardest to retrofit convincingly. Documentation should follow the same order: prove record integrity and traceability before spending validation hours on lower-risk, convenience features.

— Brian

Get help scoping or building a Part 11-capable system

Building software that satisfies Part 11 is a technical problem as much as a regulatory one, and it benefits from a team that has done the architecture, logging, and validation documentation work before. Wve Labs supports regulated teams through system design, secure backend and audit trail engineering, cloud deployment, and ongoing product care as your system evolves.

Before a scoping call, gather what you already have: a draft URS, a description of your current system architecture, and any risk assessment notes on which records fall under Part 11. From there, we can map out:

• Which components need new engineering work versus configuration of existing tools.
• What validation evidence your team will need to assemble alongside development.
• How ongoing maintenance and change control should be structured once the system is live.

Visit our services page to see the full range of engineering and product support available, or reach out to start a conversation about your specific system.

Sources

• eCFR :: 21 CFR Part 11 – Electronic Records; Electronic Signatures
• Guidance for Industry: Part 11, Electronic Records; Electronic Signatures — Scope and Application (FDA)

FAQ

Does 21 CFR Part 11 apply to every electronic record my company keeps?

No, Part 11 applies only to electronic records required by an FDA predicate rule, submitted to FDA electronically, or relied on to demonstrate regulated compliance. Purely internal, non-regulated records generally fall outside its scope, though you should document that determination as described in FDA’s scope guidance.

What must an audit trail capture to satisfy Part 11?

An audit trail must be secure, computer-generated, and time-stamped, recording the operator’s identity, the date and time, and the type of action taken for every create, modify, or delete event on a regulated record, per §11.10. It must also be append-only, so past entries cannot be altered or deleted without leaving evidence of the change.

What information has to appear with an electronic signature?

Under §11.50, any signed record must display the signer’s printed name, the date and time of signing, and the meaning associated with the signature, such as review or approval. These elements must appear together in every human-readable version of the record, whether on screen or in print.

Does moving to a cloud or SaaS platform change our Part 11 obligations?

Moving to the cloud shifts who controls the infrastructure, but the regulated company remains responsible for confirming the system meets Part 11 controls as used. Request the vendor’s validation artifacts, audit trail design documentation, and security attestations, and build in contractual right-to-audit and change-notification terms.

How much validation does a new software system actually need?

The right amount depends on the system’s risk to product quality and record integrity, documented through a risk assessment before validation begins. FDA’s Computer Software Assurance guidance recommends concentrating testing effort on the functions most likely to affect product quality rather than applying uniform, maximal validation everywhere.

Made with BabyLoveGrowth to grow organic traffic