Der Sarbanes-Oxley Act (SOX) ist ein US-Bundesgesetz aus dem Jahr 2002. Section 404 verlangt von börsennotierten Unternehmen, dass die Geschäftsführung jährlich die Wirksamkeit der internen Kontrollen über die Finanzberichterstattung bewertet (Internal Control over Financial Reporting, ICFR). Diese Bewertung muss durch einen externen Wirtschaftsprüfer attestiert werden.
Im SAP-Kontext entstehen aus SOX Section 404 spezifische Anforderungen an die IT General Controls (ITGC). Sie erfassen alle Aktivitäten, die SAP-Systeme mit Finanz-Wirkung betreffen: FI, CO, AA, GL, MM, SD. Die ITGC umfassen vier Bereiche: Access Controls, Change Management, Computer Operations und Program Development.
Das 4-Augen-Prinzip (Four Eyes Principle, Two-Person Rule) ist eine zentrale Change-Management-Kontrolle. Es verlangt, dass eine kritische Aktivität von mindestens zwei unterschiedlichen Personen getragen wird: einer, die die Änderung durchgeführt hat, und einer unabhängigen, die die Freigabe erteilt. In Kombination mit Segregation of Duties (SoD) ist es die operative Übersetzung des Vertrauensprinzips: Keine einzelne Person darf allein eine kritische Aktion durchführen.
SOX-Kontrollen im SAP-Change-Prozess scheitern aus strukturellen Gründen, nicht aus blattem Vorsätz:
Das Basis-Administrator-Problem. SAP-Basis-Administratoren haben oft weitreichende Systemberechtigungen, die es ihnen ermöglichen, Transports direkt in Produktivsysteme zu importieren, Berechtigungen direkt zuzuweisen und Customizing direkt ändern. Wenn dieselbe Person, die einen Change umsetzt, ihn auch in Produktion bringen kann, ist das 4-Augen-Prinzip technisch ausgehebelt, auch wenn prozessual Genehmigungen vorgesehen sind.
Das Emergency-Missbrauch-Problem. Emergency Changes können ein abgekürztes Genehmigungsverfahren rechtfertigen. Wenn aber 30-40 Prozent aller Changes als Emergency klassifiziert werden, ist der Emergency-Prozess zum Regularweg geworden. Auditoren erkennen dieses Muster als Kontrollfehler.
Das Dokumentations-statt-Erzwingungs-Problem. Das 4-Augen-Prinzip steht im Prozesshandbuch, wird aber nicht im Berechtigungskonzept durchgesetzt. Die Genehmigung erfolgt, aber dieselbe Person könnte technisch auch ohne Genehmigung handeln. Für den Auditor zählt, ob die Kontrolle technisch erzwungen ist oder nur dokumentiert wird.
Die zentrale Frage im SOX-Audit ist nicht: „Hat jemand die Genehmigung dokumentiert?“, sondern: „Konnte jemand ohne Genehmigung handeln?“
Was technische Erzwingung bedeutet. Technische Erzwingung bedeutet, dass das System die kritische Aktion ohne vorherige Genehmigung von einer zweiten Person technisch verhindert. Für den Transport-Import in Produktion: Die Importberechtigung (‘S_CTS_ADMI’ oder äquivalent) ist so konfiguriert, dass sie nur Personen haben, die nicht gleichzeitig die Entwicklerrolle haben. Das SAP-Berechtigungskonzept erzwingt die SoD.
Was nur dokumentiert ist. Wenn die Genehmigung im Change-System erfasst wird, der Entwickler aber technisch noch die Möglichkeit hätte, seinen eigenen Transport zu importieren, dann ist das 4-Augen-Prinzip dokumentiert, aber nicht erzwungen. Im SOX-Audit ist das eine Kontrollsächwche (Control Weakness), je nach Ausprägung eine Significant Deficiency oder Material Weakness.
Die Kompensationskontrolle. Wenn die technische Erzwingung nicht möglich ist (z.B. bei kleinen Teams mit begrenztem Personal), müssen Kompensationskontrollen das Risiko mitigieren: detaillierte Systemlogs, regelmäßige Überprüfungen von Direktimporten, automatisierte Anomalie-Erkennung. Diese Kompensationskontrollen müssen selbst dokumentiert und geprüft sein.
Die häufigsten SOX-Findings im SAP-Change-Prozess. In der Praxis dominieren drei Typen: Direktimporte in Produktion ohne Change-Record (Kontrollfehler im Change Management), fehlende technische Erzwingung der SoD zwischen Entwicklung und Produktion (Kontrollschwache im Access Control), und zu hoher Anteil an Emergency Changes (Kontrollfehler im Change Management, ermöglicht Prozesskorrektheit zu umgehen).
Grenzen der Kompensationskontrollen. Kompensationskontrollen können technische Lücken bis zu einem Grad ausgleichen. Aber: Sie sind teuer in der Durchführung (manuelles Review ist aufwendig), fehleranfällig (Menschen übersehen Ausnahmen) und werden vom Auditor als schwerer bewertet als technisch erzwungene Primärkontrollen. Eine gute Kompensationskontrolle löst das Grundproblem nicht, sie verwaltet es.
Das KI-Change-Problem für SOX. Wenn AI-Coding-Werkzeuge ABAP-Code erzeugen, der in finanzrelevante SAP-Systeme deployed wird, muss dieser Code denselben SOX-Kontrollen unterliegen wie human-generierter Code. Der Unterschied: Der Entwickler ist jetzt ein Mensch, der KI-generierten Code übernimmt und released. Die Frage für den Auditor: Wurde der Code von einer zweiten, unabhängigen Person reviewed, bevor er in Produktion ging?
Technische SoD im Berechtigungskonzept. Der erste Schritt ist die Überprüfung des SAP-Berechtigungskonzepts: Welche Rollen erlauben den Transport-Import in Produktivsysteme? Können Entwickler diese Rollen gleichzeitig mit Entwicklerrollen haben? Die SoD-Matrix definiert, welche Rollenkombinationen verboten sind. Diese Matrix wird technisch im Berechtigungskonzept durchgesetzt und regelmäßsig überprüft.
Direktimport-Monitoring als Kompensation. Für die Fälle, in denen technische Erzwingung nicht vollständig möglich ist (kleine Teams, Notfälle), wird Direktimport-Monitoring eingerichtet: automatisierte Erkennung von Imports, die nicht über den Change-Prozess laufen, automatische Benachrichtigung und Eskalation, regelmäßige Review-Zyklen durch eine unabhängige Stelle.
Emergency-Change-Quote als KPI. Die Quote der Emergency Changes am Gesamtvolumen wird als KPI gemessen und an das Management berichtet. Eine Quote über 15-20 Prozent ist ein Signal, dass der reguläre Prozess als zu langsam gilt. Das Problem liegt dann im Prozess, nicht im Emergency-Mechanismus.
AI-Code-Review als explizite Kontrollpflicht. Für Changes, die AI-generierten Code enthalten, wird im Change-Record explizit dokumentiert: Welches AI-Werkzeug wurde verwendet? Wer hat den generierten Code reviewed (zweite Person)? Welche Prüfungen wurden durchgeführt (ATC, Security-Check)? Diese explizite Dokumentation ist die technische Erzwingung des 4-Augen-Prinzips für KI-generierten Code.
SOX und das 4-Augen-Prinzip sind 2026 keine theoretischen Compliance-Übungen mehr, sondern operative Audit-Realität mit konkreten Findings. Die Kernfrage: Ist das 4-Augen-Prinzip technisch erzwungen oder nur dokumentiert? Technische SoD im Berechtigungskonzept, Direktimport-Monitoring, Emergency-Change-Quote als KPI und explizite AI-Code-Review-Dokumentation sind die vier operativen Konsequenzen.