Data Integrity (ALCOA+) in SaaS/Cloud: Audit Trail, Zugriffe, elektronische Signaturen und operative Kontrollen
Im GxP-Umfeld lautet die implizite Frage des Auditors immer:
„Wie weisen Sie nach, dass Ihre Daten zuverlässig sind?“
In der Cloud ist diese Frage noch zentraler, weil:
- Systeme stark vernetzt sind,
- Zugriffe häufig remote erfolgen,
- Updates regelmäßig stattfinden,
- ein Teil der technischen Kontrollen beim Provider liegt.
Die Antwort ist keine einzelne Policy, sondern ein kohärentes Zusammenspiel aus:
- technischen Kontrollen,
- operativen Prozessen,
- Governance.
Die Guideline fasst dies in einem Schlüsselkonzept zusammen: Data Integrity by design, durch die Kombination technischer Kontrollen (Audit Trail, Berechtigungen, Signaturen) und prozeduraler Maßnahmen (SOPs, Audit-Trail-Review, Vier-Augen-Prinzip), um ALCOA+ für elektronische Datensätze sicherzustellen.
ALCOA+ (erklärt, wie ich es in einer URS anwenden würde)
ALCOA+ ist keine Theorie, sondern ein Satz von Anforderungen, die sich in Konfigurationen und Verfahren übersetzen lassen:
- Attributable: Wer hat was getan (Identität, Signatur, Rolle)
- Legible: Daten sind lesbar und interpretierbar
- Contemporaneous: Aufzeichnung zum Zeitpunkt der Handlung
- Original: Originalquelle bleibt erhalten
- Accurate: Korrektheit, Kontrollen und Fehlervermeidung
- Complete / Consistent / Enduring / Available: Daten sind vollständig, konsistent, dauerhaft gespeichert und verfügbar (auch über Zeit und im Audit)
Wo die Cloud Lücken erzeugen kann (wenn man nicht frühzeitig plant)
Typische Beispiele:
- zu mächtige „Admin“-Rollen,
- vorhandener Audit Trail, der jedoch nicht reviewed wird,
- gemeinsame Accounts oder aktive Test-User,
- SaaS-Updates, die Workflows ändern oder Konfigurationen zurücksetzen,
- unklare Regelungen zu Backup/Restore und Datenlokation.
Annex 11 legt z. B. besonderen Fokus auf Risikomanagement, Audit Trail, Backup und Sicherheit; im Cloud-Kontext zusätzlich auf Datenlokalisierung, Verschlüsselung, Mandantentrennung sowie darauf, wie das Unternehmen die Integrität periodisch überprüft (z. B. Re-Extraktionen und Reconciliation).
Praktisches Framework: Die 5 Data-Integrity-Kontrollen, die du in SaaS „schließen“ musst
1) Identity & Access Management (IAM) + Funktionstrennung
In SaaS kannst du die Server nicht kontrollieren – Zugriffe jedoch sehr wohl:
- wer zugreift,
- mit welcher Rolle,
- mit welchen Rechten.
Best Practices:
- minimale Rechte (Least Privilege),
- Trennung von Funktionen (z. B. QA ≠ technischer Admin),
- regelmäßige Access-Reviews.
Die Guideline empfiehlt zudem eine Rollen- und Berechtigungsmatrix als auditfähiges Dokument zur Demonstration von Funktionstrennung und Authority Checks (Part 11).
2) Audit Trail (aktiv, geschützt, „reviewfähig“)
Fragen, die du beantworten können musst:
- Welche Ereignisse werden erfasst? (Login, Changes, Freigaben, Löschungen usw.)
- Ist der Audit Trail unveränderbar?
- Wer kann ihn einsehen und wer (falls überhaupt) ändern?
- Wie erfolgt die Review (Frequenz, Stichprobe, Kriterien)?
3) Elektronische Signaturen und Part-11-Kontrollen
„Eine Signatur ist vorhanden“ reicht nicht aus:
- sie muss eindeutig einem Benutzer zuordenbar sein,
- sie muss mit Datensatz und Bedeutung verknüpft sein (Freigabe, Review etc.),
- es braucht Governance zu Passwörtern, Sessions, Timeouts usw.
In der URS ist es sinnvoll, Compliance-Anforderungen explizit den regulatorischen Referenzen (Part 11 / Annex 11) zuzuordnen, um Vollständigkeit und Nachvollziehbarkeit sicherzustellen.
4) Datenlebenszyklus: Aufbewahrung, Export, Verfügbarkeit
In der Cloud musst du auch an den Exit denken:
- Datenexport in lesbarem Format,
- Retention und Archivierung,
- Zugriff bei Vertragsende.
(Dies ist häufig im Quality Agreement und in der Exit-Strategie geregelt.)
5) Prozedurale Kontrollen: SOPs + Review + Training
Technische Kontrollen ohne Verfahren sind fragil.
Mindestanforderungen:
- SOP Account-Management,
- SOP Audit-Trail-Review,
- SOP Change Control (inkl. SaaS-Updates),
- dokumentiertes und periodisches Training.
„Audit-Trail-Review“ richtig umgesetzt: eine kleine operative Vorgehensweise (Beispiel)
Für Glaubwürdigkeit klar definieren:
- Frequenz: monatlich/vierteljährlich, risikobasiert
- Rolle: QA oder Delegierte mit QA-Überwachung
- Prüfinhalte: ungewöhnliche Login-Versuche, Rollenänderungen, Löschungen, Workflow-Bypass
- Evidenzen: Reports/Exporte, Review-Records, ggf. Deviation/CAPA
Wenn du Checklisten und Templates suchst, um Data Integrity zu prüfen, Rollen/Berechtigungen zu konfigurieren, URS im Sinne von „Compliance by Design“ aufzubauen und Evidenzen im Audit sauber zu präsentieren, findest du die Guideline „Operativer Leitfaden zur Computer System Validation (CSV) im GxP-Umfeld“ auf guidegxp.com.
