Audit Trail: Wie Änderungen und Eingriffe nachvollziehbar bleiben

Was ein Audit Trail bedeutet

Die MHRA ordnet dem Audit Trail die rekonstruierbare Geschichte elektronischer Aufzeichnungen zu. Frühere Informationen dürfen durch eine Änderung nicht verdeckt oder überschrieben werden.^[1]

Der Audit Trail ist damit nicht einfach eine lange Liste technischer Meldungen. Sein Zweck besteht darin, die Geschichte einer prüfungsrelevanten Aufzeichnung verständlich zu erhalten. Eine prüfende Person muss erkennen können, welcher Wert ursprünglich vorlag, welcher neue Wert eingetragen wurde, welche Identität die Handlung ausgeführt hat und wie die Änderung in den fachlichen Vorgang einzuordnen ist. Diese Rekonstruktion ist ein wichtiger Baustein der Datenintegrität.

MHRA und FDA beziehen den Begriff sowohl auf die Erzeugung als auch auf Änderungen und Löschungen elektronischer Aufzeichnungen. PIC/S konkretisiert unter anderem Identität, Handlung, alte und neue Werte, Zeitpunkt, Änderungsgrund und – sofern anwendbar – die autorisierende Person.^[2][3]

42,6 wird zu 24,6: Was muss das Review klären?

Das folgende fiktive Beispiel betrifft eine Temperaturaufzeichnung. Eingetragen wurden 42,6 °C, später korrigiert auf 24,6 °C. Als Grund steht lediglich „Tippfehler“. Beide Werte sind sichtbar. Damit ist eine Änderung erkennbar, aber noch nicht ausreichend erklärt.

Die prüfende Person benötigt den Bezug zur konkreten Messung und den zugrunde liegenden Gerätebeleg. Bestätigt dieser 24,6 °C, kann er die Erklärung eines Übertragungsfehlers stützen. Zu prüfen bleiben die Identität und Befugnis der korrigierenden Person, die zeitliche Reihenfolge und die Verwendung des alten Werts.

Hat 42,6 °C bereits eine Folgeentscheidung ausgelöst, ist diese gesondert zu bewerten. Ein richtiger neuer Wert erledigt nicht automatisch die Wirkung der früheren Aufzeichnung. Fehlt der Gerätebeleg, muss die verbleibende Unsicherheit sichtbar bleiben; die bloße Korrekturbegründung ersetzt ihn nicht.

Das Review hält fest, welche Unterlagen geprüft wurden, ob die Korrektur nachvollziehbar ist und welche Folgeprüfung offen bleibt. So entstehen drei unterscheidbare Aussagen: Die Änderung fand statt; ihre Begründung wurde bewertet; ihre möglichen Auswirkungen wurden bearbeitet oder ausdrücklich offengehalten.

Erfassung allein genügt nicht: Audit Trails müssen geprüft werden

Ein Audit Trail kann vollständig vorhanden und dennoch praktisch wirkungslos sein. Wenn niemand relevante Einträge prüft, unverständliche Codes angezeigt werden oder kritische Änderungen in einer unstrukturierten Liste verborgen bleiben, entsteht keine wirksame Kontrolle.

Die Prüfung sollte an den zugehörigen Datensatz und den fachlichen Prozess gekoppelt sein. Bei kritischen Aufzeichnungen kann sie vor Abschluss, Freigabe oder Chargenentscheidung erforderlich sein. Für weniger kritische Vorgänge kann eine vorab festgelegte periodische Prüfung angemessen sein. PIC/S unterscheidet entsprechend zwischen kritischen Audit Trails, die mit der Aufzeichnung vor Abschluss oder Freigabe geprüft werden, und nicht kritischen Audit Trails mit definierter Prüffrequenz.^[2]

Die FDA ordnet die Verantwortung grundsätzlich den Personen zu, die auch die jeweilige Aufzeichnung prüfen. Ist keine konkrete Prüffrequenz vorgeschrieben, soll sie risikobasiert aus Datenkritikalität, Kontrollmechanismen und möglicher Auswirkung auf die Produktqualität abgeleitet werden.^[3]

Eine Audit-Trail-Prüfung sollte deshalb mindestens beantworten:

• Gab es relevante Änderungen, Löschungen oder wiederholte Eingaben?
• Sind alter und neuer Zustand sowie der Änderungsgrund verständlich?
• War die handelnde Person für die Aktion berechtigt?
• Passt die zeitliche Reihenfolge zum tatsächlichen Prozess?
• Wurde eine erforderliche Prüfung oder Genehmigung durchgeführt?
• Deuten Muster auf ein systematisches Problem hin?

Auch das Ergebnis der Prüfung braucht eine dokumentierte Identität, ein Datum und eine nachvollziehbare Entscheidung. Sonst ist später zwar die Änderung sichtbar, nicht aber ihre fachliche Bewertung. Bei der Auswahl von Compliance-Software lässt sich diese Prüfbarkeit vorführen: vom Änderungseintrag über seinen Beleg bis zur dokumentierten Bewertung und noch offenen Folgeprüfung.

Welche Angaben für die Rekonstruktion benötigt werden

Ein brauchbarer Audit-Trail-Eintrag muss mehr enthalten als einen Zeitstempel und den Hinweis „geändert“. Welche Angaben erforderlich sind, hängt vom Datentyp, Prozessrisiko und Regelungsrahmen ab. Für eine relevante Datenänderung gehören typischerweise folgende Elemente zusammen:

• Identität: die eindeutig zuordenbare Person oder technische Instanz, die eine Handlung ausführte,
• Handlung: Anlegen, Erfassen, Ändern, Bestätigen, Löschen, Freigeben oder eine andere relevante Aktion,
• betroffenes Objekt: beispielsweise Messwert, Prüfentscheidung, Dokument, Materialbuchung oder Chargenzustand,
• alter und neuer Inhalt: soweit eine Änderung vorgenommen wurde,
• Zeitpunkt: Datum und Uhrzeit in einer nachvollziehbaren Zeitbasis,
• Grund: eine fachlich verständliche Begründung, wenn der Vorgang eine solche erfordert,
• Autorisierung: die prüfende oder genehmigende Identität, wenn ein kontrollierter Prozess dies vorsieht.

Diese Angaben dürfen nicht losgelöst voneinander vorliegen. Ein alter und ein neuer Wert ohne Bezug zum betroffenen Messpunkt bleibt mehrdeutig. Eine Benutzerkennung ohne Rollen- und Berechtigungskontext sagt wenig darüber aus, ob die Handlung zulässig war. Ein Änderungsgrund wie „Korrektur“ ist zwar formal vorhanden, erklärt aber nicht, welcher Fehler behoben wurde.

Das System muss deshalb nicht nur einzelne Felder speichern, sondern ihre Beziehung erhalten: zur Aufzeichnung, zur Aufgabe, zur Charge, zur verwendeten Vorgabe, zur verantwortlichen Rolle und gegebenenfalls zu einer Prüfung oder Freigabe. Erst dieser Zusammenhang macht aus protokollierten Daten eine verständliche Historie.

Das Original darf durch die Korrektur nicht verschwinden

Fehlerhafte Eingaben müssen korrigierbar bleiben. Eine kontrollierte Korrektur ist kein Widerspruch zur Integrität einer Aufzeichnung. Problematisch wird sie, wenn der ursprüngliche Zustand nicht mehr erkennbar ist, eine Änderung ohne Identität erfolgt oder eine Person die Historie nachträglich bereinigen kann.

Die zentrale Anforderung lautet daher nicht „Daten dürfen niemals verändert werden“, sondern: Relevante Veränderungen müssen nachvollziehbar erfolgen, während die vorherige Information erhalten bleibt. Die FDA formuliert für geschlossene Systeme, dass Änderungen zuvor aufgezeichnete Informationen nicht verdecken dürfen; die Aufbewahrungsdauer des Audit Trails ist an die zugehörigen elektronischen Aufzeichnungen gebunden.^[5]

In der Praxis kann das bedeuten, dass ein Messwert nicht direkt überschrieben wird. Stattdessen entsteht eine neue Version oder ein Korrekturvorgang, der den alten Wert, den neuen Wert, den Grund, die ausführende Person und eine erforderliche Prüfung verbindet. Die aktuelle Anzeige darf den freigegebenen Wert hervorheben. Sie muss dennoch einen nachvollziehbaren Weg zur vorherigen Aufzeichnung bieten.

Dieses Prinzip findet sich auch in ALCOA+ wieder: Aufzeichnungen sollen unter anderem zuordenbar, zeitnah, originalgetreu, genau, vollständig, konsistent, dauerhaft und verfügbar sein. Ein Audit Trail unterstützt mehrere dieser Eigenschaften. Er ersetzt die übrigen Kontrollen jedoch nicht.

Identität und Berechtigungen gehören zusammen

Die Angabe „wer“ setzt eine eindeutige Identität voraus. Gemeinsam genutzte Konten, weitergegebene Zugangsdaten oder nachträglich nicht mehr zuordenbare Systemkennungen schwächen die Aussagekraft eines Audit Trails. Das gilt auch dann, wenn alle Änderungen technisch vollständig protokolliert wurden.

Rollen und Berechtigungen bestimmen, wer Daten erfassen, korrigieren, prüfen, freigeben oder administrieren darf. Normale Anwender sollten Audit-Trail-Funktionen weder abschalten noch vorhandene Einträge verändern oder löschen können. Änderungen durch Administratoren müssen ihrerseits erfasst werden. MHRA und PIC/S betonen diese Trennung ausdrücklich.^[1][2]

Dabei genügt es nicht, nur einen besonders mächtigen Administrator zu schützen. Auch die Vergabe, Änderung und Aufhebung von Berechtigungen ist selbst eine relevante Handlung. Annex 11 verlangt, dass die Erteilung, Änderung und Löschung von Zugriffsberechtigungen aufgezeichnet wird. Außerdem soll das System die Identität von Personen erfassen, die Daten eingeben, ändern, bestätigen oder löschen, einschließlich Datum und Uhrzeit.^[4]

Eine eindeutige Benutzerkennung beweist dennoch nicht, dass tatsächlich die richtige Person gehandelt hat oder die Entscheidung fachlich korrekt war. Authentisierung, organisatorische Verantwortlichkeit, Schulung, Rollenmodell und fachliche Prüfung müssen zusammenwirken.

Zeit, Reihenfolge und Granularität müssen zum Vorgang passen

Eine Änderungsgeschichte ist nur dann belastbar, wenn ihre zeitliche Ordnung verlässlich ist. Datum und Uhrzeit sollten automatisch erzeugt werden und dürfen nicht beliebig durch normale Benutzer veränderbar sein. Bei verteilten Systemen muss außerdem klar sein, auf welche Zeitzone oder gemeinsame Zeitbasis sich die Einträge beziehen.

PIC/S fordert eine zeitgerechte Aufzeichnung und eine Granularität, mit der relevante Ereignisse unterschieden werden können.^[2] Ein täglicher Sammelvermerk genügt beispielsweise nicht, wenn mehrere Änderungen an einem kritischen Prüfwert in ihrer tatsächlichen Reihenfolge beurteilt werden müssen.

Umgekehrt erzeugt eine extrem feine technische Protokollierung nicht automatisch mehr fachlichen Nutzen. Wenn jeder Mauszeiger, jeder Bildschirmaufruf und jede interne Datenbankoperation gleichrangig erscheint, können die relevanten Handlungen in einer Masse bedeutungsloser Einträge verschwinden. Die Granularität muss deshalb den prüfungsrelevanten Vorgang abbilden.

Bei einem Chargenprozess kann es ausreichen, Beginn und Abschluss einer geführten Aufgabe, eingegebene Ergebnisse, Korrekturen, Prüfentscheidungen und Freigaben getrennt festzuhalten. Innerhalb einer automatisierten Messung können dagegen Kalibrierstatus, Rohdatenbezug, Berechnungsschritte und nachträgliche Parameteränderungen relevant sein.

Eine prüfbare Historie braucht eine verständliche Darstellung

Audit-Trail-Daten werden häufig in Tabellen gespeichert, deren technische Feldnamen für Fachanwender schwer verständlich sind. Eine wirksame Darstellung übersetzt diese Struktur in den betrieblichen Zusammenhang: betroffene Charge, Aufgabe, Datensatz, alter und neuer Wert, handelnde Rolle, Zeitpunkt, Grund und Status der Prüfung.

PIC/S verlangt eine aussagekräftige Form und die Möglichkeit, Audit Trails als Ausdruck oder elektronische Kopie bereitzustellen. Such- und Exportfunktionen sollen möglichst erhalten bleiben.^[2] Annex 11 verlangt zudem eine allgemein verständliche Form und eine regelmäßige Prüfung relevanter Protokolle.^[4]

Eine reine PDF-Ausgabe kann für eine konkrete Prüfung genügen, verliert aber möglicherweise Filter, Beziehungen oder dynamische Metadaten. Ein Export ist daher nur dann eine geeignete Kopie, wenn Inhalt, Bedeutung und erforderlicher Kontext erhalten bleiben.

Ausnahmeberichte können große Datenmengen beherrschbar machen. Sie dürfen jedoch nicht als undurchsichtiger Filter wirken. Die Regeln, nach denen Einträge hervorgehoben oder ausgeblendet werden, müssen validiert, dokumentiert und dem Risiko angemessen sein. Eine prüfende Person benötigt außerdem einen Weg zu den vollständigen zugrunde liegenden Daten.

Audit Trail, Systemprotokoll und Prozesshistorie sind nicht dasselbe

In digitalen Systemen entstehen verschiedene Arten von Historien. Ihre Begriffe werden häufig vermischt, obwohl sie unterschiedliche Fragen beantworten.

• Audit Trail: Welche relevante Aufzeichnung wurde durch wen, wann, wie und aus welchem Grund erzeugt oder verändert?
• Systemprotokoll: Welche technischen oder sicherheitsbezogenen Vorgänge fanden im System statt, etwa Anmeldung, Dienststart, Fehler oder Konfigurationswechsel?
• Prozesshistorie: Welche fachlichen Aufgaben, Zustände, Prüfungen und Entscheidungen bildeten den tatsächlichen Ablauf?
• Ereignislog: Welche strukturierten Ereignisdaten stehen für eine Prozessanalyse zur Verfügung?
• Change Control: Wie wird eine geplante Änderung an System, Prozess oder Konfiguration bewertet, genehmigt und umgesetzt?

Zwischen diesen Perspektiven bestehen Überschneidungen. Eine Freigabe kann Teil der Prozesshistorie, ein Audit-Trail-Eintrag und ein Ereignis für spätere Analysen sein. Trotzdem bleiben Zweck, erforderliche Angaben und Aufbewahrungslogik verschieden.

Ein Audit Trail dokumentiert Änderungen an Aufzeichnungen; er ersetzt kein Verfahren zur kontrollierten Änderung eines Systems. Annex 11 unterscheidet diese Aufgaben: Nr. 9 behandelt Audit Trails, Nr. 10 verlangt für Änderungen an computergestützten Systemen einschließlich ihrer Konfiguration ein kontrolliertes Vorgehen nach einem festgelegten Verfahren.^[4] Ebenso sollte ein technisches Systemlog nicht ungeprüft als fachlicher Audit Trail ausgegeben werden. Eine erfolgreiche Anmeldung erklärt beispielsweise noch nicht, welcher Messwert anschließend geändert wurde.

Eine Ereignishistorie braucht zusätzliche Reviewinformationen

Event Sourcing kann einen aktuellen Zustand aus gespeicherten Ereignissen bilden. Ob diese Ereignisse auch einen geeigneten Audit Trail ergeben, hängt von ihrem Inhalt und der Ausgestaltung ab: Sind alte und neue Informationen, Identität, erforderliche Gründe und der Prüfbezug verfügbar?

Eine Rekonstruktion des heutigen Zahlenwerts beantwortet noch nicht, warum eine Korrektur zulässig war. Data Provenance kann ergänzende Entstehungsbeziehungen liefern. Für das Review müssen diese und die Änderungsaufzeichnungen in einem verständlichen Zusammenhang zugänglich sein.

Aufsichtsbefund

Befund: Die FDA beanstandete Änderungen an elektronischen Chargenaufzeichnungen, die ein Mitarbeiter der Qualitätssicherung beim Softwareanbieter beauftragt hatte. Dabei wurde unter anderem eine Mitarbeiterkennung ausgetauscht. Diese Änderung wurde weder im Audit Trail erfasst noch im Chargenprotokoll vermerkt.^[6]

Einordnung: Auch beauftragte Korrekturen müssen nachvollziehbar bleiben. Die Änderungshistorie muss Eingriffe durch Anbieter und Support einschließen – unabhängig davon, wer sie veranlasst.

Prüffrage: Können Anbieter oder Support Daten ändern, ohne dass der Audit Trail es zeigt?

Schreiben vom 30.03.2026 · Quelle geprüft am 18.09.2026.

Dargestellt ist der ausgewählte Behördenbefund zum Zeitpunkt des Schreibens. Unternehmensantworten und spätere Entwicklungen werden hier nicht bewertet; die Darstellung beschreibt keinen aktuellen Compliance-Status.

Eine sichtbare Korrektur ist der Beginn der Prüfung

Der Wechsel von 42,6 auf 24,6 lässt sich technisch lückenlos darstellen und trotzdem fachlich ungeklärt bleiben. Erst der Belegbezug und das dokumentierte Review zeigen, wie die Änderung bewertet wurde.

Ein brauchbarer Audit Trail führt deshalb von der aktuellen Aufzeichnung zu ihrer Vorgeschichte und zu offenen Fragen. Er unterstützt die Prüfung; er darf deren Ergebnis nicht durch die bloße Vollständigkeit einer Protokollliste vorwegnehmen.

Ein Audit Trail erzeugt keine automatische Compliance. Anforderungen und Prüfintervalle ergeben sich aus Einsatz, Risiko und anwendbarem Regelungsrahmen.

Für automatisierte Compliance-Nachweise müssen die erforderlichen Informationen bereits während der Arbeit so zusammengeführt werden, dass sie eine prüfbare Aussage über den konkreten Vorgang tragen.