Undocumented Changes Break Validated Clinical Systems
By Eshaan Jain, Senior Consultant, Mphasis
A coordinator asks for a small change to an interactive response technology (IRT) system: widen a data field, adjust a randomization stratification rule, or add a dropdown value to a screening form. An administrator changes the code directly in production because it looks trivial. Nobody opens a change ticket, nobody documents what else in the system depends on that field or rule, and nobody reruns the test scripts that originally proved the system worked as intended. The change works from the user's perspective. The system's validated state, the documented proof of its intended functionality, ended the moment no one assessed what that field or rule actually affected.
I have spent 15 years moving between two sides of this problem. At PwC and Accenture, I worked IT general controls (ITGC) engagements where change management, not access control, was the finding that kept coming back. At T-Mobile, employed through Mphasis, I run release and change management for a production Salesforce CPQ (configure, price, quote) and CLM (contract lifecycle management) environment that must remain in a defensible, tested state with every release. The discipline is the same whether the system prices a wireless contract or randomizes a patient into a trial arm.
Access control and change control are both IT general controls that inspections cite, but they do not represent the same failure mode. Access control asks who is allowed to touch a system. Change control asks whether, once inside, what they did to it was assessed, tested, approved, and recorded before it went live. A user with entirely appropriate permissions can still push an unreviewed, undocumented change that quietly invalidates the system around them. That is the failure this piece covers.
What “Validated” Actually Means For A Clinical System
Computer system validation (CSV) is documented evidence, tied to a specific configuration and code baseline, that a system consistently does what its requirements say it does for its intended use. FDA's guidance on computerized systems used in clinical trials lays out what that evidence must include: written design specifications, test plans, and test results demonstrating that the design specifications were met.1 FDA's more recent guidance on electronic systems, records, and signatures in clinical investigations builds on the same risk-based validation expectation for current trial technology.2
That evidence is scoped to the system as it existed at the moment of testing. Once the configuration changes, the proof no longer describes what is running in production. The system's validation history still exists, but it now describes a state the system has already left.
A Small Change Still Breaks The Validated State
This phenomenon is what trips up teams: the size of a change does not affect whether it breaks the validated state. A dropdown value, a field length, a randomization parameter, and a full module replacement all affect the baseline in the same way. Each one moves the system away from what was tested.
FDA's 1999 guidance is explicit that any modification requires an evaluation of its effect and a documented decision about whether revalidation is needed, with revalidation required whenever a change exceeds the system's tested operational limits or design specifications.1 The regulation governing computer and automated systems in current good manufacturing practice, 21 CFR 211.68(b), sets a similar expectation: accuracy checks on data going into and out of the system and controls over how records and configurations change, at a frequency tied to the complexity of the system.3 Neither standard treats “the change was small” as a reason to skip the assessment. The assessment is what determines whether the change was small.
Change Management Is Its Own Control Domain
Auditors who work IT general controls treat change management as a category with its own recurring findings, distinct from access control. An analysis of FDA warning letter patterns in computer system validation names poor change control specifically: systems that were properly validated at launch drift out of that validated state as changes accumulate without impact assessment or retesting until nobody can explain why a given change was made, what it touched, or how it was evaluated.4
The control framework that prevents this drift is consistent across regulated industries, whether the driver is Sarbanes-Oxley financial reporting controls or GxP quality systems. A documented change process needs five things: a change request that is traceable, someone other than the person who made the change signing off on it, testing evidence proportional to what the change touches, a rollback plan in case the change fails, and a retained record an auditor can pull months later and reconstruct.5 Strip any one of those out and the process stops being change control and becomes an informal habit that happens to work most of the time.
What Does This Look Like In A Comparable Production System?
The CPQ and CLM environment that I run at work carries the same weight as a validated clinical system: it is tested and approved for its intended production use, and every change to pricing logic, approval workflows, or contract clause libraries goes through a sandbox first, a documented approval gate before promotion, and a scheduled deployment window rather than an ad hoc push. That structure is a large part of why we cut contract creation time by 50% without introducing errors into a live commercial system: every change that reached production had already been tested against the configuration it was changing, not against a stale assumption about how the system used to behave.
The same logic applies to a different system I helped build earlier in my career: a machine learning clause extraction system at Amazon that processed a $40 billion-plus annual portfolio of logistics contracts. A single change to an extraction rule or a training update, pushed without a controlled test cycle, would have shifted results across every contract the model touched, not just the one that prompted the change. Validated systems that operate at scale do not forgive an untested change just because it appears contained. An IRT randomization engine or an electronic data capture (EDC) edit check library is no different: the blast radius of an unreviewed change is defined by what depends on the system, not by how many lines were edited.
A Change Control Checklist For IRT, EDC, And CTMS Systems
The same five gates apply to a validated clinical system, whether it is an IRT platform, an EDC system, or a clinical trial management system (CTMS):
Change request. Every change starts as a documented, ticketed request that states what is changing and why, tied to a specific business or regulatory reason rather than a verbal ask.
Impact assessment. Before anyone touches the system, someone documents what else depends on the change: which reports, integrations, edit checks, or downstream systems consume the field, rule, or module being modified. This step is also where the team decides and records whether the change affects validated functionality, such as randomization logic or dosing calculations.
Testing evidence. The change is tested in a nonproduction environment against the specific functionality flagged in the impact assessment, with results attached to the change record rather than described from memory later.
Approval before promotion. Someone independent of the person who made the change signs off, and that approval happens before the change reaches production, not as a retroactive rubber stamp during the next audit.
Validation recertification. The validation package, whether a full revalidation or a documented rationale for why one was not needed, is updated before the change goes live in the system the trial actually runs on. A validation summary that does not reflect the current configuration is not evidence of anything.
Skipping any one of these gates moves the discovery of the problem from a change review meeting, where catching it costs a few minutes of a reviewer's time, to an inspection, where it costs a finding on the record.
The Cost Of A Skipped Gate Lands At Inspection
An undocumented change costs a team on the day an inspector or auditor asks for the change history behind a specific piece of system behavior and the record does not exist or exists in a chat thread rather than in a change log. Before the next change ships to an IRT, EDC, or CTMS system your team runs, check whether the ticket contains a documented impact assessment and names an approver who did not write the change. If either is missing, hold the deployment until it is there. That single check is cheaper than rebuilding a validation history after the fact, and it is the difference between a system that is validated and a system that merely used to be.
References:
- FDA, "Guidance for Industry: Computerized Systems Used in Clinical Trials" (April 1999): FDA.gov
- FDA, "Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations: Questions and Answers," guidance for industry (October 2024), Federal Register notice: FederalRegister.gov
- 21 CFR 211.68, "Automatic, mechanical, and electronic equipment," part (b), controls over computer and related systems: eCFR via Cornell Law School Legal Information Institute
- TRI, "Top 10 FDA Warning Letter Findings in Computer System Validation," including change control as a named recurring finding: TRItrials.com
- ChangeRiskIntel, "SOX Change Management Controls: ITSM Checklist," on the five core requirements of a documented IT change control process: ChangeRiskIntel.com
About The Author:
Eshaan Jain is a senior enterprise product leader with almost 15 years of experience at the intersection of AI/ML, Quote-to-Cash (CPQ), and Contract Lifecycle Management (CLM). Currently serving as a Salesforce Product Owner / Senior Product Manager at a management consulting firm.
Eshaan has also spent nearly five years at Amazon (2020–2025) as a Salesforce Technical Product Manager. He was responsible for the Global Supply Chain Transportation Procurement (GSCTP) platform, where he managed a $40B annual procurement spend and led the digital transformation of Amazon's entire last-mile transportation contract lifecycle.
Eshaan's career also includes foundational leadership roles at PricewaterhouseCoopers (PwC) and Accenture, specializing in Salesforce assurance and IT controls.
In addition to his corporate achievements, Eshaan is an active researcher in the field of AI and Machine Learning. He has published three peer-reviewed papers with IEEE and Elsevier. He holds a Master of Science in Computer Science from the University of Southern California (USC) and a B.Tech in Computer Science from GGSIPU in Delhi, India.