Shared Responsibility Model Cloud GxP: Rollen und RACI-Matrix
Shared Responsibility Model im Cloud-GxP-Umfeld: Rollen- und Verantwortungsmatrix für IaaS, PaaS und SaaS
In einem Cloud-GxP-Projekt gibt es eine Frage, die über Erfolg oder ein Audit-Finding entscheidet:
„Okay, aber wer macht was?“
Die Cloud verlagert operative Tätigkeiten (Patching, Infrastruktur, Security Hardening, Backup, Monitoring) zum Provider. Die Compliance bleibt jedoch bei dir: Du kannst Aufgaben delegieren, nicht die finale Verantwortung.
Diese Seite hilft dir dabei:
- die realen Unterschiede zwischen IaaS, PaaS und SaaS (in Bezug auf Kontrollen) zu verstehen,
- eine auditfeste Responsibility Matrix aufzubauen,
- die Matrix in Quality Agreement + SOPs + Evidenzen zu überführen.
Was ist das Shared Responsibility Model im GxP-Kontext – wirklich?
Das Prinzip ist einfach:
- der Provider betreibt einen Teil des Stacks und stellt Kontrollen/Garantien bereit,
- du verantwortest den verbleibenden Teil und musst nachweisen, dass das Gesamtsystem kontrolliert ist,
- in der Inspektion gilt: Gibt es eine Lücke, kannst du nicht sagen „das war der Vendor“ – du musst zeigen, wie du sie gesteuert hast.
Die Leitlinie stellt klar: Im Cloud-Umfeld werden einige Verantwortlichkeiten geteilt, die regulierte Organisation muss jedoch durch Verträge, Audits und Governance sicherstellen, dass der Provider angemessene Standards einhält.
IaaS vs. PaaS vs. SaaS: Wie sich das „Gewicht“ der Verantwortung verschiebt
Praxisregel (sehr hilfreich für QA und IT):
- SaaS: Viele technische Verantwortlichkeiten liegen beim Provider → du steuerst Konfiguration, Zugriffe, Prozesse, Data Governance, Changes/Upgrades, Intended Use und Training.
- IaaS: Mehr Verantwortung bleibt beim Kunden (OS, Patching, Hardening, Backup, Monitoring etc.) → der Compliance-Aufwand ist näher an On-Prem.
Zusammengefasst: Bei SaaS wird ein Großteil des Stacks vom Provider betrieben; je näher man sich IaaS nähert, desto mehr Pflichten und Kontrollen liegen beim Kunden.
Die Matrix, die funktioniert: Kontroll-Domänen + Ownership + Evidenzen
Eine audit-taugliche Responsibility Matrix ist keine generische Tabelle. Sie muss drei Fragen beantworten:
- Wer führt die Aktivität aus? (Provider / Kunde / Shared)
- Wer genehmigt/entscheidet? (oft QA/Business)
- Welche Evidenz existiert? (Report, Log, SOP, Ticket, Audit-Report, SOC-Report etc.)
Beispielstruktur (geeignet für CMS/Excel):
| Domäne | Ausführung | Genehmigung | Typische Evidenzen |
|---|---|---|---|
| Zugriffe & Rollen (RBAC) | Kunde | QA / Process Owner | Rollenmatrix, Access-Logs, Account-SOP |
| Audit Trail | Provider (Funktion) + Kunde (Review) | QA | Audit-Trail-Konfig., Review-SOP, Review-Records |
| Backup/Restore | Provider / Shared | IT + QA | Backup-Policy, Reports, Restore-Tests, Tickets |
| Change/Upgrade | Provider (Release) + Kunde (Bewertung) | QA | Release Notes, Change Record, Regressionstests |
| Incident/RCA | Provider + Kunde | QA | RCA, Deviation/CAPA, Kommunikation |
| Data Export/Retention | Shared | QA/RA | Export-Tests, SOPs, Vertrag |
Hinweis: Domänen und Evidenzen müssen auf Modell (SaaS/IaaS) und Kritikalität abgestimmt werden.
Vom Workshop zum Dokument: die „richtigen“ Fragen an den Anbieter
Eine belastbare Responsibility Matrix entsteht aus einem Workshop mit Vendor + QA + IT + Business.
Beispiele für hochrelevante (und oft übersehene) Fragen:
- „Wer führt das Restore durch, wenn ein User Daten versehentlich löscht – wir über die Oberfläche oder ihr auf Anfrage?“
- „Wer stellt sicher, dass Backups funktionieren, und welche Reports erhalten wir?“
- „Gibt es eine Sandbox/Staging-Umgebung, um neue Releases vor Produktion zu testen?“
Die Leitlinie empfiehlt ausdrücklich, diese Punkte zu klären und anschließend in Matrix und Quality Agreement festzuhalten.
Wie man die Matrix in echte Governance überführt (und nicht zu „einem PDF in der Schublade“)
1) Quality Agreement (QA) / vertragliche Anhänge
Hier werden die Verpflichtungen fixiert:
- Change-Notification (Zeitpunkte, Inhalt der Release Notes)
- Incident-Management und RCA
- Datenhoheit, Rückgabe und Exit
- Audit-Rechte und Zugriff auf Evidenzen (z. B. SOC-Reports)
2) Interne SOPs
Ohne SOPs lebt die Matrix nicht:
- SOP Account- und Berechtigungsmanagement
- SOP Audit-Trail-Review
- SOP Cloud-Change-Control (inkl. SaaS-Updates)
3) Operative Evidenzen
Im Audit reicht „wir haben eine SOP“ nicht – die Anwendung muss gezeigt werden:
- Review-Register
- abgeschlossene Change Records mit Tests
- Trainingsnachweise
- Periodic Reviews
Typische Fehler (die Auditor-Nachfragen auslösen)
- Matrix existiert, ist aber nicht mit Vertrag/QA abgestimmt
- „Alles beim Vendor“ ohne Audit-Rechte oder Evidenzen
- Rollen und Zugriffe ohne Segregation of Duties
- Keine klare Regel für SaaS-Updates (wie und wann akzeptiert)
Mini-Checkliste (bereit für SOP-Übernahme)
- Für jeden GxP-Cloud-Provider existiert eine Responsibility Matrix
- Die Matrix enthält Ausführung, Genehmigung und Evidenzen
- Kritische Punkte (Backup, Audit Trail, Change, RCA) sind im Quality Agreement geregelt
- Interne SOPs spiegeln das Cloud-Modell wider (nicht nur On-Prem)
- Im Audit-Pack gibt es Nachweise der Umsetzung (Records, Reports, Logs)
Möchtest du eine vollständige Struktur mit Beispielen, Checklisten und Templates, um Rollen/Verantwortlichkeiten zu definieren und im Audit sauber darzustellen?
Dann kaufe die Anleitung „SaaS & Cloud Validation: guida all’implementazione GxP“ auf guidegxp.com.