When a sponsor uses an electronic data capture system run by a vendor or a CRO, it is tempting to treat validation as the vendor's job. The vendor did validate its platform. But each study build is a new configuration, and the sponsor stays responsible for the data.
Here is where the line sits, and what sponsors are expected to show.
What changed recently
Two documents raised the bar. EMA's guideline on computerised systems and electronic data in clinical trials, in effect since 2023, sets out detailed expectations for systems used in trials, including EDC. ICH E6(R3), finalised in 2025, puts more weight on the reliability of computerised systems and on the sponsor's oversight of them.
Neither is a surprise for anyone who has been through a GCP inspection recently. Both make it harder to point at the vendor when asked how you know the system worked.
Platform versus study build
Think of it in two layers. The platform is the vendor's software: its audit trail, security, electronic signatures and core functions. The vendor validates it, and you assess the vendor, usually through an audit or a strong questionnaire with evidence behind it.
The study build is the forms, edit checks, derivations, visit schedule and integrations set up for your protocol. That is new each time, and it is where most errors are. Sponsors need evidence the build matches the protocol and works as intended, whoever did the building.
User acceptance testing that is real
Study build UAT is often rushed, because it lands right before first patient in. The usual result is testing that confirms forms open and save, and misses the edit check that never fires.
Focus testing on what can hurt the data: edit checks on eligibility and safety fields, derived values, visit windows, and any data that flows to or from another system such as IRT or a central lab. Test the awkward cases, not just the happy path. The same risk-based testing thinking applies here as anywhere.
Changes mid-study
Protocol amendments mean build changes while the study is live. Each one needs impact assessment, testing and a record of what changed, plus a check that existing data was not affected. Migration of data between form versions is a frequent source of findings, because it is easy to test the new form and forget the old data.
Assessing the vendor properly
Vendor assessment is where many sponsors save time and later regret it. A questionnaire returned with every answer marked yes tells you very little. Ask for evidence: the vendor's validation summary for the current platform version, how they test releases, how they control their own changes to a live study, how they handle access for their staff, and what happened in their most recent audits.
Then decide how much to rely on them, and write that down. An audit every few years, with lighter checks in between, is a reasonable pattern for a vendor you use across many studies.
At the end of the study
The sponsor needs the data, the audit trail and the metadata in a form that can be read for the whole retention period, independent of the vendor's platform. Agree the format and test the export before the study closes, not after the contract ends. We work with CROs and sponsors on this. If you want a second view of a vendor assessment, get in touch.
Where to go next
Explore GxP Copilot for AI-native validation, TraceDraft for source-traceable clinical documentation, or book a demo to see either on your own data.