GxP-Cloud: Shared Responsibility statt Anbieterpaket

GxP-Cloud-Validierung ist der dokumentierte Nachweis, dass ein cloudbasiertes System für seinen regulierten Einsatzzweck geeignet ist und über den Lebenszyklus kontrolliert bleibt. Der Cloud-Anbieter kann Infrastruktur, Plattform, Standardfunktionen und Sicherheitsnachweise bereitstellen. Die regulatorische Verantwortung für den Einsatz im eigenen GxP-Prozess bleibt beim Pharma-Hersteller.

Damit verschiebt sich die Validierungsfrage. Nicht die Cloud als Betriebsmodell steht im Mittelpunkt, sondern der Verantwortungsschnitt: Welche Kontrolle liegt beim Anbieter, welche Kontrolle liegt beim Anwender, welche Kontrolle wird geteilt und welche Evidenz trägt im Audit?

Ausgangspunkt für Pharma-Hersteller

Cloud-Systeme sind im regulierten Umfeld etabliert. Veeva Vault, ValGenesis, SAP, Microsoft 365, ServiceNow, LIMS- und eQMS-Lösungen werden als SaaS, PaaS oder gehostete Plattformen betrieben. Die technische Architektur unterscheidet sich von klassischen On-Premise-Systemen, die GxP-Frage bleibt gleich: Das System muss für den vorgesehenen Zweck geeignet sein, Datenintegrität sichern und Änderungen kontrolliert durchlaufen.

Annex 11 beschreibt diese Erwartung für computergestützte Systeme im EU-GMP-Umfeld. 21 CFR Part 11 ergänzt Anforderungen an elektronische Aufzeichnungen und elektronische Signaturen im FDA-Geltungsbereich. Beide Regelwerke schreiben kein bestimmtes Hosting-Modell vor. Sie verlangen Kontrollen, die in der Cloud anders belegt werden müssen als im eigenen Rechenzentrum.

Die FDA-Guidance zu Computer Software Assurance, nach dem Draft von 2022 am 24.09.2025 finalisiert und am 03.02.2026 in aktualisierter Fassung mit Angleichung an die neue Quality Management System Regulation (QMSR) veröffentlicht, liefert dafür einen methodischen Impuls, aber keine allgemeine Pharma-Cloud-Regel. Die Guidance bezieht sich auf Software für Medical-Device-Produktion und Qualitätsmanagementsysteme. Für Pharma-Hersteller ist sie vor allem als risikobasierter Denkrahmen brauchbar: intended use, Prozessrisiko, angemessene Assurance-Aktivität und verwertbare objektive Evidenz.

Vier Achsen vor der Matrix

Eine Shared-Responsibility-Matrix trägt nur, wenn sie auf vier Achsen aufgebaut wird.

1. Service-Modell. IaaS, PaaS und SaaS verteilen Betrieb, Wartung und technische Kontrollen unterschiedlich.
2. Regulierter Prozess. Ein eQMS-Modul für Abweichungen, ein LIMS, ein Dokumentenmanagementsystem und ein Collaboration-Tool erzeugen unterschiedliche GxP-Risiken.
3. Datenklasse. Produktionsdaten, Qualitätsdaten, klinische Daten, Pharmakovigilanzdaten und personenbezogene Daten benötigen unterschiedliche Kontrolltiefen.
4. Anbieterzugriff. Supportzugriffe, Administrationsrechte, Subprozessoren, Wartungsfenster und Logging bestimmen, welche Kontrollen beim Anwender erklärt werden müssen.

Diese Achsen verhindern zwei Fehlsteuerungen. Der Anwender übernimmt nicht jede technische Kontrolle selbst, nur weil das System GxP-relevant ist. Umgekehrt reicht ein Anbieterzertifikat nicht aus, wenn die regulierte Nutzung, die Konfiguration und der Review-Prozess beim Pharma-Hersteller liegen.

Service-Modelle und Verantwortungsschnitt

Infrastructure as a Service (IaaS) stellt virtualisierte Infrastruktur bereit. Der Anbieter verantwortet Rechenzentrum, physische Sicherheit, Basisnetzwerk und Virtualisierung. Der Anwender verantwortet Betriebssystem, Middleware, Anwendung, Konfiguration, Datenmigration, Benutzerrollen und Validierungsdossier. AWS EC2 oder Azure Virtual Machines mit einer selbst betriebenen GxP-Anwendung fallen in diese Logik.

Platform as a Service (PaaS) stellt zusätzliche Plattformdienste bereit, etwa Datenbanken, Authentifizierung, Logging, Laufzeitumgebungen oder Integrationsdienste. Der Anbieter belegt die Plattformkontrollen. Der Anwender validiert die Geschäftslogik, Konfiguration, Schnittstellen, Datenflüsse und den regulierten Prozess. Salesforce-basierte Anwendungen oder Azure-Dienste für Datenverarbeitung verlangen deshalb eine genauere Trennung als reine IaaS-Architekturen.

Software as a Service (SaaS) stellt eine fertige Anwendung bereit. Der Anbieter entwickelt, betreibt und aktualisiert die Standardsoftware. Der Anwender validiert den vorgesehenen Einsatz, die Konfiguration, Rollen, Workflows, Datenmigration, Schnittstellen, Audit-Trail-Reviews und SOP-Einbettung. Veeva Vault QualityDocs, ValGenesis VLMS oder cloudbasierte LIMS-Module sind typische Beispiele.

Der Verantwortungsschnitt verschiebt sich mit dem Service-Modell. Die Endverantwortung wandert nicht. In GMP-Inspektionen wird nicht der Hyperscaler erklären müssen, warum ein Freigabe-Workflow im eQMS passend konfiguriert ist.

Shared-Responsibility-Matrix

Die Matrix gehört pro Anwendung in das Validierungsdossier oder in eine referenzierte Cloud-Governance-Unterlage. Sie dokumentiert nicht nur Zuständigkeiten, sondern auch Evidenz: welches Dokument, welcher Test, welcher Review und welcher Vertragspunkt eine Kontrolle belegt.

Die Matrix wird nicht einmalig erstellt und abgelegt. Neue Module, geänderte Datenflüsse, zusätzliche Integrationen, KI-Funktionen, neue Subprozessoren oder geänderte Supportmodelle lösen eine Aktualisierung aus.

Anbieterunterlagen mit GxP-Wert

Anbieterunterlagen sind Eingangsmaterial für die eigene Bewertung. Sie ersetzen keine Validierungsentscheidung des Anwenders. Ein Audit kann deshalb zwei Fragen stellen: Liegen die Unterlagen vor, und wurde aus ihnen eine nachvollziehbare GxP-Entscheidung abgeleitet?

SOC 2 Typ 2 belegt Kontrollen über einen Zeitraum. Für Cloud-Anbieter sind vor allem Security, Availability und Confidentiality relevant. Der Report ist kein GxP-Validierungsnachweis, hilft aber bei der Bewertung von Betriebs- und Sicherheitskontrollen.

ISO/IEC 27001:2022 belegt ein Informationssicherheits-Managementsystem. Das Zertifikat sagt wenig über eine konkrete GxP-Konfiguration, liefert aber einen belastbaren Rahmen für Risikomanagement, Zugriffskontrolle, Lieferantensteuerung und Incident Management.

C5:2020 ist im DACH-Umfeld relevant, wenn Cloud-Sicherheit gegenüber deutschen Kunden, regulierten Unternehmen oder öffentlichen Stellen nachgewiesen werden soll. Für Pharma ist C5 kein GMP-Ersatz, aber ein nützlicher Kontrollkatalog für Cloud-Basisrisiken.

Validierungsdokumentation des Anbieters beschreibt Entwicklungsmodell, Testabdeckung, Release-Kontrollen, Standardfunktionen und bekannte Einschränkungen. Bei SaaS-Systemen ist sie der wichtigste Baustein für die Übernahme von Anbieteraktivitäten in das eigene Dossier.

Subprozessorenliste und Supportmodell zeigen, welche Dritten beteiligt sind, wo Verarbeitung stattfindet und welche Zugriffe möglich sind. Diese Unterlagen verbinden Datenschutz, Informationssicherheit und GxP-Datenintegrität.

Release Policy und Release Notes entscheiden über die Betriebsphase. Cloud-Systeme bleiben nur validiert, wenn Anbieteränderungen bewertet, relevante Änderungen getestet und nicht relevante Änderungen begründet ausgeschlossen werden.

Datenresidenz und Anbieterzugriff

Datenresidenz ist kein isolierter Länder-Parameter. Für GxP zählt die Kombination aus Speicherort, Verarbeitung, Backup, Supportzugriff, Verschlüsselung, Schlüsselkontrolle, Restore-Fähigkeit und Behördenverfügbarkeit. Eine EU-Region allein löst das Problem nicht, wenn privilegierter Support aus Drittstaaten ohne belastbare Kontrolle möglich bleibt.

Eine belastbare Bewertung unterscheidet Datenklassen. Pharmakovigilanzdaten, klinische Daten, Chargendokumentation, Laborrohdaten, Qualitätsereignisse und allgemeine Prozessmetadaten tragen unterschiedliche Risiken. Die Datenklasse bestimmt, ob EU-only-Verarbeitung, Kundenschlüssel, eingeschränkter Supportzugriff, lokales Backup oder zusätzliche Vertragskontrollen erforderlich werden.

Multi-Region-Architekturen sind nicht automatisch unzulässig. Sie benötigen aber eine dokumentierte Begründung: Welche Regionen sind beteiligt, welche Daten werden repliziert, welche Schlüssel schützen sie, welche Subprozessoren greifen zu, wie werden Löschung, Export, Restore und Behördenzugriff sichergestellt? Ohne diese Antworten bleibt die Architektur im Audit schwer erklärbar.

Part 11 und Annex 11 in der Cloud

21 CFR Part 11 verlangt Kontrollen für elektronische Aufzeichnungen und elektronische Signaturen, soweit elektronische Records im FDA-Geltungsbereich maßgeblich sind. Die FDA-Guidance zu Scope and Application stellt zugleich klar, dass Predicate Rules die eigentliche Aufbewahrungs- und Nachweispflicht tragen. Für Cloud-Systeme heißt das: Der Part-11-Scope entsteht nicht durch das Hosting, sondern durch die regulierte elektronische Aufzeichnung.

Vier Kontrollen stehen im Vordergrund:

1. Audit Trail. Relevante Änderungen müssen nachvollziehbar sein, mit Nutzerbezug, Zeitstempel und inhaltlicher Veränderung. Der Anwender muss testen, dass der Audit Trail aktiv ist und im Prozess reviewt wird.
2. Zugriffskontrolle. Rollen, privilegierte Konten, SSO, MFA und Anbieterzugriffe müssen zur Kritikalität passen. Access Reviews gehören in die Betriebsphase.
3. Elektronische Signatur. Signaturen müssen eindeutig einer Person zugeordnet sein und mit dem Datensatz verbunden bleiben. Re-Authentifizierung bei kritischen Aktionen, etwa Freigaben, liegt nahe.
4. Datenintegrität. Records müssen vollständig, lesbar, verfügbar und gegen unautorisierte Änderung geschützt bleiben. Backup, Restore und Export sind deshalb Validierungsthemen, nicht nur IT-Betrieb.

Annex 11 ergänzt diese Sicht im EU-GMP-Kontext. Relevant sind insbesondere Risikomanagement, Lieferantenbewertung, Validierung, Datenintegrität, Audit Trails, Security, Incident Management, Business Continuity und Änderungskontrolle. Die Cloud ändert die Nachweisform, nicht die Grundpflicht.

Migration einer GxP-Anwendung

Eine Cloud-Migration beginnt nicht mit der technischen Umstellung. Sie beginnt mit der regulatorischen Systemdefinition: beabsichtigter Einsatz, GxP-Scope, Datenklassen, Schnittstellen, Nutzerrollen, Anbieterleistungen und verbleibende Anwenderpflichten.

Phase 1: Systemdefinition und Risiko. URS, Prozessbeschreibung, Datenklassen, GxP-Scope und Service-Modell festlegen. Die Shared-Responsibility-Matrix entsteht bereits hier, nicht erst nach Vertragsabschluss.

Phase 2: Anbieterbewertung und Vertrag. Zertifikate, Reports, Validierungsdokumentation, Subprozessoren, Supportmodell, SLA, Audit-Cooperation und Exit-Regelung prüfen. Vertrag und AVV müssen die späteren Nachweise ermöglichen.

Phase 3: Validierungsstrategie. Intended Use, Risikoanalyse, Teststrategie, Rollenmodell, Part-11-Scope, Datenmigration und Change-Control-Modell dokumentieren, methodisch entlang GAMP 5 (Second Edition, 2022). Anbieteraktivitäten werden referenziert, nicht ungeprüft übernommen.

Phase 4: Konfiguration und Nachweis. Workflows, Rollen, Audit Trail, Signaturen, Schnittstellen, Migration und Reports testen. Der Schwerpunkt liegt auf der Nutzung im eigenen regulierten Prozess.

Phase 5: Betrieb und Continued Verification. Release-Bewertung, Access Reviews, Audit-Trail-Reviews, Incident-Bewertung, Restore-Nachweise und Lieferantenreviews halten den validierten Zustand aufrecht.

Je stärker ein SaaS-System standardisiert ist, desto wichtiger wird die Begründung der Konfiguration. Je stärker ein IaaS- oder PaaS-System individualisiert ist, desto stärker wandert die Test- und Dokumentationslast zum Anwender.

Prüfpfad für bestehende Cloud-Systeme

Für bereits produktive GxP-Cloud-Systeme bietet sich ein 90-Tage-Prüfpfad an.

1. Inventar klären. Alle Cloud-Systeme mit GxP-Bezug erfassen, einschließlich Subsystemen, Integrationen, Reporting-Layern und KI-Funktionen.
2. Matrix nachziehen. Pro System dokumentieren, welche Kontrollen Anbieter, Anwender und Subprozessoren tragen.
3. Anbieterpaket prüfen. SOC 2, ISO 27001, C5, Validierungsdokumentation, Subprozessorenliste, Release Policy und Supportmodell gegen den eigenen GxP-Scope bewerten.
4. Part-11-Scope festlegen. Elektronische Aufzeichnungen, Signaturen, Audit Trail, Zugriffskontrollen und Datenexport pro Prozess prüfen.
5. Betriebsnachweise schließen. Release-Impact-Assessment, Access Review, Audit-Trail-Review, Backup/Restore und Incident-Prozess in den laufenden Betrieb aufnehmen.

Der Prüfpfad ist bewusst eng gehalten. Er erzeugt keine vollständige Neuvalidierung, sondern macht sichtbar, ob die vorhandene Validierung den Cloud-Verantwortungsschnitt trägt.