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. Ein Datenbank-Administrator mit vollen Rechten kann weiterhin alles ändern — er hinterlässt dabei eine gebrochene Kette, mehr nicht. Und sie beweist weder die Uhrzeit gegenüber Dritten noch die Echtheit einer eingespielten Sicherung.

• 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“.

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 fünf 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?
• 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.