Ein Audit Trail in der SAP-Welt ist die durchgängige, lückenlose, revisionssichere Aufzeichnung aller Aktivitäten, die im Rahmen einer Änderung an einem SAP-System geschehen. Er beginnt mit der Erfassung einer Anforderung, führt über deren Bewertung, Genehmigung, Umsetzung in Entwicklung, Test, Freigabe und Deployment in das Produktivsystem und endet erst, wenn alle Nachweispflichten dieser Änderung erfüllt sind. Der Audit Trail ist nicht ein technisches Logfile, sondern eine geschäftliche Spur. Sie verbindet die fachliche Anforderung, die organisatorische Genehmigung, die technische Umsetzung und die regulatorischen Nachweise zu einer einzigen, wiederherstellbaren Beweiskette.
Im ITIL-4-Sprachgebrauch entspricht der Audit Trail mehreren Praktiken in Kombination: Service Configuration Management, Change Enablement, Release Management, Information Security Management und Incident Management. Die Aufgabe eines belastbaren Audit Trails ist es, diese Praktiken in einer kohärenten Spur zusammenzuführen, nicht parallel zu dokumentieren.
In der SAP-Welt bekommt der Audit Trail eine technische Dimension: Jede SAP-Änderung materialisiert sich in einem Transport Request (TR). Die Audit-Trail-Pflicht erstreckt sich auf den TR selbst: Welche Objekte enthält er? Welche Abhängigkeiten bestehen? Wer hat verändert und freigegeben? Welche Tests sind gelaufen? Welche Quality Gates wurden passiert? In welcher Reihenfolge wurden TRs importiert? Welche Sicherheitsprüfungen wurden durchgeführt?
2026 konvergieren vier regulatorische Regime auf denselben SAP-Change-Prozess. Jedes Regime definiert eigene Audit-Trail-Anforderungen, die idealerweise aus einer einzigen Datenbasis beantwortet werden.
EU AI Act. Für Hochrisiko-KI-Systeme nach Annex III verlangt Artikel 12 automatisch generierte Logs. Artikel 26 (6) verpflichtet Deployer, diese Logs mindestens sechs Monate aufzubewahren. Jede Änderung an einem Hochrisiko-KI-System muss lückenlos dokumentiert sein, inklusive Risikoklasse und durchlaufener Quality Gates.
SOX (Sarbanes-Oxley, Section 404). SOX verlangt nachweisbare IT General Controls (ITGC) in finanzrelevanten Systemen. Auditoren prüfen: Gab es eine formale Anforderung? Wer hat genehmigt? War die Genehmigung unabhängig von der Umsetzung? Wurden Tests abgeschlossen? Ohne belastbaren Audit Trail gibt es keine SOX-Compliance.
NIS2 (Richtlinie (EU) 2022/2555). NIS2 verlangt Risikomanagement mit Kontrolle über IT-Änderungen. Meldepflichten für schwerwiegende Vorfälle: innerhalb von 24 Stunden Erstmeldung, 72 Stunden detaillierter Bericht. Der Audit Trail muss zeigen, welche Änderungen vor einem Vorfall durchgeführt wurden.
DORA (Verordnung (EU) 2022/2554). DORA gilt seit Januar 2025 für Finanzunternehmen. Artikel 13 schreibt Change-Management-Policies für ICT-Systeme vor. Der Audit Trail muss Rollback-Fähigkeit dokumentieren: Wie schnell kann nach einer fehlgeschlagenen Änderung der Vorherige Zustand wiederhergestellt werden?
Ein belastbarer Audit Trail in SAP-Landschaften besteht aus vier Schichten:
Prozess-Layer: der Change-Record. Jede Änderung beginnt mit einem Change-Record im ALM-System. Der Record enthält: Anforderungsbeschreibung, Risikoklassifikation, betroffene Systeme und Objekte, Genehmigungen mit Timestamp und Genehmiger-ID, Test-Ergebnisse, Release-Entscheidung, Deployment-Zeitpunkt. Der Change-Record ist die menschliche Spur.
Transport-Layer: der TR-Trail. Jeder Transport Request hat einen technischen Log: Inhalt (Objekte), Exporte, Importe, Fehlermeldungen. Das TMS protokolliert diese Aktivitäten automatisch. Ohne Integration mit dem Change-Record ist der TR-Trail technisch korrekt, aber nicht businessseitig nachvollziehbar.
Quality-Gate-Layer: die Prüfspur. Jede automatisierte Prüfung vor dem Import hinterlässt ein Protokoll. Dieses Protokoll muss mit dem Change-Record verknüpft sein. Fehlt diese Verknüpfung, gibt es eine Lücke zwischen dem genehmigten Change und dem tatsächlich deployed Artefakt.
Regulatorischer Layer: die Compliance-Spur. Aus den vorherigen Schichten werden regime-spezifische Berichte generiert: SOX-Audit-Report, EU-AI-Act-Log-Report, NIS2-Incident-Context-Report, DORA-Change-Control-Evidence. Diese Berichte entstehen als Auswertung der gemeinsamen Datenbasis, nicht als separate Dokumentation.
Das Medienbruch-Problem. Anforderungen in Jira, Changes in SolMan, Tests in einem dritten Tool, Genehmigungen per E-Mail. Jeder Systemwechsel ist ein potenzieller Informationsverlust. Der Audit Trail ist nur so belastbar wie seine schwächste Verbindung.
Das Direktimport-Problem. Basis-Administratoren importieren Transports direkt in Produktivsysteme ohne Change-Record. Im SOX-Audit ist ein Direktimport ohne Change-Record ein Kontrollfehler. Im Worst Case eine Material Weakness.
Das Shadow-Change-Problem. Customizing-Anpassungen direkt im Produktivsystem, die nicht über TRs transportiert werden, fehlen im Audit Trail. Sie fallen durch das Raster des Transport-Monitorings.
Das KI-Change-Problem. KI-Änderungen entstehen auf mehreren Wegen: SAP-Updates (neue Version des Joule-Agenten), Konfigurationsänderungen im Joule Studio, ABAP-Code-Updates mit KI-Logik, Änderungen an Trainingsdaten. Nicht alle laufen durch den klassischen Transport-Prozess. Ohne explizite KI-Governance entstehen Lücken.
Keine manuelle Audit-Trail-Dokumentation. Ein Audit Trail, der manuell gepflegt werden muss, ist kein belastbarer Audit Trail. Jeder Schritt im Change-Prozess wird automatisch protokolliert. Genehmigungen im System, nicht per E-Mail. Test-Abschlüsse im System, nicht in Excel.
Gemeinsame Datenbasis für alle Regime. Der Audit Trail wird einmal aufgebaut und aus einer gemeinsamen Datenbasis für mehrere Regime ausgewertet. Ein Change-Record enthält alle relevanten Felder, auch wenn nur ein Regime sie benötigt. Regime-spezifische Views werden als Filtered Report generiert.
Explizite KI-Governance im Change-Prozess. Für jede Änderung mit KI-Komponente werden obligatorisch erfasst: Name des KI-Systems, Risikoklasse nach EU AI Act, Art der Änderung, Auswirkung auf Risikoklassifikation, Log-Persistenz-Nachweis.
Audit-Readiness als Systemeigenschaft. Das Ziel ist nicht, für Audits zu dokumentieren, sondern dass die Dokumentation als Nebenprodukt des normalen Betriebs entsteht. Wenn ein Auditor kommt, wird ein Report gezogen, nicht ein Dokumentations-Sprint gestartet.
Audit Trail im SAP-Change-Prozess ist 2026 keine technische Compliance-Übung mehr, sondern eine geschäftliche Pflicht mit vier parallelen regulatorischen Treibern: SOX, EU AI Act, NIS2 und DORA. Die operative Konsequenz: eine gemeinsame Datenbasis, automatische Protokollierung, explizite KI-Governance im Change-Record. Kein manueller Dokumentations-Sprint vor Audits, sondern Audit-Readiness als Systemeigenschaft des normalen Betriebs.