Part 11 Compliance Is About the Environment, Not Just the Software

Written by: Patti Rossman

A validated system with full audit trails can still produce records that fail 21 CFR Part 11. The software is only half of compliance. The other half is the environment around it: the procedures, forms, and people that feed information into the system.

A recent audit of a clinical research site shows how this happens in practice. The site had chosen a good system and validated it properly. Yet one gap in a paper-based change request process meant that the audit trail could not do its job. This article walks through that finding and what any sponsor, CRO, or clinical site can learn from it.

What the site got right

The site ran its in-house studies on a single cloud-hosted platform: a configurable commercial off-the-shelf (COTS) system that served as both eSource and electronic data capture (EDC). On paper, the setup was strong.

• Independent validation. A third-party vendor validated the system before use.
• Standards-based design. The system was certified against the CDISC Operational Data Model (ODM) standard for clinical data exchange.
• Direct data capture. The system connected to clinical devices such as ECG machines, used barcode-verified data entry at workstations, and integrated results from a central laboratory.
• Complete audit trails. Every transaction was stamped with the date, time, and identity of the logged-in user who created or changed the data.
• Documented GxP assessment. A formal assessment described the system and confirmed it held GxP data.
• Controlled access. Users got access only through a formal request with training acknowledgement. Multi-step authentication protected logon, and access was deactivated when no longer needed.
• Build quality checks. Internal staff performed QC on every case report form (CRF) build and logged the findings. User acceptance testing (UAT) was completed before any volunteer was screened.

The system could record the user, date, time, and reason for every entry or change. By any reasonable measure, the technology was Part 11 capable.

The gap: a change request that didn’t say who or why

The problem sat outside the software. After a study database went live, any change to it had to be requested on a paper Database Change Request (DCR) form. A data manager then made the change in the system.

The DCR form did not capture two things:

1. Who requested the change. The requester’s identity was not recorded.
2. Why the change was needed. No reason for the change was required.

So when the data manager entered the change, the system prompted for a reason, but the data manager had none to give. The audit trail faithfully recorded who made the change and when. It could not record the real reason, because that reason never reached the person at the keyboard.

Why it matters: an audit trail is only as good as its inputs

Part 11 expects audit trails to let anyone reconstruct the history of a record: what changed, who changed it, when, and why. The “why” is what lets an inspector judge whether a change was legitimate, such as correcting a transcription error, rather than an unexplained alteration of trial data.

In this case, the chain of traceability broke before the data reached the system. Months or years later, an inspector, reviewer, or regulator might ask why a value was changed. The site would have a timestamp and a data manager’s name, but no documented reason and no record of who asked for the change.

This cuts against core data integrity principles, often summarised as ALCOA+. Data must be attributable to the person responsible for it, and its history must be complete and consistent. A change with no recorded requester and no reason is neither fully attributable nor complete.

The principle: a compliant system needs a compliant environment

FDA has long made the point that a system can be “Part 11 compliant” and still be used in a way that is not. Part 11 controls apply to the whole process that creates and maintains electronic records, not just to the software’s feature list.

A useful way to think about it is that the system provides the capability, and the environment determines whether that capability is used correctly. The environment includes:

• Procedures (SOPs) that define how data is entered, reviewed, and changed.
• Forms and templates, paper or electronic, that carry information into the system.
• People and training, so that users know what to record and why it matters.
• Hand-offs between roles, where information is most easily lost.

In this audit, every software control worked as designed. The weak link was a form that let critical information drop out at the hand-off between the requester and the data manager. No amount of software validation could have fixed that.

How to close the gap

The fix in this case is simple, and the same checks apply to any regulated electronic system.

1. Make the form carry the audit trail’s inputs. Change request forms should require the requester’s name, the date, the records affected, and a specific reason for the change. A blank field should stop the request.
2. Pass the reason through, word for word. The person making the change should enter the documented reason into the system, so the audit trail matches the request.
3. Link the paper and electronic records. Give each change request a unique number and reference it in the system’s reason-for-change field. An inspector can then trace from audit trail to request and back.
4. Review changes before and after. Have a second person approve the request and verify that the change was made as requested.
5. Map every hand-off. Walk through each process that feeds the system and ask at each step: who, what, when, and why — is all of it recorded?
6. Audit the environment, not just the software. Include SOPs, forms, and actual working practices in periodic reviews and self-inspections, alongside system validation.
7. Train for the reason, not just the click. Users who understand why audit trails matter are far more likely to give meaningful reasons for changes.

The takeaway

Buying and validating a Part 11-capable system is necessary, but it is not enough. Traceability and data integrity depend on every step that feeds the system, including a single paper form. When you assess compliance, look past the software to the environment it lives in.

Globiox helps sponsors, CROs, and clinical sites assess both sides of Part 11 compliance: system validation and the procedures, forms, and practices around it. Contact us to find the gaps before an inspector does.