Cloud-Validierung: Shared Responsibility auditfähig belegen

Shared Responsibility in der Cloud verteilt Aufgaben, aber nicht die Verantwortung des regulierten Unternehmens für den GxP-Einsatz. Der Cloud- oder SaaS-Anbieter kann Infrastruktur, Plattform, Standardsoftware und bestimmte Kontrollen betreiben. Der Kunde muss dennoch Intended Use, Konfiguration, Datenflüsse, Berechtigungen, betriebliche Verfahren und Release-Entscheidungen beherrschen. Auditfähig wird das Modell erst durch eine kontrollierte Zuordnung von Anforderungen, Nachweisen und Ownern.

Das Zertifikat des Anbieters beantwortet nicht Ihre Intended-Use-Frage

Der Anbieter stellt ISO-Zertifikate, SOC-Berichte, Penetrationstests, Verfügbarkeitskennzahlen und eine umfangreiche Dokumentation bereit. Das ist wertvolle Evidenz. Trotzdem bleibt offen, ob Ihre konfigurierte Anwendung den vorgesehenen GxP-Prozess zuverlässig unterstützt.

Genau hier verläuft die Validierungsgrenze. Supplier Evidence kann Kontrollen belegen, die der Anbieter betreibt. Sie kann nicht allein zeigen, ob Ihre Rollen korrekt zugeordnet sind, ein kritischer Workflow richtig konfiguriert wurde oder Ihre Schnittstelle einen Fehler vollständig behandelt.

EU GMP Annex 11 verlangt eine klare Zusammenarbeit zwischen Prozessverantwortlichen, System Ownern, Quality und IT. Bei externen Anbietern sollen Verantwortlichkeiten in formalen Vereinbarungen festgelegt werden. Die regulierte Organisation muss Lieferanten nach Kompetenz und Zuverlässigkeit bewerten und verfügbare Auditinformationen auf Anfrage bereitstellen können.

Die Cloud- und SaaS-Validierung verbindet deshalb Provider-Nachweise mit kundenspezifischen Kontrollen.

Vier Ebenen der geteilten Verantwortung

Ebene	Typische Provider-Verantwortung	Typische Kundenverantwortung
Infrastruktur	Rechenzentrum, Hardware, Basisnetzwerk, physische Sicherheit	Auswahl zulässiger Region und Services, vertragliche Anforderungen
Plattform und Standardservice	Betrieb, Patching, Backup-Funktion, technische Verfügbarkeit	Risikobewertung, Nutzungskonzept, Wiederherstellungsanforderungen
Anwendung und Konfiguration	Standardcode, dokumentierte Funktionen, Release-Information	Intended Use, Konfiguration, Rollen, Workflows, Schnittstellen, UAT
GxP-Prozess und Daten	Technische Speicherung und definierte Servicekontrollen	Datenklassifikation, Prozesskontrollen, Review, Freigabe, Aufbewahrung

Die konkrete Grenze hängt vom Servicemodell ab. Bei IaaS betreibt der Kunde mehr technische Schichten. Bei einem standardisierten SaaS-Angebot übernimmt der Anbieter mehr Betrieb. Die fachliche Eignung und kontrollierte Nutzung bleiben jedoch kundenspezifisch.

AWS beschreibt dieses Prinzip als Verantwortung „of the cloud“ und „in the cloud“. Für GxP-Systeme betont AWS zugleich, dass die regulierte Organisation ihre regulatorischen Pflichten und ihr Risikoprofil selbst bestimmen muss.

Eine Responsibility Matrix, die ein Auditor verwenden kann

Eine allgemeine RACI-Liste reicht nicht. Die Matrix sollte jede kritische Anforderung mit Kontrolle, Evidenz, Owner und Review-Frequenz verbinden.

1. Anforderungen und Kontrollziele definieren

Beispiele sind Verfügbarkeit, Zugriffsschutz, Audit Trail, Backup und Restore, Datenexport, Mandantentrennung, Änderungskontrolle, Incident Management und Exit-Fähigkeit.

2. Betreiber und Evidenz zuordnen

Für jede Kontrolle wird festgelegt:

• Wer betreibt die Kontrolle?
• Welcher Nachweis belegt ihre Wirksamkeit?
• Wie aktuell ist der Nachweis?
• Wer bewertet ihn beim Kunden?
• Welche Restkontrolle bleibt kundenseitig?

3. Lücken und Abhängigkeiten sichtbar machen

Ein Provider kann tägliche Backups belegen. Der Kunde muss dennoch definieren, welche Daten und Wiederherstellungszeiten für den Prozess erforderlich sind. Ein erfolgreicher Provider-Test ersetzt nicht automatisch den kundenspezifischen Restore- oder Business-Continuity-Nachweis.

4. Änderungen versioniert steuern

Verantwortung verschiebt sich, wenn der Anbieter Services, Subprozessoren, Regionen oder Funktionen ändert. Die Matrix braucht deshalb einen Owner und eine Versionshistorie.

Vertrag, Qualitätssicherung und Betrieb zusammenführen

Verträge sind ein Kontrollinstrument, aber kein vollständiger Validierungsnachweis. Servicebeschreibung, Qualitätsvereinbarung, Datenschutzvereinbarung und technische Dokumentation müssen dieselbe Verantwortungsgrenze abbilden.

Für kritische Services sollte die Vereinbarung mindestens Informationspflichten bei Änderungen, Zugriff auf relevante Auditinformationen, Incident-Kommunikation, Datenrückgabe, Aufbewahrung, Unterstützung beim Exit und den Umgang mit Unterauftragnehmern regeln. Die Formulierung muss zum tatsächlich gebuchten Service passen. Ein generisches Cloud-Addendum kann wichtige Konfigurations- oder Datenflussrisiken übersehen.

Im Betrieb braucht jede vertragliche Zusage einen internen Owner. Eine zugesagte Release-Vorankündigung wirkt nur, wenn jemand sie bewertet. Ein Restore-SLA schützt den Prozess nur, wenn Wiederanlauf und fachliche Akzeptanz intern geregelt sind.

Ebenso wichtig ist die Nachweisaufbewahrung. Zertifikate, Berichte und Release-Unterlagen ändern sich. Das Team muss festlegen, welche Version eine Entscheidung gestützt hat und wie lange sie zusammen mit dem Validierungsrecord verfügbar bleibt. Ein nachträglich aktualisiertes Portal ersetzt nicht die historische Evidenz zum Zeitpunkt der Freigabe.

Bei Vertragsverlängerung oder wesentlicher Serviceänderung wird die Evidenz erneut bewertet. So bleibt die Lieferantenfreigabe mit dem aktuellen Risiko- und Betriebsmodell verbunden.

Die Bewertung bleibt damit nachvollziehbar, wiederholbar und für spätere Audits belastbar dokumentiert.

Welche Lieferantennachweise wirklich verwertbar sind

Ein Nachweis ist nicht deshalb nützlich, weil er umfangreich ist. Er ist nützlich, wenn er ein konkretes Kontrollziel im eigenen Scope belegt.

Typische Evidence-Pakete umfassen:

• aktuelle Zertifikate und unabhängige Prüfberichte;
• System- und Servicebeschreibung mit klarer Scope-Grenze;
• Entwicklungs-, Test- und Freigabeverfahren des Anbieters;
• Release Notes und bekannte Einschränkungen;
• Backup-, Restore-, Incident- und Business-Continuity-Nachweise;
• Sicherheits- und Berechtigungskonzepte;
• Datenexport-, Aufbewahrungs- und Exit-Verfahren;
• dokumentierte Abweichungen und CAPA, soweit vertraglich verfügbar.

Das Review-Ergebnis sollte nicht „Dokument vorhanden“ lauten. Es sollte benennen, welche Kundenanforderung belegt ist, welche Einschränkung bleibt und welche ergänzende Kontrolle erforderlich ist.

Release Assurance ohne Vollvalidierung bei jedem Update

Cloud-Releases erfordern eine wiederholbare Impact-Entscheidung. Nicht jedes Update braucht denselben Testumfang. Jedes Update braucht jedoch eine kontrollierte Bewertung.

Ein belastbarer Ablauf umfasst:

1. Release-Information und betroffene Funktionen erfassen.
2. Änderung gegen Intended Use, Konfiguration, Schnittstellen und offene Risiken bewerten.
3. Provider-Evidence auf Scope und Aktualität prüfen.
4. Regressionstests nach kritischen Prozessen auswählen.
5. Abweichungen, Freigabe und Restmaßnahmen dokumentieren.
6. Validierten Zustand und Verantwortungsmatrix aktualisieren.

Dieser Ansatz folgt derselben risikobasierten Logik wie eine moderne Assurance-Strategie. Die FDA-CSA-Guidance von 2026 hat jedoch einen spezifischen Medizinprodukte-Scope. Sie ist kein Ersatz für anwendbare pharmazeutische CGMP-Anforderungen.

Exit-Fähigkeit gehört in die initiale Validierung

Cloud-Validierung endet nicht beim produktiven Start. Schon vor Vertragsabschluss muss klar sein, wie Records, Metadaten, Audit Trails, Konfigurationen und Signaturkontext exportiert werden können.

Ein Exit-Test muss nicht sofort eine vollständige Migration simulieren. Er sollte jedoch belegen, dass die Organisation relevante Daten in einem vereinbarten Format erhält, ihre Vollständigkeit prüfen und sie für die Aufbewahrungsdauer interpretieren kann. Ohne diese Kontrolle wird ein Anbieterwechsel später zum Datenintegritätsprojekt unter Zeitdruck.

Drei Lücken, die trotz guter Provider-Dokumentation bleiben

Unklare Konfigurationsverantwortung. Der Anbieter dokumentiert den Standard. Niemand besitzt den Nachweis für die kundenspezifische Konfiguration.

Evidence ohne Review-Owner. Berichte werden abgelegt, aber nicht gegen Anforderungen, Findings und Gültigkeit bewertet.

Release-Information ohne Prozesswirkung. Technische Notes werden gelesen, aber nicht mit kritischen Workflows, Daten und Schnittstellen verbunden.

Auch Audit Trails bleiben geteilt: Der Anbieter stellt Funktion und Betrieb bereit; der Kunde definiert Relevanz, Frequenz und Bewertung. Der Praxisleitfaden zum Audit Trail Review zeigt diese kundenseitige Kontrolle.

Häufige Fragen

Ersetzt ein SOC- oder ISO-Bericht die Cloud-Validierung?

Nein. Er kann Provider-Kontrollen im definierten Prüfungsumfang belegen. Intended Use, Konfiguration, Datenflüsse, Rollen und betriebliche Verfahren des Kunden bleiben separat zu bewerten und zu testen.

Muss der Kunde den Cloud-Anbieter vor Ort auditieren?

Nicht automatisch. Art und Tiefe der Lieferantenbewertung folgen Risiko, Kritikalität, verfügbarer unabhängiger Evidenz, Vertragsrechten und offenen Fragen. Die Entscheidung und ihre Begründung müssen dokumentiert sein.

Wie bleibt ein SaaS-System nach häufigen Releases validiert?

Durch einen festen Release-Assurance-Prozess: Change Intake, Impact Assessment, Bewertung der Provider-Evidence, risikobasierte Regression, dokumentierte Freigabe und Aktualisierung des Validierungsstatus.

Primär- und Provider-Quellen

• EU GMP Annex 11: Computerised Systems, wirksame Fassung 2011
• AWS: Shared Responsibility
• AWS: GxP Systems on AWS

---

Autor

Daniel Herrmann Consulting — Boutique-Beratung für GxP-Compliance und Computer System Validation in Pharma, Biotech und MedTech. 15+ Jahre Hands-on-Expertise. 60+ validierte Systeme. 100 % Audit-Bestehensquote. 0 kritische Findings.