By Eshaan Jain, Senior Consultant, Mphasis

Two days after the FDA announced it was inspecting a trial site, a third-party vendor deleted the electronic clinical outcome assessments and audit trails for all 47 subjects in the study, across every site. The sponsor, Applied Therapeutics, received a warning letter in November 2024 documenting the deletion along with a separate finding: At least 19 patients had received doses roughly 80% lower than the protocol specified, because the investigational product was mislabeled, and the company had reported the protocol dose rather than what patients actually received.¹

That single case shows both halves of the problem clinical research organizations, sponsors, and their vendors are still underfunding: data integrity in the systems that record what happened and data integrity in the systems that control what gets shipped, labeled, and dosed. Neither failure was caught by the validation package for the systems involved. Both were caught by an FDA inspection, after the fact.

I spent part of my career at PwC working on IT general controls (ITGCs), business process controls, and application security assessments across regulated industries. The pattern I saw repeatedly: Teams pour their compliance budget into proving a system performs its intended function and computerized system validation, and they leave almost nothing for the controls that determine whether the system stays trustworthy for the years a trial actually runs.

Validation And Controls Answer Different Questions

Computerized system validation answers: Does this system perform its intended function correctly? IT general controls answer a different question: Can you trust that only the right people changed the right things, at the right time, with the right approval, for as long as the system has been running, whether that system is an electronic data capture (EDC) platform, an electronic clinical outcome assessment (eCOA) tool, a lab data system, or an interactive response technology (IRT) platform managing drug supply?

In a clinical supply environment, that means a control failure can change more than what appears in a system record. A configuration change to a randomization rule, treatment assignment, resupply threshold, or depot inventory setting can directly affect what product is shipped, when it is shipped, and which patient receives it. The control therefore has to protect the supply decision itself, not simply the integrity of the application.

A system can pass every functional test in its validation package and still fail here. The three cases below did.

Three real failures, three different systems:

A sponsor's eCOA and supply data, deleted by a vendor. The Applied Therapeutics case above is a vendor access and audit trail failure. The sponsor did not delete the data. A vendor did, and the sponsor was still held responsible, because ITGCs are ultimately the sponsor's obligation regardless of who operates the system.² The dosing error, tied to a mislabeled investigational product, shows the same gap on the supply side: nobody had a control in place to catch a mismatch between what the label said and what patients received.

A site's source records were lost when a vendor closed its system. In March 2025, the FDA issued a warning letter to a clinical investigator after an inspection found that source records for one study were unavailable because the company supplying the investigational product had closed its EDC system, taking adverse event source data with it.³ Nobody had a plan for what happens to the records when a vendor relationship ends. That is a program development and implementation control gap: System decommissioning was never built into the plan the way system go-live was.

A lab's electronic data was deleted with no access controls to trace it. An FDA warning letter to an analytical laboratory found 36 deleted electronic data files and no unique user account access controls, meaning multiple staff shared login credentials and nobody could reconstruct who deleted what.⁴ This is the access-to-programs-and-data domain in its purest form: If you cannot identify who touched the data, you cannot trust the data.

Three different organizations, three different system types, and the same root cause each time: nobody owned the question of who could touch the data after the system went live. Validation had already signed off on all three. None of the three validation packages asked who has access, what changed, or what happens when a vendor leaves.

The Four Domains That Matter Most

IT general controls break down into four domains, and all four apply directly to the systems above, not just to financial reporting systems, which is where most teams first learn the framework.

Access to programs and data. Who can see or change source records, eCOA entries, or IRT allocations, and is that access reviewed on a schedule rather than granted once and forgotten? Shared login credentials, such as those found at the analytical lab above, make this question unanswerable by design.

Program changes. Every configuration change to a randomization algorithm, an eCOA scoring rule, or a supply threshold should carry a change ticket, a documented reason, a tested outcome, and an approval from someone who did not make the change. For clinical supply teams, the review also needs to ask what downstream operational activity the change will trigger. A seemingly minor IRT change can alter resupply calculations, inventory positioning, or depot activity across multiple countries, making change control part of supply risk management rather than an IT-only exercise.

Program development and implementation. This domain covers onboarding a new system and decommissioning an old one. The Lightner case shows what happens when only the first half is planned: a vendor's EDC system is closed, and nobody has defined where the records will live afterward.

Computer operations. Backup, incident response, and business continuity determine whether a system that goes down for 6 hours during a critical window can still produce the records an inspection or a safety review will need later.

How does this reach the clinic?

None of these three cases are IT hygiene stories. The Applied Therapeutics dosing error affected real patients, who received only a fraction of their intended dose. The Lightner case involved hospitalizations for acute kidney injury and abdominal conditions that were not properly documented as serious adverse events, in part because the records infrastructure around the trial had gaps.³ A missing audit trail removes the evidence a safety board needs to catch a problem while it is still happening, long before a warning letter documents it after the fact.

The 3 Questions To Ask About Your Critical Systems

Pick your three most critical trial systems, likely an EDC or eCOA platform, an IRT or supply system, and a lab or site system your trial depends on, and ask three questions about each: Who has access today and when was that access last reviewed, what happens to the records if the vendor operating this system exits the relationship, and can you produce a complete audit trail for the last 12 months without asking the vendor for help? If the answer to any of those is unclear, treat the system as documented but unproven, no matter what its validation package says.

For a supply system, the test should go one step further: Could the team reconstruct why a particular shipment, resupply decision, or treatment assignment occurred, who authorized the underlying configuration, and whether the inventory data driving that decision was trustworthy at the time? If not, the system may be validated, but the supply process it supports is not fully controlled.

References:

1. FDA Warning Letter to Applied Therapeutics, Inc. (ref. 24-HFD-45-11-01), issued November 27, 2024, following a BIMO inspection of the AT-007-1002 trial: www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/applied-therapeutics-inc-696833-120320243FDA Warning Letter to Applied Therapeutics, Inc., November 27, 2024, on sponsor responsibility for third-party vendor data integrity under 21 CFR Part 11 (same letter as reference 1): www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/applied-therapeutics-inc-696833-12032024
2. FDA Warning Letter to Amy Lightner, MD (CBER-25-682593), issued March 25, 2025: www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/amy-lightner-md-682593-03252025
3. FDA Warning Letter to Missouri Analytical Laboratories, Inc. (WL #615319), issued September 30, 2021, following a May 2021 inspection: www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/missouri-analytical-laboratories-inc-615319-09302021

About The Author:

Eshaan Jain is a senior consultant for Mphasis and serves as the lead product owner for Salesforce/Vlocity CPQ and CLM at T-Mobile, engaged through Mphasis’s consulting services. He previously worked on IT general controls (ITGCs), business process controls, and application security assessments at PwC and Accenture. He is an IEEE senior member and holds professional membership with Forbes Tech Council, ACM, IEEE, Isaca, and AAAI.