Audit-Log-Management: Compliance und Nachvollziehbarkeit

Ein belastbarer Audit-Trail beantwortet eine einfache Frage: Wer hat was, wann, wo und mit welchem Ergebnis getan? Eine einheitliche gesetzliche Mindestfrist für alle Logs gibt es in Österreich nicht. Die Aufbewahrung richtet sich nach Zweck und Systemklasse: sieben Jahre für Buchhaltungsunterlagen nach UGB und BAO, mindestens sechs Monate für Logs von Hochrisiko-KI nach dem EU AI Act, und für technische Sicherheitslogs empfehlen etablierte Standards wie die CIS Controls mindestens 90 Tage. Gleichzeitig verlangt der Datenschutz eine zweckgebundene und sparsame Speicherung.

Die Prüferin sitzt im Besprechungsraum und stellt eine einfache Frage: „Zeigen Sie mir den vollständigen Ablauf dieser Zahlung.“ Die Transaktion begann im ERP, wurde im CRM angestoßen, im Finanzsystem freigegeben und später von einem automatisierten Prozess verbucht. Ihr Team öffnet mehrere Oberflächen. Ein System zeigt lokale Zeit, ein anderes UTC. Ein Protokoll kennt nur eine technische Kennung, ein weiteres enthält zwar den Benutzer, aber nicht das Ergebnis der Aktion. Die Quell-IP fehlt, die Freigabe ist nicht mit dem Auftrag verknüpft, und niemand kann sicher sagen, ob ein Eintrag nachträglich verändert wurde.

Das ist kein Problem fehlender Logdaten. Es ist ein Problem fehlenden Audit-Log-Managements. Die Lage verschärft sich, weil Compliance, Incident Response, Datenschutz und neue KI-Workflows dieselben Ereignisse aus unterschiedlichen Blickwinkeln benötigen. Wer Audit-Logs nur sammelt, besitzt deshalb noch keinen prüfbaren Nachweis.

Wenn die Prüfung nach dem kompletten Ablauf fragt

Die unangenehme Szene beginnt meist nicht mit einem Sicherheitsvorfall, sondern mit einer Rückfrage zur Kontrolle. Eine Finanzleiterin soll erklären, wer eine Zahlung freigegeben hat, welches Dokument die Freigabe ausgelöst hat und ob danach noch Daten geändert wurden. Im ERP findet sie den Buchungssatz. Im CRM liegt der Kundenkontext. Im Finanzsystem erscheint eine technische Schnittstellenkennung. Der Zusammenhang zwischen diesen Ereignissen ist nicht dokumentiert.

Das Team exportiert CSV-Dateien, kopiert Screenshots und bittet Systemverantwortliche um manuelle Auszüge. Jeder hilft, doch niemand besitzt den vollständigen Ablauf. Die Protokolle enthalten unterschiedliche Feldnamen, uneinheitliche Zeitstempel und keinen gemeinsamen Korrelationsschlüssel. Selbst ein erfolgreicher Status beantwortet nicht, welche Person oder welcher Agent die Aktion veranlasst, welches System sie ausgeführt und welches Ergebnis es erzeugt hat.

Der eigentliche Fehler liegt zwischen den Systemen

Ein einzelnes System kann durchaus gute Logs erzeugen. Die Beweiskette zerreißt trotzdem an den Übergängen. Ein ERP protokolliert die Änderung, der Connector den API-Aufruf, der Agent seine Entscheidung, und das Zielsystem speichert nur das technische Konto. Ohne gemeinsames Schema bleibt der Ablauf eine Sammlung plausibler Einzelstücke.

Gutes Audit-Log-Management macht daraus einen rekonstruierbaren Trail. Es definiert, welche Ereignisse relevant sind, welche Felder verpflichtend bleiben, wer Zugriff erhält und wie Integrität nachgewiesen wird. Das Ziel ist nicht, jede technische Meldung für immer aufzubewahren. Das Ziel ist ein vertrauenswürdiger, zweckgebundener und schnell durchsuchbarer Nachweis.

Was Audit-Logs sind und warum sie mehr sein müssen als Logdateien

Eine Logdatei beschreibt häufig, was ein System technisch beobachtet hat. Ein Audit-Log muss dagegen eine geschäftlich oder sicherheitsrelevante Handlung nachvollziehbar machen. Die entscheidende Frage lautet nicht nur, ob ein API-Aufruf stattgefunden hat, sondern wer ihn mit welchem Zweck und welchem Ergebnis ausgelöst hat.

Ein brauchbares Ereignis ist strukturiert, zeitgestempelt und gegen unbemerkte Veränderung geschützt. Es enthält die betroffene Ressource, den auslösenden Benutzer oder Dienst, den aufrufenden Prozess, den Kontext und den Erfolg oder Fehler der Aktion. Bei Änderungen an kritischen Datensätzen gehören, sofern rechtlich und fachlich vertretbar, auch vorherige und nachherige Werte dazu.

Die fünf Fragen eines belastbaren Ereignisses

• Wer: Benutzer-ID, Servicekonto, Agenten-ID oder delegierte Identität. Ein generisches „system“ reicht nicht.
• Wann: Ereigniszeit, Empfangszeit und eine eindeutige Zeitzonenlogik. Zeitangaben müssen systemübergreifend korrelierbar sein.
• Was: Aktion, betroffene Entität, Datensatz und bei Änderungen die relevante Veränderung.
• Wo: System, Mandant, Anwendung, Quelladresse und Zielressource. Die CIS Controls nennen für Systeme mit sensiblen Daten ausdrücklich Ereignisquelle, Datum, Benutzername, Zeitstempel sowie Quell- und Zieladressen als Bestandteile detaillierter Audit-Logs (Safeguard 8.5).
• Wie: Auslöser, verwendete Schnittstelle, Freigabe, Policy-Entscheidung und Ergebniscode.

Monitoring beantwortet, ob ein Dienst verfügbar ist oder eine ungewöhnliche Aktivität auftritt. Forensische Audit-Daten müssen zusätzlich die Handlung und ihren Kontext erklären. Ein Dashboard kann einen Alarm anzeigen. Ein Audit-Trail muss den Ablauf belegen.

Praktische Regel: Wenn eine neue Mitarbeiterin die Aktion ohne Rückfrage nicht aus den Daten rekonstruieren kann, ist der Eintrag noch kein ausreichender Audit-Nachweis.

Pflichten im Überblick: DSGVO, UGB und BAO, NISG 2026, DORA und EU AI Act

Mehrere Regelwerke stellen Anforderungen an Protokollierung und Aufbewahrung. Sie verstärken sich bei Integrität und Nachvollziehbarkeit, erzeugen aber Reibung bei Speicherdauer, Zugriff und Datenminimierung.

DSGVO und Datenschutz

In Österreich bilden die DSGVO, anwendbar seit 25. Mai 2018, und das Datenschutzgesetz den Rechtsrahmen für Protokollierung und Rechenschaftspflichten im Umgang mit personenbezogenen Daten. Die österreichische Datenschutzbehörde verweist dabei auch auf Art. 30 DSGVO, der ein Verzeichnis der Verarbeitungstätigkeiten verlangt.

Für Logs ist das wichtig, weil IP-Adressen, Zeitstempel, Zugriffsereignisse und Benutzeraktionen personenbezogene Daten enthalten können. Unternehmen brauchen daher einen dokumentierten Zweck, klare Zugriffsregeln und eine begründbare Aufbewahrung. „Wir speichern alles, falls wir es später brauchen“ ist keine Datenschutzstrategie. Weil Logs auch zur Kontrolle von Beschäftigten taugen, ist bei Mitarbeiterbezug der Betriebsrat einzubeziehen; das Arbeitsverfassungsgesetz (§§ 96 und 96a ArbVG) sieht dafür Zustimmungspflichten vor.

UGB und BAO

Das UGB (§ 212) und die BAO (§ 132) verlangen für Bücher, Belege und relevante Unternehmensunterlagen eine Aufbewahrung von sieben Jahren. Nach § 131 BAO muss bei elektronischer Buchführung außerdem erkennbar bleiben, was ursprünglich erfasst und was später geändert wurde. Diese Anforderungen betreffen nicht automatisch jede technische Logzeile. Sie verlangen aber, dass relevante Geschäfts- und Kontrollnachweise verfügbar und nachvollziehbar bleiben. Für prüfungspflichtige Gesellschaften kommt die Abschlussprüfung dazu, die genau diese Nachweise anfordert.

NIS2 und NISG 2026

Für Einrichtungen im Anwendungsbereich von NIS2 gilt in Österreich ab 1. Oktober 2026 das NISG 2026 (BGBl. I Nr. 94/2025), das das NISG 2018 ablöst. Es verlangt Risikomanagementmaßnahmen, die Meldung erheblicher Sicherheitsvorfälle und die Berücksichtigung von Lieferkettenrisiken. Für das Logging heißt das: Risikoentscheidungen, Eskalationen und die Reaktion auf Vorfälle müssen fortlaufend nachvollziehbar sein, und die Protokolle müssen eine fristgerechte Meldung überhaupt erst ermöglichen. Die BMI/DSN-Schriftenreihe zu Logdaten als Grundlage für Incident Response beschreibt, welche Logdaten dafür praktisch gebraucht werden.

DORA im Finanzsektor

Für Finanzunternehmen gilt seit 17. Jänner 2025 der Digital Operational Resilience Act (Verordnung (EU) 2022/2554). Die Fristen für die Meldung schwerwiegender IKT-Vorfälle regelt die Delegierte Verordnung (EU) 2025/301: Die Erstmeldung erfolgt spätestens 4 Stunden nach der Einstufung als schwerwiegend und spätestens 24 Stunden nach Kenntnis des Vorfalls, die Zwischenmeldung spätestens 72 Stunden nach der Erstmeldung, der Abschlussbericht spätestens einen Monat nach der letzten aktualisierten Zwischenmeldung. Ohne korrelierbare Logs sind diese Fristen kaum einzuhalten.

EU AI Act: Anbieter- und Betreiberpflichten

Der EU AI Act verlangt für Hochrisiko-KI automatisch erzeugte Logs. Art. 19 verpflichtet Anbieter, diese Logs mindestens sechs Monate aufzubewahren, soweit sie unter ihrer Kontrolle stehen. Für die meisten Unternehmen wichtiger ist Art. 26 Abs. 6: Betreiber (Deployer) von Hochrisiko-Systemen müssen die automatisch erzeugten Logs, soweit sie unter ihrer Kontrolle stehen, für einen dem Zweck angemessenen Zeitraum von mindestens sechs Monaten aufbewahren, sofern Unions- oder nationales Recht nichts anderes vorsieht. Finanzinstitute führen diese Logs als Teil ihrer Dokumentation nach dem Finanzdienstleistungsrecht.

Zum Zeitpunkt: Nach der Änderung durch die Verordnung (EU) 2026/1744 gelten die Pflichten für Hochrisiko-Systeme nach Anhang III ab dem 2. Dezember 2027, für Hochrisiko-KI in Produkten nach Anhang I ab dem 2. August 2028. Viele Agenten in ERP- und Finanzprozessen sind keine Hochrisiko-Systeme. Wer das Logging-Schema jetzt sauber aufsetzt, erfüllt die Anforderung aber ohne Umbau, falls ein Anwendungsfall später in eine Hochrisiko-Kategorie fällt.

Manipulationsschutz und Aufbewahrung: die zwei Säulen vertrauenswürdiger Logs

Ein Audit-Log beweist nur, was nachträglich überprüfbar bleibt. Kann ein privilegierter Administrator Einträge löschen oder verändern, ohne Spuren zu hinterlassen, verliert der gesamte Trail seine Beweiskraft, auch bei technisch vollständiger Sammlung.

Die Architektur muss deshalb die Quelle von der alleinigen Kontrolle über Archiv und Prüfprozess trennen. Schreibgeschützter oder Append-only-Speicher, kryptografische Verkettung und digitale Signaturen machen Manipulationen erkennbar. Getrennte Rollen für Logbetrieb, Sicherheitsprüfung und Löschung verhindern, dass ein einzelnes Konto die Beweiskette beherrscht; mehr dazu im Beitrag zur Funktionstrennung.

Integrität muss prüfbar bleiben

Technische Kontrollen brauchen einen festen Prüfprozess. Prüfen Sie regelmäßig, ob Quellen senden, die Zeitbasis stimmt und Exporte dieselben Integritätsinformationen wie das Original enthalten. Ein Bericht aus einer Oberfläche ersetzt keinen unveränderbaren Datensatz. Bei verteilten Architekturen zählen klare Verantwortlichkeiten, dokumentierte Prüfungen und eine nachvollziehbare Kette vom Ereignis bis zum Export.

Aufbewahrung folgt Zweck und Systemklasse

Die sieben Jahre nach UGB und BAO gelten für relevante Unternehmensunterlagen, nicht automatisch für Netzwerk- und Debug-Logs. Die CIS Controls empfehlen, Audit-Logs über alle Assets mindestens 90 Tage aufzubewahren (Safeguard 8.10). Das ist eine technische Empfehlung, keine gesetzliche Pflicht, und ein sinnvoller Ausgangswert für Sicherheitslogs. Sensible Systeme benötigen zusätzliche Felder und differenzierte Zugriffsregeln.

Eine Zuordnungsmatrix schafft Klarheit:

• Geschäftsnachweis: Welche Ereignisse belegen Buchung, Freigabe oder Änderung?
• Sicherheitsnachweis: Welche Daten benötigt die Incident Response zur Rekonstruktion eines Angriffspfads?
• KI-Nachweis: Welche Agenten- und Modelllogs fallen unter Art. 19 oder Art. 26 AI Act?
• Datenschutz: Welche personenbezogenen Felder sind erforderlich, wer darf sie sehen und wann werden sie gelöscht?
• Revisionssicherheit: Welche Kopie ist unveränderbar, und wie wird ein Export verifiziert?

Webserver-Logs mit IP-Adresse, Zeitpunkt, aufgerufener Seite und Browserdaten dienen meist einem engen Zweck und brauchen deutlich kürzere Fristen als Geschäftsnachweise.

Audit-Logs und MCP-Agenten: warum Nachvollziehbarkeit ohne Schema scheitert

Ein Agent kann heute eine Anfrage aus Slack aufnehmen, Kundendaten im CRM lesen, eine Rechnung im ERP prüfen und eine Buchung im Finanzsystem anstoßen. Ein MCP-Layer (Model Context Protocol) vermittelt dabei Werkzeuge und Berechtigungen. Für die Prüfung entsteht aber nur dann ein belastbarer Ablauf, wenn jede Station dieselbe Ereignisidentität weitergibt.

Ohne Schema erscheint im ERP lediglich ein technischer API-Benutzer. Das CRM kennt vielleicht den ursprünglichen Auftrag, während der Agent seine Entscheidung in einer eigenen Laufzeitumgebung protokolliert. Der MCP-Layer speichert den Tool-Aufruf, aber nicht zwingend die menschliche Freigabe oder das Ergebnis im Zielsystem. So entsteht Automatisierung ohne Nachvollziehbarkeit.

Ein Agentenereignis braucht eine durchgehende Identität

Jeder Lauf sollte eine eindeutige Workflow- oder Correlation-ID erhalten. Diese ID wird vom menschlichen Auftrag über den Agenten, den MCP-Tool-Aufruf und den Connector bis zur Zielaktion weitergereicht. Zusätzlich gehören mindestens folgende Zusammenhänge in den Trail:

• Auftraggeber: menschliche Identität, Rolle und ursprünglicher Zweck.
• Agent: Modell- oder Agentenkennung, Version und ausgeführte Fähigkeit.
• Freigabe: Regel, Nutzerentscheidung oder Policy, die den Schritt erlaubt.
• Werkzeug: aufgerufene Funktion, Zielsystem und betroffene Ressource.
• Ergebnis: Erfolg, Ablehnung, Fehler und nachgelagerte Aktion.

Ein zentraler Audit-Trail muss dabei nicht jeden Prompt dauerhaft im Klartext speichern. Sensible Inhalte können minimiert, klassifiziert oder getrennt geschützt werden, während die entscheidenden Metadaten erhalten bleiben. Wer Enterprise-Automatisierung mit einer MCP- und Agentenplattform plant, sollte das Ereignisschema vor dem ersten produktiven Workflow festlegen. Sonst baut das Team später Adapter für unvereinbare Logmodelle.

Drei konkrete Anwendungsfälle: ERP, Buchhaltung und Incident Response

Die Qualität eines Trails zeigt sich nicht im Dashboard, sondern bei einer konkreten Rekonstruktion.

Ein Finanzteam verfolgt eine Zahlungsfreigabe durch Navision und DATEV. Der Trail muss den ursprünglichen Datensatz, die verantwortliche Person, den Freigabeschritt, die Connector-Aktion, die Zielbuchung und das Ergebnis zusammenführen. Eine technische Konto-ID allein genügt nicht, wenn sie nicht mit der delegierten Identität und der Geschäftsaktion verknüpft ist. Wie das im KI-gestützten Rechnungswesen aussieht, beschreibt unser Beitrag zu KI in der Buchhaltung.

Beim Sicherheitsvorfall braucht die Incident Response eine andere Sicht: Ereigniszeit, betroffene Systeme, Nutzerkontext und Folgeaktionen müssen konsistent vorliegen, damit Meldefristen nach NISG 2026 oder DORA eingehalten werden können.

Beim Agentenworkflow beginnt der Trail mit einer menschlichen Anfrage, führt über eine Policy-Prüfung und mehrere Tool-Aufrufe bis zur bestätigten oder abgelehnten Buchung. Der Unterschied zum klassischen ERP-Log ist die zusätzliche Verantwortungskette. Die Prüfung muss erkennen können, was der Agent selbstständig entschied, welcher Schritt regelbasiert erlaubt wurde und wo ein Mensch eingegriffen hat.

Die drei häufigsten Fehler im Audit-Log-Management

Der erste Fehler ist die Gleichsetzung von Sammlung und Compliance. Ein SIEM kann Millionen Ereignisse aufnehmen und trotzdem keine Antwort auf die Prüfungsfrage liefern. Wenn Felder fehlen, Zeitstempel nicht korrelieren oder privilegierte Nutzer Logs löschen können, ist die Datenmenge kein Nachweis.

Der zweite Fehler ist eine pauschale Aufbewahrung. Manche Teams behalten alles „für alle Fälle“, andere löschen nach einer kurzen Standardfrist. Beides ignoriert Zweckbindung und Risikoklasse. Geschäftsbelege, Sicherheitsdaten, KI-Logs und personenbezogene Webserver-Logs brauchen unterschiedliche Regeln, Freigaben und Löschprozesse.

Ein überfülltes Archiv ist nicht automatisch ein gutes Archiv. Entscheidend ist, ob die richtige Information geschützt, auffindbar und begründbar bleibt.

Der dritte Fehler betrifft Automatisierung. Unternehmen protokollieren den Agenten, aber nicht die menschliche Autorisierung. Oder sie erfassen den MCP-Aufruf, ohne das Ergebnis im ERP zu verbinden. Bei einem Fehler sieht jeder Beteiligte seinen eigenen Ausschnitt, und niemand kann den gesamten Ablauf erklären.

Die Korrektur beginnt bei den Ereignissen

Definieren Sie ein Pflichtschema, bevor Sie weitere Quellen anschließen. Validieren Sie eingehende Events, lehnen Sie unvollständige Ereignisse für kritische Prozesse ab und vergeben Sie eine gemeinsame Correlation-ID. Danach lassen sich Aufbewahrung, Zugriff und Integrität pro Asset-Klasse kontrolliert umsetzen.

Wie Sie jetzt starten: ein pragmatischer Fahrplan

Beginnen Sie nicht mit der Auswahl einer neuen Plattform. Beginnen Sie mit einem Prozess, bei dem ein fehlender Trail heute bereits Kosten oder Prüfungsstress verursacht, etwa einer Zahlungsfreigabe, einer privilegierten Änderung oder einem Agentenlauf.

Die erste Arbeitswoche

Erstellen Sie eine einfache Quellenkarte für ERP, CRM, Finance, Identität, Integrationen und Agenten. Markieren Sie je Quelle, wer das Ereignis erzeugt, welche Felder vorhanden sind, wo die Daten gespeichert werden und wer sie exportieren darf. Nehmen Sie dabei nicht nur erfolgreiche Aktionen auf. Fehlgeschlagene Zugriffe, Ablehnungen und nachträgliche Korrekturen gehören ebenfalls in den Ablauf.

Definieren Sie anschließend ein gemeinsames Event-Schema. Die Pflichtfelder decken mindestens Identität, Zeit, Aktion, Ressource, Quelle, Ziel, Auslöser, Ergebnis und Correlation-ID ab. Für KI-Workflows ergänzen Sie Agent, Tool, Policy-Entscheidung und menschliche Freigabe.

Danach wird aus Sammlung ein Betrieb

Zentralisieren Sie die relevanten Ereignisse, schützen Sie die Primärkopie gegen nachträgliche Manipulation und dokumentieren Sie die Aufbewahrung pro Zweck. Richten Sie regelmäßige Reviews ein, bei denen jemand prüft, ob Quellen senden, Felder vollständig sind und Zugriffsrechte noch passen. Testen Sie außerdem einen Export unter Zeitdruck, nicht erst beim nächsten Audit.

Der Nutzen reicht über Compliance hinaus. Strukturierte Logs verkürzen die Suche bei Vorfällen, erleichtern Kontrollen und machen Agenten in ERP-, CRM- und Finanzprozessen sicherer. Audit-Log-Management ist damit kein Archivprojekt, sondern ein Baustein der KI-Governance und eine operative Fähigkeit für nachvollziehbare Entscheidungen.

Sprechen Sie mit uns

Wenn Sie Ihren Audit-Trail von der ersten Prozessaufnahme bis zur kontrollierten Automatisierung belastbar aufbauen möchten, sprechen Sie mit uns.