Audit-Trail nachrüsten oder neu bauen: Wann sich welcher Weg rechnet

Der Anlass ist selten Architektur. Der Anlass ist ein Fragebogen: ein Sicherheits-Assessment eines Enterprise-Kunden, ein NIS2-Nachweis, eine interne Revision. Darin steht eine Frage, die harmlos aussieht — „Können Sie nachvollziehbar darlegen, wer welche Änderung wann und auf welcher Grundlage vorgenommen hat?" — und Ihr System kann es nicht. Nicht, weil es schlecht gebaut wäre. Sondern weil es gebaut wurde, um den aktuellen Zustand korrekt zu halten, nicht um die Geschichte zu belegen.

Ab hier gibt es zwei Wege: nachrüsten oder neu bauen. Beide sind legitim. Teuer wird es, wenn man den falschen wählt und das erst nach zwölf Monaten merkt.

Was ein Audit tatsächlich verlangt

Bevor Sie über Technik reden, klären Sie die Anforderung. „Audit-Trail" ist kein Feature, sondern eine Menge von Eigenschaften:

• Vollständigkeit. Jede fachlich relevante Änderung erzeugt einen Eintrag — nicht nur die, an die jemand gedacht hat.
• Unveränderbarkeit. Einträge lassen sich im Nachhinein nicht still korrigieren. Korrekturen sind selbst wieder Einträge.
• Zurechenbarkeit. Zu jedem Eintrag gehört ein Akteur: Mensch, technischer Nutzer oder Automatismus.
• Fachlicher Kontext. Nicht nur status = 3, sondern: Kreditlimit überschritten, Freigabe durch Vertriebsleitung, Begründung hinterlegt.
• Rekonstruierbarkeit. Aus den Einträgen lässt sich der Zustand zu einem beliebigen Zeitpunkt herleiten.

Die ersten drei bekommen Sie mit Nachrüsten hin. Die letzten beiden sind der Grund, warum Projekte scheitern. Mehr dazu im Fundamentbeitrag zu revisionssicherem Logging.

Der Weg „nachrüsten"

Nachrüsten heißt in der Praxis fast immer eine Kombination aus drei Bausteinen: Datenbank-Trigger oder Change-Data-Capture auf den kritischen Tabellen, eine Append-only-Tabelle für die Einträge und eine Anreicherung im Applikationscode, damit Akteur und Absicht mitkommen.

Das funktioniert gut, wenn:

• die auditpflichtigen Vorgänge auf wenige, klar abgrenzbare Tabellen fallen,
• der Schreibpfad zentral ist — nicht drei Services und ein Nachtjob schreiben nebeneinander,
• „wer und wann" genügt und „warum" nur in Ausnahmefällen gefragt wird,
• der Zeitdruck real ist: ein Kundenaudit in acht Wochen ist kein Modernisierungsprojekt.

Realistischer Aufwand für ein mittelgroßes Fachsystem: sechs bis zwölf Wochen bis zum belastbaren Nachweis, plus dauerhafte Wartung. Der eigentliche Preis ist nicht die Einführung, sondern die Disziplin danach: Jeder neue Schreibpfad muss den Trail bedienen, sonst entstehen genau die Lücken, die im nächsten Audit auffallen.

Der Weg „neu bauen"

Neu bauen heißt nicht „alles wegwerfen". Es heißt: Der auditpflichtige Kern wird als eigenes Fachsystem modelliert, in dem die Veränderung selbst das primäre Datum ist — nicht der abgeleitete Zustand. Genau das leistet Event Sourcing, wenn es sich lohnt: Der Nachweis ist kein Nebenprodukt, sondern die Quelle, aus der der Zustand berechnet wird.

Dieser Weg rechnet sich, wenn:

• die Nachweispflicht dauerhaft ist und eher wächst (NIS2 heute, EU AI Act morgen),
• der Fachprozess über mehrere Systeme läuft und niemand die Reihenfolge rekonstruieren kann,
• die Frage nach dem „warum" regelmäßig gestellt wird — von Kunden, Prüfern oder der eigenen Fachabteilung,
• das Bestandssystem ohnehin an eine Grenze stößt: Mandantenfähigkeit, Performance, Wartbarkeit.

Die Grenze zwischen beiden Wegen

Der entscheidende Punkt ist selten technisch. Nachrüsten wird teurer als Neubau, sobald der Trail den fachlichen Kontext liefern muss, den das Datenmodell nicht kennt. Wenn der Prüfer fragt „auf welcher Grundlage wurde die Kreditprüfung übersprungen?" und die Antwort im Bestandssystem nirgends steht, hilft kein Trigger — die Information wurde nie erzeugt.

Drei Signale, dass Nachrüsten nicht mehr trägt:

1. Sie müssen Ereignisse aus Zustandsänderungen erraten („status ging von 2 auf 3, also wurde vermutlich freigegeben").
2. Der Trail widerspricht regelmäßig dem, was Fachbereiche berichten — und niemand kann sagen, welche Seite recht hat.
3. Für jede Prüfanfrage braucht ein Entwickler mehrere Tage Forensik. Das ist keine Anfrage mehr, das ist ein Prozess.

Ein ausführliches Beispiel dafür steht im Praxisbeitrag zur Auftragsabwicklung über fünf Systeme.

Ein pragmatischer Mittelweg

In den meisten Fällen ist die richtige Antwort nicht „entweder oder", sondern eine Reihenfolge: nachrüsten, um das aktuelle Audit zu bestehen, und parallel den auditpflichtigen Kern sauber modellieren — als klar abgegrenztes Teilsystem, das schrittweise übernimmt. Das Nachrüsten kauft Zeit; die Modellierung sorgt dafür, dass die nächste Prüfpflicht kein zweites Notprojekt auslöst.

Wichtig ist, dass die Übergangslösung als Übergangslösung benannt wird — mit Ablaufdatum, Verantwortlichem und Budget. Nachgerüstete Trails ohne Nachfolgeplan werden dauerhaft und sind fünf Jahre später der Grund, warum niemand mehr etwas ändert.

Wie Sie in einer Stunde zu einer Entscheidung kommen

Nehmen Sie die drei häufigsten Prüffragen aus Ihrem letzten Fragebogen und beantworten Sie sie an einem echten Vorgang aus dem Bestandssystem — mit Uhrzeit, Akteur und Begründung. Wenn Sie das mit vorhandenen Daten schaffen, reicht Nachrüsten. Wenn Sie an einer Stelle raten müssen, kennen Sie Ihre Antwort.

Der Nachweis-Check führt Sie in fünf Minuten durch diese Fragen; die Übersicht Nachweisbarkeit ordnet ein, welche Pflichten für Ihr Umfeld tatsächlich gelten.