Validating a SaaS eClinical System: Who Does What
A vendor validates the software as a product. You validate your configured use of it. Four documents are always yours regardless of what the vendor supplies: the validation plan, the requirements and configuration specification, test evidence for your build, and the validation summary with its release decision.
Cloud delivery changed where the software runs and left the regulatory obligation exactly where it was. The organization running the study is responsible for assurance that the system is fit for its intended use, and intended use is a property of your study rather than of the product.
This guide sets out the responsibility split layer by layer, the four documents that cannot be delegated, how to qualify a vendor proportionately, and the upgrade question that is easier to answer before signature. It sits under what you own and what the vendor owns in eClinical validation.
After reading this you will be able to:
- Draw the responsibility line layer by layer rather than system by system
- Identify which validation documents a vendor can never supply
- Size vendor qualification to risk instead of auditing everyone or nobody
- Settle the platform upgrade question before it becomes an incident
The Responsibility Split
Reading down that table, the vendor column thins out and disappears. Infrastructure and platform security are genuinely theirs, with your obligation being to assess that what they provide is adequate and to record that assessment. Product function is theirs to validate and yours to review.
From configuration downward there is no meaningful vendor column. They supply tools. What you build with those tools, who you let use it, how data moves through it and what your people are instructed to do are entirely yours, and that is where inspections go.
The Four That Are Always Yours
The second is the one that proves the point. A requirements and configuration specification states what you need the system to do for this study and how you set it up to do that. A vendor cannot write it, because they do not know your protocol, and no amount of product documentation substitutes for it.
The first document is where reliance on vendor evidence becomes defensible. Naming inside your own validation plan which vendor evidence you are relying on, and stating what it does not cover, converts an implicit assumption into a documented decision. That single paragraph does more for an inspection than a folder of vendor certificates.
Qualifying the Vendor
Proportionality is the operative principle. A system holding primary endpoint data for a pivotal study justifies more scrutiny than a scheduling tool, and applying the same questionnaire to both means one is over-examined and the other under-examined.
The fourth step is the one organizations skip. Deciding what triggers a reassessment, such as a significant release, a security incident, an ownership change or simply elapsed time, turns qualification from a one-off purchase activity into the ongoing oversight that Annex 11 expects. Where that expectation differs between frameworks is covered in Annex 11 and Part 11 side by side.
What IQ, OQ and PQ Mean When You Install Nothing
The traditional qualification stages assume you installed software on hardware you control. In a SaaS arrangement that assumption does not hold, which leaves teams unsure whether the structure still applies.
The concepts survive, with changed emphasis. Installation qualification becomes confirmation that you are operating in the environment you qualified, with access correctly provisioned and the expected version in place. Operational qualification covers whether your configuration behaves as specified. Performance qualification covers whether it performs for your intended use with realistic data and realistic users.
Some organizations keep the labels because their quality system is built on them. Others move to a risk-based structure organized around intended use and assurance activity, which is the direction described in what the assurance approach changes in practice. Either is defensible provided the reasoning is written down.
The Upgrade Question
This is the part of SaaS validation that has no equivalent in the on-premise world, and it is the one most often discovered rather than planned.
Your vendor will upgrade the platform on their schedule. Your validated state is therefore affected by changes you did not initiate and may not have asked for. Four things need to be established, ideally before signature: how much notice you receive, whether a sandbox is available to test in advance, what their release documentation contains, and what your own process is for assessing whether a given release requires action.
That last one is yours and is frequently absent. A release assessment does not have to be heavy, but there should be a defined route by which someone looks at what changed, decides whether it touches anything you validated, and records the decision. These are among the questions worth putting to a vendor during evaluation, alongside the others in twelve questions to ask an EDC vendor before you sign.
The Clinera accelerator covers how a study is stood up with the customer-side validation path built in, and clinical and R&D AI covers the additional questions that arise when a system includes adaptive components.
References
- Annex 11, Computerised Systems. EudraLex Volume 4, Good Manufacturing Practice guidelines. health.ec.europa.eu
- 21 CFR Part 11, Electronic Records; Electronic Signatures. US Code of Federal Regulations, Title 21, Part 11. www.ecfr.gov
- ICH E6(R3) Good Clinical Practice. International Council for Harmonisation, adopted 6 January 2025. www.ich.org
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
If the vendor is validated, are we validated?
No. A vendor validates the software as a product, covering their development lifecycle and product testing. You validate your configured use of it: the study you built, the edit checks you specified, the roles you assigned, the integrations you connected and the procedures your people follow. The two are different exercises producing different evidence, and conflating them is the most expensive misunderstanding in eClinical procurement.
What validation documents are always ours?
Four. A validation plan scoped to your configuration and use. A requirements and configuration specification saying what you need the system to do and how you set it up. Test evidence covering your build rather than the product. And a validation summary with a release decision. No vendor certificate substitutes for any of them, because none of them is about the product.
How much should we rely on vendor evidence?
As much as it genuinely covers, which is usually more than teams assume for product function and less than they assume for configuration. The useful exercise is a gap analysis: list what their evidence demonstrates, then list what your intended use requires, and the difference is your scope. Naming the vendor evidence you are relying on inside your own validation plan is what makes that reliance defensible rather than implicit.
Does IQ, OQ and PQ still apply to a cloud system?
The concepts apply, though the shape changes. Installation qualification has limited meaning when you do not install anything, so it typically becomes confirmation that the environment is the one you qualified and that access is correctly provisioned. Operational and performance qualification remain yours, focused on your configuration and whether it performs for your intended use. Some organizations retain the labels and some move to a risk-based structure instead.
What happens when the vendor upgrades the platform?
This is the question most worth settling before signature. A SaaS vendor will upgrade on their schedule, and your validated state is affected by changes you did not initiate. You need to know what notice you get, whether you can test in advance in a sandbox, what their release documentation contains, and what your own assessment process is for deciding whether a release requires any action from you.
Can Nirmitee Healthtech produce the validation package for a system we have bought?
Yes, and the starting point is the gap analysis between what the vendor supplies and what your intended use requires. That determines scope, which determines effort. The deliverable is the four documents above plus the test evidence, sized by risk. Clinera is built with the customer-side validation path in mind, including the sandbox and release notification elements that make upgrades manageable.
