Audit Trails in GxP-Systemen: technische und organisatorische Anforderungen

Ein Audit Trail ist technisch schnell gebaut: eine Tabelle, ein paar Trigger oder ein Interceptor, fertig. Beanstandet wird er trotzdem regelmäßig – weil er unvollständig ist, weil er abschaltbar war, weil ihn niemand auswerten kann oder weil ihn niemand ausgewertet hat. Dieser Deep Dive trennt die technische von der organisatorischen Seite.

1. Wozu der Audit Trail dient

Der Audit Trail beantwortet für GxP-relevante Daten die Frage: Wer hat wann was geändert – und, wo gefordert, warum? Er ist damit die technische Grundlage der Datenintegrität. Ohne ihn lässt sich weder eine Abweichung nachvollziehen noch belegen, dass Aufzeichnungen nicht unbemerkt verändert wurden.

2. Was aufgezeichnet werden muss

Der Mindestumfang je Änderung an einem GxP-relevanten Datensatz:

• Wer – eindeutige, personenbezogene Identität, kein Sammelkonto und keine technische Kennung ohne Zuordnung.
• Wann – Zeitstempel aus einer verlässlichen Quelle, vorzugsweise in UTC mit Zeitzoneninformation.
• Was – betroffener Datensatz und Feld, alter und neuer Wert.
• Art der Änderung – Anlegen, Ändern, Löschen; bei Löschungen vorzugsweise als Kennzeichnung statt physischer Entfernung.
• Grund, wo das Regelwerk oder der Prozess ihn verlangt – etwa bei Korrekturen freigegebener Daten.

3. Audit Trail, Log, Historie

Die drei überschneiden sich technisch, dürfen aber nicht vermischt werden. Ein Anwendungslog mit Rotationsfrist ist kein Audit Trail. Umgekehrt sollte der Audit Trail nicht mit Betriebsdaten geflutet werden – sonst ist er praktisch nicht auswertbar.

4. Technische Umsetzung

Ein tragfähiges Grundmuster für den Datensatz – unabhängig von Datenbank und Framework:

audit_entry
  id                 -- immutable, sequential
  occurred_at        -- UTC timestamp from a trusted source
  actor_id           -- resolvable to a real person
  actor_display      -- captured at write time, survives user renames
  entity_type        -- e.g. "batch_record"
  entity_id          -- business key of the affected record
  field              -- affected attribute
  old_value          -- previous value (null on create)
  new_value          -- new value (null on delete)
  action             -- CREATE | UPDATE | DELETE
  reason             -- required where the process demands it
  context_id         -- request/transaction, groups related entries

Zwei Details lohnen die Aufmerksamkeit. Erstens actor_display: Wird nur die Benutzer-ID gespeichert, ist der Eintrag nach einer Umbenennung oder Löschung des Kontos schwer lesbar. Zweitens context_id: Ohne Gruppierung erscheint eine fachliche Änderung als zwölf unzusammenhängende Feldänderungen.

Die Aufzeichnung gehört möglichst nah an die Datenhaltung – als Teil der Persistenzschicht oder der Plattform. Wird sie in der Anwendungslogik verstreut implementiert, fehlen einzelne Pfade praktisch immer.

5. Schutz vor Veränderung

• Nur Anfügen. Keine Anwendungsfunktion darf Einträge ändern oder löschen; Datenbankrechte entsprechend eng setzen.
• Nicht abschaltbar für GxP-relevante Daten – auch nicht temporär „für die Migration“.
• Trennung der Rechte. Wer Fachdaten pflegt, darf nicht gleichzeitig Administrationsrechte auf den Audit Trail haben.
• Integritätssicherung bei erhöhtem Schutzbedarf, etwa durch Prüfsummenketten – der Aufwand sollte zum Risiko passen.
• Sicherung und Wiederherstellbarkeit mitgetestet, nicht nur eingerichtet.

6. Auswertbarkeit ist Pflicht

Ein Audit Trail, den man nur als Rohexport bekommt, wird faktisch nicht geprüft – und genau das wird beanstandet. Was er können muss:

• filtern nach Zeitraum, Person, Datensatz und Änderungsart,
• eine fachliche Änderung als Einheit darstellen, nicht als Feldliste,
• gezielt auf auffällige Muster hin auswertbar sein – etwa Änderungen an freigegebenen Datensätzen oder Aktivitäten außerhalb üblicher Zeiten,
• Ergebnisse exportierbar machen, in einem Format, das ohne das erzeugende System lesbar bleibt.

7. Audit Trail Review

Hier liegt die eigentliche organisatorische Last, und sie lässt sich nicht automatisieren – nur unterstützen. Ein praktikabler Ansatz:

1. Risikobasiert festlegen, welche Datenbereiche in welcher Frequenz geprüft werden. Nicht alles gleich oft.
2. Auffälligkeiten vorfiltern lassen, damit die Prüfung sich auf Relevantes konzentriert.
3. Ergebnis dokumentieren – auch „keine Auffälligkeiten“ ist ein Nachweis, wenn er datiert und gezeichnet ist.
4. Abweichungen weiterleiten in den regulären Abweichungsprozess.

8. Aufbewahrung und Migration

Der Audit Trail unterliegt derselben Aufbewahrungspflicht wie die Daten, auf die er sich bezieht – und muss über diesen Zeitraum lesbar bleiben. Bei Systemablösungen ist das der kritische Punkt: Die Einträge müssen mitgenommen oder in einem lesbaren, selbsttragenden Format archiviert werden. Wer das erst bei der Abschaltung bedenkt, hat die Wahl zwischen teurer Migration und laufendem Altsystem.

Typische Beanstandungen

• Alter Wert fehlt – die Änderung ist nicht nachvollziehbar.
• Sammelkonten – keine personenbezogene Zuordnung möglich.
• Abschaltbarkeit durch Konfiguration oder Administratorrechte.
• Keine Auswertung im Betrieb – der Trail existiert, wird aber nie geprüft.
• Lücken in einzelnen Pfaden, etwa bei Massenimporten oder Schnittstellen.
• Zeitstempel ohne verlässliche Quelle oder ohne Zeitzone.

Checkliste: Audit Trail

Fazit

Der technische Teil eines Audit Trails ist in wenigen Tagen erledigt – wenn er an der richtigen Stelle sitzt und die richtigen Felder erfasst. Der schwierige Teil ist der Betrieb: auswerten, prüfen, dokumentieren, aufbewahren, migrieren.

Für Projekte heißt das: Historisierung möglichst nicht selbst bauen, sondern als Plattformeigenschaft nutzen – und den Review-Prozess von Anfang an mitplanen. Wie CodamAI Historie und Nachvollziehbarkeit abbildet, steht auf der Feature-Seite.