Cloud validation goes wrong in a specific and predictable way: the organisation validates what it can see, assumes the vendor has handled the rest, and discovers at audit that nobody wrote down where the line was.
The line is the deliverable. Not a questionnaire, not a certificate — a document stating for each layer who is responsible, what evidence exists, and who holds it. Most organisations have that knowledge spread across three people and no page.
This is how we build it on cloud & SaaS validation engagements.
The layers, and who owns each
Start by naming the layers rather than arguing about the word cloud. The split differs between infrastructure, platform and software services, and getting it explicit is most of the work.
Physical and infrastructure. Data centres, hardware, hypervisor, network. Always the provider. Your obligation is to establish that they qualify it and to obtain evidence of that — which for the large hyperscalers means certifications and audit reports rather than test scripts, and that is a reasonable position provided you record it as such.
Platform and application. Operating system, database, application code, and the release process that changes them. For SaaS this is the provider's, and it is the layer where your validated state acquires a dependency you do not control.
Configuration. Yours, always, without exception. Workflows, roles, master data, business rules, reports. This is where your intended use lives and no vendor evidence reaches it.
Data and its integrity. Yours. The provider stores it; you are accountable for it.
Intended use and the validation conclusion. Yours. A vendor can prove the software works. They cannot prove it works for what you are using it for, because they do not know your process.
The question that decides your approach
How much notice do you get before a production change, and can you defer it?
Everything else follows. If you receive meaningful notice, can test in a sandbox that receives the update first, and can defer production if regression testing finds a problem, then you can keep operating a change-control model that resembles on-premise validation.
If the provider updates production on their schedule with little notice and no deferral, you cannot. The honest response is to stop pretending you control change and move to monitoring with a defined response: know what changed, have a way to detect behaviour you did not expect, and have a documented process for what happens when you find it.
Both positions are defensible. What is not defensible is a change control procedure describing an approval step that the vendor does not actually wait for. Inspectors find that quickly, because the procedure and the release notes disagree.
What to obtain from the provider, and what you will not get
Be realistic about this, because an unrealistic expectation produces an empty file rather than a mitigation.
From a large hyperscaler you will generally get certifications, audit reports under established frameworks, and documentation of their qualification approach. You will not get their test scripts, and asking for them signals inexperience. Record what you obtained, assess whether it is adequate for the layers they own, and note what you could not obtain.
From a life sciences application vendor you can reasonably expect more: a validation or qualification package for the application, test evidence you can review, documentation of their release and regression process, and a clear statement of the responsibility split. A vendor in this market who declines all of that is telling you something.
Where you cannot obtain evidence, the mitigation is your own testing of the behaviour you depend on, plus a documented assessment of the residual risk. supplier qualification is where this gets structured so it reads as a decision rather than a gap.
Multi-tenancy, residency and exit
Three questions that rarely appear in a validation plan and reliably appear in an audit.
Tenant segregation. How is your data separated from other customers, and what evidence supports it. You will not be shown the architecture in detail; you should be told the model and be able to record it.
Data residency. Where the data physically sits, including backups and any processing in other regions. This matters for privacy obligations as much as GxP, and the backup answer is the one people have not checked.
Exit. What happens to your records if the relationship ends — what you receive, in what format, and whether you can still read it without the vendor's software. Retention obligations outlast most contracts, and a readable export is the only real answer.
Qualifying the configuration, which is the part that is yours
Since configuration is unambiguously your responsibility, it is where scripted, boundary-focused testing belongs: roles and permissions including segregation of duties, workflow and approval routing, electronic signature behaviour, any calculation or rule you configured, and the integrations you built.
The broad surface of supplied functionality you did not configure — navigation, search, standard reports — is a candidate for unscripted testing or for vendor evidence under the FDA's Computer Software Assurance guidance, finalised in September 2025 and reissued in February 2026. The condition, as always, is that you record the reasoning. CSA services is where that becomes the deliverable rather than an omission.
Keeping it valid
A cloud system changes without asking you, which makes periodic review more load-bearing than it is on-premise rather than less. Set the interval before go-live and schedule the first one.
What to check: does the configuration specification still match the live configuration, what has the vendor changed since the last review and did any of it touch functionality you rely on, is the supplier assessment still current — one that predates two platform versions describes a product you are not running — and has anything changed about residency or subprocessors.
cloud & SaaS validation and audit readiness are the practices. book a demo if you want a shared-responsibility matrix built for a system you already run.
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.
