Shared Responsibility Model in Cloud GxP: Roles and Responsibility Matrix for IaaS, PaaS and SaaS

In a Cloud GxP project, there is one question that determines success—or an audit finding:

“Okay, but who does what?”

The cloud shifts operational activities (patching, infrastructure, security hardening, backup, monitoring) to the provider. Compliance, however, remains yours: you can delegate activities, not the final responsibility.

This page helps you to:

• understand the real differences between IaaS, PaaS and SaaS (in terms of controls),
• build a responsibility matrix that stands up in an audit,
• transform the matrix into Quality Agreements + SOPs + evidences.

What the Shared Responsibility Model really means in a GxP context

The principle is simple:

• the provider manages part of the stack and delivers controls/assurances,
• you manage the remaining part and must demonstrate that the whole system is controlled,
• during inspection, if a gap exists, you cannot say “it was the vendor’s fault”: you must show how you governed it.

The guidance is clear: in the cloud, some responsibilities are shared, but the regulated company must ensure—through contracts, audits and governance—that the provider operates to appropriate standards.

IaaS vs PaaS vs SaaS: how the “weight” of responsibility changes

Practical rule (very useful for QA and IT):

• SaaS: many technical responsibilities sit with the provider → you govern configuration, access, processes, data governance, changes/upgrades, intended use and training.
• IaaS: more responsibilities remain with you (OS, patching, hardening, backup, monitoring, etc.) → compliance effort is much closer to on-prem.

In short: in SaaS, most of the stack is managed by the provider; moving toward IaaS increases customer responsibilities and required controls.

The matrix that works: control domains + ownership + evidence

An audit-proof Responsibility Matrix is not a generic table. It must answer three questions:

1. Who performs the activity? (Provider / Customer / Shared)
2. Who approves or decides? (often QA / Business)
3. What is the evidence? (reports, logs, SOPs, tickets, audit reports, SOC reports, etc.)

Example structure (suitable for CMS/Excel):

Note: domains and evidences must be tailored to the cloud model (SaaS/IaaS) and system criticality.

From workshop to document: the “right” questions to ask the vendor

A robust responsibility matrix is built through a workshop involving vendor, QA, IT and business.

Examples of high-value questions (often overlooked):

• “Who performs the restore if a user deletes data by mistake: us via the interface or you upon request?”
• “Who ensures backups are working and what reports do we receive?”
• “Do you provide a sandbox/staging environment to test new releases before production?”

The guidance explicitly recommends clarifying these points and then documenting them in the matrix and the Quality Agreement.

How to turn the matrix into real governance (not just “a PDF in a drawer”)

1) Quality Agreement (QA) / contractual annexes

This is where commitments are fixed:

• change notification (timing and content of release notes),
• incident management and RCA,
• data ownership, return and exit strategy,
• audit rights and access to evidence (e.g. SOC reports).

2) Internal SOPs

Without SOPs, the matrix does not live:

• SOP for account and privilege management,
• SOP for audit trail review,
• SOP for cloud change control (including SaaS updates).

3) Operational evidence

In an audit, it is not enough to say “we have a SOP”—you must show it in use:

• review logs,
• closed change records with testing,
• training records,
• periodic reviews.

Common mistakes (that trigger auditor questions)

• Matrix exists but is not aligned with contract/QA
• “Everything is vendor responsibility” without audit rights or evidence
• Roles and access without proper segregation of duties
• No clear rule for SaaS updates (how and when they are accepted)

Mini-checklist (ready to copy into SOPs)

• A Responsibility Matrix exists for each GxP cloud provider
• The matrix includes execution, approval and evidence
• Critical areas (backup, audit trail, change, RCA) are covered by the Quality Agreement
• Internal SOPs reflect the cloud model (not only on-prem)
• The audit pack contains proof of execution (records, reports, logs)

Do you want a complete structure with examples, checklists and templates to define roles and responsibilities and present them clearly in audits? Purchase the guide “SaaS & Cloud Validation: Implementation Guide for GxP” on guidegxp.com.