Audit-Trail-Review in GxP: Umfang, Frequenz, Verantwortung

Unsere Leistungen beim Audit-Trail-Review

Der Audit Trail ist das computergenerierte, unveränderliche Protokoll eines Systems: Wer hat wann welchen Datensatz erstellt, geändert oder gelöscht, und warum. Er sichert das Wer-wann-warum hinter jedem GMP-relevanten Datensatz und trägt damit die Zuordenbarkeit aus ALCOA+. Ohne Review bleibt er jedoch totes Protokoll: Erst die regelmäßige, sachkundige Prüfung macht aus dem Audit Trail eine Kontrolle, die Manipulation, Fehlbedienung und Prozessschwächen sichtbar macht.

Genau hier setzen die Behörden an. Ein Audit Trail, den niemand ansieht, ist in Inspektionen kein Nachweis von Datenintegrität, sondern ein Finding mit Ansage.

Umfang klären?

Erstgespräch vereinbaren

Leistungs-Wegweiser

Welche Ausgangslage beschreibt Ihr Vorhaben?

Wählen Sie die Ausgangslage. Sie erhalten einen fokussierten Startpunkt mit Vertiefungen und Kontaktweg.

Vom Erstgespräch zum Plan

Wir klären Umfang, Rollen, Risiken und regulatorischen Rahmen und schlagen einen belastbaren Fahrplan vor.

Erstgespräch vereinbaren Projektmanagement ansehen

Unser Vorgehen in GxP-Projekten: von Planung bis Freigabe – jeder Schritt endet mit einem Ergebnis, das Sie in QA-Review und Audit vorlegen können. GxP-Beratung in fünf Schritten ansehen

Was die Regelwerke fordern

EU-GMP Annex 11, Abschnitt 9: Audit Trails über GMP-relevante Änderungen und Löschungen müssen regelmäßig geprüft werden. Die geltende Fassung des Annex 11 lässt die Frequenz offen, der Revisionsentwurf konkretisiert die Erwartung in Richtung dokumentierter, risikobasierter Reviews.
21 CFR Part 11, § 11.10(e): Systeme benötigen einen sicheren, computergenerierten, zeitgestempelten Audit Trail. Die FDA-Guidance zu Data Integrity beantwortet ausdrücklich, dass Audit Trails von einer sachkundigen Person geprüft werden sollen, etwa im Rahmen des Record Reviews vor der Freigabe.
MHRA GXP Data Integrity Guidance: Die britische Guidance verankert den risikobasierten Review als Teil des Datenlebenszyklus und nennt deaktivierte oder nie geprüfte Audit Trails als typisches Integritätsrisiko.

Ob Ihre Systeme die Grundanforderungen erfüllen, klären in einer ersten Selbsteinschätzung unser Part-11-Check und der Annex-11-Check.

Was ein Audit Trail enthalten muss

Bevor ein Review sinnvoll wird, muss der Audit Trail selbst vollständig sein. Aus 21 CFR Part 11 § 11.10(e) für die USA und EU-GMP Annex 11 Abschnitt 9 in Verbindung mit den ALCOA+-Prinzipien ergibt sich ein klarer Mindestinhalt je Eintrag:

Wer: die eindeutige Benutzerkennung der handelnden Person, kein Gruppen- oder Systemkonto.
Wann: ein computergenerierter Zeitstempel mit Datum und Uhrzeit aus einer synchronisierten, nicht manipulierbaren Systemzeit.
Was: die Aktion (Erstellen, Ändern, Löschen) und der betroffene Datensatz, eindeutig referenziert.
Alter und neuer Wert: Änderungen dürfen den ursprünglichen Wert nicht überdecken. Part 11 formuliert das ausdrücklich: record changes shall not obscure previously recorded information.
Warum: die Änderungsbegründung, wo das übergeordnete Regelwerk sie fordert, etwa bei GMP-Aufzeichnungen nach EU-GMP Kapitel 4.

Dazu kommen Eigenschaften des Audit Trails als Ganzes: Er wird automatisch vom System erzeugt, kann von Anwendern weder geändert noch abgeschaltet werden und bleibt über die gesamte Aufbewahrungsfrist der Daten lesbar und auswertbar, auch nach Systemablösung. Für die Langzeitverfügbarkeit greifen die Regeln unserer Datenarchivierung.

Was reviewt werden muss und was nicht

Der häufigste Fehler ist der Versuch, alles zu prüfen. Wer jede Anmeldung sichtet, ermüdet und übersieht die relevanten Einträge. Der Review konzentriert sich auf GMP-relevante Ereignisse:

Änderungen an Ergebnissen und Rohdaten: geänderte oder erneut verarbeitete Resultate, manuelle Neuintegrationen in der Chromatographie, überschriebene Messwerte.
Löschungen und Verwerfungen: gelöschte Sequenzen, verworfene Läufe, abgebrochene Messungen samt Begründung.
Methoden- und Parameteränderungen: geänderte Integrationsparameter, Rezeptur- oder Grenzwertänderungen zwischen Messung und Freigabe.
Datum-, Uhrzeit- und Sequenzauffälligkeiten: Messungen außerhalb der Schicht, Testläufe vor der eigentlichen Probe, auffällige Wiederholungsmuster.
Systemereignisse: Rechteänderungen, neue oder deaktivierte Konten, Konfigurationsänderungen, ein abgeschalteter Audit Trail.

Routineeinträge wie erfolgreiche Anmeldungen oder automatische Backups gehören nicht in den Einzelreview. Auffällige Muster darin, etwa Anmeldungen unter fremder Kennung, deckt der periodische Systemreview ab.

Risikobasierte Frequenz: zwei Ebenen, zwei Takte

Datenbezogener Review

Vor der Entscheidung, die auf den Daten beruht: Chargenfreigabe, Ergebnisfreigabe, Stabilitätsbewertung. Geprüft werden die Audit-Trail-Einträge der betroffenen Datensätze, im Takt des Freigabeprozesses.

Systembezogener Review

Periodisch nach Risikobewertung des Systems: Rechte- und Kontenänderungen, Konfiguration, Audit-Trail-Status. Üblich sind Intervalle zwischen monatlich und jährlich, festgehalten in der SOP und im Periodic Review.

Die Einstufung folgt der Kritikalität der Daten und der Konfigurierbarkeit des Systems. Ein Chromatographie-Datensystem mit manueller Integration braucht einen engeren Takt als ein Temperaturlogger mit festem Messprogramm. Die Risikobewertung dokumentieren wir je System, methodisch angelehnt an unser Vorgehen in der Computersystemvalidierung (CSV).

Wer prüft: Rollen und Verantwortung

Der Review gehört zu den Personen, die die Daten fachlich beurteilen können. Bewährt hat sich ein dreistufiges Modell:

Zweite Person im Vier-Augen-Prinzip: prüft die datenbezogenen Einträge im Zuge des Record Reviews vor der Freigabe. Der Ersteller der Daten prüft nie seine eigenen Einträge.
Systemverantwortlicher oder Key User: führt den periodischen Systemreview durch, inklusive Rechte, Konfiguration und Audit-Trail-Status.
QA: definiert den Prozess, prüft stichprobenartig und bewertet Auffälligkeiten im Abweichungsmanagement.

Signiert wird der Review elektronisch im System oder auf einer Checkliste; die Anforderungen an solche Signaturen beschreibt unsere Seite zu elektronischen Signaturen.

Praxis-Tipps: So wird der Review im Alltag machbar

Aus unseren Projekten haben sich fünf Festlegungen bewährt, die jede Review-SOP beantworten sollte, bevor der erste Review startet:

Filter in der Bedien- oder Betreiber-SOP festschreiben: Welche Filter, Abfragen oder Berichte im System für den Review verwendet werden, gehört dokumentiert in die Bedien-SOP des Systems oder die Betreiber-SOP. Nur so ist der Review reproduzierbar und nicht davon abhängig, welche Ansicht sich der einzelne Reviewer zusammenklickt. Ideal: vordefinierte, validierte Filtersets je Systemrolle.
Intervall festlegen und regulatorisch begründen: Das Review-Intervall wird je System aus der Risikobewertung abgeleitet und gegen die einschlägigen Regularien geprüft: Annex 11 fordert regelmäßige Prüfung, die FDA erwartet den datenbezogenen Review im Record Review vor der Freigabe, die MHRA verlangt risikobasierte Frequenzen. Das Ergebnis samt Begründung steht in der SOP, nicht nur im Kopf des Systemverantwortlichen.
Dokumentationsart definieren: Vorab festlegen, wie der Review nachgewiesen wird: elektronische Signatur mit Review-Status im System, Checkliste im Dokumentenmanagement oder Review-Bericht. Der Nachweis nennt Zeitraum, geprüfte Datenbereiche, verwendete Filter, Auffälligkeiten und Bewertung.
Rechte für den Review klären: Der Reviewer braucht lesenden Zugriff auf den vollständigen Audit Trail inklusive Export- oder Berichtsfunktion, aber keine Änderungs- oder Administratorrechte. Fehlt ein eigenes Review-Rollenprofil, entsteht in der Praxis oft ein Dilemma: Entweder sieht der Reviewer nicht alles, oder er bekommt zu mächtige Rechte. Das Rollenkonzept gehört deshalb in die Systemkonfiguration und in die Betreiber-SOP.
Orphan-Data-Check einplanen: Verwaiste Daten sind Datensätze, die außerhalb des berichteten Workflows entstehen und in keiner Auswertung auftauchen: Einzel- und Testinjektionen, abgebrochene Läufe, Messungen in lokalen Ordnern oder unter Testprojekten. Der Orphan-Data-Check gleicht ab, ob alle vom System erzeugten Rohdaten entweder berichtet oder nachvollziehbar begründet verworfen wurden. Er deckt damit genau die Daten auf, die ein reiner Blick in den Audit Trail des berichteten Ergebnisses nie zeigt.

Typische Auffälligkeiten beim Audit-Trail-Review

Diese Muster sollte jeder Reviewer kennen, denn sie tauchen in Inspektionsberichten immer wieder auf:

Testinjektionen oder Probeläufe unmittelbar vor der eigentlichen Messung, die wie ein Vorab-Test des Ergebnisses wirken.
Wiederholte Messungen derselben Probe, bis ein spezifikationskonformes Ergebnis erscheint, ohne Abweichungsmeldung.
Ergebnis- oder Parameteränderungen kurz vor der Freigabe, besonders geänderte Integrationsparameter beim selben Analyten.
Aktivitäten unter fremder Benutzerkennung, außerhalb der Schichtzeiten oder von unerwarteten Arbeitsplätzen.
Lücken in Sequenznummern oder Zeitstempeln, rückdatierte Einträge, auffällige Sprünge der Systemzeit.
Ein zwischenzeitlich deaktivierter Audit Trail oder geänderte Audit-Trail-Konfiguration.
Verwaiste Daten aus dem Orphan-Data-Check, die in keinem Bericht auftauchen und nie begründet verworfen wurden.

Jede Auffälligkeit ist zunächst ein Prüfauftrag, kein Urteil: Viele Muster haben harmlose Erklärungen. Entscheidend ist, dass der Reviewer sie erkennt, dokumentiert und über das Abweichungsmanagement bewerten lässt.

Typische Findings aus Audits und Inspektionen

Der Audit Trail ist vorhanden, aber seit Systemeinführung wurde nie ein Review durchgeführt oder dokumentiert.
Die SOP fordert einen Review "regelmäßig", ohne Frequenz, Umfang oder Verantwortliche zu nennen.
Der Audit Trail lässt sich im System deaktivieren, und niemand prüft, ob er aktiv ist.
Reviews werden pauschal abgezeichnet, ohne dass das System Filter oder Berichte für einen sinnvollen Review bietet.
Ergebnisänderungen zwischen Messung und Freigabe fallen erst dem Inspektor auf, nicht dem eigenen Review.
Bei Altsystemen ohne Audit Trail fehlen Risikobewertung und kompensierende Kontrollen.

Was Sie bekommen

Wir bringen den Audit-Trail-Review vom Papieranspruch in den gelebten Betrieb.

Welche Artefakte brauchen Sie zuerst?

Erstgespräch vereinbaren

FAQ: Audit-Trail-Review

Muss jeder Audit Trail vollständig reviewt werden?

Nein. Die Behörden erwarten einen risikobasierten Review: Im Fokus stehen Änderungen und Löschungen GMP-relevanter Daten, etwa Ergebnisänderungen, erneute Integrationen in der Chromatographie oder geänderte Methodenparameter. Routineeinträge wie erfolgreiche Anmeldungen müssen nicht einzeln gesichtet werden, wohl aber auffällige Muster.

Wie oft muss ein Audit-Trail-Review stattfinden?

Chargen- oder ergebnisbezogene Audit-Trail-Einträge werden vor der jeweiligen Entscheidung geprüft, also vor Chargenfreigabe oder Ergebnisfreigabe. Systembezogene Einträge wie Rechteänderungen, Konfigurationsänderungen oder deaktivierte Audit Trails werden periodisch geprüft, die Frequenz folgt der Risikobewertung des Systems, üblich sind Intervalle zwischen monatlich und jährlich.

Wer darf den Audit-Trail-Review durchführen?

Eine sachkundige Person, die die Daten fachlich beurteilen kann und nicht der Ersteller der Daten ist. In der Praxis übernimmt der Review häufig die prüfende zweite Person im Vier-Augen-Prinzip; QA behält die Aufsicht über Prozess und Stichproben. Die Verantwortung muss in einer SOP eindeutig zugewiesen sein.

Was tun, wenn das Altsystem keinen auswertbaren Audit Trail hat?

Zuerst das Risiko bewerten und dokumentieren. Übergangsweise helfen kompensierende Kontrollen wie eingeschränkte Rechte, Vier-Augen-Prüfungen auf Papier und regelmäßige Datenabgleiche. Mittelfristig erwarten die Behörden ein Upgrade oder einen Systemwechsel; die Erwartung ist in der FDA- und MHRA-Guidance klar formuliert.

Was ist ein Orphan-Data-Check?

Der Orphan-Data-Check sucht nach verwaisten Daten: Rohdaten, die das System erzeugt hat, die aber in keinem berichteten Ergebnis auftauchen, etwa Testinjektionen, abgebrochene Läufe oder Messungen in lokalen Ordnern und Testprojekten. Geprüft wird, ob alle erzeugten Daten entweder berichtet oder nachvollziehbar begründet verworfen wurden. Der Check ergänzt den Audit-Trail-Review, weil der Audit Trail des berichteten Ergebnisses diese Daten nicht zeigt.

Muss der Audit-Trail-Review selbst dokumentiert werden?

Ja. Ohne Nachweis gilt der Review im Audit als nicht durchgeführt. Üblich sind eine Checkliste oder Signatur im System, die den geprüften Zeitraum, die geprüften Datenbereiche, Auffälligkeiten und die Bewertung festhält. Idealerweise unterstützt das System den Review mit Filtern und einem eigenen Review-Status.

Fordert Annex 11 einen regelmäßigen Audit-Trail-Review?

Ja. Annex 11 Abschnitt 9 verlangt, dass Audit Trails regelmäßig geprüft werden, wenn sie GMP-relevante Änderungen und Löschungen aufzeichnen. Der Entwurf der Annex-11-Revision konkretisiert die Erwartung weiter in Richtung risikobasierter, dokumentierter Reviews. 21 CFR Part 11 fordert in § 11.10(e) einen sicheren, computergenerierten Audit Trail, dessen Prüfung die FDA in ihrer Data-Integrity-Guidance erwartet.