Moving a GxP workload to a cloud provider does not move the compliance obligation with it. Cloud service provider qualification establishes what the provider is actually responsible for, what evidence proves they meet it, and what remains the customer's job under the shared responsibility model, before a single validated workload goes live on the platform.
Shortcut: A provider's ISO or SOC 2 certificate proves their controls exist. It does not prove your specific configuration and intended use are validated.
At a glance
| Area | Question | Evidence |
|---|---|---|
| Responsibility mapping | What does the provider own vs. the customer? | Documented shared responsibility matrix |
| Certifications | Third-party attestations the provider holds | SOC 2, ISO 27001, or equivalent reports reviewed |
| Change notification | How and when the provider notifies of changes | Contractual notification terms, SLA |
| Ongoing oversight | Periodic reassessment, not one-time approval | Scheduled requalification, audit rights |
Map shared responsibility before assuming coverage
Infrastructure-as-a-service, platform-as-a-service, and software-as-a-service each shift the responsibility line differently. Document exactly which controls the provider owns and which remain the customer's responsibility for the specific service model in use, rather than assuming a general cloud certification covers everything.
Request evidence, don't accept marketing claims
A vendor's website stating "we are compliant" is not evidence. Request the actual third-party attestation reports — SOC 2 Type II, ISO 27001 certificates, penetration test summaries — and review them for scope, exceptions noted, and date of the most recent audit, not just the headline claim.
- Confirm the attestation scope actually covers the service and region being used.
- Check the report date; an attestation from three years ago says little about current controls.
- Review noted exceptions or qualifications in the report, not just the overall opinion.
Contract for change notification, then honor it operationally
A provider's obligation to notify of infrastructure or service changes only helps if the customer's side actually has a process to receive and assess those notifications. Both the contractual notification term and the internal review process need to exist together; one without the other leaves a gap.
Qualify continuously, not once at onboarding
A provider qualified at onboarding can drift in control maturity, change subcontractors, or alter their infrastructure over the life of the relationship. Schedule periodic requalification — reviewing updated attestation reports, confirming no material change to the responsibility mapping — rather than treating the initial qualification as permanent.
Preserve audit and access rights in the contract
When a regulator asks for evidence about a cloud-hosted GxP system, the customer needs the contractual right to obtain it from the provider, sometimes on short notice. Negotiate audit rights and evidence-access terms into the contract before go-live, not after an inspection request arrives.
Why this matters at review time
As GxP workloads move to cloud infrastructure at scale, regulators have made clear that outsourcing a function does not outsource the compliance obligation; the customer remains accountable for the validated state regardless of where the infrastructure physically runs. A documented qualification process, reviewed evidence, and ongoing oversight are what demonstrate that accountability was actually exercised, not just assumed to transfer with the contract.
Who owns what
| Role | Responsibility |
|---|---|
| Procurement/vendor management | Leads initial qualification and evidence collection |
| Quality assurance | Reviews attestation reports and approves the shared responsibility mapping |
| IT/infrastructure | Implements customer-side controls per the responsibility split |
| Vendor management | Owns periodic requalification and notification review |
Common mistakes to avoid
- Accepting a certification badge without reading the report. A certification logo on a vendor's website says nothing about scope, exceptions, or currency; the actual attestation report is the evidence, not the badge.
- Assuming the shared responsibility model is the same across service types. IaaS, PaaS, and SaaS shift the responsibility line differently; applying one assumed split across all provider relationships leaves gaps uninvestigated.
- No internal process to receive vendor change notifications. A contractual notification clause is worthless if nobody on the customer side is assigned to receive, triage, and act on what the provider sends.
- Treating initial qualification as permanent. A provider's control maturity, subcontractors, and infrastructure can all change after onboarding; qualification needs to be revisited, not filed away.
Putting this into practice
Request and actually read the underlying attestation report for every cloud provider hosting a GxP workload, checking scope and date, not just the certification claim. Document the shared responsibility split specifically for the service model in use. Assign an internal owner to receive and act on vendor change notifications. Schedule periodic requalification on a risk-proportional interval.
Quick checklist
- Shared responsibility mapping documented for the specific service model in use
- Actual attestation reports requested and reviewed, not just certification claims
- Attestation scope and date checked against the service and region actually used
- Change notification terms exist in the contract and are received by an assigned owner
- Audit and evidence-access rights are written into the contract before go-live
- Requalification scheduled on a periodic, risk-proportional interval
Where this shows up in practice
The qualification process proves its worth the moment something goes wrong at the provider's end: an outage, a security incident, or a subcontractor change that affects data handling. A customer with a documented responsibility mapping and contractual evidence-access rights can quickly determine what happened, what it means for their validated state, and what evidence they can request. A customer that qualified the provider only informally, without reviewed evidence or contractual access rights, is left negotiating for basic information at the exact moment speed and clarity matter most.
A worked example
Consider a scenario where a cloud provider notifies customers of a planned subcontractor change for a specific regional data center, and the customer's vendor management team needs to determine whether this affects their validated workload's compliance posture. Without a documented shared responsibility mapping specific to their service model, the team cannot quickly determine whether subcontractor changes are something the provider's existing SOC 2 attestation already covers, or a new risk requiring independent assessment. A team with the mapping already documented can answer the question in an afternoon by checking which controls the attestation scope covers and whether the subcontractor change falls inside or outside that boundary. A team without it spends weeks reconstructing the relationship from scratch, exactly when a fast, confident answer is needed to satisfy an internal governance review or, worse, a regulator's direct question.
A validation lifecycle management platform that stores the shared responsibility mapping, attestation review dates, and requalification schedule for every connected vendor gives a vendor management function one place to answer a regulator's question about any specific provider, instead of reconstructing the qualification history from contracts and email archives under time pressure.
For related control detail, see the SaaS shared responsibility model and the supplier audit checklist elsewhere in this archive.
Frequently asked questions
Does a cloud provider's SOC 2 report replace the need for customer validation?
No. It provides evidence about the provider's controls for the services they own under the shared responsibility model, but the customer's specific configuration and intended use still require validation.
What is the shared responsibility model in cloud GxP hosting?
A framework defining which security, availability, and operational controls the cloud provider owns versus which remain the customer's responsibility, varying by service model (IaaS, PaaS, SaaS).
How often should a cloud provider be requalified?
Periodically, on a defined schedule proportional to risk, reviewing updated attestation reports and confirming no material change to the original responsibility mapping.
What should be included in a cloud vendor contract for GxP use?
At minimum: change notification terms, audit and evidence-access rights, and defined service level commitments relevant to the validated workload.
Sources
Talk to VLMS about your validation programme
See how VLMS supports supplier and cloud controls with a validated, audit-ready platform.
Contact VLMS