Audit Trail Review in Pharma: Umfang, Frequenz und Nachweis

Ein Audit Trail Review in Pharma prüft nicht pauschal jedes technische Ereignis. Er fokussiert die Änderungen, Löschungen und Aktionen, die einen GxP-relevanten Record oder eine Qualitätsentscheidung beeinflussen können. Umfang, Frequenz und Reviewer werden aus Datenkritikalität, Prozessrisiko und vorhandenen Kontrollen abgeleitet. Der Nachweis muss zeigen, was geprüft wurde, welche Auffälligkeiten untersucht wurden und wer die Bewertung freigegeben hat.

Warum „Audit Trail vorhanden“ noch kein wirksamer Kontrollnachweis ist

Ihr System erzeugt Tausende Einträge. QA fordert einen regelmäßigen Review. Der Betrieb kann jedoch nicht jeden Login, jeden technischen Statuswechsel und jede Hintergrundmeldung manuell bewerten. Genau an dieser Stelle wird aus einer regulatorischen Anforderung schnell ein kaum steuerbarer Prozess.

Die Lösung ist nicht weniger Kontrolle. Die Lösung ist ein fachlich definierter Scope. Ein Review beginnt beim regulierten Record und der Qualitätsentscheidung. Erst danach wird festgelegt, welche Audit-Trail-Ereignisse dafür relevant sind.

Die FDA verknüpft die Audit-Trail-Prüfung mit der Prüfung des zugehörigen CGMP-Records. Ist eine Prüffrequenz für den Record vorgegeben, gilt sie auch für den dazugehörigen Audit Trail. Fehlt eine konkrete Frequenz, soll die Organisation sie anhand von Datenkritikalität, Kontrollen und möglicher Produktwirkung bestimmen.

EU GMP Annex 11 sieht vor, risikobasiert zu prüfen, ob für GMP-relevante Änderungen und Löschungen ein Audit Trail in das System integriert wird. Vorhandene Audit Trails müssen in eine verständliche Form überführbar sein und regelmäßig geprüft werden. Soweit 21 CFR Part 11 auf einen elektronischen Record anwendbar ist, fordert § 11.10(e) einen sicheren, computergenerierten und zeitgestempelten Audit Trail. PIC/S PI 041-1 ergänzt, dass kritische Daten und aufzuzeichnende Änderungen klar definiert sein sollen.

Daten-Audit-Trail, Systemlog und Sicherheitsprotokoll trennen

Nicht jedes Protokoll erfüllt denselben Zweck. Ohne diese Trennung wächst der Review-Umfang, während die Aussagekraft sinkt.

Protokolltyp	Typische Inhalte	Review-Zweck
Daten-Audit-Trail	Anlage, Änderung oder Löschung eines GxP-Records; alter und neuer Wert; Grund	Einfluss auf Datenintegrität und Qualitätsentscheidung bewerten
Konfigurations-Audit-Trail	Rollen, Workflows, Berechnungsregeln, Stammdaten oder Systemeinstellungen	Unerwartete oder nicht genehmigte Systemänderungen erkennen
Sicherheits- oder Systemlog	Login, fehlgeschlagener Zugriff, technische Jobs, Schnittstellenfehler	Sicherheits- und Betriebsrisiken überwachen
Support- und Vendor-Protokoll	Remote-Zugriff, Ticket, privilegierte Aktivität	Externe Eingriffe mit System- und Quality-Nachweisen abgleichen

Ein technisches Log kann für einen periodischen Sicherheitsreview wichtig sein. Es muss deshalb nicht automatisch Bestandteil jeder Chargen- oder Laborergebnisprüfung werden. Umgekehrt darf ein für den Record relevantes Ereignis nicht aus dem Scope fallen, nur weil es technisch in einem anderen Log liegt.

Welche Risiken bei Vendor-Eingriffen entstehen, zeigt der Beitrag zum Validieren elektronischer Batch Records.

Audit Trail Review in fünf Schritten aufsetzen

1. GxP-Records und Qualitätsentscheidungen priorisieren

Beginnen Sie nicht mit einer Liste vorhandener Logdateien. Beginnen Sie mit den Records, deren Integrität für Produktqualität, Patientensicherheit oder Freigabe entscheidend ist.

Dazu können Laborergebnisse, elektronische Batch Records, Freigaben, Spezifikationen, kritische Stammdaten oder qualitätsrelevante Berechnungen gehören. Für jeden Record wird festgelegt, welche Änderungen, Löschungen, Wiederholungen oder Statuswechsel relevant sind.

2. Signifikante Ereignisse und Ausnahmen definieren

Die Review-Regel braucht konkrete Kriterien. Beispiele sind Änderungen nach fachlichem Abschluss, gelöschte Ergebnisse, wiederholte Analysen, fehlende Änderungsgründe, privilegierte Aktionen oder Änderungen außerhalb des vorgesehenen Workflows.

Diese Kriterien werden mit Prozessverantwortlichen, System Owner und Quality abgestimmt. So erkennt der Reviewer nicht nur technische Ereignisse, sondern versteht ihre mögliche fachliche Wirkung.

3. Frequenz mit dem Record-Lebenszyklus verbinden

Kritische Änderungen an einem Record können vor dessen Genehmigung oder Freigabe geprüft werden müssen. Andere Ereignisse eignen sich für einen periodischen Review.

Eine belastbare Frequenzentscheidung berücksichtigt:

• die regulatorisch oder verfahrensseitig vorgegebene Record-Prüfung;
• Datenkritikalität und mögliche Produktwirkung;
• technische Prävention und Berechtigungsmodell;
• Volumen, Änderungsrate und bisherige Auffälligkeiten;
• weitere Kontrollen wie Zweitprüfung, Abweichungsmanagement und Zugriffskontrolle.

„Monatlich“ oder „quartalsweise“ ist ohne diese Begründung nur ein Kalendereintrag. Die Risikologik muss im Verfahren oder in der systemspezifischen Bewertung nachvollziehbar sein.

4. Review by Exception validieren

Ein Exception Report kann den Review fokussieren. Er ersetzt die fachliche Bewertung jedoch nicht. Das Team muss nachweisen, dass Filter, Abfragen und Schwellenwerte die relevanten Ereignisse vollständig und korrekt erfassen.

Zur Validierung gehören Positiv- und Negativfälle. Der Report muss bekannte kritische Änderungen anzeigen und irrelevante Ereignisse nachvollziehbar ausblenden. Änderungen an Filtern, Rollen oder Datenquellen unterliegen der Änderungskontrolle.

5. Reviewer-Nachweis und Eskalation schließen

Der Nachweis sollte mindestens Zeitraum, System, Record-Scope, verwendete Abfrage, Ergebnis, Auffälligkeiten, Folgeaktionen, Reviewer und Datum enthalten. Ein bloßes Häkchen „geprüft“ reicht für komplexe Ereignisse nicht.

Der Reviewer braucht fachliches Verständnis, Systemzugriff und eine definierte Unabhängigkeit von der geprüften Aktivität. Auffälligkeiten werden nicht nur kommentiert. Sie werden bei Bedarf mit Abweichung, Untersuchung, CAPA oder Change Control verknüpft.

Die systemspezifische Review-Spezifikation festhalten

Ein unternehmensweites Verfahren definiert Grundprinzipien, Rollen und Eskalation. Der konkrete Review-Scope gehört zusätzlich in eine systemspezifische Spezifikation oder Risikobewertung. Dort werden GxP-Records, relevante Audit Trails, ausgeschlossene technische Logs, Frequenzen, Abfragen und Verantwortliche benannt.

Diese Trennung hält die SOP stabil, obwohl Systeme unterschiedlich arbeiten. Sie erleichtert außerdem Änderungen. Wird ein neuer Workflow, ein anderes Exception-Kriterium oder eine zusätzliche Schnittstelle eingeführt, kann das Team gezielt prüfen, ob der Review-Scope angepasst und erneut getestet werden muss.

Ein prüfbarer Review-Nachweis

Ein Auditor muss die Entscheidungskette rekonstruieren können. Dafür empfiehlt sich ein kompakter, aber vollständiger Review-Record:

1. Scope: Welche Records, Datenfelder, Ereignisse und Zeiträume waren eingeschlossen?
2. Methode: Welche Systemansicht, Abfrage oder validierte Ausnahmefunktion wurde verwendet?
3. Ergebnis: Wie viele Ereignisse wurden erkannt und welche waren signifikant?
4. Bewertung: Welche Wirkung hatten Auffälligkeiten auf Record, Charge, Produkt oder Freigabe?
5. Folgeaktion: Welche Abweichung, CAPA oder technische Änderung wurde eröffnet?
6. Freigabe: Wer hat geprüft und wer hat die Bewertung genehmigt?

Diese Struktur verbindet technische Evidenz mit der Quality-Entscheidung. Sie erleichtert zugleich die GxP-Audit-Vorbereitung, weil Scope und Begründung nicht erst vor der Inspektion rekonstruiert werden müssen.

Drei typische Fehlansätze

Alles prüfen. Vollständige manuelle Logprüfung klingt streng, verdeckt aber relevante Ereignisse in großen Datenmengen. Besser ist ein begründeter Scope mit validierten Ausnahmen.

Nur das Systemlog prüfen. Login- und Betriebsereignisse ersetzen nicht die Prüfung von Änderungen am regulierten Record.

Den Report ohne Prozesskontext abzeichnen. Ein Ereignis wird erst durch seine Wirkung bewertbar. Reviewer benötigen deshalb Record-, Prozess- und Quality-Kontext.

Wiederkehrende Kontrolllücken aus Inspektionen ordnet der Beitrag zu FDA Warning Letters und Datenintegrität ein.

Häufige Fragen

Muss jeder Audit-Trail-Eintrag vor jeder Freigabe geprüft werden?

Nein. Die Frequenz folgt der Prüfung des zugehörigen Records oder einer dokumentierten Risikobewertung. Kritische Datenänderungen können eine Prüfung mit dem Record erfordern. Technische Ereignisse ohne direkten Record-Bezug können in einen begründeten periodischen Review fallen.

Darf ein Exception Report die manuelle Prüfung ersetzen?

Ein validierter Exception Report kann die Auswahl relevanter Ereignisse automatisieren. Die fachliche Bewertung und dokumentierte Entscheidung bleiben erforderlich. Filter, Datenquellen und Änderungssteuerung des Reports müssen nachweisbar beherrscht werden.

Wer sollte den Audit Trail prüfen?

Der Reviewer braucht ausreichende Prozess-, Daten- und Systemkenntnis sowie Zugriff auf den relevanten Record. Die Rollenverteilung muss Interessenkonflikte vermeiden. Für CGMP-Records verknüpft die FDA den Review mit den verantwortlichen Record- und Quality-Prüfungen.

Primärquellen

• FDA: Data Integrity and Compliance With Drug CGMP — Questions and Answers
• eCFR: 21 CFR Part 11 § 11.10 — Controls for closed systems
• EU GMP Annex 11: Computerised Systems, wirksame Fassung 2011
• PIC/S PI 041-1: Guidance on Data Integrity

---

Autor

Daniel Herrmann Consulting — Boutique-Beratung für GxP-Compliance und Computer System Validation in Pharma, Biotech und MedTech. 15+ Jahre Hands-on-Expertise. 60+ validierte Systeme. 100 % Audit-Bestehensquote. 0 kritische Findings.