Entwicklung & DeliveryAus der Praxis
Revisionssicheres Logging: Warum Datenbank-Logs im Audit nicht zählen
3 Min. Lesezeit
Der Satz fällt fast immer im selben Tonfall, halb erstaunt, halb genervt: „Wir loggen doch alles." Das stimmt in aller Regel auch. Es gibt eine Tabelle, sie heißt audit_log oder history, sie wird bei jeder Änderung befüllt, und sie ist beeindruckend groß.
Und trotzdem endet das Gespräch mit dem Prüfer damit, dass dieses Log nicht als Nachweis akzeptiert wird.
Der Unterschied, um den es geht
Ein Log ist eine Aufzeichnung. Ein Nachweis ist eine Aufzeichnung, an der niemand unbemerkt etwas ändern kann.
Das klingt nach einer Feinheit und ist der ganze Punkt. Eine Log-Tabelle in derselben Datenbank, in die auch die Anwendung schreibt, ist mit denselben Rechten erreichbar wie die Fachdaten. Wer den Datensatz ändern kann, kann in aller Regel auch den Eintrag ändern, der die Änderung beschreibt. Ein Prüfer muss davon ausgehen, dass genau das möglich ist — nicht, weil er Ihrem Team misstraut, sondern weil seine eigene Prüfung sonst wertlos wäre.
Vier Eigenschaften, die den Unterschied machen
Unveränderlichkeit. Einträge werden angehängt, nie überschrieben und nie gelöscht. Kein UPDATE, kein DELETE — auch nicht für Administratoren, auch nicht „nur diesmal, wegen der Migration".
Vollständigkeit. Jede fachlich relevante Änderung erzeugt einen Eintrag, und zwar in derselben Transaktion wie die Änderung selbst. Ein Log, das bei einem Fehler ausfallen kann, hat Lücken genau an den interessanten Stellen.
Fachlichkeit. Der Eintrag beschreibt, was geschäftlich passiert ist, nicht welche Spalte technisch beschrieben wurde. „Kreditlimit auf 50.000 erhöht, freigegeben durch die Vertriebsleitung, Grundlage Jahresvereinbarung" ist ein Nachweis. „UPDATE customer SET limit=50000" ist ein Beleg dafür, dass etwas passiert ist, nicht dafür, warum.
Zurechenbarkeit. Zu jedem Eintrag gehört eine Identität, die zum Zeitpunkt der Aktion galt — nicht der Nutzer, der heute hinter der ID steht, und schon gar nicht ein technischer Sammelaccount.
Der Test, den man selbst durchführen kann
Nehmen Sie einen beliebigen Vorgang aus dem letzten Quartal und beantworten Sie drei Fragen, ohne einen Entwickler zu fragen:
- Wer hat ihn zuletzt geändert und aufgrund welcher Freigabe?
- Wie sah er an einem bestimmten Tag davor aus?
- Könnte jemand diese beiden Antworten manipulieren, ohne dass es auffiele?
Bleibt eine Frage offen, existiert kein Nachweis, sondern eine Aufzeichnung. Der Nachweisfähigkeits-Check stellt diese Fragen systematisch für zehn typische Prüfsituationen.
Warum das gerade jetzt hochkommt
Zwei Entwicklungen treffen aufeinander. Die Nachweispflichten werden konkreter: NIS2 verlangt nicht nur Maßnahmen, sondern deren Wirksamkeit, und die Meldefristen lassen keine Zeit für forensische Handarbeit. Gleichzeitig entsteht Software schneller und mit weniger Übergaben, wodurch weniger Dokumentation als Nebenprodukt anfällt — ein Punkt, den auch die Konsolidierung der Engineering-Rollen sichtbar macht.
Beides zeigt in dieselbe Richtung: Was nicht das System selbst festhält, wird niemand später rekonstruieren.
Wie man es nachrüstet, ohne alles umzubauen
Die teure Variante ist der Generalumbau. Die tragfähige beginnt mit einer Auswahl: Es gibt in fast jedem Unternehmen ein bis drei Prozesse, bei denen die Frage nach der Historie tatsächlich gestellt wird — Freigaben, Preise, Berechtigungen, Zahlungen. Diese bekommen eine unveränderliche, fachlich formulierte Historie. Der Rest bleibt, wie er ist.
Technisch führt der direkte Weg über eine Append-only-Ablage, deren Schreibpfad von der Anwendung getrennt ist, und über Ereignisse, die fachlich benannt sind. Das ist der Punkt, an dem Event Sourcing ins Spiel kommt — nicht als Architekturmode, sondern weil es genau diese Form von Historie zum Normalfall macht. Es ist nicht der einzige Weg, und wir sagen auch, wann er zu groß ist.
Was Sie am Ende in der Hand haben
Nicht mehr Logs. Sondern die Fähigkeit, eine unangenehme Frage in Minuten statt in Personentagen zu beantworten — und zwar so, dass die Antwort auch dann noch trägt, wenn jemand sie anzweifelt. Wie das in der Praxis aussieht, zeigt das Beispiel „Wer hat was zugesagt?", in dem genau diese Lücke ein halbes Jahr Aufwand erzeugt hat.
← Zurück zu den InsightsBeiträge zu diesem Thema
Entwicklung & DeliveryNotiz
Logging als Ballast — wo ist die Wahrheit?
AI nimmt uns die Last der menschlichen Unschärfe. Warum stellen wir unseren Kernprozessen dann eine zweite Unschärfe in Form eines Logs daneben?
Entwicklung & DeliveryFundament
Mandantentrennung, die den Security-Fragebogen übersteht
Ein vergessener Filter ist ein meldepflichtiger Vorfall. Warum Isolation im Anwendungscode kein Nachweis ist — und welche Modelle Enterprise-Kunden akzeptieren.
Entwicklung & DeliveryAus der Praxis
Production Readiness in der AI Factory: Was man prüft, wenn Agenten den Code schreiben
Requirements sind agentenlesbar, das arc42 gepflegt, die Pipeline grün. Die alte Frage „läuft es?" ist trivial geworden. Die neue lautet: Woran erkennen wir, dass eine Änderung stimmt, wenn niemand mehr jede Zeile gelesen hat?