FAQ: SoD & Funktionstrennung im SAP
Autor: Tobias Harmes | 18. April 2019
Wenn IT-Prüfer und Auditoren ihren Abschluss-Bericht vorlegen, gibt es regelmäßig lange Gesichter. Weil schon wieder so viele SoD-Konflikte gefunden worden sind. Doch ein Teil des Frustes entsteht auch, weil niemand so richtig weiß, was eigentlich SoDs sind oder wie man damit umgehen sollte. Der Beitrag geht auf die häufigsten Fragen zu diesem Begriff ein.
… als Podcast
Für unterwegs – den Podcast abonnieren: https://rz10.de/podcast
… auf YouTube
YOUTUBE-CHANNEL abonnieren: https://www.youtube.com/c/Rz10De_ms
Feedback? harmes@rz10.de
Was heißt SoD eigentlich?
Oft fällt der Begriff SoD oder SoD-Konflikt. Das ist die Abkürzung von Segregation of Duties und das wiederum heißt Funktionstrennung. Ein SoD-Konflikt ist daher ein Funktionstrennungskonflikt, also die Feststellung, dass anscheinend die Funktionstrennung hier nicht eingehalten wird.
Wofür benötigt man SoD noch mal?
Eine SoD oder Funktionstrennung verhindert, dass eine Person allein die Möglichkeit hat, eine kompletten Geschäftsprozess in betrügerischer Absicht zu durchlaufen. Das lässt sich an einem Beispiel verdeutlichen.
Herr Müller arbeitet in der Buchhaltung der Firma XY. Dort betreut er die Kundendaten und kann Rechnungen sowohl schreiben, als auch ändern oder stornieren. Außerdem verarbeitet er den eingehenden und ausgehenden Zahlungsverkehr auf Kunden- und Lieferantenseite.
Das Problem: Herr Müller hat so viele Rechte, dass er mit krimineller Energie unkompliziert Geld von der Firma XY stehlen kann. Das funktioniert, indem er eingehende Zahlungen auf private Konten einzahlt, die vorher als Firmenkonten ausgegeben wurden, und die zugehörigen Rechnungen löscht. Der Kunde wird nichts merken, da sein Rechnungsbetrag auf dem vermeintlichen Konto bei der Firma XY eingegangen ist. Die Firma XY wird das zunächst auch nicht bemerken, da Herr Müller alle zugehörigen Daten und Rechnungen löschen konnte.
In der Praxis kommt es leider immer wieder zu solchen oder ähnlichen Fällen, welche den Unternehmen hohe Betrugsverluste bescheren. Solch ein Risiko ließe sich vermeiden, wenn die einzelnen Schritte innerhalb des Buchhaltungsprozesses klar durch Rollenverteilung getrennt werden. Herr Müller sollte also keine Rechnungen schreiben und diese auch ändern oder stornieren können. Um so etwas aufzudecken, gibt es Listen mit Funktionstrennungskonflikten.
Wer ist für SoD / Funktionstrennung verantwortlich und zuständig?
Bei vielen SAP Systemanalysen und Prüfungen erlebe ich es, dass die Teilnehmer in Workshops beim Thema Funktionstrennung genervt die Augen rollen. „Dafür ist …“ zuständig. Und das kann dann wahlweise die Revision, die IT, die Anwendungsbetreuung oder der Fachbereich sein. Wer hat recht? Aus meiner Sicht alle!
Optimalerweise fühlt sich der Fachbereich bzw. der Verantwortliche für den jeweiligen Bereich (z.B. Finanzen, Logistik, etc.) dafür verantwortlich. Das bedeutet jedoch nicht, dass diese Person alles selbst machen muss oder kann. Auf Konflikte oder Probleme diesbezüglich weist oft ein Auditor im Rahmen einer IT-Prüfung für ein Jahresabschluss hin. Das kann ein interner Mitarbeiter aus der Revision oder ein externer Wirtschaftsprüfer sein. Sowohl bei der proaktiven Erkennung als auch bei der Bearbeitung von vorliegenden Feststellungen hat es sich bewährt, dass sowohl Fachbereich, Applikationsbetreuung als auch IT eine Aufgabenteilung machen. So kann der Fachbereich am besten entscheiden, welche Personen welche Aufgaben innerhalb eines Geschäftsprozesses übernehmen können. Und vor allem, welche Personen bestimmte Prozessschritte auf keinen Fall durchführen dürfen.
Die IT kann dagegen Tools bereitstellen und Schulungen durchführen in der systematischen Analyse von kritischen Funktionstrennungskonflikten. Die Applikationsbetreuung kann Hilfestellung geben in der Abarbeitung von gefundenen Konflikten.
Muss jeder Funktionstrennungskonflikt bereinigt werden?
Nein. Viele Prüfungen erzeugen große Mengen von Feststellungen hinsichtlich Funktionstrennungskonflikten. Zu jedem gefundenen Konflikt gehört aber auch die Bewertung des Risikos. Wenn an einem Außenstandort nur ein Buchhalter arbeitet, ist eine Trennung von Stammdaten- und Buchungstätigkeiten manchmal nicht möglich. In solchen Situationen kann das Risiko auch akzeptiert werden („Wir haben das Risiko verstanden, machen aber nichts.“) oder kompensiert werden („Wir haben das Risiko verstanden und wir erzeugen als kompensierende Maßnahme eine Belegliste am Ende des Monats zur Prüfung durch einen dritten.“).
Eine weitere Variante ist die Nutzung eines Super-User-Management oder Privileged Access Management. Ich können haben Anwender im Tagesgeschäft normale Berechtigungen und nur wenn es eine besondere Situation (z.B. Jahresabschluss) erfordert, bekommt der Anwender für einen genau überwachten Zeitraum erhöhte Berechtigungen. So kann das Risiko aus den Berechtigungen minimiert werden.
Welche SoD-Konflikte/Funktionstrennungskonflikte gibt es?
Die Liste an potenziellen SoD-Konflikten ist schier endlos. Das bedeutet aber nicht, dass für jedes Unternehmen jeder mögliche Konflikt gleich kritisch ist. Funktionstrennungskonflikte werden oft beschrieben mit den beiden Seiten des Konflikts. Jeder Seite für sich ist ein an sich nicht kritischer Geschäftsprozessschritt – aber wenn eine Person beide Seiten darf, dann ergibt sich daraus eventuell ein Risiko. Jedes Jahr wird die Liste an möglichen Funktionstrennungskonflikten etwas länger – weil jemand einen neuen Weg gefunden hat auf kreative Art und Weise aus dem System Geld zu schöpfen.
Hier ein paar Beispiele für Funktionstrennungskonflikte, die auf viele Unternehmen mit typischen ERP-Prozessen zutreffen:
- Hauptbuchstammdaten pflegen und Buchungen im Hauptbuch vornehmen
- Zahlungsrelevante Daten zum Lieferanten pflegen und Buchung Lieferantenrechnung
- (Fiktiven) Lieferanten pflegen und Bestellung pflegen und Wareneingang anlegen, ändern, buchen
Die Funktionstrennungskonflikte ergeben sich meistens durch das, was der jeweilige Anwender im System machen _könnte_ – nicht durch das was er tagtäglich macht. Mitarbeiter, die im Laufe der Karriere durch drei Abteilungen gegangen sind ohne ihre alten Berechtigungen im SAP zu verlieren sind oft wandelnde Funktionstrennungskonflikte. Und das oft auch ohne, dass sie es selbst wissen.
Wie finde ich heraus, ob Mitarbeiter einen SoD-Konflikt/Funktionstrennungskonflikt haben?
Vor einigen Jahren war der einzige Weg das herauszufinden den Business-Champion, den Keyuser und FI-Druiden zu fragen. Heutzutage gibt es durch die hohe Integration der Geschäftsprozesse kaum eine Möglichkeit durch den Blick auf das Arbeitsumfeld zu sagen, ob eine jeweilige Person einen Funktionstrennungskonflikt hat. Deshalb verwenden Prüfer und Revisionen in den letzten Jahren verstärkt Werkzeuge, die durch automatisierte Prüfläufe gegen große Regelwerk Funktionstrennungskonflikte aufdecken. Um zu vermeiden, dass man durch Prüfungen „kalt erwischt wird“, gehen immer mehr Unternehmen dazu über, selbst die Prüfung durch geeignete Tools regelmäßig durchzuführen. Durch so ein SoD-Tool können Schwachstellen innerhalb der Rollenverteilung aufgedeckt und korrigiert werden.
Wie funktioniert ein SAP SoD-Prüfwerkzeug?
Ein effektives SoD- Prüfwerkzeug unterstützt ein Unternehmen dabei, Richtlinien und Kontrollen innerhalb der Governance-, Risk Management- und Compliance-Programme durchzuführen. Diese Tools können in das SAP installiert werden oder von außerhalb das SAP zugreifen. Sie haben in der Regel große Regeldatenbanken, die viele bekannte Funktionstrennungskonflikte in technischen Details ausdrücken. Ein Prozessschritt wie „Beleg buchen“ wird dann zur Transaktion FB01 mit entsprechenden Berechtigungsobjektwerten und Aktivitäten. Diese Regelwerke können dann in frei konfigurierbaren Abstand auf Benutzer und Berechtigungen angewendet werden. Als Ergebnis wird eine Liste von Konflikten erzeugt – also Feststellungen wo bei einer Rolle oder einem Benutzer eine kritsche Kombination von Funktionen festgestellt worden ist. Diese Liste muss dann in Zusammenarbeit zwischen Fachbereich, Applikationsbetreuung und IT abgearbeitet werden.
Wie das funktionieren kann, habe ich im Beitrag SoD-Troubleshooting exemplarisch beschrieben.
Welche Schwierigkeiten gibt es bei der Implementierung von SAP SoD-Prüfwerkzeugen?
Bei der Implementierung von SAP SoD-Prüfwerkzeugen ist Effizienz einer der größten Stolpersteine. Sind viele manuelle Prozesse im Spiel, kann SoD zu einem kostspieligen und schwerfälligen Unterfangen werden. Bei großen Unternehmen mit mehreren Standorten kann die Einbindung von SAP SoD-Tools durchaus schwierig werden. Hierbei ist es wichtig, dass die SAP SoD-Tools ideal auf die Prozessabläufe in den Finanzabteilungen abgestimmt sind und es ein klar definiertes Verständnis der beteiligten Rollen gibt.
Fazit
Alle Abteilungen müssen bei dem Thema Funktionstrennung zusammenarbeiten. Die Implementierung eines SAP SoD-Tools ist aus Gründen der Compliance sinnvoll und steuert einiges zur Gesamtsicherheit innerhalb der Unternehmenslandschaft bei. Notfall- / Super-User-Management Prozesse können helfen, auch schwierige Ausgangslagen regelkonform und sicher abzubilden. Zusätzliche Hinweise dazu finden Sie auch in unserem Webinar Last-Minute-Tipps, bevor die Prüfer kommen.
Weitere Informationen
https://rz10.de/sap-grc/sod-troubleshooting-funktionstrennungskonflikte-in-sap/
https://rz10.de/sap-berechtigungen/segregation-of-duties-mit-der-sap-transaktion-suim/
Unsere Workshops rund um das Thema SoD und Funktionstrennungen
Strategie Workshop SAP Berechtigungen: https://rz10.de/angebot/strategieworkshop-berechtigungen/
XAMS Starter Workshop: https://rz10.de/angebot/xams-starter-workshop/
2 Kommentare zu "FAQ: SoD & Funktionstrennung im SAP"
Klasse Beitrag! und Bitte weiter so :.)
Leider investieren die meisten Firmen kein Geld in proaktive Tools wie SOD-Prüfwerkzeuge oder ander sinnvolle Basis-Tools sondern bezahlen lieber teuere WiPrü-Gesellschaften wie die der Big4, welche noch nicht einmal alle schwere Verstöße gegen SOD, SOX und Change Management Regeln feststellen!
Hallo Herr Manner.
Danke für Ihr Feedback. Hier könnte tatsächlich bei vielen Unternehmen mehr auf Tools gesetzt werden. Zumindest bei den SAP Systemen mit dem höchsten Schutzbedarf.
Mit freundlichen Grüßen
Tobias Harmes