SaaS- und Cloud-Validierung im GxP-Umfeld: vollständige Roadmap für QA, IT und Validation

In den letzten Jahren setzen viele Unternehmen der Life-Science-Branche zunehmend auf Cloud-Lösungen (SaaS, PaaS, IaaS), um Flexibilität und Geschwindigkeit zu erhöhen. Dies bringt jedoch neue Herausforderungen für die GxP-Compliance mit sich: Datenintegrität, Systemverfügbarkeit, Change Management sowie die geteilte Verantwortung mit dem Anbieter.

Die goldene Regel bleibt jedoch unverändert:
Wenn ein System GxP-relevante Daten oder Prozesse beeinflusst, muss es kontrolliert und validiert werden.
Und auch wenn das System „dem Anbieter gehört“, ist die finale Verantwortung für die Compliance nicht delegierbar: Das regulierte Unternehmen muss den Anbieter durch Verträge, Audits und robuste interne Prozesse steuern.

Diese Seite ist eine vollständige, audit-ready Roadmap, um:

• zu entscheiden, was und mit welcher Tiefe validiert werden muss (risikobasiert),
• Rollen und Verantwortlichkeiten festzulegen (Shared Responsibility),
• Anbieter zu qualifizieren und Evidenzen zu managen,
• Data-Integrity-Kontrollen gemäß ALCOA+ aufzubauen,
• den validierten Zustand durch Change Control und Continuous Compliance aufrechtzuerhalten.

Was bedeutet es, ein SaaS/Cloud-System im GxP-Umfeld zu „validieren“ (in einem Satz)

Ein GxP-Cloud-System zu validieren bedeutet, mit dokumentierten Evidenzen nachzuweisen, dass:

• das System fit for intended use ist,

• Risiken für Patient, Produkt und Daten identifiziert und mitigiert sind,

• das System auch nach dem Go-Live in einem kontrollierten Zustand bleibt
  (denn in der Cloud „ändert sich ständig etwas“).

CSV vs. CSA: Was ändert sich wirklich in der Cloud?

Die klassische CSV (GAMP 5, Part 11, Annex 11) bleibt die Referenz für das „Was“ (Anforderungen und Erwartungen).
Der modernere CSA-Ansatz (Computer Software Assurance) fokussiert sich hingegen auf das „Wie“: weniger Bürokratie, mehr Fokus auf kritische Funktionen und Risiko.

In der Praxis bedeutet das:

• nicht „weniger Kontrolle“,
• sondern bessere, proportionale und langfristig nachhaltige Kontrollen.

Der regulatorische Rahmen, den du „griffbereit“ haben solltest

Für ein SaaS-/Cloud-System im GxP-Umfeld umfasst der Mindestumfang typischerweise:

• FDA 21 CFR Part 11 (elektronische Aufzeichnungen und Signaturen)
• EU GMP Annex 11 (computergestützte Systeme, 17 Klauseln über den gesamten Lebenszyklus)
• Data Integrity / ALCOA+ (Prinzipien sowie technische und prozedurale Kontrollen)

Praxis-Hinweis:
Part 11 ist stark technisch auf Records und Signaturen fokussiert; Annex 11 ist stark lebenszyklus-orientiert (Risikomanagement, Lieferanten, Konfigurationsmanagement, Security, Backup). In globalen Projekten müssen beide Logiken abgedeckt werden.

Warum die Cloud die Validierung „verkompliziert“ – und gleichzeitig vereinfacht

Die Cloud bringt neue Spielregeln:

• Shared Responsibility: Ein Teil der Kontrollen liegt beim Anbieter – du musst jedoch nachweisen, dass du diese steuerst (Verträge, Audits, Governance).
• Häufige Updates: Besonders bei SaaS kommen Releases und Patches regelmäßig → operatives und kontinuierliches Change Control ist zwingend.
• Multi-Tenancy: Es muss verstanden werden, wie Daten zwischen Kunden logisch getrennt werden.
• Remote Access: Hohe Effizienz, aber strenge Disziplin bei Zugriffen, Rollen und Audit-Trail-Reviews erforderlich.
• Abhängigkeit vom Anbieter: Incidents, Downtime, RCA, Backup/Restore werden auch „anbieterabhängig“.

10-Schritte-Roadmap zur Validierung (und Aufrechterhaltung) eines GxP-SaaS/Cloud-Systems

1) GxP-Impact und Intended Use festlegen

Noch bevor Tests diskutiert werden:

• Welche Prozesse werden unterstützt? (GMP, GCP, GLP …)
• Welche Datentypen werden verarbeitet? (Qualitätsdaten, Batch Records, Training, Deviations usw.)
• Direkter oder indirekter Einfluss auf Qualität und Patient?

Typische Outputs:

• GxP-Impact-Klassifizierung
• Scope-Definition (in scope / out of scope)

2) Governance und Rollen definieren (vor der Validation-Dokumentation)

In der Cloud ist Governance die halbe Compliance.

Minimum:

• System Owner (Business)
• IT Owner / Administrator (technisch)
• QA / CSV / Validation (Compliance-Governance)
• Vendor Owner (Lieferanten- und Vertragsmanagement)

Audit-ready-Tipp:
Eine formale RACI-Matrix bereits im Validation Plan festlegen (wer URS erstellt/genehmigt, Tests ausführt, Release freigibt).

3) Lieferantenqualifizierung (bevor man den Evidenzen vertraut)

Der SaaS-/Cloud-Anbieter wird Teil deines Prozesses und muss geprüft, auditiert und überwacht werden.

Typische Deliverables:

• Vendor Assessment / Audit Report
• Quality Agreement / SLA / Security-Anhänge
• Monitoring-Plan (SLA-Reviews, Zertifizierungen, periodische Bewertungen)

4) Risk Assessment (ICH Q9) und Definition des Validation Effort

Hier wird entschieden, wie tief getestet und dokumentiert wird.

Typische Cloud-Risiken:

• Verfügbarkeit / Konnektivität
• Häufige Changes
• Data Residency
• Vendor Lock-in
• Incidents und Abhängigkeit von der RCA des Anbieters

Outputs:

• Risk Assessment mit Mitigations und Verknüpfung zu Tests
• Entscheidung, was intern getestet wird und was vom Anbieter akzeptiert wird (mit Begründung)

5) Cloud-tauglichen Validation Plan erstellen

Ein klarer Plan vermeidet Missverständnisse und verkürzt Projektzeiten.

Schlüsselelemente (oft im Audit gefragt):

• Systembeschreibung und Impact
• Rollen und Verantwortlichkeiten
• Deliverables (URS, RA, IQ/OQ/PQ, RTM, VSR, SOPs)
• Strategie zur Wiederverwendung von Vendor-Evidenzen (z. B. FAT, Vendor-Tests)

6) Anforderungen definieren: URS + Konfigurationsspezifikationen (FS/CS)

Die URS ist die Vertrags- und Testbasis: Jede Anforderung muss verifizierbar sein.

Kritische SaaS-Anforderungen:

• Geplante und kommunizierte Updates
• Test-/Sandbox-Umgebungen
• Support- und SLA-Anforderungen
• Compliance-Funktionen (Audit Trail, Signaturen, Zugriffskontrolle)

7) IQ/OQ/PQ realistisch für die Cloud planen

In SaaS bedeutet IQ nicht „Server aufbauen“, sondern meist:

• korrekte Instanz / Tenant
• Basiskonfiguration
• Prerequisites (Browser, Zugriffe, Schnittstellen)
• Vendor-Evidenzen für Infrastruktur (falls zutreffend)

Der Lebenszyklus bleibt klassisch, wird aber angepasst:
IQ = Instanz-/Infrastruktur-Verifikation,
OQ/PQ oft gemeinsam mit dem Anbieter.

8) Traceability aufbauen, die Auditoren überzeugt

Die RTM muss vollständige Abdeckung zeigen, insbesondere für kritische Compliance-Anforderungen.

Typische Felder: Requirement-ID, Kategorie, IQ/OQ/PQ-Testfall, Status, Notes, Deviations.

9) Kontrollierter Release: Training, SOPs, Support

Vor dem Go-Live müssen vorhanden sein:

• SOPs (Nutzung, Account-Management, Audit-Trail-Review, Backup sofern zutreffend)
• Nachgewiesenes Training
• Definierter Support / Service Desk
• Verifizierte Datenmigration (falls vorhanden)

10) Post-Go-Live: Change Control & Continuous Compliance

Der validierte Zustand muss aktiv erhalten werden:

• Change Control für Vendor-Releases und Konfigurationsänderungen
• Incident Management, RCA, CAPA
• Periodic Review
• Kontinuierliche Audit Readiness
• Decommissioning- / Exit-Strategie

Das minimale „Audit Pack“ für ein GxP-SaaS/Cloud-System

• Validation Plan
• URS + Konfiguration (FS/CS)
• Risk Assessment
• IQ/OQ/PQ (Protokolle + Evidenzen)
• RTM
• Validation Summary Report
• SOPs + Trainingsnachweise
• Vendor Qualification + Quality Agreement
• Change-Control-Log + Periodic Review Report

Häufige Fehler (die Auditoren sofort sehen)

• „Es ist SaaS, also keine Validierung nötig“ → falsch und riskant.
• Vollständige Delegation an den Anbieter ohne Audit und Quality Agreement.
• Tick-the-Box-Dokumentation ohne Fokus auf reale Risiken.
• Ignorieren von SaaS-Updates (größter Compliance-Killer).

FAQ (Featured Snippet / People Also Ask)

Muss ein SaaS in GMP validiert werden?
Ja, wenn es GxP-relevante Daten oder Prozesse beeinflusst.

Wer ist verantwortlich, wenn das System dem Anbieter gehört?
Die finale Verantwortung bleibt beim regulierten Unternehmen.

Können Vendor-Tests wiederverwendet werden?
Ja, nach Bewertung ihrer Angemessenheit und mit definierter Integration.

Worauf achten FDA/EMA bei Cloud-Systemen?
Governance, Data Integrity, Zugriffskontrollen, Audit Trail, Change Control, Tests und Lieferantenqualifizierung.

Wenn du diese Roadmap in eine audit-fertige Implementierung mit Checklisten und Templates (Validation Plan, URS, RTM, IQ/OQ/PQ, Change Log usw.) umsetzen willst, findest du die vollständige Anleitung „SaaS & Cloud Validation: Leitfaden zur GxP-Implementierung“ auf guidegxp.com.