21 CFR Part 11 Compliance: What Inspectors Ask to See
21 CFR Part 11 applies to how a regulated organization uses a system, not to the software as a product. A vendor supplies capability. You supply configuration, procedures, training and evidence. The four findings that recur all sit on your side of that line.
The sentence that causes the most trouble is "the vendor is Part 11 compliant, so we are." It is said in good faith, usually by someone repeating what they were told during procurement, and it describes a responsibility split that does not exist.
This guide sets out what the vendor can and cannot provide, the four findings that come up most often, and the evidence pack that answers them. It sits under what you own and what the vendor owns in eClinical validation.
After reading this you will be able to:
- State precisely where vendor responsibility ends and yours begins
- Close the four gaps that produce most Part 11 findings
- Assemble an evidence pack with a named owner for every requirement area
- Answer the audit trail question without improvising on the day
What Part 11 Actually Covers
Part 11 governs electronic records and electronic signatures where they are used in place of paper under a predicate rule. It is about trustworthiness: can you show that a record is what it claims to be, attributable to a person, unaltered or altered traceably, and retrievable for as long as required.
Read that way, most of the obligation is procedural rather than technical. A system that supports every Part 11 feature can be used in a way that satisfies none of them, which is precisely why the regulation attaches to the user rather than to the software.
The Four Findings That Recur
What they share is that each is a short conversation on the day of an inspection and a long remediation afterward. An inspector asking for the audit trail review procedure either receives a document or does not, and there is no version of that exchange where improvising helps.
Enabled Is Not Reviewed
The first finding deserves separate treatment because it is the most common and the most misunderstood. Teams enable the audit trail, confirm it cannot be switched off, and consider the requirement met.
Enabling satisfies the technical half. The procedural half asks what you do with it: which records are reviewed, at what frequency, by whom, what constitutes a signal worth investigating, and what the output of each review was. Without that, the trail is a log nobody reads, and its existence demonstrates only that the data was available to be checked.
Scoping that review by risk rather than attempting to read everything is both practical and expected. How to write the procedure so it survives scrutiny is covered in writing an audit trail review procedure that survives an inspection.
Signatures That Mean Something
An electronic signature has to carry three things on the record: the printed name of the signer, the date and time, and the meaning of the signature.
The meaning is the part that gets dropped. A signature block showing a name and a timestamp tells an inspector that someone signed and nothing about what they were attesting. Review, approval, responsibility and authorship are different acts with different consequences, and the signer should have known which one they were performing at the time.
The adjacent requirement is that signatures are linked to their records so they cannot be excised, copied or transferred. That is usually a system property, but it is worth confirming rather than assuming, because it is the kind of thing a demonstration never covers.
Attribution Breaks on Shared Accounts
Every Part 11 requirement that depends on knowing who did something fails if accounts are shared. The audit trail still records actions faithfully, and it records them against an identity that does not correspond to a person.
Shared accounts are rarely a policy decision. They appear because provisioning was slow during start-up and a workaround became a habit, or because a site has more coordinators than licenses. Both causes are fixable, and both are cheaper to fix than to explain.
The habit that keeps this clean is a periodic access review: read the current user list against the current staff roster, remove what should not be there, and keep the record of having done it.
Part 11 Does Not Stand Alone
A point that saves a lot of argument: Part 11 applies where an electronic record is used in place of a paper record required by some other regulation. That other regulation is the predicate rule, and it is what decides which records are in scope in the first place.
This matters practically because it bounds the exercise. Not every file in your environment is a Part 11 record, and treating everything as in scope produces an unusable amount of work and a controls regime nobody follows. Identifying which records are required by a predicate rule, and therefore which need the full treatment, is the first step and is frequently skipped in favor of applying controls everywhere.
The corollary is that the predicate rule also sets the retention period. Part 11 asks that records remain accurate and retrievable throughout that period, which for clinical records can be a long time and can outlast the system that created them.
The Evidence Pack
The column that matters most is the third. A requirement area with no named owner is where the evidence will turn out to be incomplete, because nobody was responsible for noticing. Assigning owners takes an afternoon and is the single highest-return action in this list.
Assemble the pack while the study is running rather than when an inspection is announced. A pack assembled under notice is usually complete and carries metadata showing when it was assembled, which invites exactly the scrutiny it was meant to deflect.
Where This Meets Annex 11
If you operate in both the United States and the European Union, Part 11 is not the only framework in play. Annex 11 covers computerized systems under EU GMP and overlaps substantially, while diverging on supplier assessment, risk management and periodic review.
The practical consequence is a documentation set that satisfies both rather than two parallel sets, which is achievable but needs deliberate design. The differences that actually change what you write are in Annex 11 and Part 11 side by side.
Clinera EDC ships with the audit trail, role framework and signature components configured, and clinical and R&D AI covers where automation assists with audit trail review at volume rather than replacing the procedure.
References
- 21 CFR Part 11, Electronic Records; Electronic Signatures. US Code of Federal Regulations, Title 21, Part 11. www.ecfr.gov
- Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations. US Food and Drug Administration guidance for industry. www.fda.gov
- ICH E6(R3) Good Clinical Practice. International Council for Harmonisation, adopted 6 January 2025. www.ich.org
- Annex 11, Computerised Systems. EudraLex Volume 4, Good Manufacturing Practice guidelines. health.ec.europa.eu
This guide describes process and regulatory expectations in general terms and is not legal or regulatory advice. Confirm the current version and applicability of any standard or guidance for your study and region.
Frequently Asked Questions
Does buying a Part 11 compliant system make us compliant?
No, and this is the most expensive misunderstanding in eClinical procurement. The regulation applies to the regulated party, meaning you. A vendor can supply technical capability that makes compliant use achievable: an audit trail that cannot be disabled, a role framework, signature functions, and product validation documentation. What it cannot supply is your configuration, your procedures, your training records or your validation of how you actually use the system.
What are the most common Part 11 findings?
Four recur. An audit trail that is enabled but never reviewed, with no documented review procedure. Electronic signatures applied without a recorded meaning, so nobody can say what the signer was attesting to. Shared or generic accounts, which break attribution entirely. And a vendor certificate offered in place of validation of your own configuration. None of these requires a sophisticated inspection to find, and all four are answerable in advance.
Is an enabled audit trail enough?
No. Enabling the trail satisfies the technical requirement and leaves the procedural one untouched. What is expected is a documented review: which records are reviewed, how often, by whom, what triggers a closer look, and what the output of each review was. "Enabled but never reviewed" is among the most commonly cited gaps, and it is one of the easier ones to close before anyone asks.
What does signature meaning actually require?
That the signed record shows the printed name of the signer, the date and time of signing, and the meaning associated with the signature, such as review, approval, responsibility or authorship. The meaning has to be clear to the signer at the time and visible on the record afterward. A signature block with a name and a timestamp but no stated meaning leaves an inspector unable to tell what was being attested to.
Do we need to validate a cloud system the vendor already validated?
You validate your configured use of it, which is a different exercise from the vendor validating the product. Your package covers the study build you specified, the roles you configured, the data flows you connected and the procedures your people follow. Scoping that effort by risk rather than applying uniform effort is both accepted practice and considerably cheaper than revalidating everything the vendor already tested.
Can Nirmitee Healthtech assemble our Part 11 evidence pack?
Yes, and the useful form is a gap assessment first. The work walks each requirement area, checks what evidence exists today, names the owner, and lists what is missing in the order an inspector would reach it. That assessment is useful whatever system you run. Clinera EDC is configured with the audit trail, role and signature components in place, but the evidence pack is yours either way.
