Was ist ein Audit-Trail?
Ein Audit-Trail ist eine Aufzeichnung, mit der sich gegenüber Dritten belegen lässt, wie ein Datensatz, eine Entscheidung oder eine Konfiguration zu ihrem heutigen Stand gekommen ist. Technische Logdateien dienen vor allem Betrieb und Angriffserkennung; ein Audit-Trail dient dem Nachweis. Dieselbe Protokollierung kann beides speisen; für den Nachweis zählen zusätzlich Vollständigkeit, Schutz vor Veränderung und Aufbewahrung.
Welche Ereignisse ein System technisch protokolliert und wie sie ausgewertet werden, beschreibt der Eintrag Protokollierung und Monitoring. Wie Protokollierung und Nachweisführung in ein Managementsystem eingebettet werden, beschreibt der Leitfaden ISMS einführen.
Welche Angaben braucht ein Eintrag?
Ein Eintrag ist ohne Rückfrage lesbar, wenn er diese Angaben enthält:
| Feld | Inhalt | Warum es zählt |
|---|---|---|
| Wer | eindeutige Benutzer- oder Systemkennung | hinter einem Sammelkonto steht keine zuordenbare Person |
| Was | Aktion: anlegen, ändern, löschen, freigeben, bei sensiblen Daten auch einsehen | ohne Aktion keine Aussage |
| Woran | betroffenes Objekt mit eindeutiger Kennung | der Eintrag muss dem Datensatz zuordenbar sein |
| Wann | Zeitstempel aus einer synchronisierten Zeitquelle | Reihenfolge und Fristen lassen sich sonst nicht belegen |
| Vorher und nachher | alter und neuer Wert | ohne den alten Wert ist der ursprüngliche Inhalt nicht feststellbar |
| Warum | Begründung, wo das Verfahren sie verlangt | bei kritischen Änderungen fragen Prüfer nach dem Anlass |
| Kontext | System, Quelle, Ergebnis der Aktion | auch fehlgeschlagene Versuche sind relevant |
Beispiel (fiktiv): „14.10.2026 09:42:17 MESZ, Benutzer m.keller, Kreditorenstamm 70412, Feld IBAN geändert von „…2051“ auf „…3000“, Grund: Ticket 4711 mit Rückrufvermerk, Ergebnis: gespeichert.“ Name, Kennungen und Werte sind frei gewählt und dienen ausschließlich der Veranschaulichung.
Welche Vorschriften verlangen einen Audit-Trail?
Mehrere Regelwerke verlangen in der Sache einen Audit-Trail, auch wenn nicht alle den Begriff verwenden:
| Quelle | Gilt für | Kernaussage in eigenen Worten |
|---|---|---|
| ISO/IEC 27001:2022 Anhang A 8.15 | Organisationen mit ISMS nach ISO/IEC 27001 | Protokollierung; Anhang A 8.17 ergänzt die Uhrensynchronisation |
| Art. 12 Delegierte Verordnung (EU) 2024/1774 | Finanzunternehmen im regulären IKT-Risikomanagementrahmen nach DORA | Verfahren zur Datenaufzeichnung mit aufzuzeichnenden Ereignissen, Speicherfrist, Schutz vor Manipulation, Löschung und unbefugtem Zugriff, Erkennung von Ausfällen und synchronisierten Uhren |
| § 146 Abs. 4 AO, § 239 Abs. 3 HGB | Buchführungs- und Aufzeichnungspflichtige | ursprünglicher Inhalt muss feststellbar bleiben; erkennbar sein muss auch, ob eine Änderung ursprünglich oder später gemacht wurde |
| 21 CFR Part 11, § 11.10(e) (USA) | Unternehmen, die elektronische Aufzeichnungen nach FDA-Vorschriften führen | sichere, rechnergenerierte Audit-Trails mit Zeitstempel, aufbewahrt mindestens so lange wie die Aufzeichnungen selbst |
Die DSGVO kennt keinen Audit-Trail dieses Namens. Ein Audit-Trail enthält aber personenbezogene Daten, sobald er Handlungen einer Person zuordnet; legen Sie deshalb Zweck, Zugriff und Löschung ebenso fest wie die Erfassung.
Was verlangt DORA zur Protokollierung?
DORA regelt die Protokollierung in Art. 12 der Delegierten Verordnung (EU) 2024/1774. Nach Abs. 2 Buchst. c zeichnen Finanzunternehmen Ereignisse zu logischer und physischer Zugangskontrolle und Identitätsmanagement, Kapazitätsmanagement, Änderungsmanagement, IKT-Vorgängen und Netzwerkverkehr auf. Die Speicherfrist legt das Finanzunternehmen selbst fest; es berücksichtigt dabei Geschäfts- und Sicherheitsziele, den Grund der Aufzeichnung und das Ergebnis der IKT-Risikobewertung.
Wie die technischen Standards zu DORA aufgebaut sind, beschreibt der Beitrag DORA RTS: was die technischen Standards verlangen.
Was verlangen AO und HGB?
Nach § 146 Abs. 4 AO und § 239 Abs. 3 HGB darf eine Buchung oder Aufzeichnung nicht so verändert werden, dass der ursprüngliche Inhalt nicht mehr feststellbar ist. Unzulässig sind auch Veränderungen, bei denen ungewiss bleibt, ob sie ursprünglich oder erst später gemacht worden sind. In einem IT-System belegt beides ein Audit-Trail, der den alten Wert und einen verlässlichen Zeitstempel festhält.
Wie das für IT-gestützte Buchführung umzusetzen ist, konkretisieren die GoBD (BMF-Schreiben vom 28. November 2019, geändert am 11. März 2024 und am 14. Juli 2025).
Technischer Prüfpfad und Prüfpfad des Managementsystems
Ein ISMS-Audit sieht sich zwei Ebenen an. Der technische Audit-Trail liegt in Betriebssystemen, Datenbanken und Fachanwendungen: privilegierte Zugriffe, Konfigurationsänderungen, Rechtevergaben. Er lässt sich in einem SIEM zusammenführen.
Der Prüfpfad des Managementsystems zeigt, wer eine Anforderung wann bewertet hat, mit welchem Nachweis, wer ein Restrisiko akzeptiert hat und wann die Leitung informiert war. Wird er in Tabellen und E-Mails geführt, lässt er sich für einen vergangenen Prüfzeitraum nur mühsam rekonstruieren.
Den Audit-Trail testen: drei Stichproben
Ein Audit-Trail hat Beweiskraft, wenn er auch die Wege abdeckt, auf denen Daten am Protokoll vorbei geändert werden können. Prüfen Sie in einer Testumgebung oder mit einem Testdatensatz:
| Stichprobe | Aktion | Erwartetes Ergebnis | Nachweis |
|---|---|---|---|
| normale Änderung | Testbenutzer ändert ein Feld eines Testdatensatzes | Eintrag mit Kennung, altem und neuem Wert und einem Zeitstempel, der zur Referenzzeit passt | Auszug des Eintrags und Zeitvergleich |
| privilegierte Änderung | Administrator versucht, die Protokollierung abzuschalten oder einen Eintrag zu löschen | die Aktion wird verweigert oder selbst protokolliert und löst eine Meldung an eine zweite Person aus | Berechtigungskonzept, Meldung, Protokolleintrag |
| Export und Reimport | Daten werden exportiert, außerhalb geändert und wieder eingespielt | der Reimport erscheint mit Benutzer, Zeitpunkt und den geänderten Werten | Eintrag zum Reimport mit Feldwerten |
Prüfen Sie außerdem drei Bedingungen: Hinter keinem schreibenden Konto steht eine Gruppe statt einer Person. Stammdaten werden historisiert, nicht überschrieben, sodass ältere Belege ihren ursprünglichen Inhalt behalten. Für die Durchsicht des Audit-Trails gibt es einen festen Turnus und eine verantwortliche Person. Wie Änderungen freigegeben werden, bevor sie im Audit-Trail landen, beschreibt der Eintrag Change-Management.
Der Prüfpfad der Anforderungen in Rizzqo
Rizzqo bildet den Teil des Prüfpfads ab, der Anforderungen betrifft: wer sie wann beantwortet und finalisiert hat. Anforderungen erscheinen über Kategorie und Unterkategorie an den unterstützenden Assets; so erscheint die Protokollierungsanforderung aus dem Katalog ISO/IEC 27002 an den Systemen, für die sie gilt. Ein zugewiesener Eigentümer beantwortet sie, kann einen Nachweis anhängen und finalisiert die Antwort mit Name und Zeitstempel.
Die Abdeckung rechnet Rizzqo aus den finalisierten Antworten; eine als „nicht erfüllt“ finalisierte Antwort ist eine Lücke. Tägliche Momentaufnahmen halten die Abdeckung fest, sodass sich ihr Verlauf über einen Prüfzeitraum zeigen lässt. Maßnahmen laufen als Aufgaben mit geplanter Risikominderung, die sich in beide Richtungen mit Jira synchronisieren.