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 „SaaS & Cloud Validation: guida all’implementazione GxP“ auf guidegxp.com.