Audit Trail Review Checkliste: kaum ein Begriff taucht in den Data-Integrity-Inspektionen der letzten Jahre so häufig auf. FDA- und EMA-Inspektoren fragen längst nicht mehr nur, ob Audit Trails aktiviert sind, sondern wie sie geprüft werden: von wem, wie oft, auf welche Ereignisse und mit welchem dokumentierten Nachweis. Eine gut aufgebaute Checkliste macht aus der Review eine gezielte Kontrolle statt einer generischen Pflichtübung: Sie legt vorab fest, was in jedem System (CDS, LIMS, MES, SCADA, eQMS) zu prüfen ist, wie Auffälligkeiten zu bewerten sind und wie das Ergebnis dokumentiert wird. In diesem Artikel finden Sie die einschlägigen regulatorischen Anforderungen, die Prüfpunkte für die Checkliste System für System, die Kriterien für eine risikobasierte Frequenz und die Fehler, die Auditoren am häufigsten beanstanden.
Audit Trail Review Checkliste: Was die Regelwerke verlangen
Kein Regelwerk liefert eine fertige Checkliste, aber die Anforderungen ergeben sich aus vier Hauptquellen.
Die FDA-Guidance Data Integrity and Compliance With Drug CGMP: Questions and Answers (Dezember 2018) behandelt Audit Trails in den Fragen 1.c, 7 und 8. Das Kernprinzip von Frage 7: Die Audit-Trail-Review gehört zu dem Personal, das ohnehin für die Prüfung der Aufzeichnungen verantwortlich ist — genauso, wie man auf Papier Streichungen und Korrekturen bewertet. Sie ist also keine IT-Aufgabe, sondern Aufgabe von QC, Produktion und QA im Rahmen der routinemäßigen Data Review.
Der EU-GMP-Annex 11 (Computerised Systems) verlangt unter Punkt 9, auf Basis einer Risikobewertung Audit Trails für Änderungen und Löschungen GMP-relevanter Daten vorzusehen, den Grund von Änderungen zu dokumentieren und sicherzustellen, dass Audit Trails verfügbar, in eine lesbare Form konvertierbar und regelmäßig geprüft sind. Der Revisionsentwurf des Annex 11, den die Europäische Kommission vom 7. Juli bis 7. Oktober 2025 zusammen mit dem neuen Annex 22 zur Konsultation gestellt hat, verschärft genau die Kontrollen zu Audit Trails, elektronischen Signaturen und Systemsicherheit: Die dokumentierte Review wird noch zentraler.
Die Leitlinie PIC/S PI 041-1 (Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments, 1. Juli 2021) ist heute die operativste Referenz der Inspektorate: Sie koppelt Tiefe und Frequenz der Review an die Kritikalität der Daten und fordert den Nachweis, dass Auffälligkeiten erkannt und bearbeitet werden. Die MHRA-Guidance 'GXP' Data Integrity Guidance and Definitions (März 2018) vervollständigt das Bild mit den Audit-Trail- und Metadaten-Definitionen, die ein Großteil der Industrie verwendet.
So bauen Sie die Checkliste auf: die drei Kernblöcke
Eine wirksame Audit Trail Review Checkliste gliedert sich in drei Blöcke.
- Systemvoraussetzungen: Audit Trail aktiviert und durch normale Benutzer nicht abschaltbar, Uhrzeitsynchronisation, Pflichtfeld "Änderungsgrund", getrennte Rollen und Berechtigungen (wer Daten erzeugt, darf sie nicht administrieren).
- Zu prüfende Ereignisse: die gefilterte Liste der kritischen Ereignisse je System, in der Validierung festgelegt und in der SOP referenziert. "Alles" zu prüfen heißt, nichts zu prüfen.
- Ergebnis und Dokumentation: Bewertung der Auffälligkeiten (per Verfahren vorgesehen? begründet? konsistent mit Zeiten, Rollen und Signaturen?), bei Bedarf Eröffnung einer Abweichung oder Untersuchung sowie dokumentierte Erfassung der Review mit Datum und Unterschrift des Prüfers.
Themen wie dieses — Data Integrity, Audit Trails, Inspektionen — sind das tägliche Brot von The Pragmatic GMP, dem kostenlosen wöchentlichen Newsletter von GuideGxP: jede Woche ein GMP-Thema, heruntergebrochen auf operative Entscheidungen, ohne überflüssige Theorie. Hier anmelden.
Die kritischen Ereignisse im Überblick, System für System
Die Tabelle fasst zusammen, welche Ereignisse eine Checkliste in den gängigsten Labor- und Produktionssystemen erfassen sollte.
| System | Kritische zu prüfende Ereignisse | Typischer Review-Zeitpunkt |
|---|---|---|
| CDS (HPLC/GC) | Reprozessierungen und manuelle Integrationen, Änderungen an Methoden und Sequenzen, Ausschluss oder Löschung von Injektionen, nicht begründete Wiederholungen | Mit der analytischen Review, vor der Ergebnisfreigabe |
| LIMS | Ergebnisänderungen nach der Erfassung, Statuswechsel (Review/Freigabe), stornierte Prüfungen, Änderungen an Spezifikationen und Stammdaten | Mit der Chargen- oder Probenreview |
| MES / SCADA | Änderungen kritischer Prozessparameter, manuelle Overrides, Alarme und zugehörige Reaktionen, wiederholte oder abgebrochene Schritte | Mit der Batch-Record-Review, vor der Freigabe |
| eQMS / Dokumentenmanagement | Änderungen an freigegebenen Aufzeichnungen, Wiedereröffnung von Workflows, Administratoraktionen an GMP-Daten | Geplante periodische Review |
| Alle Systeme | Wiederholte fehlgeschlagene Logins, auffällige Aktivitäten außerhalb der Arbeitszeit, Aktivitäten unter Sammel- oder "Admin"-Konten, Änderungen an Systemdatum/-uhrzeit | Periodische Review + anlassbezogen |
Review-Frequenz: der risikobasierte Ansatz
Es ist die Frage, die jede QA hört: Wie oft muss die Review erfolgen? Frage 8 der FDA-Guidance liefert die konkreteste Regel: Ist die Prüffrequenz der Daten bereits durch die CGMP-Vorschriften festgelegt, folgt die Audit-Trail-Review dieser Frequenz. Audit Trails zu Änderungen kritischer Daten sind daher zusammen mit der zugehörigen Aufzeichnung und vor der endgültigen Freigabe zu prüfen — bei einem Analysenergebnis mit der Data Review, bei einer Charge vor der Freigabe. Für alle übrigen Audit Trails wird die Frequenz über eine dokumentierte Risikobewertung festgelegt, unter Berücksichtigung der Datenkritikalität, der vorhandenen technischen Kontrollen und der Auswirkung auf die Produktqualität: Periodische Reviews (etwa monatlich oder quartalsweise) sind akzeptabel, wenn die Begründung fundiert und schriftlich ist.
Ein verbreiteter Fehler ist es, in der SOP nicht haltbare Frequenzen zu versprechen: Besser eine gezielte Review auf gefilterte Ereignisse, die tatsächlich stattfindet, als eine deklarierte "Voll-Review", die nie abgeschlossen wird.
Die Fehler, die Inspektoren am häufigsten beanstanden
- Review deklariert, aber nicht dokumentiert: Die SOP existiert, der Nachweis nicht. Jede Review muss eine Spur hinterlassen: elektronische Signatur, Kommentar oder gefilterter Report.
- Keine Ereignisfilter: Tausende Logzeilen auszudrucken ist keine Review. Filter für "signifikante Ereignisse" müssen definiert und validiert werden.
- Änderungsgrund optional: Erzwingt das System keine Begründung der Änderung, verliert die Review einen Großteil ihres Werts.
- Nicht getrennte Berechtigungen: Analysten mit Administratorrechten machen den Audit Trail selbst unzuverlässig.
- Auffälligkeiten ohne Follow-up: Eine erkannte, aber nicht in Abweichung oder Untersuchung nachverfolgte Auffälligkeit ist in den Augen eines Inspektors schlimmer als eine nicht erkannte.
GuideGxP-Empfehlung
Beginnen Sie mit dem Inventar der GxP-Systeme und klassifizieren Sie deren Audit Trails nach Kritikalität; definieren Sie je System in der Validierung die Liste der kritischen Ereignisse und die zugehörigen Filter; schreiben Sie eine SOP, die die Review denjenigen zuweist, die die Aufzeichnungen ohnehin prüfen, mit über die Risikobewertung begründeten Frequenzen; dokumentieren Sie jede Review und verknüpfen Sie Auffälligkeiten mit dem Abweichungssystem. Überarbeiten Sie die Checkliste bei jeder relevanten Systemänderung und in der periodischen Review.
Wenn Sie einen bereits strukturierten Weg suchen: Der GuideGxP-Leitfaden Data Integrity im GMP-Umfeld – Operativer Leitfaden zu Governance, Audit Trail Review und QC-Laboren enthält die vollständige Methode, um Governance, Checklisten und inspektionsfeste Audit-Trail-Review-Frequenzen aufzusetzen, inklusive operativem Toolkit.
Offizielle Quellen
- FDA – Data Integrity and Compliance With Drug CGMP: Questions and Answers (2018)
- PIC/S PI 041-1 – Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments (2021)
- Europäische Kommission – Konsultation zu EudraLex Vol. 4: Chapter 4, Annex 11 und Annex 22 (2025)
- MHRA – 'GXP' Data Integrity Guidance and Definitions (2018)
