Cloud Validation: Make Shared Responsibility Audit-Ready

Shared responsibility distributes cloud tasks, but it does not remove the regulated company’s accountability for GxP use. A cloud or SaaS provider may operate infrastructure, platforms, standard software and selected controls. The customer still controls intended use, configuration, data flows, access, operating procedures and release decisions. The model becomes audit-ready only when requirements, evidence and owners are mapped in a controlled way.

A provider certificate does not answer your intended-use question

The provider supplies ISO certificates, SOC reports, penetration tests, availability metrics and extensive documentation. This is valuable evidence. It still does not show whether your configured application reliably supports its intended GxP process.

That is the validation boundary. Supplier evidence can support controls operated by the provider. It cannot, by itself, demonstrate that your roles are correct, a critical workflow is configured as intended or an interface handles an error completely.

EU GMP Annex 11 requires close cooperation between process owners, system owners, Quality and IT. Responsibilities of external providers should be defined in formal agreements. The regulated organisation should assess supplier competence and reliability and be able to make audit information available on request.

Cloud and SaaS validation therefore connects provider evidence with customer-specific controls.

Four layers of shared responsibility

Layer	Typical provider responsibility	Typical customer responsibility
Infrastructure	Data centres, hardware, base network, physical security	Selection of permitted regions and services, contractual requirements
Platform and standard service	Operation, patching, backup capability, technical availability	Risk assessment, use concept, recovery requirements
Application and configuration	Standard code, documented functions, release information	Intended use, configuration, roles, workflows, interfaces, UAT
GxP process and data	Technical storage and defined service controls	Data classification, process controls, review, release, retention

The exact boundary depends on the service model. With IaaS, the customer operates more technical layers. A standard SaaS service shifts more operation to the provider. Fitness for the business process and controlled use remain customer-specific.

AWS describes this as responsibility “of the cloud” and “in the cloud”. Its GxP guidance also states that the regulated company remains responsible for determining its obligations and risk profile.

A responsibility matrix an inspector can use

A generic RACI table is not enough. The matrix should connect each critical requirement with its control, evidence, owner and review frequency.

1. Define requirements and control objectives

Examples include availability, access protection, audit trails, backup and restore, data export, tenant separation, change control, incident management and exit capability.

2. Assign operator and evidence

For each control, establish:

• Who operates the control?
• Which evidence demonstrates effectiveness?
• How current is the evidence?
• Who assesses it for the customer?
• Which residual customer control remains?

3. Make gaps and dependencies visible

A provider may demonstrate daily backups. The customer still defines required data and recovery times. A successful provider test does not automatically replace customer-specific restore or business-continuity evidence.

4. Control changes to the model

Responsibility can shift when the provider changes services, subprocessors, regions or functions. The matrix therefore needs an owner and version history.

Align contracts, Quality and operation

Contracts are controls, but they are not complete validation evidence. The service description, quality agreement, data-processing agreement and technical documentation should describe the same responsibility boundary.

For critical services, agreements should address change notification, access to relevant audit information, incident communication, data return, retention, exit support and subprocessors. Every provider commitment then needs an internal owner. A release notification only works when someone assesses it. A restore SLA only protects the process when internal restart and business acceptance are defined.

Which supplier evidence is actually usable

Evidence is not useful merely because it is extensive. It is useful when it supports a defined control objective in your scope.

Typical evidence packages include:

• current certificates and independent assurance reports;
• system and service descriptions with clear scope boundaries;
• provider development, test and release procedures;
• release notes and known limitations;
• backup, restore, incident and business-continuity evidence;
• security and access-control concepts;
• data export, retention and exit procedures;
• documented deviations and CAPA where contractually available.

The review outcome should not say only “document available”. It should identify the customer requirement supported, remaining limitations and additional controls required.

Release assurance without full revalidation for every update

Cloud releases need a repeatable impact decision. Not every update requires the same testing depth. Every update does require controlled assessment.

A defensible process covers:

1. Capture release information and affected functions.
2. Assess the change against intended use, configuration, interfaces and open risks.
3. Review provider evidence for scope and currency.
4. Select regression tests for critical processes.
5. Document deviations, approval and residual actions.
6. Update the validated state and responsibility matrix.

This follows the same risk logic as modern assurance strategy. FDA’s February 2026 CSA guidance has a specific medical-device scope and does not replace applicable pharmaceutical CGMP requirements.

Include exit capability in initial validation

Cloud validation does not end at production release. Before contract award, establish how records, metadata, audit trails, configurations and signature context can be exported.

An exit test does not need to simulate a complete migration on day one. It should demonstrate that the organisation can receive relevant data in an agreed format, verify completeness and interpret the records throughout retention. Without this control, a later provider transition becomes a time-critical data-integrity project.

Three gaps that remain despite strong provider documentation

Unclear configuration ownership. The provider documents the standard. No one owns the evidence for the customer configuration.

Evidence without a review owner. Reports are stored but not assessed against requirements, findings and validity.

Release information without process impact. Technical notes are read but not connected to critical workflows, data and interfaces.

Audit trails are also shared. The provider supplies functionality and operation; the customer defines relevance, frequency and assessment. The guide to audit trail review covers this customer control.

Frequently asked questions

Does a SOC or ISO report replace cloud validation?

No. It may support provider controls within its defined audit scope. Customer intended use, configuration, data flows, roles and operating procedures still require separate assessment and testing.

Must the customer audit the cloud provider on site?

Not automatically. Assessment depth follows risk, criticality, available independent evidence, contractual rights and unresolved questions. The decision and rationale should be documented.

How does a SaaS system remain validated through frequent releases?

Use a fixed release-assurance process: change intake, impact assessment, review of provider evidence, risk-based regression, documented approval and update of the validation status.

Primary and provider sources

• EU GMP Annex 11: Computerised Systems, effective 2011 version
• AWS: Shared Responsibility
• AWS: GxP Systems on AWS

---

Author

Daniel Herrmann Consulting — boutique consultancy for GxP compliance and Computer System Validation in pharma, biotech and MedTech. 15+ years of hands-on expertise. 60+ validated systems. 100 % audit pass rate. 0 critical findings.