Continuous Compliance im Cloud-GxP-Umfeld: Change Control, Incident Management, Periodic Review und Audit Readiness

Die meisten Probleme bei Inspektionen von Cloud-Systemen entstehen nicht „während der Validierung“. Sie entstehen danach.

Warum?

• SaaS-Systeme werden regelmäßig aktualisiert,
• Benutzer wechseln,
• Rollen und Berechtigungen häufen sich an,
• Incidents treten auf.

Die Guideline ist sehr klar: Jedes Update / jeder Patch / jede Konfigurationsänderung muss hinsichtlich des GxP-Impacts bewertet sowie getestet und dokumentiert werden; ein wirksames Change Control mit QA-Einbindung ist erforderlich; Incident Handling und Periodic Reviews belegen die kontinuierliche Kontrolle; Audit Readiness hängt auch von sauberer Dokumentation und geschulten Teams ab.

1) Change Control in SaaS: Was zählt als „Änderung“ (und was nicht)

In der Cloud kann eine Änderung sein:

• Vendor-Releases / neue Versionen
• Konfigurationsänderungen (Workflows, Business Rules)
• Infrastrukturänderungen (z. B. Data-Center-Migrationen, Regionswechsel)
• hinzugefügte oder entfernte Integrationen
• wesentliche Security-Patches

Wenn dies nicht klar definiert ist, endet man im Chaos („wir wussten nicht, dass das ein Change ist“).

2) Praktischer Prozess zur Steuerung eines SaaS-Updates (audit-ready Workflow)

Schritt A — Change Record sofort eröffnen

Sobald eine Benachrichtigung eingeht:

• Change Record eröffnen (z. B. „Upgrade XYZ v2.5“)
• Release Notes und – falls verfügbar – Vendor-Testdokumentation anhängen

Schritt B — Impact Assessment (GxP + Risiko)

Leitfragen:

• betrifft es GxP-Funktionen?
• ändern sich kritische Workflows oder UI-Elemente?
• werden Compliance-relevante Bugs behoben?
• ist Training erforderlich?

Kritikalität festlegen (minor/major) und ggf. Risk Assessment aktualisieren.

Schritt C — Regressionstests und Akzeptanzkriterien definieren

• welche kritischen Funktionen werden erneut getestet?
• steht eine Staging-/Sandbox-Umgebung zur Verfügung?
• welche Akzeptanzkriterien gelten? (z. B. „alle kritischen Tests bestanden“)

Schritt D — Umsetzung, Verifikation und Abschluss

Nach der Implementierung:

• prüfen, dass der Audit Trail weiterhin funktioniert und nicht „zurückgesetzt“ wurde,
• sicherstellen, dass kritische Konfigurationen nicht auf Default zurückgefallen sind,
• Evidenzen archivieren und QA-Freigabe zum Change-Abschluss durchführen.

3) Incident & Problem Management: Warum Auditoren darauf großen Wert legen

Ein System kann „validiert“ sein – wenn Incidents nicht sauber gemanagt werden, verliert man:

• Kontrolle,
• Datenintegrität,
• Glaubwürdigkeit (und das fällt im Audit auf).

Gute Praxis:

• Ticket / Incident erfassen,
• GxP-Impact bewerten,
• RCA (oft vom Vendor) prüfen und archivieren,
• CAPA einleiten, falls erforderlich.

4) Periodic Review: Die „Inspektion“, die Audit und Budget rettet

Periodic Review = systematische Überprüfung, dass das System weiterhin geeignet und kontrolliert ist.

Typische Inhalte:

• Liste der Changes im Zeitraum und Status (geschlossen? Evidenzen vorhanden?)
• Access Review (aktive User, Berechtigungen)
• Zusammenfassung der Audit-Trail-Reviews
• Incident-Trends und CAPAs
• Vendor-Performance (SLA, RCA, Zertifizierungen)
• ggf. Schulungsbedarf

5) Kontinuierliche Audit Readiness: Wie man den „Last-Minute-Stress“ vermeidet

Audit Readiness bedeutet:

• Dokumente sind innerhalb von Minuten auffindbar,
• Personen können konsistent und sicher antworten,
• Evidenzen sind schlüssig (aktuelle URS / RTM / SOPs).

Die Guideline betont: Ein System kann technisch gut sein – wenn Dokumente nicht auffindbar sind oder Anwender nicht erklären können, wie es funktioniert, kann die Inspektion scheitern.

Praktischer Tipp:

• ein aktuelles „Audit Pack“ pflegen,
• regelmäßige interne Mock-Audits durchführen (auch leichtgewichtig),
• Zeiten zur Evidenzbereitstellung messen.

Fehler, die zu echten Findings führen

Die Guideline nennt sehr typische Fehler:

• SaaS-Updates ohne Validierung akzeptieren (blindes Vertrauen in den Vendor),
• Dokumentation nach Changes nicht aktualisieren (Inkonsistenz = mangelnde Kontrolle),
• Änderungen nicht an Anwender kommunizieren (unvollständige/falsche Daten),
• Test-Accounts oder alte Benutzer aktiv lassen (sehr kritisch im Audit).

Wenn du eine vollständige Checkliste für Cloud-Change-Control, Periodic Review und Audit Readiness (inkl. praxisnaher Beispiele und Templates wie Change Register) suchst, findest du sie in der Guideline „SaaS & Cloud Validation: guida all’implementazione GxP“ auf guidegxp.com.