Shared Responsibility Model nel Cloud GxP: matrice ruoli e responsabilità per IaaS, PaaS e SaaS

In un progetto cloud GxP la domanda che decide il successo (o un finding in audit) è sempre la stessa:

“Ok, ma chi fa cosa?”

Il cloud sposta attività operative (patching, infrastruttura, security hardening, backup, monitoring) verso il provider. Ma la compliance resta tua: puoi delegare attività, non la responsabilità finale.

Questa pagina ti aiuta a:

• capire differenze reali fra IaaS/PaaS/SaaS (in termini di controlli),
• costruire una Responsibility Matrix che regge in audit,
• trasformare la matrice in Quality Agreement + SOP + evidenze.

Che cos’è (davvero) il Shared Responsibility Model in contesto GxP

Il principio è semplice:

• il provider gestisce una parte dello stack e fornisce controlli/garanzie,
• tu gestisci la parte rimanente e devi dimostrare che l’insieme produce un sistema controllato,
• in ispezione, se c’è una lacuna, non puoi dire “era del vendor”: devi mostrare come l’hai governata.

La guida lo esplicita chiaramente: in cloud alcune responsabilità diventano condivise, ma l’azienda regolata deve assicurare tramite contratti, audit e governance che il provider operi con standard adeguati.

IaaS vs PaaS vs SaaS: come cambia “il peso” delle responsabilità

Regola pratica (molto utile per QA e IT):

• SaaS: molte responsabilità tecniche sono del provider → tu governi configurazione, accessi, processi, data governance, change/upgrade, uso previsto, training.
• IaaS: più responsabilità rimangono a te (OS, patching, hardening, backup, monitoring, ecc.) → sforzo di compliance più vicino a on-prem.

La guida sintetizza: nel SaaS gran parte dello stack è gestito dal provider; andando verso IaaS aumentano oneri e controlli in capo al cliente.

La matrice che funziona: domini di controllo + ownership + evidenze

Una Responsibility Matrix “audit-proof” non è una tabella generica. Deve rispondere a 3 domande:

1. Chi esegue l’attività? (Provider / Cliente / Condiviso)
2. Chi approva/decide? (spesso QA/Business)
3. Qual è l’evidenza? (report, log, procedura, ticket, audit report, SOC report, ecc.)

Ecco un esempio di struttura (adatta a CMS/Excel):

Dominio	Esecuzione	Approvazione	Evidenze tipiche
Accessi & ruoli (RBAC)	Cliente	QA/Process Owner	matrice ruoli, log accessi, SOP account
Audit trail	Provider (funzione) + Cliente (review)	QA	audit trail config, SOP review, record review
Backup/restore	Provider / Condiviso	IT + QA	policy backup, report, test restore, ticket
Change/upgrade	Provider (rilascio) + Cliente (valutazione)	QA	release notes, change record, test regressione
Incident/RCA	Provider + Cliente	QA	RCA, deviation/CAPA, comunicazioni
Data export/retention	Condiviso	QA/RA	export test, procedure, contratto

Nota: i domini e le evidenze vanno calibrati su modello (SaaS/IaaS) e criticità.

Dal workshop al documento: le domande “giuste” da fare al fornitore

Una matrice di responsabilità robusta nasce da un workshop con vendor + QA + IT + business.

Esempi di domande ad altissimo valore (e spesso ignorate):

• “Chi effettua il restore se un utente cancella dati per errore: noi da interfaccia o voi su richiesta?”
• “Chi garantisce che i backup funzionino e che report riceviamo?”
• “Ci date una sandbox/staging per testare nuove release prima della produzione?”

La guida consiglia esplicitamente di chiarire questi punti e poi riportarli nella matrice e nel Quality Agreement.

Come trasformare la matrice in governance reale (e non “un PDF nel cassetto”)

1) Quality Agreement (QA) / allegati contrattuali

Qui “fissi” gli impegni:

• change notification (tempi, contenuto release note)
• gestione incidenti e RCA
• proprietà e restituzione dati / exit
• diritto di audit e accesso a evidenze (es. SOC report)

2) SOP interne

Senza SOP, la matrice non vive:

• SOP gestione account e privilegi
• SOP audit trail review
• SOP change control cloud (incluso update SaaS)

3) Evidenze operative

In audit non basta dire “abbiamo la SOP”: devi mostrare l’uso.

• registri di review
• change record chiusi con test
• training log
• periodic review

Errori da evitare (quelli che fanno “scattare” le domande dell’auditor)

• Matrice scritta, ma non allineata a contratto/QA
• “Tutto in capo al vendor” senza diritto di audit o evidenze
• Ruoli e accessi senza segregazione
• Assenza di una regola chiara su update SaaS (come e quando si accettano)

Mini-checklist (pronta da copiare in SOP)

• Esiste una Responsibility Matrix per ogni fornitore cloud GxP
• La matrice include esecuzione, approvazione e evidenze
• I punti critici (backup, audit trail, change, RCA) sono coperti da Quality Agreement
• Le SOP interne riflettono il modello cloud (non solo on-prem)
• In audit pack esistono prove di esecuzione (record, report, log)

Vuoi una struttura completa con esempi, checklist e template per definire ruoli/responsabilità e presentarle in audit? Acquista la guida “SaaS & Cloud Validation: guida all’implementazione GxP” su guidegxp.com.