Revisionssicher — was der Begriff verlangt und woran man ihn prüft

Was heißt revisionssicher?

Revisionssicher ist eine Aufzeichnung, wenn sich nachweisen lässt, dass sie nachträglich nicht verändert wurde — und wenn sie über die ganze Aufbewahrungsfrist vollständig, auffindbar und lesbar bleibt. Der Kern ist der Nachweis, nicht die gute Absicht.

Das Wort kommt von der Revision, also der Prüfung. Revisionssicher ist, was einer Prüfung standhält: Wer prüft, muss eine Lücke von einem Ereignis unterscheiden können, das es nie gab. Kann er das nicht, belegt die Aufzeichnung nichts — egal, wie sorgfältig sie geführt wurde.

Ist „revisionssicher“ ein gesetzlich definierter Begriff?

Nein. Das Wort steht in keinem Gesetz. Es stammt aus der Praxis der elektronischen Archivierung und fasst Anforderungen zusammen, die an anderer Stelle stehen — vor allem die Unveränderbarkeit nach § 239 Abs. 3 HGB und § 146 Abs. 4 AO.

Beide Vorschriften sagen dasselbe: Eine Aufzeichnung darf nicht so verändert werden, dass der ursprüngliche Inhalt nicht mehr feststellbar ist. Die GoBD der Finanzverwaltung führen das für elektronische Systeme aus. Diese Regeln gelten für Bücher und steuerlich relevante Unterlagen — das Protokoll eines IT-Betriebs fällt in der Regel nicht darunter. Der Maßstab taugt trotzdem, weil er die richtige Frage stellt: Ist der ursprüngliche Inhalt noch feststellbar?

Weil der Begriff nicht geschützt ist, darf ihn jeder verwenden. Ein Siegel „revisionssicher“ sagt deshalb für sich genommen nichts. Aussagekräftig ist allein, wie die Unveränderbarkeit hergestellt und geprüft wird.

Reicht es, wenn ein System Einträge einfach nicht ändert?

Nein. „Wir schreiben nur, wir ändern nie“ ist eine Eigenschaft der Anwendung, und die Anwendung ist nicht der einzige Weg zu den Daten. Wer Zugang zur Datenbank hat, ändert eine Zeile an der Anwendung vorbei — und danach sieht das Protokoll aus wie vorher.

Es fehlt also nicht die Sperre, sondern die Erkennbarkeit. Ein Protokoll ohne sie lässt nur die Aussage zu „uns ist nichts aufgefallen“. Revisionssicherheit verlangt die stärkere: „Es wurde nachgerechnet, und es stimmt.“

Wie funktioniert eine Hashkette?

Jeder Eintrag erhält eine lückenlose Folgenummer und einen Hash — eine Prüfsumme über den eigenen Inhalt und den Hash des Vorgängers. Dadurch hängt jeder Eintrag an allen davor. Wer einen ändert, entfernt oder einfügt, bricht die Kette an genau dieser Stelle.

• Ändern: Der Hash passt nicht mehr zum Inhalt.
• Entfernen: Die Folge reißt, und der Nachfolger zeigt auf einen Vorgänger, den es nicht mehr gibt.
• Einfügen: Alle folgenden Einträge müssten neu berechnet werden — dafür braucht es Schreibrechte, die niemand haben sollte.

Üblich ist SHA-256. Das Verfahren ist dasselbe, das Versionsverwaltungen und Blockchains verwenden — nur ohne verteiltes Netz, das es für diesen Zweck nicht braucht.

Warum gehört die Kette in die Datenbank und nicht in die Anwendung?

Weil eine Kette, die die Anwendung berechnet, nur gegen Fehler der Anwendung schützt — nicht gegen jemanden mit direktem Datenbankzugang. Genau das ist aber der Fall, gegen den sie schützen soll. Die Kette muss dort entstehen, wo die Zeile entsteht: in einem Datenbank-Trigger.

Das allein genügt noch nicht. Einen Trigger kann abschalten, wem die Tabelle gehört. Läuft die Anwendung mit einem solchen Zugang, ist die Unveränderbarkeit wieder nur eine Absprache. Deshalb gehört eine Rechtetrennung dazu: Ein Datenbankbenutzer besitzt die Tabellen und wird nur für Aktualisierungen gebraucht. Ein zweiter, mit dem die Anwendung läuft, darf Protokolleinträge schreiben und lesen — nicht ändern, nicht löschen, und die Sperre nicht abschalten.

Ein Detail, das über die Glaubwürdigkeit entscheidet

Erzeugung und Prüfung müssen dieselbe Rechenvorschrift benutzen. Zwei Berechnungen sind zwei Wahrheiten: Irgendwann meldet die Prüfung eine Abweichung, die es nicht gibt, und danach glaubt ihr niemand mehr.

Wovor schützt eine Hashkette nicht?

Sie verhindert nichts, sie macht sichtbar — und auch das nur zwischen zwei Einträgen. Dass die Kette vollständig ist, beweist sie nicht: Wer die letzten zwanzig Einträge entfernt, hinterlässt eine kürzere, in sich gültige Kette. Wer mit Eigentümerrechten die Sperre abschaltet, eine Zeile ändert und ab dort alle Hashes neu rechnet, ebenfalls. Und sie beweist weder die Uhrzeit gegenüber Dritten noch die Echtheit einer eingespielten Sicherung.

• Die Kette braucht einen Anker außerhalb der Datenbank. Jede Prüfung hält fest, bis wohin die Kette reichte und welchen Hash der letzte Eintrag trug — an einem Ort, an den der Datenbankbetreiber nicht schreibt. Die nächste Prüfung sieht nach, ob genau dieser Eintrag noch genau so dasteht. Eine gekürzte Kette hat ihn nicht mehr, eine neu gerechnete trägt an seiner Stelle einen anderen Hash. Wer Datenbank und Anker beherrscht, kann beides anpassen; deshalb entscheidet der Ort des Ankers über seinen Wert.
• Die Zeit ist die Serverzeit. Gegenüber Dritten beweist sie nichts. Dafür braucht es Zeitstempel eines unabhängigen Dienstes nach RFC 3161, im strengsten Fall qualifizierte Zeitstempel nach der eIDAS-Verordnung.
• Die Vergangenheit bleibt offen. Wird eine Kette über einen bestehenden Bestand gelegt, belegt sie nur die Zeit danach. Wer vorher etwas geändert hat, bleibt unentdeckt.
• Sicherungen sind ein Umweg. Wer eine Sicherung manipuliert und einspielt, umgeht alles. Dagegen hilft nur eine Ablage, die Überschreiben verbietet.
• Dateien sind nicht das Protokoll. Ein unterschriebenes PDF im Dateisystem lässt sich überschreiben. Prüfsummen decken das auf — aber nur, wenn sie jemand nachrechnet.

Der letzte Punkt ist der, an dem die meisten Systeme scheitern. Eine Prüfsumme, die gespeichert, aber nie verglichen wird, ist ein Schutz, der eine Handlung voraussetzt, die im Alltag niemand vornimmt. Die Prüfung muss von selbst laufen, und ihr Ergebnis gehört auch dann ins Protokoll, wenn alles stimmt. Sonst lässt sich später nur sagen „es ist nichts aufgefallen“ — nicht „am 3. März war alles in Ordnung“.

Reicht ein geschütztes Protokoll?

Nein. Ein unveränderliches Protokoll neben Fachtabellen, in denen sich alles umschreiben lässt, belegt nur, dass umgeschrieben wurde. Revisionssicher ist ein System erst, wenn auch die Entscheidungen selbst geschützt sind: Abgeschlossenes bleibt zu, eine Genehmigung gilt für den Inhalt, der genehmigt wurde, und die Spur entsteht zusammen mit der Tat.

• Die Spur in derselben Transaktion. Schreibt die Anwendung erst die Entscheidung und danach den Protokolleintrag, gibt es einen Zustand, in dem die Entscheidung da ist und die Spur fehlt — bei jedem Fehler dazwischen. Beides oder nichts.
• Genehmigung bindet an den Inhalt. Lässt sich ein Antrag nach der Freigabe noch ändern, ist die Freigabe wertlos: Genehmigt wurde etwas anderes. Entweder ist der Inhalt ab der Einreichung gesperrt, oder die Stimmen verfallen bei jeder Änderung.
• Abgeschlossenes bleibt zu. Ein geschlossener Vorfall, eine geschlossene Abweichung, ein abgeschlossenes Audit: unveränderlich. Sonst lässt sich die Bewertung nachträglich entschärfen, und die Kennzahl, die darauf aufbaut, lügt.
• Nachweise hängen fest. Wenn das Löschen eines Vorgangs die Genehmigungen, Kommentare und Unterschriften mitnimmt, ist jede Spur nur so stabil wie ihr Elterndatensatz. Die Datenbank muss das Entfernen verweigern, solange Nachweise daran hängen.
• Alt- und Neuwert. „Einstellung geändert" belegt nichts. Wer den Mailserver umgestellt oder eine Verzeichnisgruppe auf Administratorrechte abgebildet hat, muss mit beiden Werten im Protokoll stehen.

Was verlangt ISO 27001 dazu?

Zwei Controls im Annex A: A.8.15 Protokollierung verlangt, dass Protokolle erzeugt, gespeichert, geschützt und ausgewertet werden. A.5.33 Schutz von Aufzeichnungen verlangt den Schutz vor Verlust, Zerstörung, Fälschung, unbefugtem Zugriff und unbefugter Veröffentlichung.

Wie das geschieht, lässt die Norm offen. Die Umsetzungshinweise der ISO/IEC 27002 nennen zu A.8.15 unter anderem kryptografische Hashes und Ablagen, an die nur angehängt werden kann — und sie weisen eigens darauf hin, dass auch privilegierte Benutzer die Protokolle ihrer eigenen Tätigkeit nicht löschen können sollten. Das ist die Rechtetrennung von oben, in der Sprache der Norm.

Muss ein manipulationssicheres Protokoll ewig wachsen?

Zunächst ja. Archivieren ist technisch eine Änderung, Löschen entfernt Zeilen — beides zerreißt die Kette. Für ein verkettetes Protokoll gibt es deshalb nur eine Aufbewahrungsregel: behalten. Das ist kein Versehen, sondern der Preis.

Der saubere Ausweg heißt Siegeln und Überrollen: einen Abschnitt exportieren, die Kette darin prüfen, den letzten Hash als Anker in den neuen Abschnitt übernehmen und erst dann die alten Zeilen entfernen. Die Lücke ist damit belegt statt unerklärt. Fragen Sie nach, ob ein Anbieter das schon kann oder nur plant — und bedenken Sie personenbezogene Daten im Protokoll: Eine Löschpflicht nach der DSGVO und eine unveränderliche Kette vertragen sich nur, wenn das vorher durchdacht wurde.

Woran erkenne ich, ob ein Anbieter es ernst meint?

An sieben Fragen — und daran, ob die Antwort eine Behauptung ist oder eine Fehlermeldung. Wer es ernst meint, kann zeigen, was passiert, wenn man es versucht.

• Wo entsteht die Verkettung? In der Anwendung oder in der Datenbank?
• Mit welchen Rechten läuft die Anwendung? Darf ihr Datenbankbenutzer Protokolleinträge ändern oder löschen?
• Wer prüft die Kette, und wie oft? Von selbst oder nur auf Knopfdruck? Wird auch das gute Ergebnis festgehalten?
• Was meldet die Prüfung? Nur „fehlerhaft“ oder die genaue Stelle mit Befund?
• Gibt es einen Anker außerhalb der Datenbank? Wenn nicht, bleibt eine gekürzte oder neu gerechnete Kette unentdeckt.
• Was ist mit den Entscheidungen selbst? Lässt sich ein genehmigter Antrag nachträglich ändern, ein geschlossener Vorfall umbewerten?
• Was kann das Verfahren nicht? Ein Sicherheitsversprechen, dessen Grenzen man nicht kennt, ist selbst ein Risiko.

Zur Einordnung: Diese Seite erklärt ein technisches Verfahren und ist keine Rechts- oder Steuerberatung. Ob und wie lange Sie bestimmte Unterlagen unveränderbar aufbewahren müssen, richtet sich nach HGB, AO und den GoBD und gehört im Zweifel vor Ihre Steuerberatung. Die Angaben zu den Controls folgen der ISO/IEC 27001:2022; maßgeblich ist der Normtext.