Audit Trail deaktiviert: Was unter GMP jetzt zu tun ist

Der technische Befund sagt noch nicht, was passiert ist

Ein deaktivierter Audit Trail ist zunächst ein konkreter Kontrollbefund. Er beweist nicht automatisch, dass Daten manipuliert wurden. Er beweist aber ebenso wenig, dass die historischen Daten unverändert sind. Prüfen Sie, welche Ereignisse die Funktion erfassen sollte, welche Aufzeichnungen betroffen sein können und ob andere verlässliche Spuren vorhanden sind. Die Bewertung muss sowohl belegte Tatsachen als auch verbleibende Unsicherheit erkennen lassen.

Grenzen Sie die Funktion genau ab. Manche Systeme haben mehrere Protokolle für Daten, Methoden, Konfiguration oder Administration. Eine aktive Systemhistorie bedeutet nicht automatisch, dass Änderungen an allen relevanten Datensätzen erfasst wurden. Umgekehrt kann eine deaktivierte Teilfunktion einen begrenzten Bereich betreffen. Dokumentieren Sie tatsächlichen Zustand, Version, Einstellungen und relevante Verantwortlichkeiten. Vermeiden Sie eine vorzeitige Zusammenfassung als entweder „nur ein Häkchen“ oder „alle Daten unbrauchbar“.

Quellen: [1] [2]

Weitere Risiken begrenzen und Spuren erhalten

Informieren Sie die zuständigen Qualitäts- und Systemverantwortlichen und legen Sie eine kontrollierte Reaktion fest. Je nach Risiko können betroffene Tätigkeiten eingeschränkt, zusätzliche Reviews eingeführt oder Daten vorläufig von bestimmten Entscheidungen ausgeschlossen werden. Welche Maßnahme angemessen ist, hängt von Prozess, Datenkritikalität und verfügbaren Kontrollen ab. Eine pauschale Fortführung oder ein pauschaler Komplettstopp lässt sich aus dem technischen Befund allein nicht ableiten.

Sichern Sie relevante vorhandene Aufzeichnungen und Konfigurationsinformationen nach einem geeigneten Verfahren. Vermeiden Sie unkoordinierte Änderungen, Restore-Vorgänge oder Aufräumaktionen, die Spuren überschreiben könnten. Bei notwendiger unmittelbarer Gefahrenbegrenzung wird das Vorgehen mit den zuständigen Stellen abgestimmt und dokumentiert. Beschreiben Sie, wer welche Informationen wann erfasst hat. Eine nachträgliche Abschrift muss als solche erkennbar bleiben und darf nicht wie eine zeitgleich entstandene Originalaufzeichnung dargestellt werden.

Den möglichen Zeitraum nachvollziehbar eingrenzen

Suchen Sie nach belegbaren Zustandswechseln: Konfigurationsänderungen, Installationen, Upgrades, Berechtigungsereignissen, freigegebenen Baselines und früheren Prüfnachweisen. Ein Screenshot von heute zeigt nicht den Zustand vor drei Monaten. Auch ein fehlender Eintrag beweist nicht von selbst das Datum einer Deaktivierung. Die Zuverlässigkeit jedes Hinweises wird bewertet. Ein Zeitfenster kann zunächst als „spätestens seit“ oder „nicht sicher vor“ beschrieben werden, wenn eine genaue Grenze nicht belegbar ist.

Erfassen Sie betroffene Projekte, Geräte, Mandanten oder Datenklassen. Prüfen Sie, ob das gleiche Konfigurationsmuster in weiteren Systemen verwendet wurde. Ein einzelner Befund kann auf eine breitere Ursache hinweisen, ohne dass automatisch alle Systeme betroffen sind. Verwenden Sie Kriterien für die Ausweitung und Begrenzung. Die historische Bewertung sollte erkennen lassen, warum ein bestimmter Bereich einbezogen und ein anderer ausgeschlossen wurde. Eine bequeme feste Rückschaufrist ersetzt diese Begründung nicht.

Daten- und Produktfolgen getrennt von der Konfiguration bewerten

Prüfen Sie, welche Entscheidungen auf den potenziell betroffenen Daten beruhen. Dazu können Prüfberichte, Materialentscheidungen und bereits freigegebene Chargen gehören. Erfassen Sie, welche Unsicherheit die fehlende Historie erzeugt und welche unabhängigen Informationen die Bewertung unterstützen. Andere Aufzeichnungen können hilfreich sein, ersetzen den fehlenden Audit Trail aber nur insoweit, wie sie die konkrete erforderliche Aussage tatsächlich tragen. Eine reine Plausibilitätsannahme schließt die Lücke nicht.

Die zuständigen Qualitäts- und gegebenenfalls Produktverantwortlichen entscheiden über erforderliche weitere Maßnahmen. Untersuchungen, Einschränkungen, erneute Prüfungen oder regulatorische Kommunikation werden nach den einschlägigen Verfahren bewertet. Dieser allgemeine Leitfaden legt keine universelle Meldefrist und keine automatische Rückrufentscheidung fest. Ebenso darf eine erneute Analyse nicht stillschweigend eine ungeklärte historische Datenlage ersetzen. Die ursprüngliche Aufzeichnung und die spätere Bewertung bleiben unterscheidbar.

Quellen: [3]

Konstruiertes Beispiel: drei Wochen mit unklarer Historie

Im eigenen Übungsfall zeigt der heutige Konfigurationsstand eine deaktivierte Datenhistorie. Ein freigegebener Test von vor drei Wochen belegt die damals aktive Funktion. Zwischen beiden Zeitpunkten wurden mehrere Analysefolgen ausgeführt. Ein Upgrade liegt innerhalb dieses Zeitfensters, beweist jedoch noch nicht allein die Ursache. Das Team erstellt zunächst eine Liste der betroffenen Daten und Entscheidungen und prüft vorhandene Änderungs- und Betriebsnachweise.

Der Maßnahmenplan trennt Sofortkontrolle, Untersuchung und dauerhafte Verbesserung. Er führt offene Fragen weiter, statt sie durch eine heutige Aktivierung zu schließen. Die folgende Arbeitshilfe ist ein eigener Vorschlag. Sie bestimmt keine allgemeine Behördenreaktion und verlangt nicht, dass jeder Fall dieselbe technische Forensik benötigt. Entscheidend ist eine risikogerechte, nachvollziehbare Bearbeitung mit klarer Verantwortung für die fachlichen Folgen.

Warum Wiederaktivieren allein nicht genügt

Im Warning Letter an ABC Testing vom 4. Juni 2019 beschrieb die FDA unter anderem deaktivierte Audit Trails und unzureichende Zugriffskontrollen. Die angekündigte Aktivierung und Einrichtung von Konten reichte als Antwort nicht aus; Zwischenkontrollen und Verfahren zur Kontrolle und Prüfung der analytischen Daten fehlten. Dieser historische Einzelfall ist keine verbindliche Mustervorlage für jeden Betrieb. Er veranschaulicht jedoch die Trennung zwischen technischer Korrektur und tragfähiger Gesamtmaßnahme.

Prüfen Sie bei der Wiederaktivierung, ob die tatsächlich benötigten Ereignisse nun erfasst werden. Eine aktive Einstellung kann weiterhin unzureichende Abdeckung haben. Testen Sie relevante Erstellung, Änderung und gegebenenfalls weitere benötigte Handlungen anhand kontrollierter Daten. Prüfen Sie Zeitpunkt, Akteur, Inhalt und Zusammenhang in dem erforderlichen Umfang. Der Nachweis sollte auch zeigen, dass die im Routinebetrieb vorgesehenen Verantwortlichen die Historie sinnvoll lesen und beurteilen können.

Quellen: [4]

Ursachen und CAPA mit dem Zielprozess verbinden

Untersuchen Sie technische und organisatorische Ursachen gemeinsam. Wurde eine Einstellung beim Upgrade verändert? War die Anforderung unklar? Konnten zu viele Anwender die Funktion ändern? Fehlte ein Nachweis nach einer Systemkopie? Eine Maßnahme „Mitarbeiter schulen“ kann unzureichend sein, wenn ein unkontrollierter technischer Pfad bestehen bleibt. Umgekehrt löst eine technische Sperre nicht automatisch fehlende Zuständigkeiten für Review und Änderungsbewertung.

Verbinden Sie die CAPA mit dem gewünschten künftigen Betrieb. Ein standardisierter Konfigurationsabgleich, passende Rollen und klare Übergaben können ähnliche Fehler vermeiden und zugleich den Alltag entlasten. Priorisieren Sie anhand von Risiko, Abhängigkeiten und strategischem Zielbild. Bearbeiten Sie den konkreten Befund vollständig, ohne das gesamte Projekt auf eine isolierte Behördenformulierung zu reduzieren. Die Wirksamkeit zeigt sich an funktionierenden Kontrollen und verlässlichen Entscheidungen, nicht nur an mehr Dokumenten.

Quellen: [5]

Historische Lücke und künftige Wirksamkeit getrennt abschließen

Der Abschluss muss erkennen lassen, was über die Vergangenheit tatsächlich belegbar ist. Welche Daten konnten bewertet werden? Welche Einschränkungen verbleiben? Welche Entscheidungen wurden getroffen und von wem? Eine heute bestandene Funktionsprüfung kann die künftige Kontrolle bestätigen, rekonstruiert aber keine nie aufgezeichneten historischen Ereignisse. Erzeugen Sie keine künstlichen rückdatierten Audit-Trail-Einträge, um eine scheinbar vollständige Historie herzustellen.

Für den künftigen Betrieb werden Zustandskontrolle, Änderungsbewertung, Review und Eskalation festgelegt. Prüfen Sie geeignete Anlässe wie Upgrade, Migration oder Systemkopie. Die Häufigkeit laufender Kontrollen wird passend zum Risiko begründet. Falls die Ursache mehrere Systeme betrifft, wird die Wirksamkeit auch im entsprechenden Umfang bewertet. So bleiben historische Untersuchung und nachhaltige Prävention verbunden, ohne ihre unterschiedlichen Nachweisziele zu vermischen.