Newsblog

ICon 2026 Recap: Zwei Tage SAP-Security pur im Hamburger Hafen

Rebecca Zimmer — Tue, 16 Jun 2026 11:00:10 GMT

Die SAP-Sicherheitslandschaft verändert sich in einem rasanten Tempo. Cloud-Migrationen, der Einzug Künstlicher Intelligenz (KI) in den Prüfungsalltag und immer komplexere regulatorische Vorgaben stellen Unternehmen beim Thema Zugriffsmanagement und Compliance vor enorme Herausforderungen.

SU53 und STAUTHTRACE in der Berechtigungsanalyse

Julica Herold — Tue, 02 Jun 2026 07:56:36 GMT

Die Analyse von Berechtigungsfehlern in SAP erfolgt häufig mit Hilfe technischer Analysewerkzeuge, beispielsweise über die Transaktion SU53 (Werte der letzten fehlgeschlagenen Berechtigungsprüfung) oder über den STAUTHTRACE (Systemtrace für Berechtigungen). Beide Werkzeuge liefern Informationen darüber, welche Berechtigungsprüfungen im System stattgefunden haben und ob diese erfolgreich waren oder fehlgeschlagen sind. Damit sind sie wichtige Hilfsmittel bei der Untersuchung von Berechtigungsproblemen. Bei der Auswertung der Ergebnisse ist jedoch zu beachten, dass technische Prüfergebnisse nicht immer unmittelbar mit einem fachlichen Berechtigungsbedarf gleichgesetzt werden können.

Technische Prüfungen fachlich richtig einordnen

Ein wesentlicher Punkt bei der Interpretation von Berechtigungsanalysen aus SU53 oder STAUTHTRACE besteht darin, dass beide Tools zunächst nur technische Prüfungen im System sichtbar machen. Hieraus lässt sich jedoch nicht automatisch ableiten, dass jedes angezeigte Berechtigungsobjekt für den betrachteten fachlichen Use Case tatsächlich benötigt wird. Im technischen Ablauf können beispielsweise auch Berechtigungsprüfungen auftreten, die aus allgemeinen Umfeldfunktionen einer Transaktion, optionalen UI-Funktionen oder zusätzlichen Verarbeitungsschritten resultieren. Fehlgeschlagene Prüfungen müssen daher im fachlichen Kontext bewertet werden. Es kann vorkommen, dass zusätzliche Prüfungen im Hintergrund ausgeführt werden und fehlschlagen, die fachliche Basisfunktion aber trotzdem weiterhin erfolgreich genutzt werden kann.

Ohne eine genaue Differenzierung besteht die Gefahr, dass Berechtigungsobjekte vorschnell in Rollen übernommen werden, obwohl sie für den eigentlichen Prozess nicht erforderlich sind. Dies kann bei der Rollenpflege problematisch sein, wenn Analyseergebnisse ungeprüft als Grundlage für Rollenänderungen verwendet werden, da es dadurch zu einer schleichenden Ausweitung von Berechtigungen kommen kann. Auf diese Weise besteht auch das Risiko, dass kritische Berechtigungen in vermeintlich harmlose Fachrollen eingebaut werden, obwohl sie für die vorgesehenen Tätigkeiten im System gar nicht erforderlich sind.

Voraussetzungen für belastbare Ergebnisse

Für eine belastbare Berechtigungsanalyse ist deshalb ein sauberer Testaufbau erforderlich. Der zu prüfende Use Case sollte vorab eindeutig definiert werden. Darüber hinaus sollten Berechtigungstests nach Möglichkeit mit eigens dafür vorgesehenen Testbenutzern und auf den konkreten Use Case abgestimmten Rollen durchgeführt werden. Bei der Bewertung von Analyseergebnissen sollten insbesondere folgende Fragen berücksichtigt werden:

Use Case: Welcher fachliche Prozess oder Prozessschritt wurde konkret getestet und ist das in der Berechtigungsanalyse als fehlend ausgewiesene Berechtigungsobjekt für diesen Use Case fachlich überhaupt plausibel?
Auswirkung auf den getesteten Prozess: Hatte die fehlgeschlagene Berechtigungsprüfung tatsächlich Auswirkungen auf den getesteten Prozess?
Negativtest: Kann der getestete Prozess auch ohne Vergabe des fraglichen Berechtigungsobjekts erfolgreich ausgeführt werden?

Auf diese Weise lässt sich feststellen, welche Berechtigungen für einen fachlichen Prozess tatsächlich erforderlich sind und welche lediglich im technischen Ablauf geprüft werden.

Fazit

Werkzeuge wie SU53 und STAUTHTRACE leisten einen wichtigen Beitrag zur technischen Analyse von Berechtigungsprüfungen in SAP. Ihre Ergebnisse müssen jedoch immer im fachlichen Kontext interpretiert werden. Nur wenn technischer Prüfablauf, fachlicher Use Case und konkreter Testaufbau gemeinsam betrachtet werden, lassen sich Rollen präzise und im Sinne der Minimalberechtigung gestalten und unnötige Berechtigungsausweitungen vermeiden.

(Unautorisierte) Datenzugriffe über RFC-Verbindungen vom Typ H

Gerald Schrott — Tue, 02 Jun 2026 07:51:11 GMT

Die Prüfung von RFC-Verbindungen in einem ABAP-System ist ein altes aber weiterhin aktuelles und sicherheitsrelevantes Thema. Während in der Vergangenheit hier der Fokus auf Verbindungen vom Typ 3 oder L lag (RFC-Verbindungen zum Aufruf von Funktionsbausteinen im Zielsystem), wird in diesem Artikel gezeigt, dass auch Verbindungen vom Typ H zum Aufruf von HTTP-Services zu unautorisierten Datenzugriffen führen kann, und dies umso mehr, da in S/4 HANA-Systemen über den Einsatz von Fiori-Apps immer mehr auf der HTTP-Kommunikation basierende Funktionen zum Einsatz kommen.

HTTP-Services in der Transaktion SICF

Die Services werden über die Transaktion SICF im Zielsystem aktiviert und allgemein administriert. Von hier lassen sich mit den entsprechenden Berechtigungen die einzelnen Services auch direkt starten (siehe Abb. 1), das Ergebnis ist in Abb. 2 zu sehen.

Konfigurationen im Startsystem

In der Transaktion SM59 werden in einem Startsystem entsprechende RFC-Verbindungen vom Typ H angelegt. Neben den Zielsystem-Daten (ermittelbar über TA SMICM SPRINGEN – SERVICES im Zielsystem) kann hier ein Pfadpräfix gesetzt werden (siehe Abb. 3), das später bei jedem Aufruf eines Services über diese Schnittstelle automatisch vor den Aufrufpfad gesetzt wird. Damit wird also grundsätzlich der Funktionsumfang dieser Schnittstelle auf die später benötigten Services eingeschränkt.

Die Eingabe eines möglichst kleinen Ausschnitts aus der Service-Hierarchie im Feld Pfadpräfix trägt also wesentlich zur Härtung dieser Schnittstelle bei.

Auf dem Register „Anmeldung & Sicherheit“ werden in gewohnter Weise beispielsweise Benutzername und Kennwort hinterlegt (siehe Abb. 4):

Im Gegensatz zur Nutzung von Funktionsbausteinen, kann hier im Startsystem kein Service direkt gestartet und dadurch im Zielsystem remote ausgeführt werden. Es muss in irgendeiner Form Programmlogik vorhanden sein, um den gewünschten Service über die definierte Schnittstelle zu nutzen. „Dank“ KI stellt dies aber heutzutage keine große Herausforderung dar.

In diesem Fall wurde ein kleines ABAP-Programm erstellt, das über den bereits im Zielsystem direkt getesteten Service „info“ und über die zuvor definierte Schnittstelle aus dem Zielsystem die Systemdaten ausliest und aufbereitet darstellt (dies ist nur ein harmloses Beispiel 😊).

Konfigurationen im Zielsystem

Damit Services im Zielsystem gestartet werden können, müssen diese aktiviert sein. dies lässt sich beispielsweise über die Tabelle ICFSERVLOC feststellen (siehe Abb. 5).

Weiterhin muss der Schnittstellenbenutzer über das Berechtigungsobjekt S_SERVICE oder S_START auf diese Services berechtigt sein. Die benötigte Berechtigung ist abhängig von der Art des Services, so wird beispielsweise zur Ausführung eines OData-Services vom Typ V.2 das Objekt S_SERVICE, und für OData Services vom Typ V.4 das Objekt S_START benötigt.

Fazit

Die klassischen Methoden um von außen kommend Funktionen remote in einem Zielsystem auszuführen, sind Funktionsbausteine und HTTP-Services. Beides Objektarten können über Schnittstellen mit hinterlegten Anmeldeinformationen aus einem Startsystem heraus ausgeführt werden.

Generell gilt, dass in einem Produktivsystem die Berechtigungen auf den Objekten S_RFC (remote-Aufruf von Funktionsbausteinen) und S_START/ S_SERVICE (Aufruf von HTTP-Services) nur restriktiv zu vergeben sind.

Darüber hinaus sollten in einem Produktivsystem nur benötigte HTTP-Services aktiviert sein.

RFC-Verbindungen vom Typ H aus unsicheren Startsystemen heraus mit hinterlegten Anmeldeinformationen auf sensible Zielsystem zeigend sind möglichst zu vermeiden, zumindest aber über das Pfadpräfix (und natürlich über die Berechtigungen des Schnittstellenbenutzers) stark einzuschränken.

SAP Security in Einzelhaft

Timo Müller — Fri, 29 May 2026 10:08:33 GMT

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.¹

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.² 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

Im Rahmen einer S/4HANA-Transformation werden Rollen neu geschnitten, Fiori-Kataloge aufgebaut, Prozesse harmonisiert. Gleichzeitig führt die IT eine neue ITSM- und Workflow-Plattform ein – für Access Requests, Joiner-Mover-Leaver-Prozesse, Change Governance.

Was auf dem Papier zusammengehört, läuft in der Realität aneinander vorbei.

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.³

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.⁴

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.⁵

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

Gemeinsamen Control-Design-Ansatz etablieren

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

SAP-embedded Controls ins Kontrollinventar aufnehmen

Nicht als technischen Anhang, sondern als dokumentierte und überwachbare Kontrollbausteine mit Verantwortlichen, Testverfahren und Nachweis-Logik. Einbettung der Kontrollen in den Mitigationsprozess.

3

Gemeinsames übergreifendes Reporting schaffen

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.⁶

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.

Hast du in deiner 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

Die KI macht’s: Warum ich als SAP-Prüfer eigentlich nichts mehr tun muss

Johannes Schwarzenberger — Fri, 29 May 2026 10:03:34 GMT

Stell dir vor, es ist 2026 und dein Job erledigt sich von selbst. Mein Kaffee dampft, der Monitor leuchtet, und während ich entspannt aus dem Fenster schaue, rattert die Prüfung im Hintergrund einfach durch.

Meine neue Hypothese lautet: „KI löst ab jetzt alle meine Probleme – ich lehne mich zurück und schaue nur noch zu.“ Klingt nach dem ultimativen Traum für jeden Revisor und IT-Prüfer, oder? In manchen Momenten fühlt es sich tatsächlich genauso an. Der größte Gamechanger meines Jobs war der endgültige Abschied von Excel-Frust, SVERWEIS-Wahnsinn und starren Access-Datenbanken. Heute beschreibe ich einer KI mein Problem in natürlicher Sprache, und Sekunden später liefert sie mir ein fertiges Python-Skript für die Massendatenanalyse komplexer SAP-Tabellen.

Wenn die Seifenblase platzt: Die Realität im Backend

Doch wer schon einmal versucht hat, eine komplexe Berechtigungsprüfung oder eine kritische SoD-Analyse (Segregation of Duties) rein maschinell abzubilden, merkt schnell: Die KI hat eine dunkle Seite.

Die Iterations-Hölle: Es gibt Tage, da verbringe ich mehr Zeit damit, den Code der KI zu korrigieren und „nachzubessern“, als wenn ich die Abfrage gleich manuell in SQL gebaut hätte. Manchmal verfängt man sich in einer Feedback-Schleife mit der Maschine, die am Ende mehr Nerven kostet, als sie spart. Aus „schnell mal prüfen“ wird ein zweistündiges Prompt-Engineering-Dilemma.
Die Falle der „Denk-Faulheit“: Ich erwische mich selbst dabei, wie ich die KI frage, bevor ich mein eigenes Gehirn einschalte. Das ist brandgefährlich. In der SAP-Security ist blindes Vertrauen der Anfang vom Ende. Wer nur noch fragt, statt zu verstehen, verliert die Fähigkeit, Anomalien intuitiv zu erkennen.
Die Verifizierungs-Pflicht: Wenn ich nicht mehr im Detail nachvollziehen kann, was der generierte Python-Code im Hintergrund eigentlich tut, bin ich kein Prüfer mehr. Ich werde zum bloßen „Knöpfchendrücker“. Ein Revisor, der seine eigenen Werkzeuge nicht erklären kann, hat vor dem Prüfungsausschuss (und dem Gesetzgeber) einen schweren Stand.

Fazit: Das schärfste Werkzeug im Koffer

Mein Fazit nach dem Härtetest 2026: KI ist kein „Rundum-sorglos-Paket“, sondern ein extrem scharfes Skalpell. Wenn du weißt, wie man es führt, schneidet es durch riesige Datenberge wie durch Butter und legt Schwachstellen offen, die wir früher schlicht übersehen hätten. Wenn du jedoch unvorsichtig bist, schneidest du dich selbst – oder schlimmer: Du wiegst dich in einer falschen Sicherheit.

Ich nutze KI heute massiv, um meine Ergebnisse zu präzisieren und Zeit für die wirklich komplexen Architektur-Fragen zu gewinnen. Aber ich denke heute kritischer nach als je zuvor. Die KI liefert die Daten, aber die Bewertung bleibt menschlich.

Lass uns darüber diskutieren!

Wie sieht dein Arbeitsalltag aus? Bist du schon im „Prompt-Loop“ gefangen und lässt die KI das Denken übernehmen, oder nutzt du die gewonnene Zeit für die strategischen Fragen der SAP-Security?

Lass uns auf der IBS Security Convention 2026 darüber diskutieren – Auge in Auge, mit echtem Fachwissen und ganz ohne Halluzinationen. Ich freue mich auf den Austausch!

Über 20 Jahre Regelwerks-Know-how. Und plötzlich kann’s jeder?

Rebecca Zimmer — Fri, 29 May 2026 10:01:51 GMT

Jeder baut jetzt Risikoregelwerke. Wir haben damit angefangen, als SAP noch jung war.

Viele neue Anbieter betreten den Markt. Doch zwischen „Regelwerk“ und einem echten Qualitätsstandard liegt mehr als ein Jahrzehnt Arbeit.

Der Markt für SAP-Risikoregelwerke ist in Bewegung. Wer heute in eine Ausschreibung schaut oder auf LinkedIn scrollt, begegnet einer wachsenden Zahl von Anbietern, die mehr oder weniger selbstbewusst Regelwerke für SAP-Berechtigungen und GRC-Prozesse anbieten. Grundsätzlich gut – denn es zeigt, wie kritisch das Thema SAP-Security in deutschen Unternehmen inzwischen wahrgenommen wird.

Aber was steckt wirklich dahinter – und worauf kommt es an, wenn der Druck von allen Seiten wächst?

Der Druck auf Unternehmen wächst dabei von mehreren Seiten gleichzeitig: Regulatorische Anforderungen nehmen zu, Audit-Anforderungen werden strenger, und die Haftungsrisiken auf Management-Ebene steigen. SAP-Sicherheit verschiebt sich damit zunehmend von einem technischen IT-Thema hin zu einem unternehmensweiten Risiko – das auf dem Tisch des CIO, CISO und CFO liegt.

Die entscheidende Frage lautet dabei nicht mehr, ob ein Unternehmen ein Regelwerk hat – sondern ob es dem Standard entspricht. Viele bestehende Lösungen weisen kritische Schwächen auf:

Unzureichende Regelwerkstiefe – nur Berechtigungsobjekte, keine funktionalen Abfragen
Fehlende Aktualisierung – kein Schritt halten mit neuen SAP-Releases und Technologien
Keine externe Validierung – Scheinsicherheit statt geprüfter Qualität

Das Ergebnis: Risiken bleiben unentdeckt oder werden falsch bewertet. Und das ist kein IT-Problem – das ist ein Unternehmensrisiko.

Drei Dinge müssen deshalb klar sein:

SAP-Sicherheit ist ein unternehmenskritisches Risiko – kein IT-Thema.
Die Qualität des Risikoregelwerks entscheidet darüber, ob Risiken tatsächlich erkannt werden.
Das Know-how hinter den IBS Schreiber Risikoregelwerken aus über 20 Jahren lässt sich nicht einfach kopieren.

Was wirklich hinter einem Risikoregelwerk steckt

Ein SAP-Risikoregelwerk ist kein Produkt, das man in ein paar Monaten aus dem Boden stampft. Es ist das Ergebnis von Tausenden Stunden aus realen Prüfungsprojekten, intensiver Auseinandersetzung mit SAP-Systemarchitekturen und einer stetigen Arbeit an Regularik wie IDW PS 880 – und einem Team, das diese Erkenntnisse Jahr für Jahr in belastbares, systematisches Wissen überführt hat.

Bei IBS Schreiber haben wir dieses Wissen über mehr als 20 Jahre aufgebaut. Das Ergebnis: über 2.700 vordefinierte Risikoregelwerke, die auf Knopfdruck einsatzbereit sind – zertifiziert nach IDW PS 880 und halbjährlich aktualisiert. Kein anderer Anbieter im deutschsprachigen Markt kann auf eine vergleichbare institutionelle Grundlage verweisen.

Schnell gebaut ist nicht dasselbe wie erprobt

Neue Marktteilnehmer versprechen oft ähnliche Ergebnisse – schlanker, günstiger, moderner. Das klingt verlockend. Doch in der Revision und im Compliance-Umfeld ist Verlockung ein schlechter Ratgeber.

Was in einem Jahresabschluss-Audit, einer NIS2-Prüfung oder einem internen Kontrollsystem (IKS) zählt, ist Belastbarkeit. Prüfregeln, die nicht funktional auf Transaktionsebene, Fiori-App-Ebene und Berechtigungsobjekt-Ebene greifen, erzeugen False Positives – und senken die Akzeptanz in den Fachbereichen bis auf null. Das haben wir in Projekten erlebt, wenn Unternehmen von solchen Lösungen zu uns gewechselt sind.

Warum wir den Standard setzen – und ihn halten

Das Regelwerk-Know-how von IBS Schreiber ist institutionell verankert. Es liegt nicht in einzelnen Köpfen, sondern in einem eingespielten Team, in unserer Software CheckAud® und der Easy Content Solution – und in einem kontinuierlichen Qualitätsprozess, der externe Zertifizierung einschließt.

Was das konkret bedeutet:

Detailtiefe, die zählt: Unsere Regelwerke berücksichtigen nicht nur Berechtigungsobjekte, sondern alle relevanten Transaktionen, Fiori-Apps und Reports – systemspezifisch und customizing-genau. Das reduziert Fehlalarme und erhöht die Qualität jeder Prüfung.

Externe Zertifizierung nach IDW PS 880: Unsere Produkte sind durch Wirtschaftsprüfer nach diesem Standard zertifiziert. Das ist keine Selbstauskunft, das ist unabhängige Qualitätskontrolle.

SAP S/4HANA®-ready: Unsere Regelwerke passen sich automatisch an die SAP Simplification List und die Fiori Apps Library an. Migration bedeutet keinen Neustart – sondern Kontinuität.

Halbjährlicher Updateservice: SAP entwickelt sich ständig weiter. Unser Regelwerk auch – mit einem festen Rhythmus, der Aktualität garantiert.

Die Fragen, die du dir stellen solltest

Wenn du als CISO, Revisor oder IT-Verantwortlicher ein SAP-Risikoregelwerk bewertest, lohnt sich ein nüchterner Blick auf einige Kernfragen: Wie viele Prüfregeln stehen zur Verfügung – und auf welcher Grundlage wurden sie entwickelt? Gibt es eine externe Zertifizierung? Wie wird das Regelwerk bei SAP-Releases und neuen Technologien aktualisiert? Und: Wer steht dahinter – eine Einzelperson oder ein eingespieltes Team mit jahrzehntelanger Prüfungserfahrung?

Die Antworten auf diese Fragen sind entscheidend. Nicht für das nächste Quartal – sondern für die Verlässlichkeit deiner SAP-Security-Architektur über Jahre.

Fazit: Wissen, das bleibt. Regelwerke, die wirken.

Wir beobachten den Markt, begrüßen den Wettbewerb – und bleiben gelassen. Denn eines lässt sich nicht beschleunigen: der Aufbau von Regelwerk-Know-how, das echten Prüfungsanforderungen standhält.

IBS Schreiber ist seit über 20 Jahren der Qualitätsstandard für SAP-Risikoregelwerke im deutschsprachigen Markt. Das ist kein Anspruch – das ist ein Ergebnis.

Du willst sehen, was ein Regelwerk mit echter Tiefe leistet? Vereinbare einen kostenfreien Termin oder teste unsere Lösung 30 Tage unverbindlich.