21 CFR Part 11 Compliant Electronic Records: Subpart B Requirements Explained

Most conversations about 21 CFR Part 11 center on signatures: two-factor authentication, signature meaning, unique credentials. That focus makes sense for day-to-day compliance work. But it misses the foundation those signatures rest on.

21 CFR Part 11 compliant electronic records are what Subpart B is about. Before a signature has any evidentiary weight, the record it's attached to has to meet its own set of requirements. Those requirements cover how the system is controlled, how access is managed, how the audit trail works, and what happens to records when the system changes or the retention clock runs out. Get Subpart B wrong and the signatures on top of it don't matter.

This guide walks through Subpart B section by section, explains where organizations consistently fall short, and covers what the FDA's 2024 clinical investigations guidance added to the picture for cloud-based and hybrid systems.

What Subpart B Actually Covers

Subpart B of Part 11 runs from Section 11.10 through Section 11.70. It's the shorter subpart in terms of word count but it carries most of the technical compliance weight. The subject is electronic records themselves: how they're created, protected, stored, and retrieved.

It's worth being clear about what "electronic records" means in this context. The FDA defines an electronic record as any combination of text, graphics, data, audio, pictorial, or other information representation in digital form that is created, modified, maintained, archived, retrieved, or distributed by a computer system. That's a wide net. It covers case report forms, protocol amendments, adverse event reports, batch records, audit trail entries, system configuration logs, and the metadata attached to any of those. If it's in a computer system and it relates to a regulated activity, Subpart B applies.

Section 11.10: Controls for Closed Systems

Section 11.10 is where most of the compliance action happens. It applies to closed systems, which the regulation defines as environments where access is controlled by the persons responsible for the content of the electronic records. Most clinical research platforms, quality management systems, and eTMF solutions are closed systems. If your organization controls who gets into the system, it's a closed system.

The section lists eleven specific controls, each with its own compliance implications.

Validation (11.10(a))

The system must be validated to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records. Validation isn't a one-time event. It covers the initial qualification of the system and every substantive change made to it afterward. Change control is part of the validation obligation.

The FDA's 2003 Scope and Application guidance introduced a risk-based approach that reduced the documentation burden for low-risk systems. But "risk-based" doesn't mean "optional." It means the depth of your validation should match the risk the system presents to record integrity and subject safety. For systems used to sign clinical trial documents, that risk is not low.

Accurate and Complete Record Retrieval (11.10(b))

The system must be able to generate accurate and complete copies of records in both human-readable and electronic form suitable for inspection, review, and copying by the FDA. This requirement has two parts and they're both real requirements.

Human-readable means a printed page or displayed screen that a person can actually read. Electronic form means a file that an FDA investigator can take away and review using standard tools. Neither a scanned image of a database export nor a proprietary file format that requires your specific software to open is a good answer here. Records must be producible in formats that survive the context of your specific system.

This is one of the requirements most organizations underestimate until they're sitting across from an investigator who's asking for a record from a system that was decommissioned three years ago.

Record Protection During Retention (11.10(c))

Records must be protected to enable accurate and ready retrieval throughout the records retention period. Two things matter here. First, Part 11 doesn't set the retention period. Your predicate rules do. For clinical trial records, that's typically 21 CFR 312.62 for IND records (two years after the investigation is completed or discontinued, or two years after the drug is approved, whichever is longer). For clinical investigators, it's 21 CFR 312.68. For drug sponsors, records often need to be retained for 15 years or more.

Second, "ready retrieval" means what it sounds like. Not retrievable if IT has six weeks and a backup restoration project. Retrievable on demand, in a format a human can read, during an inspection. If your archival process removes that capability, you have a problem.

Access Controls and System Access Limiting (11.10(d) and (g))

Section 11.10(d) requires limiting system access to authorized individuals. Section 11.10(g) requires authority checks to ensure that only authorized individuals can use the system, sign a record, access input/output devices, alter a record, or perform a given operation.

In practice, this means role-based access controls that are documented, enforced, and reviewed. It's not enough to say the system has access controls. The access rights assigned to each user must match their job function, and there must be a process for revising those rights when someone changes roles or leaves the organization.

Shared accounts violate both provisions. A single login shared by multiple users means the audit trail can't attribute actions to individuals, and it means there's no way to know whether the person who performed a given action had the authority to do so.

Audit Trails (11.10(e))

This is the requirement that shows up most often in FDA 483 observations. Section 11.10(e) requires secure, computer-generated, time-stamped audit trails that independently record the date and time of operator entries and actions that create, modify, or delete electronic records.

The word "independently" is doing real work there. It means the audit trail must be technically separate from the data it's recording. A user who can modify the underlying record shouldn't be able to modify the audit trail entry for that modification. They're separate objects, and the integrity of one shouldn't depend on the trustworthiness of the people who created the other.

The regulation also requires that record changes not obscure previously recorded information. This is the "original value" requirement in practice. If someone changes a field, the audit trail must show what the field said before the change and what it says after. Logging that a change occurred without capturing what changed doesn't satisfy this requirement.

Audit trail retention must match the retention period for the underlying records. If a document needs to be kept for fifteen years, the audit trail for that document needs to be kept for fifteen years too. They're a package.

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

Operational system checks (11.10(f)) require that the system enforces permitted sequencing of steps and events. In a clinical trial workflow, this means the system should prevent a monitor from approving a document before a site coordinator has submitted it, or prevent an investigator from signing an amendment before the IRB has provided approval if that's the required sequence.

Device checks (11.10(h)) require the use of valid combinations of device and user ID or equivalent measures to verify that the device accessing the system is authorized. This provision is more relevant to systems where hardware plays a role in authentication. For most clinical trial platforms, it's addressed through session management and credential validation rather than physical device controls.

Personnel Qualifications and Training (11.10(i) and (j))

The regulation requires that people responsible for developing and maintaining Part 11-compliant systems have the education, training, and experience to perform their assigned tasks. It also requires written policies that hold individuals accountable for actions initiated under their electronic signatures and that prohibit unauthorized use of passwords or other identification codes.

The training requirement isn't just about how to use the system. It's about the accountability obligations that come with using an electronic signature. Users need to understand that sharing their credentials is a regulatory violation, not just a policy violation. That understanding should be documented in training records.

Documentation Controls (11.10(k))

Systems documentation must be maintained under document controls that include revision and change control procedures that maintain an audit trail documenting time-sequenced development and modification of the documentation itself. This applies to your SOPs, validation protocols, system configuration records, and user role definitions.

The meta-level here is intentional: the records about your records management system are themselves subject to Part 11's documentation integrity requirements.

Section 11.30: Controls for Open Systems

Open systems are environments where system access is not controlled by the persons responsible for the content of the electronic records. The clearest examples are public-facing portals, email-based signing workflows, and systems that allow external parties to create or modify records.

Section 11.30 requires everything in 11.10 plus additional controls. The most important are encryption of records during transmission and use of digital signatures from recognized certificate authorities. The rationale is straightforward: in an open system, you can't rely on access controls alone to guarantee integrity, so you need cryptographic protection on the records themselves.

Many organizations that think they're running closed systems are actually running hybrid configurations with open system characteristics. If external parties can access your records through a portal you control but where you don't control their devices or networks, you may need to evaluate whether 11.30 applies.

Section 11.50 and 11.70: Signature Manifestations and Record Linking

These two sections bridge Subpart B and Subpart C. They're technically part of the electronic records section but they address the relationship between records and signatures.

Section 11.50 requires that signed electronic records display the signer's printed name, the date and time of signing, and the meaning of the signature. The meaning requirement is where most systems fall short. It's not enough to capture that someone signed a record. The record must show why they signed it: review, approval, responsibility, authorship. In a clinical trial context, that distinction matters. A monitor's review signature carries different evidentiary meaning than an investigator's approval signature.

Section 11.70 requires that electronic signatures be linked to their respective electronic records in a way that prevents the signature from being removed, copied, or transferred to falsify a different record. This is the signature integrity provision. It's what prevents someone from taking a signature block from one approved document and attaching it to a different document that was never actually approved.

The technical implementation typically involves cryptographic binding, where a hash of the record content is included in the signature object. Any modification to the record after signing invalidates the signature. Systems that store signatures as metadata separate from the document they cover, without this binding, don't satisfy 11.70.

The Legacy System Question

Part 11 includes a grandfathering provision for systems that were in operation and used to create, modify, maintain, or transmit records before August 20, 1997 (the regulation's effective date). Those systems may qualify for an exemption from certain Subpart B requirements if they were already in use and are documented as fit for their intended purpose.

The exemption is narrower than it sounds. It applies only to systems that haven't been substantially modified since 1997, and only for records that were already subject to the predicate rules those systems supported. A system that was in place in 1997 but has been upgraded, migrated, or replatformed since then is not a legacy system for Part 11 purposes. And any new record types or workflows added after 1997 are fully subject to Part 11 regardless of the underlying system's age.

In practice, essentially no clinical research system in active use today qualifies for this exemption. The legacy carve-out is a historical artifact, not a practical compliance path.

What the 2024 FDA Guidance Changed for Electronic Records

The FDA's October 2024 final guidance on electronic systems, records, and signatures in clinical investigations addressed cloud-based systems explicitly. The agency confirmed that cloud-based electronic systems are held to the same Part 11 standards as on-premise systems. The responsibility split is important: the vendor is responsible for system-level controls and their validation; the sponsor or site retains responsibility for appropriate use, vendor qualification, and documented oversight.

This means your vendor's Part 11 compliance documentation doesn't substitute for your own qualification activities. You still need a vendor assessment process, a user requirements specification that covers Part 11 obligations, and documented evidence that the system was configured and tested in a way that meets your specific compliance needs. Pointing to a vendor's SOC 2 report or compliance white paper isn't sufficient.

The 2024 guidance also addressed source data integrity for cloud-based EDC and ePRO systems, clarifying that Part 11's requirements apply to the source data itself regardless of where it's stored. Records that originate in a cloud system aren't exempt from the retrieval, retention, and audit trail requirements just because they're not on your local servers.

The Most Common Subpart B Failures

Based on FDA 483 observations and warning letters, the failures in electronic records compliance cluster around a predictable set of gaps.

Audit trails that don't capture original values. The system logs that a field was changed, records the new value, but doesn't preserve what the value was before. Without the original value, the audit trail can prove that something changed but not what changed. That's not a compliant audit trail.

Records not producible on demand. Investigators ask for records and the answer involves calling IT, running a database script, or restoring an archive. Section 11.10(b) requires ready retrieval. "Ready" doesn't mean retrievable with effort. It means retrievable now, during the inspection.

Decommissioned systems with no retrieval plan. An organization migrates from one platform to another, but the migration didn't transfer the audit trail history. Or the old system was shut down and the records were exported to a format that's no longer readily readable. Both are retention and retrieval failures under 11.10(c).

Administrator actions not logged. The audit trail captures user actions but the database administrator who has direct table access isn't subject to the same logging. This creates a backdoor that compromises the integrity of the entire audit trail.

Validation that doesn't cover the current system version. The system was validated in 2021. It's been through four updates since then. Change control records exist, but they don't include IQ/OQ/PQ documentation for the updates. The validation is effectively stale.

Signature meaning not enforced. The system allows signing without requiring the signer to specify the meaning of their signature. The record captures name and timestamp but no indication of why the person signed. This fails both 11.50 and the spirit of 11.10, because a signature without stated meaning doesn't tell the FDA whether the record was reviewed, approved, or just acknowledged.

Building a Subpart B Compliance Framework

Subpart B compliance isn't a checklist you run once. It's a set of ongoing obligations that require a maintained infrastructure. The organizations that hold up well in inspections have a few things in common.

They treat their electronic records system as a validated state, not a validated event. Validation is an ongoing condition maintained through change control, periodic review, and revalidation when warranted. When a vendor pushes an update, someone is responsible for assessing whether that update affects the validated state and documenting the assessment.

They have a documented system inventory that maps which systems hold which regulated records and which predicate rules apply. When retention periods differ across record types, the system configuration reflects those differences. When a system is decommissioned, the migration plan includes transfer of audit trail history, verification of readability in the new environment, and documentation of the migration itself.

And they've tested record retrieval. Not just "we believe the system can produce a complete record." They've actually produced records in the required formats, verified they're complete and readable, and documented the test. If an investigator asks for a record from three years ago, the answer shouldn't be "I think we can do that."

What to Look for in a Platform

If you're evaluating an e-signature or electronic records platform against Subpart B, the requirements are specific enough to verify directly. You don't have to take a vendor's word for it.

Ask to see the audit trail architecture. Does it capture original values? Is it architecturally separate from the data it covers? Can it be exported in a human-readable format without IT involvement? Does it log administrator actions the same way it logs user actions?

Ask about signature-to-record linking. Is it cryptographic? Can the system demonstrate that a modification to a signed record would be detectable? What happens to the signature if the record is exported or migrated?

Ask for the IQ/OQ/PQ documentation. It should be current for the version of the software you'll be using, and it should cover the specific functions you'll rely on for compliance, not just general system functionality.

A platform purpose-built for 21 CFR Part 11 compliant electronic records treats these requirements as design constraints, not add-on features. The difference shows in the architecture, not just in the compliance matrix.

Conclusion

21 CFR Part 11 compliant electronic records are the foundation that everything else in Part 11 compliance depends on. Subpart B defines what that foundation looks like: a validated system, complete and independent audit trails, access controls with authority checks, records that are producible on demand in readable formats, and signatures that are cryptographically bound to the records they cover.

The signatures themselves get most of the attention, but an electronic signature on a record that doesn't meet Subpart B requirements isn't a compliant signature in any meaningful sense. It's a click on an inadequate system.

For more on the signature side of Part 11, see our guide to 21 CFR Part 11 electronic signatures. For a full overview of the regulation including its scope and predicate rule relationship, see our complete guide to FDA 21 CFR Part 11. To see how Certivo addresses Subpart B requirements out of the box, visit our compliance page.