Es gibt eine bestimmte Art wie SOX-Projekte in Unternehmen starten, die unter Zeitdruck stehen. Ein Datum wird gesetzt. Meistens von außen: ein Konzernmandat, ein regulatorischer Zwang, eine Auflage aus einem Audit. Das Datum ist nicht verhandelbar. Die Vorbereitung beginnt trotzdem zu spät.
Was danach folgt, ist ein Muster, das ich kenne. Nicht aus Lehrbüchern. Aus Mandaten. Das Steering Committee wird eingesetzt. Eine externe Beratung wird beauftragt. Controls werden dokumentiert. Testing wird geplant. Und irgendwann stellt sich heraus, dass die Organisation nicht in dem Zustand ist, den das SOX-Framework voraussetzt.
Was SOX wirklich ist und warum die meisten Einführungen das falsch verstehen
Der Unterschied zwischen dokumentierten und gelebten Kontrollen ist der Kern dessen, was SOX-Projekte scheitern lässt. Eine dokumentierte Kontrolle ist ein Papier, das beschreibt was getan werden soll. Eine gelebte Kontrolle ist ein Prozess der tatsächlich durchgeführt wird, dessen Durchführung nachgewiesen werden kann, und der konsistent über Zeit funktioniert.
Die sechs Fehler die CFOs unter SOX-Zeitdruck machen
Fehler 1: SOX als Compliance-Projekt behandeln statt als Führungsprojekt
SOX ist kein Dokumentationsprojekt. Es ist eine fundamentale Veränderung der Art und Weise wie eine Finance-Organisation arbeitet. Ein CFO der SOX an einen Project Manager delegiert und sich auf monatliche Statusberichte beschränkt, wird ein SOX-Projekt bekommen das formal voranschreitet und operativ nicht verwurzelt ist.
Was konkret der CFO persönlich entscheiden muss: Die Priorisierung von SOX-Arbeit gegenüber Tagesgeschäft. Die Eskalation von Entscheidungen die Abteilungsgrenzen überschreiten. Die Kommunikation an die Organisation was SOX bedeutet und warum es wichtig ist.
Fehler 2: Die Scope-Entscheidung zu spät und zu breit treffen
Die Scope-Entscheidung ist die wichtigste Einzelentscheidung in einem SOX-Projekt. Sie ist eine Kaskade von fünf Teilentscheidungen.
Entscheidung 1:
Welche Gesellschaften sind in scope? Kriterien: Umsatzbeitrag, Bilanzsumme, Geschäftskomplexität, Risikoexposition.
Entscheidung 2:
Welche Konten sind material? Quantitativ und qualitativ. Nicht wesentliche Konten müssen explizit dokumentiert werden.
Entscheidung 3:
Welche Prozesse unterstützen die wesentlichen Konten? Top-down-Ansatz: von wesentlichen Abschlussposten zu den Prozessen die sie beeinflussen.
Entscheidung 4:
Welche Controls werden priorisiert? Entity Level Controls zuerst, dann Abschlussprozess-Controls, dann IT General Controls.
Entscheidung 5:
Welcher Ansatz für IT General Controls? Zugriffsmanagement ist fast immer die erste Priorität.
Diese fünf Entscheidungen müssen in der ersten Projektwoche getroffen sein. Nicht als vorläufige Einschätzung. Als dokumentierte Entscheidung.
Fehler 3: Segregation of Duties unterschätzen
In SAP-Systemen existieren häufig Berechtigungskombinationen die SoD-Verstöße ermöglichen. Niemand hat sie bewusst angelegt. Trotzdem sind sie da seit Jahren.
Was konkret getan werden muss: Vollständige SOD-Analyse in der ersten Projektwoche beginnen. Priorisierung der kritischen Konflikte. Behebung durch Berechtigungsanpassungen in SAP. Dokumentation aller nicht behobenen Konflikte als akzeptierte Risiken mit kompensierenden Kontrollen. Einrichtung eines laufenden SOD-Monitorings.
Fehler 4: Das Testing zu spät starten
Testing muss parallel zur Dokumentation laufen. Die Definition des Testing-Ansatzes für jede Kontrolle muss vor dem Testing vorliegen. Findings müssen sofort kommuniziert werden. Unterscheidung zwischen Design-Deficiencies und Operating Deficiencies ist entscheidend für die richtige Remediation-Strategie.
Fehler 5: Die Organisation nicht ausreichend einbinden
Jeder Control Owner muss wissen: welche Kontrolle von ihm erwartet wird, was der Zweck dieser Kontrolle ist, wie sie durchgeführt wird, und wie die Evidence zu erstellen und aufzubewahren ist. Ein generisches SOX-Training reicht nicht.
Fehler 6: IT als Nachgeordneten behandeln statt als Partner
IT General Controls sind nicht weniger wichtig als Process Controls. Eine schwache IT-Kontrolle kann alle Process Controls unterlaufen. IT muss von Woche eins Partner sein, gemeinsame Definition der IT General Controls, SOX-konformes Change-Management, Überprüfung und Bereinigung des User Access Managements.
Was ich in meinen Mandaten erlebe
Ich begleite aktuell eine SOX-Einführung unter erheblichem Zeitdruck. Die Ausgangssituation ist typisch: Einige Prozesse sind dokumentiert aber die Dokumentation spiegelt nicht die gelebte Praxis wider. SOD-Verstöße existieren in SAP die niemand bewusst angelegt hat. Und das Testing ist noch nicht gestartet, weil die Dokumentation noch nicht vollständig ist.
Was ich in dieser Situation tue: Scope sofort scharf definieren. SoD-Analyse sofort durchführen. Testing parallel zur Dokumentation starten. Die Organisation mit klaren konkreten Anforderungen einbinden.
Was ich mitbringe
Ich bin Nicole Vekonj, Interim Managerin Finance & Controlling. Ich begleite SOX-Einführungen operativ, nicht konzeptionell. Ich arbeite im System, in den Prozessen, mit den Teams.
👉 Projektanfrage stellen: zahlenkompetenz.de/de/kontakt
