Inhaltsverzeichnis
Das Wichtigste vorab
Darf ein Audit-Trail-Review auf ausgewählte Ereignisse begrenzt werden?
Der Review-Umfang muss zur Datenkritikalität, zu möglichen Manipulations- oder Fehlerwegen und zur anstehenden Entscheidung passen. Eine begründete Auswahl relevanter Ereignisse kann geeignet sein. Eine willkürliche Stichprobe oder ein ungeprüfter Filter darf jedoch keine kritischen Änderungen ausblenden. Umfang, Zeitpunkt und Reaktion auf Befunde müssen nachvollziehbar festgelegt sein.
Einordnung und Geltungsbereich
Der Beitrag vertieft die Auswahlmethodik. Er nennt keine allgemeine zulässige Prozentzahl und keine pauschale Befreiung vom Review relevanter Daten vor ihrer Verwendung. Anwendbare Vorgaben und Prozesskontext bleiben maßgeblich.
Weniger Einträge lesen heißt nicht weniger Nachweis brauchen
Der Anlass verändert den Umfang. Ein routinemäßiger Datenreview, eine periodische Systembewertung und die Untersuchung eines konkreten Verdachts verfolgen unterschiedliche Fragen. Ein nachgewiesenes Problem kann eine Erweiterung auf weitere Zeiträume, Benutzer oder Datenbestände erforderlich machen.
Dokumentieren Sie auch, was nicht ausgewählt wird und warum. Technisches Rauschen kann die Erkennbarkeit wichtiger Ereignisse vermindern. Es sollte aber nicht pauschal entfernt werden, wenn darin relevante direkte Eingriffe oder fehlerhafte Verarbeitungen sichtbar werden. Die Auswahl ist eine fachliche Entscheidung, keine reine Komforteinstellung.
Den Review von der benötigten Qualitätsentscheidung ableiten
Beginnen Sie mit Daten und möglichen Fehlerfolgen. Welche Änderung könnte eine Qualitätsentscheidung beeinflussen? Wer kann sie ausführen und wie wird sie sonst erkannt? Daraus ergibt sich, welche Ereignisse im Review besondere Bedeutung besitzen. Eine lange Liste sämtlicher Logeinträge ist nicht automatisch gründlicher als eine begründete, wirksame Auswahl.
Annex 11 behandelt Audit Trails risikobezogen und verlangt, dass sie verfügbar und überprüfbar sind. Die konkrete Reviewauswahl und Häufigkeit sind für den Einsatz zu bestimmen. Dieser Artikel setzt weder einen universellen täglichen Rhythmus noch eine pauschale Vollprüfung jeder technischen Meldung voraus. Die Entscheidung sollte Datenkritikalität, Änderungsmöglichkeiten und vorhandene Kontrollen zusammenführen.
Unterscheiden Sie laufende Prüfung eines Vorgangs und übergreifenden Review. Eine Ergebnisänderung kann vor der zugehörigen Entscheidung betrachtet werden müssen. Wiederkehrende administrative Auffälligkeiten können einen anderen Reviewweg benötigen. Benennen Sie Zweck, Zeitpunkt und zuständige Rolle für jede relevante Ebene.
Eine Auswahlmatrix nach Daten, Ereignis und Risiko erstellen
Erfassen Sie kritische Datenobjekte und mögliche Aktionen: Anlegen, Ändern, Löschen, erneute Verarbeitung oder Statuswechsel. Ergänzen Sie Quelle des Auditdatensatzes und verfügbare Informationen. Ein gewünschter Review ist praktisch nicht wirksam, wenn das benötigte Ereignis im verwendeten System gar nicht angemessen sichtbar ist.
Begründen Sie auch Ausschlüsse. Eine technische Meldung ohne Einfluss auf die betrachtete Aufzeichnung kann anders behandelt werden als eine Grenzwertänderung. Die Auswahl darf aber nicht allein danach erfolgen, welche Ereignisse besonders bequem auszuwerten sind. Unbequeme, kritische Ereignisse bleiben im Risikobild sichtbar.
| Datenbereich | Kritisches Ereignis im Beispiel | Reviewfrage |
|---|---|---|
| Ergebnis | Wert nach Erfassung geändert | Warum, durch wen und mit welcher Wirkung? |
| Spezifikation | Grenzwert oder Methode angepasst | Welche Vorgänge verwenden den neuen Stand? |
| Identität | Probe oder Charge umgeordnet | Bleibt die richtige Zuordnung erhalten? |
| Rechte | Kritische Befugnis erweitert | Ist Vergabe und tatsächliche Verwendung angemessen? |
| Auditfunktion | Erfassung oder Filter verändert | Bleibt die benötigte Abdeckung erhalten? |
Beispiel: ein Filter übersieht Ergebnisänderungen durch eine zweite Rolle
Das Szenario ist konstruiert. Ein Reviewreport zeigt Änderungen durch Laborbenutzer. Eine technische Rolle kann dieselben Ergebnisfelder verändern, wird aber vom Filter ausgeschlossen. Der Report ist leer, obwohl ein kritischer Wert geändert wurde. Die bloße Existenz eines Reviewverfahrens bestätigt daher keine vollständige Abdeckung.
Erzeugen Sie kontrolliert bekannte Ereignisse durch die relevanten Rollen und Wege. Prüfen Sie, ob sie im vorgesehenen Report erscheinen und verständlich zugeordnet sind. Dokumentieren Sie den tatsächlichen Filterstand. Ergänzen Sie einen Fall außerhalb des Zeitfensters und einen unbekannten Ereignistyp, wenn diese Risiken bestehen.
Nach Korrektur des Filters wird die Erkennungsfähigkeit erneut geprüft. Bewerten Sie außerdem, ob der bisherige unvollständige Report frühere relevante Änderungen ausgelassen haben kann. Eine solche Umfangsprüfung wird anhand des konkreten Risikos festgelegt. Ein neuer funktionierender Report beantwortet die historische Frage nicht automatisch.
| Testfall | Aktion | Erwarteter Nachweis |
|---|---|---|
| Fachbenutzer | Kritischen Wert ändern | Ereignis im vorgesehenen Review sichtbar |
| Technischer Weg | Gleiche Änderung kontrolliert ausführen | Relevanter Weg nicht unbegründet ausgeschlossen |
| Zeitgrenze | Ereignis am Rand des Fensters erzeugen | Definierte zeitliche Abdeckung |
| Filteränderung | Kritische Auswahlregel gezielt verändern | Kontrollprüfung erkennt die Lücke |
| Ausfall | Bericht oder Datenzufuhr unterbrechen | Kein irreführender leerer Erfolgsreport |
Häufigkeit und Zeitpunkt fachlich begründen
Fragen Sie, wann eine fehlerhafte Änderung spätestens erkannt werden muss, damit ihre Wirkung angemessen behandelt werden kann. Eine Prüfung erst lange nach einer Qualitätsentscheidung kann für bestimmte Risiken zu spät sein. Andere Ereignisse können sinnvoll übergreifend betrachtet werden. Die geeignete Frequenz ergibt sich aus dem Prozess, nicht aus einer willkürlichen Standardzahl.
Berücksichtigen Sie Ereignismenge und verfügbare Reviewer. Ein Verfahren, das täglich tausende unstrukturierte Meldungen ohne Kriterien fordert, kann praktisch versagen. Verbessern Sie Auswahl und Darstellung, ohne kritische Abdeckung zu verlieren. Eine risikobasierte Reduktion braucht eine nachvollziehbare Begründung und geeignete Wirksamkeitsprüfung.
Definieren Sie, wie fehlende oder verspätete Reviews erkannt werden. Die Unterschrift unter einem Plan ist noch kein Nachweis der tatsächlichen Ausführung. Benötigt werden passende Aufgabensteuerung und Eskalation. Umfang und Form können in vorhandene QMS-Verfahren integriert werden.
Reviewer mit Kriterien und Untersuchungsweg ausstatten
Ein Reviewer braucht fachliches Verständnis, Zugang zum betroffenen Vorgang und Kriterien für Auffälligkeiten. Eine Änderung kann legitim sein und dennoch erklärungsbedürftig. Der Review sollte unterscheiden, ob Grund und Befugnis nachvollziehbar sind und ob weitere Daten betroffen sein können. Eine reine Kontrolle auf leere Begründungsfelder ist dafür häufig zu wenig.
Legen Sie fest, wie eine Auffälligkeit untersucht wird. Benötigt werden Datenbezug, Sicherung relevanter Informationen und Zuständigkeit. Technische Erklärung und fachliche Wirkung sind verbunden, aber nicht identisch. Eine vom Administrator bestätigte Systemfunktion beendet nicht automatisch die Bewertung einer Ergebnisänderung.
Üben Sie mit bekannten Fällen: legitime Korrektur, falsche Zuordnung und unerwartete privilegierte Änderung. Dokumentieren Sie, ob der Reviewer die relevanten Unterschiede erkennt. Dies ist eine eigene methodische Erprobung, keine allgemeine vorgeschriebene Prüfungsform.
Auswahl und Nachweise bei Änderungen erhalten
Neue Datenfelder, Rollen oder Schnittstellen können den Reviewumfang verändern. Bewerten Sie deshalb Filter und Reports bei relevanten Systemänderungen. Ein einmal geprüfter Report bleibt nicht automatisch für jede spätere Konfiguration geeignet. Der Bezug zwischen Risikobild, Auswahl und tatsächlicher Abdeckung sollte gepflegt werden.
Erhalten Sie Reviewstand, betrachteten Zeitraum, Befunde und deren Bewertung. Ein Vermerk „geprüft, keine Auffälligkeit“ ist wenig aussagekräftig, wenn der Umfang nicht erkennbar ist. Gleichzeitig ist nicht für jeden unkritischen Eintrag eine lange Einzelbegründung erforderlich. Die Dokumentation sollte den vorgesehenen Review nachvollziehbar machen.
Arbeitsvorlage: Reviewumfang und Filter mit bekannten Ereignissen abnehmen
Beschreiben Sie zunächst die relevanten Ereignisse ohne Reporttechnik. Im Beispiel sollen Änderungen an Ergebniswert, Probenzuordnung und kritischer Spezifikation betrachtet werden. Ergänzen Sie Rollen und Wege, über die diese Änderungen möglich sind. Erst danach wird geprüft, ob der konfigurierte Report diese Auswahl vollständig unterstützt.
Erzeugen Sie geeignete bekannte Ereignisse und vergleichen Sie sie mit der Ausgabe. Eine leere Liste wird nicht automatisch als Erfolg bewertet. Prüfen Sie Zeitbereich, Datenzufuhr und Filter. Benennen Sie außerdem, wie unbekannte Ereignisse oder ausgefallene Auswertung im Betrieb erkannt werden.
Dokumentieren Sie die Abdeckung mit dem tatsächlichen Filterstand. Bei neuen Rollen, Datenfeldern oder Schnittstellen wird sie erneut bewertet. Eine einmal geprüfte Auswahl bleibt nicht automatisch für jede spätere Nutzung vollständig. Die Pflege sollte mit Change Control und den fachlichen Aufgaben verbunden sein.
| Reviewfeld | Konstruierter Eintrag | Akzeptanzfrage |
|---|---|---|
| Daten | Ergebnis und zugehörige Probe. | Ist der kritische Zusammenhang abgedeckt? |
| Aktion | Wertänderung und Umzuordnung. | Erscheinen bekannte Testereignisse? |
| Rolle | Fachlicher und relevanter technischer Weg. | Kein unbegründeter Ausschluss? |
| Zeit | Bezeichneter Zeitraum mit Randfällen. | Ist die Auswahlgrenze richtig? |
| Ausfall | Datenzufuhr wird kontrolliert unterbrochen. | Kein irreführender Nullbefund? |
| Bewertung | Reviewer erklärt Ereignis und nächsten Schritt. | Kontrolle ist praktisch ausführbar? |
Die nächsten Schritte
- Entscheidung und kritische Ereignisse definieren.
- Auswahl und Filter gegen bekannte Testereignisse prüfen.
- Reviewzeitpunkt, Kompetenz und Dokumentation festlegen.
- Erweiterungsregeln bei Auffälligkeiten vorsehen.
Häufige Fragen zu Audit-Trail-Review: Auswahl
Sind zehn Prozent immer eine ausreichende Stichprobe?
Kann Software den manuellen Review ersetzen?
Reicht ein jährlicher Review für chargenrelevante Änderungen?
Müssen wir jeden technischen Logeintrag manuell prüfen?
Nicht pauschal. Leiten Sie relevante Daten und Ereignisse aus Risiken und Qualitätsentscheidungen ab. Begründen Sie Auswahl, Zeitpunkt und Grenzen. Technische Logs können wichtige Ergänzungen enthalten, sind aber nicht automatisch vollständig als Audit Trail geeignet. Die Erkennungsfähigkeit des gewählten Reports sollte mit bekannten kritischen Ereignissen geprüft werden.
Ist ein leerer Audit-Trail-Report ein gutes Ergebnis?
Nur wenn Datenzufuhr, Zeitbereich und Filter nachweislich funktionieren. Ein leerer Report kann auch eine falsche Auswahl oder einen Ausfall zeigen. Verwenden Sie geeignete bekannte Ereignisse und Vollständigkeitskontrollen. Der Review sollte seine Abdeckung erklären können, statt Leere automatisch mit dem Fehlen relevanter Änderungen gleichzusetzen.
Was sollte ein Reviewvermerk mindestens erklären?
Er sollte den betrachteten Umfang, Zeitraum, geeigneten Regel- oder Reportstand sowie Befunde und Entscheidung nachvollziehbar machen. Die konkrete Form kann variieren. Ein pauschales geprüft ohne erkennbaren Gegenstand ist schwach. Nicht jeder unkritische Eintrag benötigt deshalb automatisch eine lange Einzelbegründung.
Wie prüfen wir die Fähigkeit des Reviewers?
Verwenden Sie bekannte legitime und auffällige Änderungen mit den vorgesehenen Vergleichsinformationen. Beobachten Sie, ob der Reviewer relevante Unterschiede erkennt und passend handelt. Die Übung sollte zur Aufgabe und Arbeitslast passen. Eine Teilnahmebestätigung allein zeigt diese praktische Fähigkeit nur begrenzt.
Quellen & fachlicher Stand
Die Quellen bilden den fachlichen Rahmen. Tabellen, Checklisten und ausdrücklich illustrative Beispiele sind eigene methodische Ableitungen, keine wörtlichen Normvorgaben. Herstellerinformationen sind auf die eingesetzte Version und Konfiguration zu beziehen.
- Europäische Kommission: EU-GMP Annex 11, Computerised Systems (2011)§ 9: risikobezogener Audit-Trail-Rahmen; konkrete Auswahlmatrix und Testereignisse sind eigene Methoden. Geltende Fassung laut EudraLex am 14.10.2026; keine universelle Projekt- oder Fristvorgabe.
- PIC/S: PI 041-1, Good Practices for Data Management and Integrity (2021)Inspektionsleitlinie zur Datenintegrität; insbesondere elektronische Daten, Übertragung, Zugriff und Review.
- FDA: Data Integrity and Compliance With Drug CGMP – Questions and AnswersFinale Guidance, Dezember 2018; keine pauschale Übertragung auf sämtliche GxP-Rechtsbereiche.
Zuletzt fachlich geprüft am 14.10.2026.
Daniel Herrmann Consulting
Vom offenen Punkt zu einem nachvollziehbaren Vorgehen.
Wir unterstützen Sie dabei, die Ausgangslage einzuordnen, Verantwortlichkeiten zu klären und passende Nachweise im Betrieb umzusetzen. Welche Unterstützung sinnvoll ist, hängt von Ihrem System, Ihrem Team und dem konkreten Ziel ab.
- IT-GxP-Audit →
Offene Punkte und Prioritäten für Ihren Betrieb einordnen.
- IT-GxP-Consulting →
Vereinbarte Systemprojekte strukturiert umsetzen und übergeben.