Warum nachhaltige Compliance nur im unternehmensweiten Kontrollmodell entsteht.
Wer SAP Security noch immer isoliert im SAP-Workstream behandelt, hat ein Problem. Kein technisches – sondern ein strategisches.
Denn Berechtigungen in SAP sind längst kein Zugriffsthema mehr, das man in einem Security-Workstream abhandeln und dann zu den Akten legen kann. Sie sind ein zentrales Steuerungsinstrument für Geschäftsrisiken, Compliance, operative Stabilität und Governance.
Genau deshalb ist es ein Fehler, sie organisatorisch vom Information Security Management, vom IT Service Management und vom internen Kontrollsystem zu trennen. Aktuelle Rahmenwerke wie das NIST Cybersecurity Framework 2.0 betonen explizit die stärkere Verankerung von Cybersecurity in Governance und Enterprise Risk Management – nicht als Absichtserklärung, sondern als strukturelle Anforderung.1
Das Silo kostet mehr als es spart
Die Folgen dieses Silodenkens sind in Transformationsprogrammen mit schöner Regelmäßigkeit zu beobachten. Unternehmen investieren parallel in S/4HANA-Transformationen, neue IAM-Architekturen und moderne ITSM-Plattformen. Alle sprechen von Standardisierung, Automatisierung, Risikoreduktion. Und dennoch gelingt es in der Praxis kaum, ein gemeinsames Zielbild zu definieren.
Das Ergebnis: Die Systeme werden modernisiert, das Control Operating Model jedoch nicht.2 Das ist kein Zufall, sondern eine strukturelle Konsequenz des Silodenkens. Und es ist teuer – in Zeit, in Nacharbeitsaufwand, in Compliance-Risiken.
Praxisbeispiel 1: S/4HANA-Transformation ohne gemeinsamen Kontrollentwurf
Der SAP-Workstream definiert kritische Berechtigungen und SoD-Risiken. Der IAM- oder ITSM-Workstream modelliert Antrags- und Genehmigungsprozesse. Aber es gibt keinen gemeinsamen Kontrollentwurf.
Wer das ignoriert, baut keine Zero-Trust-Architektur – er baut ein Zero-Trust-Dokument.
NISTs Zero-Trust-Leitlinien machen unmissverständlich klar, dass Identität, Policy Enforcement und risikobasierte Entscheidungen systemübergreifend zusammenwirken müssen.3
Praxisbeispiel 2: Interne Kontrollen ohne SAP-Verankerung
Das zweite Szenario betrifft das interne Kontrollsystem. In vielen Unternehmen werden manuelle Kontrollen sauber beschrieben, getestet und berichtet: Freigaben, Stichproben, nachgelagerte Reviews. Soweit so gut.
Was dabei systematisch fehlt: SAP-embedded Controls werden oft separat betrachtet – 3-Way-Match-Logiken, Freigabeworkflows für Bestellanforderungen und Bestellungen, Toleranzgrenzen, systemische Sperren oder präventive Workflows im P2P- und Finance-Umfeld. All das existiert im System, wird aber nicht als dokumentierter Kontrollbaustein ins IKS aufgenommen.
Damit verschenken Organisationen nicht nur Kontrollwirkung. Sie verpassen auch die Chance, Zugriffsrisiken mit echten Prozesskontrollen zu verknüpfen. COSO versteht interne Kontrolle nicht als Sammlung isolierter Maßnahmen, sondern als integrierten Rahmen zur Steuerung von Risiken und Zielerreichung.4
Das Risikoprofil in S/4HANA ist nicht kleiner geworden
Das Risikoprofil in S/4HANA hat sich nicht vereinfacht – es hat sich erweitert. Zugriffskritikalität entsteht nicht mehr nur auf Ebene klassischer Transaktionen, sondern auch über Fiori-Apps, OData-Services und systemübergreifende Prozessketten.
SAP selbst weist darauf hin, dass Cross-System Segregation of Duties zu einem wachsenden Problem wird, wenn kritische Funktionen über mehrere Anwendungen verteilt sind.5
Eine Kontrolle, die nicht in das Gesamtmodell integriert ist, ist kein Kontrollinstrument. Sie ist ein Dokument.
Das Zielbild: Ein integriertes Enterprise Control Model
Die Konsequenz ist klar: SAP Security darf nicht länger als separates Fachthema organisiert werden. Es muss Teil eines integrierten Enterprise Control Models sein.
Erst wenn diese Ebenen zusammengedacht werden, entfalten Authorizations ihre eigentliche Wirkung: nicht als SAP-Spezialthema, sondern als verbindendes Element zwischen Security, Steuerung und Geschäftskontrolle.
Was das konkret bedeutet
Für Unternehmen, die vor oder mitten in einer Transformation stehen, ergibt sich ein klarer Handlungsauftrag:
1
Bei S/4HANA-Programmen nicht nur einen Security-Workstream aufsetzen, sondern SAP, IAM, ITSM und IKS von Beginn an in einen gemeinsamen Kontrollentwurf einbeziehen. Wer das am Ende der Transformation nachholen will, verschenkt Momentum und Synergien.
2
Nicht als technischen Anhang, sondern als dokumentierte und überwachbare Kontrollbausteine mit Verantwortlichen, Testverfahren und Nachweis-Logik. Einbettung der Kontrollen in den Mitigationsprozess.
3
Kritische Berechtigungen & SoD’s, Mitigationen, Policy Enforcement, Kontroll-Wirksamkeit und Residualrisiken müssen in einem Bild zusammenkommen. Weiterhin verteilte Verantwortungsbereiche kosten Aufwand und vermindern das Automatisierungspotential.6
Kernbotschaft
SAP Authorizations gehören nicht alleine in den SAP-Turm.
Wer sie dort belässt, behandelt ein unternehmensweites Steuerungsinstrument wie ein technisches Randthema – und verschenkt genau die Transparenz, Kontrollwirkung und Integrationsfähigkeit, die in modernen Transformations- und Governance-Modellen heute gebraucht werden.
Das ist keine Frage der technischen Reife. Es ist eine Frage der strategischen Entscheidung.
Haben Sie in Ihrer Organisation ähnliche Erfahrungen gemacht oder schon Lösungsansätze gefunden? Wir freuen uns auf den Austausch.
Quellen
- NIST Cybersecurity Framework (CSF) 2.0 – nist.gov/publications/nist-cybersecurity-framework-csf-20
- NIST SP 1800-35 – Implementing a Zero Trust Architecture – csrc.nist.gov/pubs/sp/1800/35/final
- NIST CSRC – Implementing a Zero Trust Architecture: SP 1800-35 – csrc.nist.gov/news/2025/sp-1800-35
- COSO – Internal Control Integrated Framework – coso.org/internal-control
- SAP Community – How to Manage Cross-System Segregation of Duties (SoD) Risk – community.sap.com (SoD Cross-System)
- NIST SP 1308 – NIST Cybersecurity Framework 2.0: Cybersecurity, Enterprise Risk Management – csrc.nist.gov/pubs/sp/1308/final