Publication

SAP® GRC Access Control 10.

0
Best-Practice-Leitfaden
zur Einführung der SAP-GRC-Lösungen
Deutschsprachige SAP-Anwendergruppe e.V.
VERSION 1.0
STAND 27. APRIL 2015
2

SAP® GRC Access Control 10.0

Best-Practice-Leitfaden
zur Einführung der SAP-GRC-Lösungen
VERSION 1.0
STAND 27. APRIL 2015
DSAG e. V.
Deutschsprachige SAP-Anwendergruppe
3
SAP® GRC ACCESS CONTROL 10.0 BEST-PRACTICE-LEITFADEN ZUR EINFÜHRUNG DER SAP-GRC-LÖSUNGEN VERSION 1.0, 27. APRIL 2015 © DSAG e. V.
Wir weisen ausdrücklich darauf hin, dass das vorliegende Dokument nicht jeglichen Regelungs-
bedarf sämtlicher DSAG-Mitglieder in allen Geschäftsszenarien antizipieren und abdecken kann.
Insofern müssen die angesprochenen Themen und Anregungen naturgemäß unvollständig bleiben.
Die DSAG und die beteiligten Autoren können bezüglich der Vollständigkeit und Erfolgsgeeignetheit
der Anregungen keine Verantwortung übernehmen. Sämtliche Überlegungen, Vorgehensweisen
und Maßnahmen hinsichtlich des Verhaltens gegenüber SAP verbleiben in der individuellen Eigen-
verantwortung jedes DSAG-Mitglieds. Insbesondere kann dieser Leitfaden nur allgemeine Anhalts-
punkte zu vertragsrechtlichen Themen geben und keinesfalls eine individuelle Rechtsberatung bei
der Verhandlung und Gestaltung von Verträgen durch IT-rechtliche Experten ersetzen.
© COPYRIGHT 2015 DSAG E.V.
HINWEIS:
Die vorliegende Publikation ist urheberrechtlich geschützt (Copyright). Alle Rechte liegen, soweit
nicht ausdrücklich anders gekennzeichnet, bei:
DEUTSCHSPRACHIGE SAP® ANWENDERGRUPPE E.V.

Altrottstraße 34 a
69190 Walldorf
Deutschland
Fon +49 (0) 6227 – 358 09 58
Fax +49 (0) 6227 – 358 09 59
www.dsag.de I [email protected]
Jede Verwertung außerhalb der engen Grenzen des Urheberrechts ist ohne Zustimmung der Urheber
unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen
und die Einspeicherung und Verarbeitung in elektronischen Systemen / digitalen Medien.
Die Autoren des vorliegenden Best-Practice-Leitfadens sind für Verbesserungs- sowie Änderungs- und
Ergänzungswünsche dankbar. Dies gilt sowohl für Vorschläge zur Vertiefung der einzelnen Kapitel als
auch für die Nennung von Beispielen aus konkreten Projekt- oder Prüfungserfahrungen.
Die Autoren des Prüfleitfadens sind für Kritik, Änderungs- und Ergänzungswünsche dankbar (bitte als
Beitrag im DSAGNet unter „Arbeitsgruppe GRC“ veröffentlichen).
4
INHALTSVERZEICHNIS
1. EINLEITUNG 7
2. ÜBERBLICK 8
3. GRC IM REGULATORISCHEN UMFELD 11
3.1. Deutscher Corporate Governance Kodex 12
3.2. Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) 13
3.3. IDW RS FAIT 1 14
3.6. IDW Prüfungsstandard PS 261 n.F. (u.a. internes Kontrollsystem) 16
3.7 IDW PS 330 18
3.8 IDW PS 980 19
3.9 Bundesdatenschutzgesetz (BDSG) 20
3.10 Bilanzrechtsmodernisierungsgesetz (BilMoG) 21
3.10.1 Lagebericht (§§ 289, 315 HGB n.F.) 21
3.10.2 Pflichten des Aufsichtsrates 21
3.10.3 Handlungsfelder für den Vorstand 22
3.11 Basel II 23
3.12 Basel III 24
3.13 Sarbanes-Oxley Act (SOX) 24
3.14 Normen (DIN ISO/IEC) 25
3.14.1 ISO/IEC 27001 25
3.14.2 ISO 27002 (vorher ISO 17799) 25
3.14.3 ISO 27005 25
3.14.4 Weitere Standards der ISO 2700x Reihe 25
3.14.5 Zertifizierung nach ISO 27001 auf Basis von IT-Grundschutz 26
4. RAHMENBEDINGUNGEN FÜR EIN ERFOLGREICHES GRC-PROJEKT 27

4.1 Zugriffsschutz ist Chefsache 27
4.1.1 Mittelstand 27
4.1.2 Großunternehmen / Konzerne 28
4.2 Motivation zum Einsatz von SAP GRC Access Control 30
4.3 Rahmenbedingungen / Erfolgsfaktoren 32
4.3.1 Top-Management 32
4.3.2 Betriebsrat 32
4.3.3 Wirtschaftsprüfer 33
4.3.4 Interne Revision 33
4.3.5 Internal Control / Risk Management 33
4.3.6 Compliance Officer 33
4.3.7 SAP-Basisbetreuung 34
4.3.8 SAP-Berechtigungsadministratoren 34
4.3.9 Organisationsabteilung 34
4.3.10 Schlüsselpersonen aus den Fachbereichen 35
4.3.11 Endanwender 35
5 FUNKTIONALER UND TECHNOLOGISCHER VERGLEICH
ZU SAP GRC ACCESS CONTROL 5.3 36
5.1 Komponentenstruktur und Namensgebung 36
5.2 Neue technologische Plattform 38
5.3 Vereinheitlichte Stammdaten, Architektur (auch bzgl. Process Control etc.) 39
5.4 Funktionale Änderungen und Erweiterungen 40
5.5 Bewertung 42
5
INHALTSVERZEICHNIS
6 EINFÜHRUNGSMANAGEMENT (ROLLOUT INKL. USERTRAINING) 43
6.1 PHASE: Projektvorbereitung („Strategie & Planung“) 44
6.1.1 Risikobasiertes Berechtigungsmanagement 44
6.1.2 Abgrenzung von Verantwortungsbereichen 45
6.1.3 Change Management Policy + Risikopolicy 48
6.1.4 Reporting / Monitoring 50
6.1.4.1 Reporting der Risikoanalyse 51
6.1.4.2 Berichte der Zugriffsanforderung 51
6.1.4.3 EAM-Verwaltungsberichte 51
6.1.5 Operative Einzelaufgaben und Projektplanung 51
6.2 PHASE Sollkonzeption („Business Blueprint und Design“) 57
6.2.1 Organisatorisch/technischer Betrieb 57
6.2.2 Architektur & Technologie: 58
6.2.2.1 Harmonisierte Konfigurations- und Stammdatenverwaltung 59
6.2.2.2 Vereinheitlichtes User Interface & Bedienung 59
6.2.3 Risikoanalyse und Bereinigung 59
6.2.4 Unternehmensweites Rollenkonzept 61
6.2.4.1 Gesetzeskonformes Benutzermanagement (User Lifecycle Management) 66
6.2.5 Notfallzugriff (Emergency Access Management) 66
6.2.6 Testvorbereitung für alle Komponenten 68
6.2.6.1 Festlegung der Testskripte 71
6.3 PHASE Realisierung („Implementierung“) 72
6.3.1 Architektur & Technologie 72
6.3.2 Risikoanalyse und Bereinigung 72
6.3.3 Unternehmensweites Rollenkonzept 73
6.3.4 Notfallzugriff (Emergency Access Management) 74
6.3.5 Testdurchführung 75
6.3.6 Fachbereichs-Training 76
6.4 PHASE Produktionsvorbereitung („Rollout“) 78
6.5 PHASE Produktivstart („Support“) 79
6.6 Implementierungsszenario 80
7 WEITERFÜHRENDE DOKUMENTATION 82
8 PRAXISBERICHT THYSSENKRUPP AG 83
9 ANHANG: 88
9.1 Migration von SAP GRC Access Control 5.3 88
9.2 Integration GRC Access Control/Identity Management 91
9.3 Ausblick SAP GRC Access Control 10.1 98
9.4 Dezentrales Notfallbenutzerverfahren, Aufnahme des DBTABLOGs 102
9.5 Funktionen für HANA-Applikationen 102
6
ABBILDUNGSVERZEICHNIS:
Abbildung 1: Die GRC 10.0 Anwendungslandschaft 8
Abbildung 2: SAP GRC Access Control Applikationen 9
Abbildung 3: SAP GRC Access Control Komponenten 10
Abbildung 4: Elemente des internen Kontrollsystems 17
Abbildung 5: Einstiegsbild GRC Access Control 37
Abbildung 6: Customizing mit dem SAP Implementation Guide 39
Abbildung 7: Anforderungen an ein Berechtigungssystem 52
Abbildung 8: Aggregierung von Einzelrollen zu Sammelrollen (Arbeitsplätze) 65
Abbildung 9: Beispiel Testskript 70
Abbildung 10: Fehlerklassifizierung 75
Abbildung 11: Zielarchitektur einer zentralen Risikoanalyseplattform
mit dezentralen Teams in den lokalen Einheiten 84
Abbildung 12: Vorgehen zum Aufbau des GRC Access Control Competence Centers –
Zusammenarbeit mit Piloten 84
Abbildung 13: Programmplanung mit Pilotunternehmen 85
Abbildung 14: Datenmigrationsapplikation in AC5.3 SP13 (Java) 88
Abbildung 15: Integrationsbild der verschiedenen Funktionen von SAP GRC Access Control
und einem Identity Management-System am Beispiel SAP NetWeaver
Identity Management 92
Abbildung 16: Sandwich-Architektur 94
Abbildung 17: Beispiel einer Tail-Architektur 95
Abbildung 18: Beispiel für ein einblendbares Side-Panel 98
Abbildung 19: Vereinfachter Antrag 100
Abbildung 20: Root Cause Analysis mit Drill-Down hinunter auf Berechtigungswerebene
und Simluation eines Rollenentzugs 101
Abbildung 21: Beispiel einer Risikoanalyse von HANA-Privilegien 102
7
1. EINLEITUNG
Aufgrund der umfangreichen Neuerungen bei SAP GRC Access Control 10.0 war es notwendig, den
DSAG Best-Practice-Leitfaden zu GRC Access Control 5.3 umfassend zu aktualisieren.
Dieser Leitfaden geht auf die einzelnen Komponenten von SAP GRC Access Control ein und stellt
insbesondere die Möglichkeiten zur Einführung innerhalb der Unternehmensorganisation einschließ-
lich des hierfür erforderlichen Projektmanagements im Sinne von Best-Practice-Empfehlungen vor.
Die Best-Practice-Empfehlungen erheben keinen Anspruch auf Vollständigkeit, sondern geben

die Projekt- und Praxiserfahrung der Autoren wieder. Insofern ist das Autorenteam auch dankbar
für jede Art von Anregungen und Hinweisen zur weiteren Vervollständigung und Verbesserung des
Leitfadens.
Dieser Leitfaden soll insbesondere den Unternehmen eine Hilfestellung bieten, die sich mit ver-
schiedensten Anforderungen gesetzlicher, fachlicher und organisatorischer Art bei der Gestaltung
der Zugriffskontrollen auf ihre Programme und Daten konfrontiert sehen. Hinzuweisen ist hier
insbesondere auf die Anforderungen des Bilanzrechtmodernisierungsgesetzes (BilMoG) mit der
Gestaltung und Überwachung von internen Kontroll- und Risikomanagementsystemen, die Min-
destanforderungen an das Risikomanagement von Finanzinstituten und Versicherungen (MaRisk)
sowie generell auf Anforderungen eines modernen Compliance Managements bei der Sicherstel-
lung von wirksamen Funktionstrennungsprinzipien innerhalb der Unternehmensorganisation.
Die Autoren sind Mitglieder der Arbeitsgruppe Governance, Risk Management, Compliance
(GRC - www.dsag.de/AG-GRC) innerhalb des DSAG-Arbeitskreises "Revision/Risikomanagement
(www.dsag.de/AK-Revision). Die Verantwortung für den Inhalt tragen die Autoren. Die redaktionelle
Bearbeitung und das Layout liegen bei der DSAG.
@ Copyright 2015 der Autoren:
› Siegfried Filla PricewaterhouseCoopers AG WPG
› Marco Geisenberger Protiviti GmbH
› Rolf-Udo Gilbert dobis GmbH & Co. KG
› Markus Griem SAP Deutschland SE & Co. KG
› Matthias Middrup ThyssenKrupp AG
› Birger Tödtmann SAP Deutschland SE & Co. KG
› Dr. Alexander Ziesemer ThyssenKrupp AG

8
2. ÜBERBLICK
SAP hat die Standardsoftwarelösungen für Governance, Risk Management und Compliance (GRC)
in der SAP GRC Suite gebündelt (siehe Abb. 1).
GRC 10.0 Landscape Synopsis
Front End Client optional

Adobe Flash SAP GUI http SAP NW Portal 7.02
Player 7.10 GRC Portal
Web Browser CRA* Content
http DIAG
Recommended for GTS/SPL optional

SAP NetWeaver 7.02 RFC AC, PC & RM RFC SAP NetWeaver 7.02
Search/Classification (Software Component: Search/Classification
GRC Search GRCFND_A) GRC Search
GTS optional
Required for GTS
(Software Component:
SAP NW7.02 RFC SLL-LEG) SAP ERP (4.6C – 7.1)
Adobe Document NW Fuction Modules
Services Nota Fiscal Eletronica (Plug-in: GRCPINW)
Required for Nota Fiscal E. SLL-NFE) RFC HR Function Modules
SAP NetWeaver PI RFC PC Automated Cntris
Content Lifecycle Plug-in: GRCPIERP)
Nota Fiscal Content Management (CLM)
GTS Plug-in
(Plug-in: SLL-PI)
optional
SAP NetWeaver
Identity Management AS ABAP 7.02 optional
Solutions web Non-SAP Business
(SAP or Non-SAP) Adapter
services SAP GRC Suite 10.0 Applications
*Crystal Reports Adapter and Active Component Framework – needed for viewing GRC Crystal Reports
Abbildung 1: Die GRC 10.0 Anwendungslandschaft
Die GRC-Suite der SAP umfasst Anwendungen zur Sicherstellung einer unternehmensweiten
Governance. Sie sollen die Zugriffssicherheit der Unternehmensdaten verbessern, Risiken der
Geschäftstätigkeit besser erkennen und steuern sowie alle Voraussetzungen zur Erreichung einer
unternehmensweiten Governance und Compliance schaffen.
Die GRC-Suite umfasst folgende Applikationen:

› SAP Access Control
› SAP Access Approver Mobile App
› SAP Global Trade Services
› SAP Process Control
› Mobile App SAP GRC Policy Survey
› SAP Risk Management
› SAP Environment, Health & Safety Management
› SAP Sustainability Performance Management
9
SAP GRC Access Control 10.0 ist mit den einzelnen Komponenten in der folgenden Abbildung
dargestellt.
Front End Client optional

NWBC 3.0 SAP NW Portal 7.02
Adobe Flash SAP GUI http GRC Portal Content
Player 7.10 (Business Package)
Web Browser Nota Fiscal Eletronica
(eSignature)
http DIAG Content Lifesycle
Management (CLM)
optional
SAP NetWeaver BI 7.06 RFC AC, PC & RM
(target) (Software Component:
GRC BI Content GRCFND_A)
Global Trade Services

SAP NetWeaver (Software Component: SAP ERP
AS JAVA 7.02 RFC (4.6C – ECC 6.0)
SLL-LEG)
Adobe Document NW Fuction Modules
Server Nota Fiscal Eletronica (Plug-in: GRCPINW)
optional SLL-NFE) HR Function Modules
SAP NetWeaver 7.02 PC Automated Ctris
Search/Classification optional Plug-in: GRCPIERP)
Content Lifecycle
GRC Search GTS Plug-in
Management (Software
Comonent: POASBC) (Plug-in: SLL-PI)
optional
RFC SAP NetWeaver
SAP NetWeaver PI optional
AS ABAP 7.02
Non-SAP Business
Nota Fiscal Content Adapter
SAP GRC Application 10.0 Applications
Abbildung 2: SAP GRC Access Control Applikationen
SAP GRC Access Control ermöglicht eine präventive Zugriffskontrolle zur Sicherstellung der Funk-
tionstrennung in SAP- und Non-SAP-Systemen (z.B. Oracle und PeopleSoft). Kritische Berechtigun-
gen können rasch entdeckt und eingeschränkt bzw. kontrolliert werden. Darüber hinaus wird ein
standardisiertes und transparentes Berechtigungsmanagement unterstützt. Mit dieser Anwendung
kann somit eine ordnungsmäßige und sichere Zugriffskontrolle organisiert werden, wobei die nach-
folgend aufgeführten Module zunehmend integriert eingesetzt werden:
10
Die folgende Abbildung zeigt eine Übersicht der Kernelemente von SAP GRC Access Control im
Zeitablauf der verschiedenen SAP-Lösungen:
VIRSA/SAP (2005) GRC Access Control 5.3 GRC Access Control 10.0
Compliance Calibrator Risk Analysis and Access Risk

Remediation (RAR) Analysis (ARA)
Firefighter Superuser Privilege Emergency Access

Management (SPM) Management (EAM)
Access Enforcer Compliant User Access Request

Provisioning (CUP) Management (ARM)
Role Expert Enterprise Role Business Role

Management (ERM) Management (BRM)
Abbildung 3: SAP GRC Access Control Komponenten
› Access Risk Analysis (ARA)

Diese Software unterstützt eine sog. „Real-Time Compliance“ mit dem Ziel, Sicherheits- und
Kontrollverletzungen zu verhindern, bevor sie auftreten. Grundlage ist eine Bibliothek mit Funk-
tionstrennungsregeln (segregation of duties) für SAP und zum Teil auch Non-SAP Systeme.Durch
einen sog. „Audit Trail“ und verbesserte Optionen zur Risikominimierung will man schnellere und
effizientere Reaktionen der Kontrollinstanzen ermöglichen.
› Emergency Access Management (EAM)

Das Notfalluser-Management kann zentral durchgeführt werden. Mittels eines standardisierten
Workflows können die Logeinträge der Notfalluser-Aktivitäten kontrolliert werden.
› Access Request Management (ARM)

Ermöglicht eine ordnungsmäßige Benutzeradministration mit automatisierten Antrags- und
Genehmigungsprozessen innerhalb einer Real-Time-Risikoüberwachung.
› Business Role Management(BRM)

BRM ermöglicht ein standardisiertes, unternehmensweites Rollenmanagement. Geschäfts-
prozess-Owner können funktionale Rollen vorgeben, die dann von der IT-Benutzeradministration
technisch umgesetzt werden können. Der gesamte Änderungsdienst wird aufgezeichnet und ist
prüfbar.
11
3. GRC IM REGULATORISCHEN UMFELD
In Deutschland haben sich Gesetzgeber, das Institut der Wirtschaftsprüfer in Deutschland (IDW)
sowie das DRSC schon seit vielen Jahren mit den Themen Governance, Risk Management und
Compliance beschäftigt. Hervorzuheben sind dabei die Regelungen zum Deutschen Corporate
Governance Kodex1, zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG2), zum
internen Kontrollsystem von Unternehmen3 und zum Bilanzrechtsmodernisierungsgesetz (BilMoG4)
Den Maßstab für die Umsetzung regulatorischer Anforderungen in deutschen Unternehmen bilden
im Rahmen der Prüfung der Finanzberichterstattung durch Wirtschaftsprüfer im Wesentlichen
folgende gesetzliche Regelungen und Prüfungsstandards des Instituts der Wirtschaftsprüfer (IDW):
› die handels- und steuerrechtlichen Vorschriften zur Ordnungsmäßigkeit der Buchführung

(§§ 238 f. und 257 HGB sowie §§ 145 bis 147 AO),
› die IDW-Stellungnahme zur Rechnungslegung „Grundsätze ordnungsmäßiger Buchführung bei

Einsatz von Informationstechnologie“ (IDW RS FAIT 1, Stand: 24. September 2002),
› die IDW-Stellungnahme zur Rechnungslegung „Grundsätze ordnungsmäßiger Buchführung bei

Einsatz von Electronic Commerce“ (IDW RS FAIT 2, Stand: 29. September 2003)
› der IDW Prüfungsstandard „Feststellung und Beurteilung von Fehlerrisiken und Reaktionen des
Abschlussprüfers auf die beurteilten Fehlerrisiken“ (IDW PS 261 n.F., Stand 01.03.2012),
› der IDW-Prüfungsstandard zur „Abschlussprüfung bei Einsatz von Informationstechnologie“

(IDW PS 330, Stand: 24. September 2002) sowie
› die von der Arbeitsgemeinschaft für Wirtschaftliche Verwaltung e.V. erarbeiteten „Grundsätze
ordnungsmäßiger DV-gestützter Buchführungssysteme (GoBS)“ sowie das dazu ergangene
Schreiben des Bundesministers der Finanzen vom 7. November 1995.
Die vorgenannten gesetzlichen Vorschriften und fachlichen Stellungnahmen sind generell zu beach-
tende Anforderungen und beziehen sich überwiegend auf rechnungslegungsrelevante Sachverhalte.
Gleichwohl sind sie aufgrund gleicher Kontrollziele geeignet, auch Aussagen zur Ordnungsmäßigkeit
bei Fragestellungen außerhalb der Buchführung zu treffen.
Darüber hinaus können im Einzelfall weitere Prüfungsstandards anzuwenden sein (z.B. für Dienst-
leistungsunternehmen oder Shared Service Center, die administrative Aufgaben u.a. im Bereich
der Benutzeradministration und des Zugriffsschutzes übernommen haben (z.B. der IDW-Prüfungs-
standard zur „Prüfung des internen Kontrollsystems bei Dienstleistungsunternehmen für auf das
Dienstleistungsunternehmen ausgelagerte Funktionen“ (IDW PS 951, Stand: 19. September 2007).
Deutscher Corporate Governance Kodex (DCGK Juni 2014)

1
Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) 1. Mai 1998

2
IDW-Prüfungsstandard „Feststellung und Beurteilung von Fehlerrisiken und Reaktionen des Abschlussprüfers auf die
3
beurteilten Fehlerrisiken“ (IDW PS 261, Stand 6. September 2006).

Bilanzrechtsmodernisierungsgesetz (BilMoG) vom 25. Mai 2009 (BGBl. I S. 1102)
4
12
Dieser GRC Best-Practice-Leitfaden möchte lediglich in Kurzform auf wesentliche zu beachtende

regulatorische Anforderungen insbesondere in jüngerer Zeit eingehen und erhebt deshalb auch
keinen Anspruch auf Vollständigkeit der hier vorgestellten Regelungen. Wer sich intensiver mit
diesem Thema beschäftigen möchte kann dies u.a. in folgenden Büchern nachlesen:
› SAP® Access Control, 2008, ISBN 978-3-8362-1141-3

› Governance, Risk und Compliance mit SAP, 2008, ISBN 978-3-8362-1140-6
› SOX Compliance with SAP Treasury and Risk Management, 2008, ISBN 978-1-59229-200¬4
› CobiT und der Sarbanes-Oxley Act, 2007, ISBN 978-3-8362-1013-3
› Sicherheit und Berechtigungen in SAP-Systemen, 2005, ISBN 978-3-89842-670-1
Als ergänzende Lektüre empfehlen wir den DSAG-Datenschutzleitfaden SAP ERP 6.0 sowie den
Prüfleitfaden SAP ERP 6.0 (beide im Mitgliederportal DSAGNet).
Alle DSAG-Leitfäden finden Sie unter folgendem Link: www.dsag.de/Handlungsempfehlungen
3.1. DEUTSCHER CORPORATE GOVERNANCE KODEX
Die Themen Risikomanagement und Compliance sind im DCGK in folgenden Abschnitten wie folgt
angesprochen:
› Abschnitt 3 „Zusammenwirken von Vorstand und Aufsichtsrat“

Der Vorstand informiert den Aufsichtsrat regelmäßig, zeitnah und umfassend über alle für das
Unternehmen relevanten Fragen der Planung, der Geschäftsentwicklung, der Risikolage, des
Risikomanagements und der Compliance.
› Abschnitt 4 „Vorstand“
Der Vorstand hat für die Einhaltung der gesetzlichen Bestimmungen und der unternehmens-
internen Richtlinien zu sorgen und wirkt auf deren Beachtung durch die Konzernunternehmen
hin (Compliance).
Der Vorstand sorgt für ein angemessenes Risikomanagement und Risikocontrolling im Unter-
nehmen.
› Abschnitt 5 „Aufsichtsrat“
Der Aufsichtsratsvorsitzende soll mit dem Vorstand, insbesondere mit dem Vorsitzenden bzw.
Sprecher des Vorstands, regelmäßig Kontakt halten und mit ihm Fragen der Strategie, der
Planung, der Geschäftsentwicklung, der Risikolage, des Risikomanagements und der Compliance
des Unternehmens beraten.
› Abschnitt 5.3 „Bildung von Ausschüssen“

Der Aufsichtsrat soll einen Prüfungsausschuss (Audit Committee) einrichten, der sich ins-
besondere mit der Überwachung des Rechnungslegungsprozesses, der Wirksamkeit des
internen Kontrollsystems, des Risikomanagementsystems und des internen Revisions-
systems, der Abschlussprüfung …… sowie der Compliance, befasst.
13
3.2. GESETZ ZUR KONTROLLE UND TRANSPARENZ IM UNTERNEHMENS-
BEREICH (KONTRAG)
Kern des KonTraG ist eine Vorschrift, die Unternehmensleitungen dazu zwingt, ein unternehmens-
weites Früherkennungssystem für Risiken (Risikofrüherkennungssystem) einzuführen und zu be-
treiben sowie Aussagen zu Risiken und zur Risikostruktur des Unternehmens im Lagebericht des
Jahresabschlusses der Gesellschaft zu veröffentlichen.
Die Einrichtung eines Risikomanagementsystems (RMS) ist unmittelbar nur für Aktiengesellschaften
gesetzlich vorgeschrieben. Das RMS muss demnach gewährleisten, dass die das Unternehmen
möglichen bedrohenden Risiken vollständig erfasst (KonTraG – Erfassung der Risiken), beherrscht
und gesteuert werden. Dies heißt konkret, dass das RMS Maßnahmen festlegen muss, die eine
effiziente Identifikation, Analyse und Bewertung der Risiken ermöglichen (Risikostrategie).
Schließlich lässt sich hieraus die weitere inhaltliche Anforderung ableiten, dass es einer unterstüt-
zenden zielorientierten Koordination von Risikostrategie, Informationsversorgung, Überwachung
und Steuerung durch ein Controlling oder spezieller ein sog. „Risikocontrolling“ bedarf, denn dies
bildet eine unabdingbare Voraussetzung für die Errichtung und Erhaltung der Reaktionsfähigkeit
und Koordinationsfähigkeit des Unternehmens und ist daher als Element eines Risikomanagement-
systems und eines Überwachungssystems unverzichtbar.
5
IDW-Stellungnahme zur Rechnungslegung „Grundsätze ordnungsmäßiger Buchführung bei Einsatz von
Informationstechnologie“ (IDW RS FAIT 1, Stand: 24. September 2002).
14
3.3. IDW RS FAIT 15
IDW RS FAIT 1 definiert u.a. Sicherheitsanforderungen an rechnungslegungsrelevante Daten. Im

Einzelnen werden gefordert:
IT-Systeme haben daher die folgenden Sicherheitsanforderungen zu erfüllen:
› Vertraulichkeit verlangt, dass von Dritten erlangte Daten nicht unberechtigt weitergegeben oder
veröffentlicht werden. Organisatorische und technische Maßnahmen – wie bspw. Verschlüsse-
lungstechniken – umfassen u.a. Anweisungen zur Beschränkung der Übermittlung personen-
bezogener Daten an Dritte, die verschlüsselte Übermittlung von Daten an berechtigte Dritte, die
eindeutige Identifizierung und Verifizierung des Empfängers von Daten oder die Einhaltung von
Löschfristen gespeicherter personenbezogener Daten.
› Integrität von IT-Systemen ist gegeben, wenn die Daten und die IT-Infrastruktur sowie die IT-
Anwendungen vollständig und richtig zur Verfügung stehen und vor Manipulation und ungewollten
oder fehlerhaften Änderungen geschützt sind. Organisatorische Maßnahmen sind geeignete Test-
und Freigabeverfahren. Technische Maßnahmen sind z.B. Firewalls und Virenscanner. Die Ord-
nungsmäßigkeit der IT-gestützten Rechnungslegung setzt voraus, dass neben den Daten und
IT-Anwendungen auch die IT-Infrastruktur nur in einem festgelegten Zustand eingesetzt wird
und nur autorisierte Änderungen zugelassen werden.
› Verfügbarkeit verlangt zum einen, dass das Unternehmen zur Aufrechterhaltung des Geschäfts-
betriebs die ständige Verfügbarkeit der IT-Infrastruktur, der IT-Anwendungen sowie der Daten
gewährleistet. Zum anderen müssen die IT-Infrastruktur, die IT-Anwendungen und Daten sowie
die erforderliche IT-Organisation in angemessener Zeit funktionsfähig bereitstehen. Daher sind
z.B. geeignete Back-up-Verfahren zur Notfallvorsorge einzurichten. Maßnahmen zur Sicherung
der Verfügbarkeit sind erforderlich, um den Anforderungen nach Lesbarmachung der Buchfüh-
rung gerecht zu werden.
› Autorisierung bedeutet, dass nur im Voraus festgelegte Personen auf Daten zugreifen können
(autorisierte Personen) und dass nur sie die für das System definierten Rechte wahrnehmen
können. Diese Rechte betreffen das Lesen, Anlegen, Ändern und Löschen von Daten oder die
Administration eines IT-Systems. Dadurch soll ausschließlich die genehmigte Abbildung von
Geschäftsvorfällen im System gewährleistet werden. Geeignete Verfahren hierfür sind physische
und logische Zugriffsschutzmaßnahmen (z.B. Passwortschutz). Organisatorische Regelungen
und technische Systeme zum Zugriffsschutz sind die Voraussetzung zur Umsetzung der erfor-
derlichen Funktionstrennungen. Neben Identitätskarten werden zukünftig biometrische
Zugriffsgenehmigungsverfahren an Bedeutung gewinnen.
5
IDW-Stellungnahme zur Rechnungslegung „Grundsätze ordnungsmäßiger Buchführung bei Einsatz von Informationstech-
nologie“ (IDW RS FAIT 1, Stand: 24. September 2002).
15
› Authentizität ist gegeben, wenn ein Geschäftsvorfall einem Verursacher eindeutig zuzuordnen ist.
Dies kann bspw. über Berechtigungsverfahren geschehen. Beim elektronischen Datenaustausch
bieten sich für eine Identifizierung des Partners bspw. digitale Signatur- oder passwortgestützte
Identifikationsverfahren an.
› Unter Verbindlichkeit wird die Eigenschaft von IT-gestützten Verfahren verstanden, gewollte
Rechtsfolgen bindend herbeizuführen. Transaktionen dürfen durch den Veranlasser nicht
abstreitbar sein, weil bspw. der Geschäftsvorfall nicht gewollt ist.
3.4. IDW RS FAIT 26
Risiken können sich innerhalb des E-Commerce insbesondere aus der fehlenden Kontrolle über
den Datentransfer im Internet ergeben:
› Unzureichender Schutz vor Verfälschung (Verlust der Integrität)

› Unsichere Datenverschlüsselung (Verlust der Vertraulichkeit)
› Gefährdung der Verfügbarkeit (Verlust der Verfügbarkeit)
› Unwirksame Authentisierungsmechanismen (Verlust der Authentizität)
› Unauthorisierte Zugriffe mit Hilfsprogrammen (Verlust der Autorisierung)
› Unzureichende Protokollierung der Transaktionsdaten (Verlust der Verbindlichkeit)
Mangelnde Authentizität und Autorisierung bewirken bspw., dass Geschäftsvorfälle inhaltlich un-
zutreffend abgebildet werden (Verletzung des Grundsatzes der Richtigkeit). Die Autorisierung soll
insbesondere sicherstellen, dass keine unberechtigten bzw. keine fiktiven Geschäftsvorfälle in das
System eingehen. Es ist festzulegen, wann, wie und durch wen die Autorisierung erfolgt.
Autorisierungsverfahren sind Teil der Verfahrensdokumentation und für zehn Geschäftsjahre auf-
bewahrungspflichtig.
Im Rahmen des durch den Anwender zu erstellenden Sicherheitskonzeptes sind auch für E-Com-
merce- Anwendungen Sicherungsmaßnahmen abzuleiten, die physische Sicherungsmaßnahmen
und logische Zugriffskontrollen sowie Datensicherungs- und Auslagerungsvefahren umfassen.
IDW-Stellungnahme zur Rechnungslegung „Grundsätze ordnungsmäßiger Buchführung bei Einsatz von Informations-
6
technologie“ (IDW RS FAIT 1, Stand: 24. September 2002).

16
3.5 IDW RS FAIT 37

Diese IDW Stellungnahme zur Rechnungslegung konkretisiert die aus § 257 HGB resultierenden
Anforderungen an die Archivierung aufbewahrungspflichtiger Unterlagen und veranschaulicht
die in der IDW Stellungnahme zur Rechnungslegung: Grundsätze ordnungsmäßiger Buchführung
beim Einsatz von Informationstechnologie (IDW RS FAIT 1, Tz. 60 ff.)2 dargestellten Aufbewahrungs-
pflichten beim Einsatz von elektronischen Archivierungssystemen.
Technische und organisatorische Risiken aus dem Einsatz von Archivierungsverfahren können die
Sicherheit und Ordnungsmäßigkeit der Rechnungslegung beeinträchtigen:
› Unzureichende organisatorische Festlegungen und Verfahrensanweisungen können die Nach-

vollziehbarkeit und Anwendbarkeit der Archivierungsverfahren gefährden.
› Mangelhafte Zugriffskontrollen innerhalb des Archivierungssystems ermöglichen die miss-
bräuchliche oder unauthorisierte Einsichtnahme der archivierten Dokumente und Daten.
› Durch Veränderungen, Manipulationen oder Löschung der archivierten Daten und Dokumente
wird deren Integrität, Authentizität oder Verfügbarkeit verletzt.
3.6 IDW PRÜFUNGSSTANDARD PS 261 N.F.

(U.A. INTERNES KONTROLLSYSTEM)
Der vorgenannte Prüfungsstandard wurde am 01.03.2012 verabschiedet und ersetzt den IDW
Prüfungsstandard 261 „Feststellung und Beurteilung von Fehlerrisiken und Reaktionen des
Abschlussprüfers auf die beurteilten Fehlerrisiken“ (IDW PS 261) i.d.F. vom 09.09.2009.
Gem. IDW PS 261 n.F. werden unter einem internen Kontrollsystem die vom „Management im
Unternehmen eingeführten Grundsätze, Verfahren und Maßnahmen (Regelungen) verstanden, die
gerichtet sind auf die organisatorische Umsetzung der Entscheidungen des Managements
› zur Sicherung der Wirksamkeit und Wirtschaftlichkeit der Geschäftstätigkeit (hierzu gehört auch
der Schutz des Vermögens, einschließlich der Verhinderung und Aufdeckung von Vermögens-
schädigungen),
› zur Ordnungsmäßigkeit und Verlässlichkeit der internen und externen Rechnungslegung sowie
› zur Einhaltung der für das Unternehmen maßgeblichen rechtlichen Vorschriften.“8
IDW Stellungnahme zur Rechnungslegung: Grundsätze ordnungsmäßiger Buchführung beim Einsatz elektronischer
7
Archivierungsverfahren (IDW RS FAIT 3)

8
IDW PS 261 n.F., Tz. 19
17
Als organisatorische Sicherungsmaßnahmen sind z.B. definiert „laufende, automatische Einrich-
tungen… Sie umfassen fehlerverhindernde Maßnahmen, die sowohl in die Aufbau- als auch die
Ablauforganisation eines Unternehmens integriert sind und ein vorgegebenes Sicherheitsniveau
gewährleisten sollen (z.B. Funktionstrennung, Zugriffsbeschränkungen im IT-Bereich, Zahlungs-
richtlinien).“9
Damit sind u.a. alle im Rahmen von Zugriffsberechtigungen getroffenen Maßnahmen Teil des internen
Kontrollsystems und damit auch wesentlicher Bestandteil der Umsetzung der Compliance-Anfor-
derungen durch das Management eines Unternehmens.
Internes Kontrollsystem(IKS)
Internes Steuerungssystem Internes Überwachungssystem
Prozessintegrierte Prozessunabhängige
Überwachungsmaßnahmen Überwachungsmaßnahmen
Organisatorische
Interne
Sicherungsmaß- Kontrollen Sonstige
Revision
nahmen
Abbildung 4: Elemente des internen Kontrollsystems
Die Regelungsbereiche des internen Kontrollsystems werden lt. IDW PS 261 n.F. wie folgt definiert:
Neben den o.g. organisatorischen Sicherungsmaßnahmen sind auch Kontrollen prozessintegrierte
Überwachungsmaßnahmen, wie z.B. die Überprüfung der Vollständigkeit und Richtigkeit verarbeite-
ter Daten (u.a. Änderungen von Berechtigungen und Benutzerprofilen).
9
IDW PS 261 n.F., Tz. 20
18
3.7 IDW PS 33010

Dieser Prüfungsstandard beschäftigt sich im Wesentlichen mit den Anforderungen an ordnungs-
mäßige und sichere Rechnungslegungssysteme und der Sicherstellung der Vollständigkeit, Richtig-
keit, der in diesen System erfassten, verarbeiteten und ausgegebenen Daten.
In diesem Zusammenhang werden u.a. folgende Risiken des IT-Einsatzes hervorgehoben:
› IT-Anwendungsrisiken (fehlende oder nicht aktuelle Verfahrensregelungen und -beschreibungen,

unzureichende Zugriffsberechtigungskonzepte und Zugriffskontrollsysteme)
› IT-Geschäftsprozessrisiken (u.a. unzureichende Transparenz der Datenflüsse, unzureichende

Integration der Systeme oder mangelhafte Abstimm- und Kontrollverfahren in Schnittstellen
zwischen Teilprozessen mit der Gefahr, dass IT-Kontrollen bspw. Zugriffsrechte, Datensiche-
rungsmaßnahmen, nur hinsichtlich der Teilprozesse, jedoch nicht hinsichtlich der Gesamt-
prozesse wirksam werden.)
› IT-Geschäftsprozessrisiken (u.a. unzureichende Transparenz der Datenflüsse, unzureichende

Integration der Systeme oder mangelhafte Abstimm- und Kontrollverfahren in Schnittstellen
zwischen Teilprozessen mit der Gefahr, dass IT-Kontrollen bspw. Zugriffsrechte, Datensiche-
rungsmaßnahmen, nur hinsichtlich der Teilprozesse, jedoch nicht hinsichtlich der Gesamtpro-
zesse wirksam werden.)
Wesentliches Beurteilungsobjekt sind im Hinblick auf SAP GRC Access Control die logischen
Zugriffskontrollen.
Logische Zugriffskontrollen sind wesentliche Elemente der Datensicherheit und des Datenschut-
zes und Voraussetzung zur Gewährleistung der Vertraulichkeit. Die Sicherheitsanforderungen
Autorisierung und Authentizität bedingen zwingend logische Zugriffskontrollen:
› Implementierung eines organisatorischen Verfahrens zur Beantragung, Genehmigung und

Einrichtung von Benutzerberechtigungen in IT-Systemen
› Berechtigungen auf Betriebssystemebene (Anmeldung gegenüber Rechnern in einem Netzwerk)
› Rechte zur Ausführung von Transaktionen in einer IT-Anwendung.
Zugriffskontrollen sind als angemessen zu beurteilen, wenn sie geeignet sind sicherzustellen, dass
die Berechtigungsverwaltung und die eingerichteten Systemrechte den Festlegungen im Sicherheits-
konzept entsprechen und damit unberechtigte Zugriffe auf Daten sowie Programmabläufe zur
Veränderung von Daten ausgeschlossen sind. Zudem müssen Zugriffskontrollen so ausgestaltet
sein, dass sie die Identität des Benutzers eindeutig feststellen und nicht autorisierte Zugriffsver-
suche abgewiesen werden.
10
IDW-Prüfungsstandard zur „Abschlussprüfung bei Einsatz von Informationstechnologie“
(IDW PS 330, Stand: 24. September 2002)
19
3.8 IDW PS 98011
Am 11. März 2011 wurde vom Institut der Wirtschaftsprüfer (IDW) der Prüfungsstandard „Grundsätze
ordnungsmäßiger Prüfung von Compliance-Management-Systemen“ verabschiedet. Dieser Standard
ist erstmals für Prüfungen anzuwenden, die nach dem 30. September 2011 durchgeführt werden.
Dabei handelt es sich um freiwillige Prüfungen, d.h., es besteht derzeit keine Prüfungspflicht. Man
kann jedoch davon ausgehen, dass sich zunehmend Unternehmen einer Prüfung ihres CMS unter-
ziehen, um zumindest von Aufsichtsrats- oder Vorstandsseite nachzuweisen, dass alle Aufsichts-
pflichten erfüllt worden sind und man sich z.B. kein pflichtwidriges Verhalten nach § 93 Absatz 1 AktG
vorzuwerfen hat.
Der Prüfungsstandard legt einen einheitlichen Rahmen für Compliance-Management-Systeme

(CMS) fest. Damit gibt es jetzt erstmalig in Deutschland ein seitens der Wirtschaftsprüfung definier-
tes Rahmenkonzept mit Leitlinien und Vorgaben für Unternehmen, die sich zur Verbesserung ihrer
Compliance mit der Einrichtung eines Compliance-Management-Systems oder ähnlichen Strukturen
beschäftigen oder dies bereits weitgehend umgesetzt haben. Damit ist davon auszugehen, dass
durch diesen Prüfungsstandard auch eine zunehmende Standardisierung der Compliance-Organi-
sation erzielt wird und die Compliance-Aufgaben innerhalb der Corporate Governance deutscher
Unternehmen wirksam und nachhaltig erfüllt werden können.
Nachfolgend sind einige Kernelemente der Prüfung des Compliance-Management-Systems nach

dem Prüfungsstandard IDW PS980 dargestellt.
Audit Compliance-Management (nach IDW PS 980)
› Compliance-Management-System (CMS) ist ein Teilbereich des Risikomanagementsystems (RMS)
› IDW PS 980 ersetzt nicht

› die Prüfung des Risikofrüherkennungssystems nach § 317 Abs. 4 HGB (IDW PS 340)
› die Beurteilung des Risikomanagements von Kreditinstituten im Rahmen der Abschlussprüfung
(IDW EPS 525)
› Auftrags-(Prüfungs-)typen
› Prüfung der Konzeption des CMS
› Prüfung von Angemessenheit und Implementierung des CMS
› Prüfung von Angemessenheit, Implementierung und Wirksamkeit des CMS
›Prüfungsgebiete (Aufbau- und Funktionsprüfung abhängig vom Auftragstyp)

› Compliance-Kultur
- Grundlagen für die Angemessenheit und Wirksamkeit des CMS
- Grundeinstellung und Verhaltensweisen des Managements (Tone from the Top)
11
DW Prüfungsstandard: Grundsätze ordnungsmäßiger Prüfung von Compliance-Management-Systemen
(IDW PS 980, Stand: 11.03.2011)
20
› Compliance-Ziele
- Festlegung wesentlicher Ziele, die mit dem CMS erreicht werden sollen
- Festlegung wesentlicher Teilbereiche und in den Teilbereichen einzuhaltender Regeln
› Compliance-Organisation
- Rollen und Verantwortlichkeiten
- Aufbau- und Ablauforganisation
- Ressourcenplanung
› Compliance-Risiken
- Identifikation von wesentlichen Compliance-Risiken
- Systematische Risikoerkennung mit Risikobeurteilung
› Compliance-Programm
- Auf Grundlage der identifizierten Risiken werden Grundsätze und Maßnahmen eingeführt,
die risikominimierend wirken
› Compliance-Kommunikation
- Betroffene Mitarbeiter und ggfs. Dritte werden über das Compliance-Programm sowie Rollen/
- Verantwortlichkeiten informiert
- Festlegung eines Berichtsweges über identifizierte Risiken, festgestellte Regelverstöße sowie
- eingehende Hinweise
› Compliance-Überwachung und Verbesserung
- Überwachung der Angemessenheit und Wirksamkeit (inkl. Reporting)
- Voraussetzung: ausreichende Dokumentation
- Management trägt Verantwortung
Mittlerweile gibt es eine ganze Reihe namhafter Unternehmen, die entweder den vorgenannten
Standard als Orientierung für die Ausgestaltung ihres Compliance-Management-Systems nutzen
oder bereits ihr CMS nach diesem Standard zertifizieren lassen.
3.9 BUNDESDATENSCHUTZGESETZ (BDSG)
Gemäß § 9 BDSG sind zur Sicherstellung des Datenschutzes bei personenbezogenen Daten tech-
nische und organisatorische Maßnahmen erforderlich. Hinsichtlich der Zugriffskontrollen wird
gefordert, dass die zur Benutzung eines Datenverarbeitungssystems Berechtigten ausschließlich
auf die ihrer Zugriffsberechtigung unterliegenden Daten zugreifen können und dass personenbe-
zogene Daten bei der Verarbeitung, Nutzung und nach der Speicherung nicht unbefugt gelesen,
kopiert, verändert oder entfernt werden können (Zugriffskontrolle).
Ferner ist zu gewährleisten, dass personenbezogene Daten bei der elektronischen Übertragung
oder während ihres Transports oder ihrer Speicherung auf Datenträger nicht unbefugt gelesen,
kopiert, verändert oder entfernt werden können und dass überprüft und festgestellt werden kann,
an welchen Stellen eine Übermittlung personenbezogener Daten durch Einrichtungen zur Daten-
übertragung vorgesehen ist (Weitergabekontrolle).
21
Gem. Ziff. 5 der Anlage zu § 9 BDSG ist zu gewährleisten, dass nachträglich überprüft und fest-
gestellt werden kann, ob und von wem personenbezogene Daten in Datenverarbeitungssysteme
eingegeben, verändert oder entfernt worden sind (Eingabekontrolle).
Weiterhin ist lt. Ziff. 7 zu gewährleisten, dass personenbezogene Daten gegen zufällige Zerstörung
oder Verlust geschützt sind (Verfügbarkeitskontrolle).
Einzelheiten zum Datenschutz im SAP-Umfeld können Sie im DSAG Datenschutzleitfaden nachlesen.12
3.10 BILANZRECHTSMODERNISIERUNGSGESETZ (BILMOG)
Die neuen Bilanzierungsregelungen sind verpflichtend für Geschäftsjahre ab dem 1.1.2010 anzu-
wenden. Sie sind anzuwenden durch kapitalmarktorientierte (Konzern-)unternehmen im Sinne des
§ 264d HGB n.F.
Sie können freiwillig bereits für den Abschluss 2009 angewendet werden, jedoch nur als Gesamtheit.
Neben einer Vielzahl neuer HGB-Regelungen zur Bilanzierung und Bewertung innerhalb der
Rechnungslegung eines Unternehmens werden mit dem BilMoG auch wesentliche Vorgaben aus
EU-Recht (8. EU-Richtlinie) umgesetzt.
Auch das interne Kontrollsystem und das Risikomanagementsystem rücken durch BilMoG stärker
in den Blickpunkt von Vorständen und Aufsichtsräten und insofern stehen in den Unternehmen die
entsprechenden aufbau- und ablauforganisatorischen Fragestellungen (auch zu Themen wie Funk-
tionstrennung und sichere Berechtigungskonzepte und -systeme) im Fokus.
3.10.1 LAGEBERICHT (§§ 289, 315 HGB N.F.)
Im Lagebericht sind die wesentlichen Merkmale des rechnungslegungsbezogenen internen

Kontroll- (IKS) und Risikomanagementsystems (RMS) zu beschreiben.
3.10.2 PFLICHTEN DES AUFSICHTSRATES
Der Aufsichtsrat hat die Verpflichtung zur Überwachung folgender Bereiche:
› Rechnungslegungsprozess
› internes Kontrollsystem (IKS)
› Risikomanagementsystem (RMS)
› internes Revisionssystem (Interne Revision)
12
Leitfaden Datenschutz SAP ERP 6.0 (Stand 20. September 2009), Download über DSAGNet
22
Diese Überwachungspflichten werden dazu führen, dass sich Aufsichtsräte entsprechende Be-
richtswege mit wirksamen Überwachungsstrukturen einrichten und dies auch Auswirkungen auf
effiziente und effektive Kontrollen insbesondere in solchen Unternehmensbereichen haben wird,
die Daten zur Finanzberichterstattung beisteuern (insbesondere Rechnungs- u. Finanzwesen,
Personalwesen, Materialwirtschaft, Produktion, Vertrieb).
3.10.3 HANDLUNGSFELDER FÜR DEN VORSTAND
Der Vorstand trägt die Verantwortung für Einrichtung, angemessene Ausgestaltung und den
Nachweis der Wirksamkeit u.a. des IKS und des RMS. Dies erfordert eine Bestandsaufnahme der
vorhandenen Instrumente zum IKS/RMS:
› Systematische Aufnahme vorhandener wesentlicher Instrumente (u.a. Softwareunterstützung)

und deren Verzahnung
› Analyse der Angemessenheit, insbesondere der „Nachweisfähigkeit“
› Maßnahmen zur Verbesserung des IKS/RMS
Darüber hinaus ist ein Nachweis der Wirksamkeit von IKS/RMS zu führen:
› Externe Zertifizierung der internen Revision (IR)

› Etablierung eines Regelprozesses zum Monitoring der Wirksamkeit (Self Assessment,
Prüfungsplanung der IR, Prüfung durch Externe, Konsolidierung der Überwachungsergebnisse)
› Initiierung von Verbesserungsmaßnahmen bei festgestellten Schwächen
› Berichterstattung an den Aufsichtsrat
Durch eine möglichst integrierte Steuerung und Überwachung der Risiken und Kontrollen innerhalb
für das Unternehmen besonders kritischer Geschäftsabläufe mit Hilfe von SAP GRC Access Control,
Process Control und Risk Management kann ein effektives und effizientes Management der Risiken
und Kontrollen erreicht werden. Dies ist eine wesentliche Voraussetzung für die praktische Umset-
zung der BilMoG-Anforderungen an Vorstand und Aufsichtsrat im Rahmen der Überwachung des
internen Kontrollsystems und internen Risikomanagementsystems.
Eine der wesentlichen Maßnahmen zur Verbesserung des internen Kontrollsystems ist die Beseiti-
gung von Risiken aufgrund von fehlender oder unzureichender Funktionstrennung beim Daten- und
Programmzugriff (Stichwort: Segregation of Duties) und damit dem unkontrollierten, umfassenden
Zugriff auf wesentliche IT-Systeme zur Abwicklung wesentlicher finanzkritischer Geschäftsprozesse.
Eine unter IKS-Gesichtspunkten wirksame Funktionstrennung in der Ablauforganisation eines
Unternehmens lässt sich durch ein entsprechendes Benutzerkonzept mit auf den Arbeitsplatz zuge-
schnittenen Benutzerberechtigungen erreichen. SAP GRC Access Control ist das hierfür genutzte
Instrument innerhalb der SAP-und Non-SAP-Welt.
Der geschilderte Handlungsbedarf gilt übrigens nicht nur für große börsennotierte Unternehmen,
sondern ist auch für kapitalmarktorientierte Mittelstandsunternehmen verpflichtend, die ein funk-
tionierendes internes Kontrollsystem sicherstellen wollen.
23
3.11 BASEL II
Unter dem Begriff Basel II werden die Eigenkapitalvorschriften für Kreditinstitute zusammengefasst,
die vom Basler Ausschuss für Bankenaufsicht in den letzten Jahren vorgeschlagen wurden. Auf der
Grundlage der EU-Richtlinien 2006/48/EG und 2006/49/EG erfolgte in Deutschland die Umsetzung
mit Wirkung ab 1. Januar 2007 durch das Kreditwesengesetz, die Solvabilitätsverordnung und die
MaRisk (Mindestanforderungen an das Risikomanagement).
Die Rahmenvereinbarung von Basel II basiert auf den drei „Säulen“
› Mindestkapitalvorschriften (Berechnung einer angemessenen Eigenkapitalausstattung)

› aufsichtsrechtliche Überprüfungsverfahren
› Marktdisziplin (höheres Maß an Transparenz bei der Offenlegung von Informationen der Bank.
Sie verlangt die Offenlegung quantitativer und qualitativer Aspekte der von der Bank verwendeten
Methoden für das Management ihrer Eigenkapitalanforderungen.)
Kreditinstitute müssen zu jedem einzelnen Risikobereich (z.B. Kredit-, Markt-, operationelles

Risiko, Zinsänderungsrisiko des Anlagebuchs und Beteiligungspositionen) die internen Ziele und
Grundsätze des Risikomanagements beschreiben. Dazu gehören:
1. Strategien und Prozesse

2. Struktur und Organisation der relevanten Risikomanagement-Funktion
3. Art und Umfang der Risikomeldungen und/oder -messsysteme
4. Grundsätze der Absicherung und/oder Minderung von Risiken sowie Strategien und Prozesse zur
Überwachung der fortgesetzten Effektivität dieser Absicherungen/Risikominderungen
Innerhalb der Mindestanforderungen an das Risikomanagement (MaRisk) ist hinsichtlich der

internen Kontrollverfahren festgelegt, dass Adressausfallrisiken, Marktpreisrisiken, Zinsänderungs-
risiken, Liquiditätsrisiken und operationelle Risiken anhand wirksamer Risikosteuerungs- und
Controllingprozesse zu überwachen sind und darüber zu berichten ist. Im Zusammenhang mit
Basel III als Nachfolgeregelung von Basel II hat die BaFin am 14.12.2012 eine Überarbeitung der
MaRisk veröffentlicht (umzusetzen bis 31.12.2013). Erstmalig werden u.a. Governance-Regelungen
innerhalb eines Liquiditätstransferpreissystems gefordert (z.B. Funktionstrennung, Genehmigungs-
verfahren). Darüber hinaus wird die Risikocontrollingfunktion gestärkt und die Compliance-Funktion
aufgewertet.
24
3.12 BASEL III

Basel III ist ein auf Basel II aufbauendes, am 16.12.2010 final veröffentlichtes Regelwerk mit dem
Ziel, die Stabilität des Bankensektors durch verschiedene im Verhältnis zu Basel II verschärfte
Maßnahmen wesentlich zu verbessern:
1. Wesentlich höhere Anforderungen an Qualität und Quantität der Risikodeckungsmassen

2. Umfassendere Abdeckung von insbesondere Kapitalmarktrisiken
3. Erfüllung umfassender Liquiditätsanforderungen
Entscheidend für die organisatorische Umsetzung eines umfassenden Risikomanagements und

Controllings im Bankenbereich sind jedoch die bereits an anderer Stelle erläuterten Mindestan-
forderungen an das Risikomanagement (MaRisk), die spätestens bis zum 31.12.2013 durch die
Banken umzusetzen sind.13
3.13 SARBANES-OXLEY ACT (SOX)
SOX ist ein Oberbegriff für gesetzliche Anforderungen an interne Kontrollen der Finanzberichter-
stattung und betrifft alle an US-Börsen gelisteten Unternehmen. Insofern fallen auch deutsche
Unternehmen unter dieses US-Gesetz von 2002, sofern ihre Wertpapiere an einer US-Börse gelistet
sind. Unternehmen müssen gem. SOX nachweisen, dass wirksame interne Kontrollen (unterneh-
mensweite Kontrollen und Geschäftsprozesskontrollen) zur Sicherstellung einer zutreffenden und
vertrauenswürdigen Finanzberichterstattung eingerichtet sind. Dieser Nachweis ist durch das
Management gegenüber der amerikanischen Börsenaufsicht (SEC) zu erbringen und durch einen
Wirtschaftsprüfer zu bestätigen. Die mit der Überwachung der Einhaltung von SOX befasste
amerikanische Aufsichtsbehörde ist die PCAOB (Public Company Accounting Oversight Board).
Ein von der SEC und dem PCAOB empfohlener Standard zur Einrichtung und Überwachung inter-
ner Kontrollen ist das sog. COSO-Framework14, das detaillierte Kontrollstrukturen und Umset-
zungsvorschläge enthält, und in Deutschland in der Regel auch Maßstab für die Umsetzung der
US-amerikanischen Anforderungen ist. Zur Umsetzung der SOX-Anforderungen auf Kontrollen im
IT-Bereich hat sich das CoBiT-Rahmenwerk als hilfreich erwiesen. Eine entsprechende Gegenüber-
stellung von COSO-Regelungen zu den Kontrollempfehlungen von CoBiT wurde vom amerikani-
schen IT Governance Institute (ITGI) mit dem Leitfaden IT Control Objectives for Sarbanes-Oxley15
erstellt.
13
Siehe auch MaRisk-Novelle 2012 - Veröffentlichung der Endfassung „Anschreiben an die Verbände, Geschäftszeichen
BA 54-FR 2210-2012/0002, Bonn/Frankfurt a. M., 14. Dezember 2012“
14
COSO (Committee of Sponsoring Organizations of the Treadway Commission). Entsprechende Informationen und
Detailbeschreibungen des Internal Control Framework nach COSO sind u.a. über folgenden Link verfügbar:
http://www.coso.org/guidance.htm.
15
IT Control Objectives for Sarbanes-Oxley, The Role of IT in the Design and Implementation of Internal Control over Financial
Reporting, 2nd edition, Sept. 2006: http://www.itgi.org
25
3.14 NORMEN (DIN ISO/IEC)
3.14.1 ISO/IEC 27001
Die ISO/IEC 27001:2005 wurde aus dem britischen Standard BS 7799-2:2002 entwickelt und als in-
ternationale Norm erstmals am 15. Oktober 2005 veröffentlicht. Mit Ausgabe 9.2008 liegt die Norm
auch als DIN-Norm DIN ISO/IEC 27001 vor.
Der ISO-Standard 27001 „Information technology – Security techniques – Information security manage-
ment systems requirements specification“ ist der erste internationale Standard zum Informations-
sicherheitsmanagement, der auch eine Zertifizierung ermöglicht. ISO 27001 gibt auf ca. 10 Seiten
allgemeine Empfehlungen. In einem normativen Anhang wird auf die Controls aus ISO/IEC 27002
verwiesen. Die Leser erhalten aber keine Hilfe für die praktische Umsetzung.
3.14.2 ISO 27002 (VORHER ISO 17799)
Das Ziel von ISO/IEC ISO 27002 „Information technology – Code of practice for information security
management“ ist es, ein Rahmenwerk für das Informationssicherheitsmanagement zu definieren.
ISO 27002 befasst sich daher hauptsächlich mit den erforderlichen Schritten, um ein funktionie-
rendes Informationssicherheitsmanagement aufzubauen und in der Organisation zu verankern.
Die erforderlichen Informationssicherheitsmaßnahmen werden kurz auf den ca.100 Seiten des
ISO-Standards ISO/IEC 27002 angerissen. Die Empfehlungen sind auf Management-Ebene und
enthalten kaum konkrete technische Hinweise. Ihre Umsetzung ist eine von vielen Möglichkeiten,
die Anforderungen des ISO-Standards 27001 zu erfüllen.
3.14.3 ISO 27005
Dieser ISO-Standard „Information security risk management“ enthält Rahmenempfehlungen zum

Risikomanagement für Informationssicherheit. Unter anderem unterstützt er bei der Umsetzung
der Anforderungen aus ISO/IEC 27001. Hierbei wird allerdings keine spezifische Methode für
das Risikomanagement vorgegeben. ISO/IEC 27005 löst den bisherigen Standard ISO 13335-2 ab.
Dieser Standard, ISO 13335 „Management of information and communications technology security,
Part 2: Techniques for information security risk management“, gab Anleitungen zum Management
von Informationssicherheit.
3.14.4 WEITERE STANDARDS DER ISO 2700X REIHE
Die Normenreihe ISO 2700x wird voraussichtlich langfristig aus den ISO-Standards 27000 –27019
und 27030-27044 bestehen. Alle Standards dieser Reihe behandeln verschiedene Aspekte des
Sicherheitsmanagements und beziehen sich auf die Anforderungen der ISO 27001. Die weiteren
Standards sollen zum besseren Verständnis und zur praktischen Anwendbarkeit der ISO 27001
beitragen. Diese beschäftigen sich bspw. mit der praktischen Umsetzung der ISO 27001, also der
Messbarkeit von Risiken oder mit Methoden zum Risikomanagement.
26
3.14.5 ZERTIFIZIERUNG NACH ISO 27001 AUF BASIS VON IT-GRUNDSCHUTZ
Das Bundesamt für Sicherheit in der Informationstechnik bietet seit Januar 2006 die ISO 27001-
Zertifizierung auf der Basis von IT-Grundschutz an. Hierüber kann nachgewiesen werden, dass in
einem Informationsverbund die wesentlichen Anforderungen ISO 27001 unter Anwendung der IT-
Grundschutz-Vorgehensweise (BSI-Standard 100-2) und ggfs. einer ergänzenden Risikoanalyse
(BSI-Standard 100-3) umgesetzt wurden.
Nach Umsetzung aller für die Zertifizierung relevanten Maßnahmen kann die Institution einen beim
BSI lizenzierten ISO 27001-Auditor beauftragen, den Informationsverbund gemäß dem Prüfschema
des BSI zu überprüfen. Die Ergebnisse dieser unabhängigen Prüfung werden in einem Auditreport
festgehalten. Ein ISO 27001-Zertifikat auf der Basis von IT-Grundschutz kann zusammen mit der
Einreichung des Auditreports beim BSI beantragt werden. Nach Prüfung des Reportes durch Experten
des BSI erteilt die Zertifizierungsstelle das Zertifikat, das ebenso wie die Auditor-Testate vom BSI
veröffentlicht wird. Alle zertifizierungsrelevanten Informationen wie das Zertifizierungsschema und
die Namen der lizenzierten Auditoren sind öffentlich verfügbar und können unter www.bsi.bund.de/
gshb/zert eingesehen werden.
27
4. GRC IM REGULATORISCHEN UMFELD
4.1 ZUGRIFFSSCHUTZ IST CHEFSACHE
Insbesondere aufgrund zunehmend heterogener Systemlandschaften in den Unternehmen mit den

neuen Herausforderungen durch mobile Endgeräte und dem Thema Cloud-Computing haben die
Risiken des Datenmissbrauchs weiter zugenommen. Zugriffssicherheit bei Anwendungen und Daten
ist insofern in allen Unternehmensgrößen eines der Prio-Themen innerhalb der IT-Sicherheit und
des Datenschutzes.
Leider gilt dies anscheinend noch nicht für die Mittelstandsunternehmen. Nach einer europäischen
Studie der PricewaterhouseCoopers AG16 machen nur 13 % der befragten Firmen das Thema Infor-
mationssicherheit zur Chefsache. Datensicherheitsrisiken werden demnach vom Management noch
weitgehend ignoriert. Darüber hinaus gehen die Unternehmen das Thema technologisch an mit der
Prämisse, dass man Informationssicherheit allein mit dem Einsatz geeigneter Tools lösen kann.
Dies gelingt aber in der Regel nicht, da vielfach mit den Fachbereichen abgestimmte Einsatzkon-
zepte fehlen.
Nachstehend einige „Best-Practice-Hinweise“ der Unternehmen, die in der Studie gut abgeschnitten
haben:
› Die Unternehmensführung kümmert sich selbst um das Thema Datensicherheit.

› Teams mit Mitarbeitern aus verschiedenen Abteilungen arbeiten laufend an einer Optimierung.
› Es besteht eine IT-Sicherheitsstrategie, deren Erfolg laufend überprüft wird.
Insofern ist insbesondere der Mittelstand aufgerufen, Informationssicherheit ernster zu nehmen,

auch im Hinblick auf die zunehmende Bedrohung durch Industriespionage.
4.1.1 MITTELSTAND
Mittelständische Unternehmen – mit eigenverantwortlicher IT-Infrastruktur – sind oftmals gesell-

schaftlich vernetzt und somit an die Vorschriften der Mutter oder der zentralen Revision gehalten;
diese hat i.d.R. bereits unternehmensweite Governance-Richtlinien erstellt. Hier stellt sich nicht
die Frage, „ob“, sondern eher „wann“ die Umsetzung und in welcher Form durchzuführen ist.
Mittelständische Unternehmen sind oftmals Zulieferer für Konzerne oder deren Vertriebspartner.
Diese Konzerne achten verstärkt darauf, dass auch die Partner ihre Regelwerke akzeptieren und –
vielleicht nicht in vollem Umfang – implementieren und einhalten.
Fast jedes größere mittelständische Unternehmen ist international aufgestellt und definiert für die
Zentrale wie auch für die nationalen Gesellschaften ein internes Kontrollsystem und ein Risikoma-
nagement, um das Zusammenwirken auf eine einheitliche, nachvollziehbare Geschäftsgrundlage
zu stellen.
16
Beyond cyber threats: Europe’s First Information Risk Maturity Index; March 2012,
A PwC report in conjunction with Iron Mountain
28
Der globale Wettbewerb zwingt zur Spezialisierung und damit – zunehmend als Wettbewerbs-
vorteil – auch zu einer Zertifizierung der Produkt und Abläufe; sensible Produktionsverfahren und
geschäftskritische Rezepturen sind in mittelständischen Unternehmen genauso verbreitet wie in
Großunternehmen und existenziell zu schützen. Eine Zertifizierung ohne sichere IT-Geschäftspro-
zesse und ausreichenden Datenschutz ist nicht mehr zu erlangen und hierzu gehört als wesentli-
cher Bestandteil ein risikofreies/risikoreduziertes Rechtewesen und ein zentrales Benutzer-
management mit Transparenz und Nachvollziehbarkeit. Prüfungsgesellschaften sind verpflichtet,
die Sicherheit von IT-Abläufen mit in ihre Prüfverfahren aufzunehmen und zu bewerten. Da der
Mittelstand sich in nicht unerheblichem Maße über Kredite finanziert, ist gelebte IT-Sicherheit und
damit ein gutes Audit-Ergebnis mit Ausschlag für die Kreditvergabe der Banken und Investoren.
Die Liste lässt sich beliebig fortsetzen; es gibt viele Gründe für die Einführung von SAP GRC Access
Control auch bei mittelständischen Unternehmen.
Aus der Beratungserfahrung kann man ableiteten, dass heute bereits Unternehmen ab 500 ERP-
User sich mit dem Gedanken tragen, ein IT-gestütztes Online-Risikomanagement einzuführen –
und dies bei überschaubarem Aufwand und Kosten. Meistens beginnt man mit der Analyse der
Berechtigungseinstellungen; durch die Implementierung von Access Risk Analysis aus der SAP
GRC Produktlinie ist der Status quo einfach zu ermitteln. Sind die Berechtigungen anhand der
ARA-Ergebnisse (Access Risk Analysis) danach überarbeitet, bietet es sich an, diese Funktionalität
auch weiterhin zu nutzen, um Veränderungen in den Berechtigungseinstellungen IT-gestützt zu
kontrollieren und qualitätszusichern. Ergänzt mit einem Notfall-User-Konzept (Emergency Access
Management) könnte so für mittelständische Unternehmen ein praktikabler und bezahlbarer Weg
als sinnvolle erste Ausbaustufe mit GRC AC beschritten werden.
4.1.2 GROSSUNTERNEHMEN / KONZERNE
Eine wirksame und effiziente Corporate Governance zur Sicherstellung einer verantwortungsbe-
wussten, transparenten und risikominimierenden Unternehmensführung steht heutzutage ganz
oben auf der Prioritätenliste der börsennotierten deutschen Unternehmen. Danach hat der Vorstand
„für die Einhaltung der gesetzlichen Bestimmungen und der unternehmensinternen Richtlinien
zu sorgen und wirkt auf deren Beachtung durch die Konzernunternehmen hin (Compliance).“17 Die
operative Umsetzung der Corporate Governance erfolgt durch ein unternehmensweites Compliance-
Management. Compliance-Verstöße können Schadensersatzforderungen, Geldbußen, Strafverfahren
und bleibende Imageschäden nach sich ziehen.
Mit der Einführung des Bilanzrechtsmodernisierungsgesetzes (BilMoG) wurden insbesondere

Prüfungsausschüsse, bzw. Aufsichtsräte, dazu verpflichtet, Compliance-Elemente wie internes
Kontrollsystem, internes Risikomanagementsystem sowie das interne Revisionssystem zu über-
wachen. Diese Regelung verstärkt die bisher schon bestehenden Empfehlungen des Deutschen
Corporate Governance Kodex, wonach der Aufsichtsrat einen Prüfungsausschuss (Audit Committee)
einrichten soll, der sich u.a. mit Fragen des Risikomanagements und der Compliance beschäftigen
soll.18
17
Deutscher Corporate Governance Kodex, Abschnitt 4.1.3 in der Fassung vom 24. Juni 2014
18
Deutscher Corporate Governance Kodex, Abschnitt 5.3.2 in der Fassung vom 24. Juni 2014
29
Ein wesentlicher Schutz- und Kontrollbereich im Rahmen des Compliance-Managements ist der
Zugriff auf Programme und Daten innerhalb der Informationstechnologie (IT). Aufgrund der Kom-
plexität und Vielfalt der eingesetzten Programme und verwendeten Datenbestände sind unter-
stützende Tools mit präventiven und detektivischen Schutzmechanismen erforderlich. Ideal sind
unternehmensweite, integrierte Lösungen mit einem breiten Anwendungsspektrum. Gerade in
Großunternehmen und Konzernen mit mehreren tausend SAP-Anwendern ist ein wirksames, pro-
aktives Identitäts- und Zugriffsmanagement insbesondere auch zur Sicherstellung notwendiger
Funktionstrennungsprinzipien nur mit Softwareunterstützung umzusetzen. Insofern ist zumindest
für die SAP-Anwendungslandschaft, wie hauptsächlich der Business Suite, die Lösung SAP GRC
Access Control ein wesentlicher Grundbaustein innerhalb eines unternehmensweiten Compliance-
Konzeptes für den Bereich Identity & Access Management eines Konzerns.
Damit die oftmals erforderlichen risikoeindämmenden Kontrollen im Berechtigungsumfeld, wie

z.B. der Abgleich von angelegten Kontenstammsätzen von Zuliefern mit kritischen Kontendaten,
auch Bestandteil des internen Kontrollsystems werden, empfiehlt es sich zudem, diese Kontrollen
in die Lösung SAP GRC Process Control zu übernehmen. Dies kann per elektronischem Interface
oder aber auch einmalig manuell erfolgen. Für die Identitätssteuerung (also Registrierung, Abtei-
lungswechsel etc.) ist zudem eine Integration der Steuerungs-Workflows mit einem eher technisch
orientierten Identity-Management-Produkt, wie z.B. SAP NetWeaver Identity Management, ratsam.
30
4.2 MOTIVATION ZUM EINSATZ VON SAP GRC ACCESS CONTROL
Die Notwendigkeit, SAP GRC Access Control einzuführen, ist in aller Regel getrieben von der Not-
wendigkeit eines effektiven und effizienten Identitäts- und Zugriffsmanagements in Verbindung mit
der Umsetzung der vorgenannten Compliance-Anforderungen.
Der Einsatz von SAP GRC Access Control lässt sich in verschiedene Kategorien unterteilen.
Gestiegene Anforderungen:
1. Einige Unternehmen setzen, initiiert durch den IT-Bereich, SAP GRC Access Control ein, weil
derzeit kein Berechtigungskonzept vorhanden ist und das Verständnis für die Notwendigkeit,
auch von der Fachseite, fehlt.
Aufgrund einer ersten Risikoanalyse mit dem von SAP ausgelieferten Regelwerk können den
Fachbereichen und dem verantwortlichen Management die vorhandenen Risiken transparent
gemacht werden. Die Transparenz dieser Risiken kann zu verschiedensten Einführungsszenarien
führen.
Eine Einführung des Emergency Access Managements (EAM) kann schon erste Beanstandungen
hinsichtlich der Profile SAP_ALL und SAP_NEW hinfällig machen. Auch weitere Anforderungen
an andere Superuser für die Fachbereiche und die IT können damit abgedeckt werden.
In dieser Kategorie der Implementierung von SAP GRC Access Control ist die Risikoanalyse,
wie so oft, der zentrale Baustein, d.h., das Unternehmen wird sich zur weiteren Sicherstellung
der Compliance dem Ausarbeiten des Regelwerkes widmen. Nach Erstellung/Ausprägung des
Regelwerkes erfolgt die Einrichtung der Workflows für das Benutzerantragsverfahren mit integ-
rierter Risikoanalyse, Beantragung von Superuser-Berechtigungen usw. Als letzte Komponente
wird man sich dann dem Business Role Management zuwenden.
2. Bei anderen Unternehmen sind eingeführte Prozesse für die Themen Benutzer- und Rollen-
verwaltung vorhanden. Die Lücken in diesen Unternehmen offenbaren sich in der geringen
Überprüfbarkeit der Funktionstrennungsrisiken. Eventuell kommt noch erschwerend eine
dezentrale Benutzer- und Rollenverwaltung hinzu.
In diesen Fällen sind auch die Benutzeranträge dezentral (im schlechtesten Fall in Papierform)
abgelegt. Eine Nachvollziehbarkeit, welche Benutzeränderung aufgrund welchen Antrages
durchgeführt wurde, wird damit erheblich erschwert.
Um diesen Missstand zu beheben, kann hier das Einführungsszenario so aussehen, dass zuerst
das Benutzerantragsverfahren ohne Risikoanalyse eingeführt wird. Erst in einem weiteren Schritt
kommen die Komponenten EAM, ARA und BRM hinzu.
31
3. Unternehmen, die aufgrund von Prüfungsergebnissen der internen Revision oder der Wirtschafts-
prüfung tätig werden und sich u.a. auch deshalb für präventive Risikoanalysen mit SAP GRC
Access Control entscheiden.
4. Eine andere Kategorie von Unternehmen hat ausgearbeitete Berechtigungskonzepte und
gelebte Prozesse implementiert. Lediglich die Dokumentation für das IKS ist verbesserungswürdig.
In diesen Fällen erlaubt das Reporting von SAP GRC Access Control den entsprechenden Nachweis
und somit die Sicherstellung der Compliance.
Die Implementierung von SAP GRC Access Control erfolgt hier oft in der Reihenfolge ARA und
EAM, ARM und BRM.
Kostendruck:
1. Grundsätzlich sind die meisten der gestiegenen Anforderungen durch die Benutzer- und Berech-
tigungsverwalter eines jeden betroffenen Systems (SAP und Non-SAP) umsetzbar. Allerdings ist
dies mit einem erheblichen zusätzlichen Personalaufwand verbunden. Daher ist der Einsatz von
SAP GRC Access Control als zentrale Lösung sinnvoll, da sich hierdurch eine bessere Effizienz
erreichen lässt.
2. Einige der Anforderungen lassen sich in den SAP-Business-Anwendungen und auch in vielen
Non-SAP-Systemen standardmäßig nicht umsetzen und wurden daher bisher bei vielen Anwendern
durch Eigenentwicklungen gelöst. Die Pflege und Weiterentwicklung dieser Eigenentwicklungen
ist sehr zeitaufwendig und kostenintensiv. Prominente Beispiele wären die Änderungsdokumen-
tation von Benutzerrollen, das gesamte Antragswesen, Workflows, manuelle Notfalluser-Rege-
lungen, Massenableitungen von Rollen. Insgesamt ist dies auch ein Entscheidungsgrund für
SAP GRC Access Control, das diese Funktionen anbietet.
Weitere unterschiedliche Ausprägungen sind denkbar, würden aber den Rahmen dieses Leitfadens
sprengen.
Zusammenfassend lässt sich feststellen, dass sich die Verwendung von SAP GRC Access Control in
den meisten Fällen von einem reaktiven Ansatz – wenn nur die Risikoanalyse zum Einsatz kommt -
zu einem präventiven Ansatz mit allen Komponenten wandelt.
32
4.3 RAHMENBEDINGUNGEN / ERFOLGSFAKTOREN
Die im Folgenden dargestellten Rahmenbedingungen und Erfolgsfaktoren für ein GRC-Access-

Control-Projekt basieren auf den Erfahrungen durchgeführter Implementierungsprojekte bei Unter-
nehmen aus unterschiedlichen Branchen und unterschiedlicher Unternehmensgrößen. Dabei hat
sich gezeigt, dass Projekte dieser Art als übergreifend anzusehen sind und nicht von der IT alleine
durchgeführt werden können. Aus diesem Grund ist es notwendig, alle Interessensgruppen frühzeitig
einzubinden (z.B. Verantwortliche aus den Fachbereichen sowie der IT und von Internal sowie
External Audit).
Für eine erfolgreiche Projektdurchführung muss das Top-Management die Verantwortung tragen
und das Projekt bei notwendigen Entscheidungen begleiten. Dabei hat sich als vorteilhaft erwiesen,
frühzeitig die Einführungsstrategie festzulegen.
Ein Einführungsprojekt setzt sich grundsätzlich aus unterschiedlichen Projektbeteiligten zusammen.

Das Projektteam besteht dabei in der Regel aus Vertretern des Fachbereiches und aus Vertretern
des IT-Bereiches. Sofern es sich aber um Projekte im Umfeld von Mitarbeiter-Berechtigungen und
dem zugrunde liegenden Change-Management-Prozess handelt, reicht diese einfache Organisati-
onsstruktur innerhalb eines Projektes nicht aus.
In diesem Zusammenhang werden Fragestellungen zum Datenschutz, zu Möglichkeiten einer Mit-

arbeiterüberwachung, den regulatorischen Anforderungen und Verantwortlichkeiten aufgeworfen,
die nur durch eine intensive Einbeziehung einzelner Gruppen bereits in einer frühen Projektphase
beantwortet werden können. Die Bedeutung und Erläuterung dieser These ergibt sich aus den
folgenden Beschreibungen der einzelnen Aufgabengebiete.
4.3.1 TOP-MANAGEMENT
Das Top-Management als Projekt-Owner muss die notwendigen Entscheidungen zeitnah her-
beiführen und die Umsetzung unterstützen. Dabei werden auch organisatorische Veränderungen
entstehen, für die die Fachbereiche motiviert werden müssen. Zur Sicherstellung einer nachhalti-
gen Zielerreichung des GRC-Access-Control-Projektes sollte das Top-Management auch ein sog.
Konsequenzenmanagement sicherstellen (insbes. Eskalationsfunktion, Budgetbereitstellung, klare
verbindliche Zielvorgaben, Erfolgscontrolling).
4.3.2 BETRIEBSRAT
Der Betriebsrat hat nach § 87 Abs. 1 Nr. 6 BetrVG ein Mitbestimmungsrecht, wenn es um die Ein-
führung und Anwendung von Einrichtungen geht, die das Verhalten der Arbeitnehmer überwachen
können. Grundsätzlich betrifft dies z.B. den Einsatz des Emergency Access Management (EAM;
vormals Firefighter) und dessen Protokoll-Datei. Es empfiehlt sich, den Betriebsrat frühzeitig als
vertrauensbildende Maßnahme über das Projekt zu informieren und in die Entscheidungsprozesse
zur Produktivsetzung einzubeziehen.
33
4.3.3 WIRTSCHAFTSPRÜFER
Eine wesentliche Aufgabe des Wirtschaftsprüfers im Rahmen der Prüfung des Jahresabschlusses
ist die Einschätzung der sog. Kontrollrisiken, d.h. die Beurteilung der Wirksamkeit des internen
Kontrollsystems hinsichtlich der durchzuführenden Prüfungshandlungen. Die Einhaltung von
Funktionstrennungsprinzipien u.a. durch ein wirksames Benutzerberechtigungskonzept und des-
sen organisatorische Umsetzung ist dabei ein wesentlicher Prüfungsbereich. Aufgrund seiner
profunden Kenntnisse des internen Kontroll- und Risikomanagementsystems des geprüften Unter-
nehmens und seiner skizzierten Prüfungspflichten sollte der Wirtschaftsprüfer bereits frühzeitig
in entsprechende Einführungsprojekte von SAP GRC Access Control einbezogen werden. Projekt-
begleitend kann er wesentliche Hinweise zur Sicherstellung eines ordnungsmäßigen und sicheren
Benutzermanagements geben und damit einen wertvollen Beitrag auch im Sinne einer projektbe-
gleitenden Qualitätssicherung leisen.
4.3.4 INTERNE REVISION
Die interne Revision ist Teil des internen Kontrollsystems einer Organisation, ist unabhängig und
der obersten Leitung unterstellt. Das Aufgabengebiet besteht vor allem aus organisationsinternen
Prüfungen und unterstützt mit Lösungsvorschlägen. So kann die interne Revision dafür zuständig
sein, Empfehlungen für ein neues Berechtigungskonzept abzugeben, für den Produktiveinsatz
freizugeben und auch entsprechende Prüfungen der ordnungsgemäßen Umsetzung vorzunehmen.
4.3.5 INTERNAL CONTROL / RISK MANAGEMENT
Zunehmend werden in größeren Unternehmen Abteilungen eingerichtet, die sich mit der Ausge-
staltung und Steuerung des internen Kontrollsystems befassen. Das interne Kontrollsystem sollte
im Projekt bei der Definition der Risiken und SoD-Konflikte sowie bei der Auflösung von Risiken
zur Identifizierung der relevanten Kontrollen einbezogen werden.
4.3.6 COMPLIANCE OFFICER
Der Compliance Officer ist zuständig für alle Arten der Wirtschaftskriminalität. Compliance Officer
entwickeln Verhaltenskodizes, Richtlinien und Trainingsmaßnahmen, damit Mitarbeitende die Regeln
und Normen einhalten, die ein Unternehmen oder eine Organisation selbst festgelegt hat. Die Regeln
sind aus gesetzlichen Anforderungen abgeleitet und stehen im Einklang mit dem Wertesystem des
Unternehmens. Compliance-Verantwortliche implementieren diese im Unternehmen, optimieren
sie und überwachen deren Einhaltung. Im Fokus stehen dabei vor allem die Prävention und die
Aufdeckung von Verstößen.
Das Aufgabengebiet des Compliance Officers ist nach Ansicht des Bundesgerichtshofs weit gefasst.
„So stehe die Verhinderung von Rechtsverstößen, insbesondere auch von Straftaten, die aus dem
Unternehmen heraus begangen werden, im Vordergrund. Derartige Beauftragte treffe regelmäßig
eine strafrechtliche Garantenpflicht. Denn dem Compliance Officer seien Obhutspflichten für eine
bestimmte Gefahrenquelle übertragen worden. Daraus folge die besondere Verantwortlichkeit für
diesen Bereich.“( BGH-Urteil vom 17.07.2009; Az 5 StR 394/08).
34
Der Compliance Officer hat damit eine ganz wesentliche Funktion bei der Gestaltung und Imple-
mentierung von Compliance- und Risikomanagementsystemen im Unternehmen und insbesondere
auch beim Thema der Zugriffskontrollen.
4.3.7 SAP-BASISBETREUUNG
Die Rolle und Aufgabe der SAP-Basisbetreuung im Umfeld von Berechtigungen im SAP-Umfeld ist
ganz vielschichtiger Art. Sie differiert selbst zwischen einzelnen Unternehmen, je nach Größe und
interner Organisation. Die SAP-Basisbetreuung kann durch eine eigene IT-Service-Einheit oder
durch eine externe IT-Service-Organisation durchgeführt werden. Ihre Aufgabe sollte dagegen aber
prinzipiell ähnlich sein.
Die SAP-Basisbetreuung ist neben vielen weiteren Aufgaben im Umfeld der SAP-Berechtigungen
in der Regel zuständig für folgende Aufgaben:
› Neuanlage von Usern im SAP-System

› Verwaltung von Benutzergruppen
› Zurücksetzen von Passwörtern
› Sperren und Entsperren von Benutzern
› häufig auch: Zuweisen und Erweitern von Berechtigungsrollen
Durch Einführung von SAP GRC Access Control ändert sich das Aufgabengebiet der SAP-Basis-
betreuung. Viele bislang manuell durchgeführte Arbeitsschritte werden nun automatisiert.
4.3.8 SAP-BERECHTIGUNGSADMINISTRATOREN
In größeren Organisationen wird bzw. sollte die Benutzer- und Berechtigungsverwaltung getrennt
werden (4-Augen-Prinzip). Diese Administratoren sind dabei für Erstellung, Anpassung und
Zuweisung der Berechtigungsrollen zuständig. Sie arbeiten eng mit den jeweiligen Fachbereichen
zusammen und verstehen die Rollen auch fachinhaltlich, um diese entsprechend dem Aufgaben-
gebiet des Mitarbeiters zuweisen zu können.
4.3.9 ORGANISATIONSABTEILUNG
Eine Organisationsabteilung ist oft bei größeren Unternehmen zu finden. Diese unterstützt u.a. bei
der Erstellung von Berechtigungsvergabeprozessen. Diese Prozesse und deren Dokumentationen
sind notwendig für einen geordneten und nachvollziehbaren Ablauf der Vergabe von Berechtigungen.
35
4.3.10 SCHLÜSSELPERSONEN AUS DEN FACHBEREICHEN
Die Schlüsselpersonen aus den Fachbereichen spielen eine vermittelnde Rolle zwischen dem
Endanwender und den Berechtigungsadministratoren. Über Sie wird oft die Berechtigungsan-
forderung der Endanwender kanalisiert und spezifiziert. Sie unterstützen bei der Definition von
Rolleninhalten und Arbeitsplatzbeschreibungen und können einschätzen, ob ein Anwender eine
Berechtigung für sein Aufgabengebiet benötigt. Sie haben zudem den Überblick und können die
Relevanz der Zugriffsrisiken einschätzen.
4.3.11 ENDANWENDER
Endanwender haben im Wesentlichen Testaufgaben wahrzunehmen, da der Fachbereich innerhalb

des Projektes durch die Schlüsselpersonen vertreten ist. Insbesondere sollten sie mitwirken beim
Usability-Test. Darüber hinaus sind die Endanwender als die wesentlich Betroffenen der Systemein-
führung (Prozessänderungen, Antragswesen) durch eine frühzeitige und nachhaltige Kommunikation
mit dem Ziel einer möglichst hohen Akzeptanz in allen Projektphasen einzubinden.
Eine frühzeitige Einbeziehung vermeidet auch nicht zielführende Fehlentwicklungen bei der Kon-
zeption und dem Go-Live von SAP GRC Access Control, die dann möglicherweise auch dazu führen
können, dass zusätzliche Prüfungshandlungen im Rahmen einer Prüfung des Jahresabschlusses
erforderlich werden und unter Umständen die Wirksamkeit des internen Kontrollsystems nur mit
Einschränkungen bestätigt werden kann.
36
5. FUNKTIONALER UND TECHNOLOGISCHER
VERGLEICH ZU SAP GRC ACCESS CONTROL 5.3
Nach dem Erwerb von Virsa Inc. und deren GRC-Produktpalette im Jahr 2006 hatte SAP das anfangs
noch unter ABAP laufende GRC Access Control 4.0 zunächst auf seine Java-Plattform portieren
lassen, auf der die Versionen 5.2 und 5.3 basieren. Andere Applikationen wie etwa Process Control
verblieben hingegen noch in der ABAP-Variante.
Mit GRC10.0 wurden von SAP nun alle GRC-Produkte (GRC Access Control, Process Control, Risk
Management usw.) auf eine einheitliche technische Basis gebracht, und zwar zurück in die ABAP-
basierten Plattformen: SAP GRC Access Control 10.0 hat als Installationsvoraussetzung den
NetWeaver ABAP 7.02.
Dies bringt gegenüber den früheren Versionen erhebliche Verbesserungen bei Betrieb, Integration
sowie User-Handling der verschiedenen Applikationen.
5.1 KOMPONENTENSTRUKTUR UND NAMENSGEBUNG
SAP hat im Rahmen des neuen Releases den einzelnen Komponenten neue Namen gegeben, die
deren Funktionalität besser umreißen und sich auch sinnvoller in die gesamte GRC-Suite samt
Process Control und Risk Management einordnen lassen:
› Risk Analysis and Remediation heißt nun Access Risk Analysis (ARA)
› Compliant User Provisioning heißt nun Access Request Management (ARM)
› Enterprise Role Management heißt nun Business Role Management (BRM)
› Superuser Privilege Management heißt nun Emergency Access Management (EAM)
Alle Komponenten werden in einer neuen, Webdynpro-ABAP-basierten Benutzeroberfläche in

verschiedene Kategorien bzw. Navigationsgruppen eingeordnet. So gibt es nicht mehr dedizierte
Einstiegspunkte etwa für ARM oder BRM, sondern einzelne Funktionspunkte wie etwa „Zugriffs-
risikoanalyse – Benutzerebene“ (ARA) und Zugriffsanforderung – Vorlagenbasierte Anforderung“
(ARM) unter der Navigationsgruppe „Zugriffsverwaltung“.
Abbildung 5: Einstiegsbild GRC Access Control
37
38
5.2 NEUE TECHNOLOGISCHE PLATTFORM
Im Gegensatz zu den Java-Versionen, die sich jeweils durch eine schmale, gekapselte und funktional
fokussierte Architektur auszeichneten, verwendet GRC10.0 den NW ABAP als Integrationsplattform
und nutzt dessen technische Vielseitigkeit durch Wiederverwendung bekannter Komponenten:
› Für den Betrieb aller Konnektoren – irrespektive ihrer jeweiligen Nutzung in den GRC-Access-
Control-Komponenten – wird die RFC-Verwaltung aus der SM59 verwendet. Ein Konnektor-
Framework sorgt für die Interpretation der Daten in die einzelnen Applikationen.
› Für eine Vielzahl von organisatorischen Objekten wird das Standard-Organisationsmanagement

des ABAP-Systems wiederverwendet. So sind z.B. mindernde Kontrollen als spezielle Objekttypen
im OM gespeichert.
› Für die Workflows in allen GRC-Komponenten werden die MSMP-Workflows des ABAP-Systems
verwendet.
› Bei einer feineren Ausarbeitung von Regeln innerhalb der Workflows, z.B. etwa um eine
Genehmigerbestimmung anzupassen, kommt der ABAP-Standard für Business-Regeln
BRF+ zum Einsatz.
› Der Betrieb der Applikation folgt nun den üblichen ABAP-Standards: Hintergrundjobs, Jobver-
waltung, Scheduling usw. können durch die üblichen Funktionen SM36, SM37 wahrgenommen
werden. Externe Jobscheduler wie Redwood und andere sind nun ebenfalls einsatzbar.
› Wie bereits oben im Screenshot angedeutet, wird als Benutzeroberfläche Webdynpro ABAP
verwendet. Dabei erfolgt das eigentliche Customizing der Komponenten ganz analog zum
ABAP-Standard im IMG (Transaktion SPRO) über die SAPGUI, die Stammdateneinrichtung und
die Businessfunktionen jedoch werden grundsätzlich per Browser oder NWBC durchgeführt,
dabei ist auch eine Portalintegration möglich. (Einzige Ausnahme: Der Emergency Access
erfolgt wie üblich direkt per SAPGUI.)
› GRC10.0 ist mittels der ABAP-Basis komplett mandantenfähig. Nur wenige Strukturen wie
etwa die SM59-Verbindungen werden mandantenübergreifend verwendet, alle anderen Appli-
kationsdaten sind mandantenabhängig, was einen verteilten Betrieb auf einer zentralen Instanz
ermöglicht.
› Anders als im NetWeaver Java gibt es nun die Möglichkeit, Vorabkorrekturen einzuspielen. Dies
ist insbesondere vor dem Hintergrund der von SAP geforderten Synchronizität der SP-Level
wichtig.19
19
Mit SP10 wurde diese Restriktion aufgehoben: SP-Level der Zentralkomponente und der Plug-ins in den Satellitensystemen
dürfen nun voneinander abweichen.
39
5.3 VEREINHEITLICHTE STAMMDATEN, ARCHITEKTUR
(AUCH BZGL. PROCESS CONTROL ETC.)
SAP hat die Haupt-Applikationen der GRC-Suite, SAP GRC Access Control, Process Control und Risk
Management einem kompletten Redesign unterzogen mit verstärktem Fokus auf die bessere Inte-
gration der Applikationen ineinander sowie die verstärkte Nutzung von Standards und gemeinsamen
Konfigurationseinstellungen und Komponenten. So wird das bereits oben erwähnte Konnektor-
Framework von allen Applikationen und Komponenten gemeinsam verwendet, aber auch das Orga-
nisationsmodell und darin enthaltene Objekte wie etwa Kontrollen oder Prozesse und Organisati-
onseinheiten. Einen guten Eindruck bekommt man von dieser harmonisierten Informations- und
Funktionsbasis, wenn man sich den Baum der Konfigurationspunkte im IMG ansieht:
Abbildung 6: Customizing mit dem SAP Implementation Guide

40
Auch werden etwa Workflow-Items aus allen Applikationen und Komponenten im Navigationspunkt
„Meine Startseite“ in einer gemeinsamen Arbeitsvorratsliste gehalten und sind dort für den Endan-
wender wesentlich besser abarbeitbar, da er sich nicht mehr in verschiedenen Applikationen oder
Komponenten bewegt und jeweils dort nach entsprechenden Elementen suchen müsste.
5.4 FUNKTIONALE ÄNDERUNGEN UND ERWEITERUNGEN
Grundsätzlich stand für SAP zunächst der technologische Umbau von GRC 10.0 gegenüber den
Vorgängerversionen der Suite im Fokus dieser Releases. Daher wurden – mit wenigen Ausnah-
men – alle in Process Control 3.0 und Risk Management 3.0 sowie Access Control 5.3 vorhandenen
Funktionen auch in GRC 10.0 abgebildet. Zwar ergeben sich aufgrund der nun verwendeten Techno-
logie Unterschiede in der Benutzeroberfläche, der Konfiguration und dem Handling verschiedener
Funktionen, erhebliche Erweiterungen wurden jedoch nur vereinzelt vorgenommen. So gibt es im
Wesentlichen einige kleinere Verbesserungen, u.a:
› Im ARA können nun besser Massenänderungen vorgenommen werden
› Mindernde Kontrollen auf Konnektorebene sind nun möglich
› Die Analyse von Sammelrollencontainern aus der ZBV
› Im ARM werden – neben einer erheblichen Flexibilisierung der Konfiguration über BRF+ –
erweiterte Möglichkeiten von Vorlagen zu Anforderungen und konfigurierbare Antragsformulare
angeboten
› Ebenfalls im ARM gibt es erweiterte Suchmöglichkeiten nach Rollen und Benutzern
› Es können im ARM nun verschiedene Risikoregelwerke geprüft werden
› Das BRM wurde erheblich verbessert um Ableitungen, Sammelrollen und das Mapping zu
technischen Einzelberechtigungen optimiert zu unterstützen
› Rollenvergleiche wurden optimiert bzgl. Änderungen in den Backendsystemen
› Über das ABAP-basierte Berechtigungswesen und die intensive Nutzung von entsprechenden
Berechtigungsobjekten können nun Zugriffe auf die Applikation wesentlich feingranularer
ausgesteuert werden, als dies bei den Vorversionen der Fall war. So können z.B. einzelne
Namensräume bestimmter Funktionen oder Risiken selektiv berechtigt werden. Dies ermög-
licht einen verteilten Betrieb sogar innerhalb ein und desselben Mandanten.
› Konfigurationen können nun über das Standardtransportwesen in Folgesysteme übertragen

werden (dies trifft jedoch nur in sehr eingeschränktem Maß auf Stammdaten zu)
41
Die Benutzeroberfläche wiederum bietet in den immer wieder verwendeten ALV-Listen auch Vor-
selektionen und Query-Speicherungen, Personalisierungen und jederzeit Download-Möglichkeiten
in Excel, außerdem können bei vielen Funktionen jeweils neue Fenster parallel geöffnet werden,
damit sind inhaltliche Vergleiche wesentlich effizienter durchzuführen als in der Vorversion.
Neben den erwähnten signifikanten Änderungen durch den Plattformumbau und die stark verän-
derte Benutzeroberfläche gibt es allerdings noch eine erhebliche funktionale Änderung im Design
beim Emergency Access Management (EAM): Der Betrieb des EAM erfolgt statt wie vorher dezentral
in den jeweiligen Backends (in der Version 5.3 war nur die Einsicht in die Logs zentral möglich) nun
zentral über die Frontendplattform GRC Access Control 10.0. Hierbei wurde auch die Konfiguration
des EAM mit Kontrolleuren und FF-ID-Ownern zentralisiert. Bis einschließlich SP9 mussten im
EAM darüber hinaus selbst die FireFighter immer über das zentrale GRC-Access-Control-System
für ihre Reparaturarbeiten einsteigen, was es erforderlich machte, alle potenziellen FireFighter-
UserIDs im Zentralsystem als User anzulegen. Ab SP10 gibt es allerdings auch die Möglichkeit
eines dezentralen, also wieder wie unter 5.3, lokalen FireFighter-Einsatzes. Die UserID muss nicht
im Zentralsystem vorgehalten werden. Allerdings bleibt die Konfiguration und Logeinsicht zentral.
42
5.5 BEWERTUNG
Aus den bisher bekannten produktiv gesetzten AC10.0-Projekten sind – mit wenigen Ausnahmen,
bei denen sehr spezielle Features nicht ähnlich genug wie in GRC Access Control 5.3 abgebildet
waren – überwiegend positive Rückmeldungen zu verzeichnen. Insbesondere der verbesserte
technologische Unterbau (mit z.B. erheblich kürzeren Analyseläufen als noch in der Java-Version)
und das wesentlich vereinfachte Handling haben viele Administratoren, Compliance-Teams und
Endanwender überzeugt.
Nachvollziehbare Schwierigkeiten gibt es vor allem in zwei Bereichen: Zum einen gibt es wegen der
verwendeten Technologie keinen direkten Upgradepfad, sondern nur eine Migration von 5.3 nach
10.0. Dabei werden nicht alle Informationen übernommen, z.B. gibt es keine Möglichkeit, historische
Analyseergebnisdaten zu migrieren, außerdem müssen komplexere Workflows neu abgebildet
werden. Darüber hinaus wird der RTA aus AC5.3 vom Plug-in (neuer Name für RTA) von AC10.0
grundsätzlich immer überschrieben. Ein Parallelbetrieb von RTA und Plug-in ist im Backend aus
technisch-organisatorischen Gründen nicht möglich. Da allerdings das Plug-in auch Process Control
und Risk Management umfasst, wäre dann auch ein Parallelbetrieb etwa von Process Control
10.0 und GRC Access Control 5.3 zunächst nicht möglich, wenn dieselben Backends dabei genutzt
werden. Allerdings hat sich SAP hierzu eine Lösung einfallen lassen – diese wird im Kapitel zur
Migration näher beschrieben.
Allgemein stellt jedoch aus den vorstehend genannten Gründen die Migration von einer Version
5.x nach 10.0, auch wegen ggf. parallel laufender Systeme, durchaus eine Herausforderung dar,
insbesondere in den Bereichen ARM und BRM.
Bis SP9 war der nun durchgehend zentralisierte Notfalluser-Mechanismus (EAM) für bestimmte
Szenarien nachteilig. Insbesondere ist in großen, verteilt strukturierten Organisationen ein zentraler
Plattformbetrieb erheblich erschwert worden, weil nun im Gegensatz zum vorherigen SPM-Design
auch alle EAM-Anwender (also diejenigen Mitarbeiter, die potenziell eine Notfallreparatur durch-
führen würden) in dem zentralen GRC10.0-System vorgehalten werden müssten, da sie hierüber
ihre EAM-Session starten müssen. Damit wurden an dieses zentrale System sofort erweiterte An-
forderungen gestellt wie etwa ein ausgedehnter Support (z.B. für Benutzereinrichtung, vergessene
Passwörter, falls kein SSO benutzt wird, etc.) als auch möglicherweise Hochverfügbarkeit – denn
wenn im zentralen EA die GRC10.0-Plattform ausfällt, sind sofort keine Notfallreparaturen mehr
möglich. Mit der Einführung des dezentralen Einstiegs für EAM-Anwender ab SP10 ist diese Proble-
matik behoben und wieder die vorherige Flexibilität erreicht.
43
6. EINFÜHRUNGSMANAGEMENT
(ROLLOUT INKL. USERTRAINING)
Gemäß der SAP-ASAP-Methodik („Accelerated SAP“), die für die Implementierung und den Rollout
von SAP-ERP-Anwendungen vor Jahren schon entwickelt wurde, lässt sich ein SAP-Einführungs-
projekt in folgende Hauptphasen einteilen (siehe auch „GRC Implementation Roadmap“ verfügbar
auf dem SAP Service-Marketplace: http://service.sap.com/roadmaps):
› Projektvorbereitung („Strategie & Planung“): In dieser ersten Phase legen die Entscheidungs-
träger klare Projektziele und eine effiziente Vorgehensweise zur Entscheidungsfindung fest.
Es wird das genaue Projektteam und dessen Kommunikation mit den Fachbereichen festgelegt.
Speziell bei einem Einführungsprojekt für SAP GRC Access Control ist die Kommunikations-
strategie mit den Verantwortlichen aus den Fachbereichen für den Gesamtprojekterfolg von
großer Bedeutung. Zudem wird der Projektplan in Abhängigkeit von einer ersten Analyse des
bestehenden Berechtigungskonzepts für SAP, des Systemumfangs, des bestehenden Identity
Lifecycle Managements und anderen Abhängigkeitsfaktoren festgelegt.
› Sollkonzeption („Business Blueprint und Design“): In dieser Phase werden die in der Strategie-
phase festgelegten High-Level-Prinzipien, wie z.B. die technische Architektur für SAP GRC
Access Control, das eventuell notwendige Reengineering des bestehenden SAP-Rollenkonzepts
und des Designs des Risikomanagements mit den notwendigen Provisionierungsworkflows, der
Festlegung der Zugriffsrisiken (also „Segregation of Duties“-Konflikte und kritische Transaktionen)
in ein Feindesign überführt. Zudem wird auch ein detailliertes Rollendesign für die Steuerung
von SAP GRC Access Control selbst festgelegt.
› Realisierung („Implementierung“): Hauptziel dieser Phase ist die eigentliche Konfiguration des
SAP GRC Access Control Systems (Customizing), um zu einer integrierten und dokumentierten,
das Risikomanagement und legale Anforderungen erfüllenden Lösung zu gelangen.
› Produktionsvorbereitung („Rollout“): In der Phase Produktionsvorbereitung erfolgt die endgültige

Vorbereitung des Systems auf die Produktionsphase. Dazu gehören beispielsweise intensive
Tests der eventuell überarbeiteten Berechtigungseinstellungen und der Provisionierungswork-
flows sowie intensive Schulung der Fachbereiche zu Genehmigungsaktivitäten und des Notfall-
benutzerverfahrens.
› Produktivstart („Support“): Nach dem Abschluss des sog. Go-live, bei dem das System in den
Produktivzustand gesetzt wird, konzentriert sich das Projektteam auf die Unterstützung der
Benutzer, deren Schulung möglicherweise noch nicht abgeschlossen ist. Es ist gleichermaßen
notwendig, Verfahren und Maßstäbe zu entwickeln, anhand derer die Applikation regelmäßig
betriebsbegleitend überprüft wird. Es wird zudem ein Know-how-System mit aufgetretenen
Fehlern und entsprechenden Lösungen aufgebaut und an den Help Desk für den First Level
Support und auch Second Level Support übergeben.
Die ASAP-Methodik sollte entsprechend auch für SAP GRC Access Control angewendet werden,
wodurch sich die nachfolgend aufgeführten Projektphasen ergeben.
44
6.1 PHASE: PROJEKTVORBEREITUNG („STRATEGIE & PLANUNG“)
6.1.1 RISIKOBASIERTES BERECHTIGUNGSMANAGEMENT
Das Hauptziel eines Unternehmens, das SAP GRC Access Control einführt, sollte speziell der
Aufbau einer risikobasierten Vergabe von SAP-Berechtigungen sein. Eine Berechtigungssteuerung
nach dem sog. „Need to know“ -Prinzip, das viele Sicherheitsstandards, wie z.B. auch ISO 27001/2,
fordert, ist in der Praxis eigentlich nicht umsetzbar und führt in der Regel immer zum gleichen
Resultat, dass speziell Fachbereiche genau „Need to know“ für die Beantragung von Berechtigun-
gen für die Durchführung von Geschäftsprozessschritten für sich selbst beanspruchen und daher
meist kein adäquates Instrument zur Steuerung der Berechtigungsvergabe darstellt.
Besser ist die Steuerung der Berechtigungsvergabe über vorher mit den Fachbereichen bzw. der
Organisation festgelegte fachbereichsspezifische Business-Funktionen und Geschäftsprozessrisiken,
wie sie z.B. das fehlende Vier-Augen-Prinzip, kritische Funktionalitäten (SAP T-Codes) oder auch
der Zugriff auf kritische Unternehmensdaten (die mit Hilfe von Anzeigeberechtigungen gesteuert
werden können) darstellen. Dabei sollte zuvor eine eindeutige Risikodefinition mit den Fachberei-
chen, basierend auf einer unternehmensweiten Richtlinie, festgelegt werden, die die Risikostufen
(bspw. niedrig, mittel und hoch) vorgibt.
SAP GRC Access Control liefert eine Risikomatrix auf Basis eines Best-Practice-Ansatzes aus,
der aber nicht einfach „blind“ übernommen werden sollte, sondern der mit den einzelnen zustän-
digen Fachbereichen abgestimmt und ergänzt bzw. reduziert werden muss. Zudem sollten mit
Fachbereichsverantwortlichen (z.B. Rechnungswesen) oder auch Geschäftsprozesseignern (z.B.
Vertriebsprozess) ein Risikoverantwortlicher festgelegt werden. Der Risikoverantwortliche ist
befugt, die Risikodefinitionen einschließlich der Risikostufen in Absprache mit dem Compliance
Officer oder auch Risikomanagern des Unternehmens ändern zu dürfen. Dies bedeutet, dass der
Änderungsprozess für Risikodefinitionen oder der SoD-Matrix einem genau festgelegten Ände-
rungsmanagementprozess unterliegen muss. Bei der erstmaligen Festlegung der Risikomatrix
mit den Fachbereichen bei der Einführung von SAP GRC Access Control muss eine Abnahme der
Risikodefinitionen durch die verantwortlichen Fachbereiche erfolgen, da ansonsten später im
Betrieb (d.h. bei der Provisionierung von Benutzern und Berechtigungen) wieder „Diskussionen“
über die Risikoklassifizierung erfolgen könnten, falls es bei der Zustimmung für Berechtigungen
zu Risikoidentifikationen kommen könnte.
Daher ist ebenfalls eine entsprechende verbindliche Richtlinie festzulegen, die den im Provisionie-
rungsprozess beteiligten Personen eine eindeutige Handlungsanweisung im Falle von hohen,
mittleren und niedrigen Risiken zur Hand gibt. Auf diese Weise erfolgt die Zuordnung von Berechti-
gungen zu den Benutzern nicht mehr auf dem „Need to know“-Prinzip und den damit allseits
verbundenen Diskussionen, was nun wirklich „Need to know“ darstellt, sondern auf Basis von ein-
deutig definierten Funktionen und Zugriffsrisiken, welcher ein Berechtigungsantrag eines Anwen-
ders inhärent beinhalten könnte. Auf diese Weise wird ein klarer Risikomanagementprozess für
die Berechtigungsvergabe festgelegt, der Berechtigungsnotwendigkeit („Need to know“ aus dem
Geschäftsprozess heraus) und Berechtigungsrisiken miteinander abwägt.
45
Wichtig ist es in diesem Kontext, auch angemessene und funktionsfähige, kompensierende Kon-
trollen festzulegen, die, falls ein Zugriffsrisiko nicht vermeidbar ist, die Auswirkung des Risikos
kompensieren. Dieses könnte z.B. eine manuelle Kontrolle sein oder aber auch eine automatische
Kontrolle, die im SAP-System durch eine Konfiguration eingestellt werden könnte. Kompensierende
Kontrollen müssen dabei einem Verantwortlichen zugeordnet werden, der den Inhalt der Kontrolle
und auch den Durchführenden der Kontrolle festlegt. Die Festlegung von Kontrollen muss ebenfalls
einem Änderungsmanagementprozess folgen. Da kompensierende Kontrollen einen nachgelagerten
Ansatz verfolgen und daher meist in der Ausführung und Dokumentation aufwendig sind, sollte die
Anzahl gering gehalten werden, da jede Kontrolle in das interne Kontrollsystem des Unternehmens
aufgenommen werden sollte. Denn Ausnahmen, sprich Irregularitäten, müssen schnell durch den
Fachbereich und auch den Risikomanager erkannt werden und entsprechend Gegenmaßnahmen
eingeleitet werden können. Das entsprechende Änderungsmanagement für die Risikofestlegung und
auch die kompensierenden Maßnahmen kann ebenfalls mit SAP GRC Access Control eingeführt
werden. Hierfür wird mit Hilfe des Compliant User Managements und des darin enthaltenen Work-
flow-Systems auch der Workflow zur Steuerung der Risikodefinition und der hierfür notwendigen
kompensierenden Kontrollen festgelegt.
Eine häufig verwendete kompensierende Kontrolle ist das Superuser-Access-Management. In die-

sem Fall wird dem Anwender temporär eine höhere Berechtigung zugeordnet, welche er mit einem
hierfür festgelegten Beantragungsprozess und einer notwendigen Begründung beantragen kann.
Der Verantwortliche einer Superuser-ID kann den Antrag genehmigen, wenn die Notwendigkeit aus
dem Geschäftsprozess heraus gegeben ist. In diesem Fall werden aber mit Hilfe eines verbesserten
Monitoring im System die Aktivitäten des Anwenders im System mitgeloggt und später durch einen
definierten Controller ausgewertet werden, wenn der Zugriff mittels der Superuser-Berechtigung
beendet ist. Das Ergebnis sollte in der festgelegten kompensierenden Kontrolle dokumentiert und
so in das interne Kontrollsystem einfließen. Insgesamt erhält man auf diese Weise ein „rundes“
Risikomanagementkonzept, mit dessen Hilfe das sog. „Need to know“-Prinzip eindeutiger und
besser umgesetzt werden kann.
6.1.2 ABGRENZUNG VON VERANTWORTUNGSBEREICHEN
Um den Risikomanagementprozess für das Berechtigungsmanagement in einem Unternehmen

erfolgreich einzuführen, müssen die Aufgaben und Verantwortungsbereiche für die am Provisio-
nierungsprozess für die Berechtigungsvergabe beteiligten Personen klar voneinander abgegrenzt
werden. Zudem müssen die Fachbereiche in diesen Prozess einbezogen werden, da sie ansonsten
ihre Verantwortung nicht akzeptieren werden und entsprechend, wie in der Vergangenheit gesche-
hen, das Berechtigungsmanagement komplett als Aufgabe dem Informationstechnologiebereich
(IT) übertragen. Indes sollte die IT nur eine unterstützende Verantwortung übernehmen und nicht
eine, die die Entscheidung für die „Zuordnung“ von Berechtigungen trägt. Denn der IT-Bereich hat
im Normalfall keine genaue Kenntnis über die Geschäftsprozesse und kann daher die Vertraulich-
keit von Informationen und auch mögliche Geschäftsprozessrisiken nicht einschätzen, geschweige
denn die entsprechende Entscheidung fällen.
46
Folgende im Unternehmen existierende Positionen sollten dabei die folgenden Aufgaben und
Verantwortungen übernehmen:
Compliance Officer/IKS-Verantwortlicher:
Aufgaben:
› Mitarbeit und Freigabe der Prozesse, die durch GRC Access Control in das Unternehmen
eingeführt werden.
› Zustimmung bei Änderungen an der SoD-Matrix/Zugriffsrisiken.
› Freigabe von kompensierenden Kontrollen in Hinblick auf die Angemessenheit der Kontrolle,
d.h. „eignet sich die Kontrolle, um das Zugriffsrisiko zu kompensieren“.
› Abnahme des Notfallbenutzer/-rollen-Verfahrens.
Zentrales Risikomanagement:
Aufgaben:
› Festlegung der Zugriffsrisiken in Übereinstimmung mit der konzernweiten Richtlinienvorgabe:

Definition der Zugriffsrisiken, Bestimmung der Risikostufe und des Risikoverantwortlichen.
Falls im Unternehmen ein Risikomanager verankert ist (Anmerkung: oftmals übernimmt dieser
auch die Funktion des Compliance Officers), so ist es dessen Aufgabe, die genaue Risikobewertung
für das Berechtigungsmanagement in Übereinstimmung mit der konzernweiten Richtlinien-
vorgabe festzulegen. Hierzu gehören die Bewertungsschemata für die Festlegung der Vertrau-
lichkeit, Verfügbarkeit und Integrität von Geschäftsinformationen und Ableitung der Risiko-
definitionen und Risikolevel. Diese Vorgaben müssen bei der Bewertung der Risiken von SAP
GRC Access Control und bei der Festlegung eigener Risiken durch die Risikoeigner der Fach-
bereiche berücksichtigt werden. Im späteren operativen Betrieb kann der Risikomanager als
überwachende Institution in den Provisionierungsprozess mit eingebunden werden. Er sollte
dann überwachen, dass die Risikobewertungen durch die Fachbereiche im Provisionierungs-
prozess und auch im Rollenänderungsmanagement entsprechend der Richtlinie durchgeführt
werden.
Risikoverantwortliche:
Pro Fachbereich oder auch Geschäftsprozess (Anmerkung: dies hängt von der Strukturierung des
Unternehmens ab) können Risikoverantwortliche für die Risiken des Fachbereichs festgelegt werden.
Dieser muss die Befugnis bekommen, die Risikolevel und auch Risikodefinitionen im Namen des
Fachbereichsvorstands oder Geschäftsprozesseigners festlegen zu dürfen. Hierfür benötigt er die
Unterschriftsberechtigung. Auch muss der Risikoeigner später bei jedweder Beantragung zur
Änderung einer bestehenden Risikodefinition seine Genehmigung erteilen.
47
Kontrollverantwortliche:
Auch bei der Festlegung von kompensierenden Kontrollen zur Eindämmung des Risikos, falls
Benutzer auf Grund ihrer Berechtigungen als kritisch einzustufen sind, muss ein Eigner zur Festle-
gung der Kontrolle aus dem betroffenen Fachbereich oder Geschäftsprozessbereich festgelegt
werden. Der Eigner muss dabei nicht selbst die notwendigen Kontrollschritte durchführen, sondern
muss die Inhalte, Dokumentationspflichten und den Kontrollausführenden festlegen. Der Eigner
hat Sorge zu tragen, dass die Kontrolle zudem in der vorgesehenen Frequenz durchgeführt wird.
Zudem muss er die Ergebnisse kontrollieren und bei entsprechender Identifikation von Verstößen
oder Irregularitäten die entsprechenden Schritte zur Auflösung der Irregularität einleiten. Hierzu
muss zudem ein klarer Eskalationsweg festgelegt werden. Es ist möglich, dass die Position Risiko-
eigner und Eigner einer hierfür notwendigen kompensierenden Kontrolle durch eine Person über-
nommen wird. Wieder ist es notwendig, dass bei einer Neuanlage einer kompensierenden Kontrolle
oder auch bei der Änderung einer bestehenden Kontrolle der Eigner des Fachbereichs involviert
wird und dieser zustimmt.
Rollenverantwortlicher/Datenverantwortlicher:
Eine sehr wichtige Voraussetzung für den Einsatz von SAP GRC Access Control ist die Bestimmung
von Rollenverantwortlichen aus den Fachbereichen, die bei entsprechender Anfrage einer Rolle
durch einen Anwender um Zustimmung gefragt werden. Die Rollenverantwortlichen werden in
der Regel auf Basis der Datenverantwortlichkeit festgelegt. Der Rollenverantwortliche muss bei
jedem Antrag entscheiden, ob der angeforderte Benutzer Zugriff auf die Daten erhält oder nicht.
Interne Revision:
Aufgaben:
› Überprüfung der kompensierenden Kontrollen in Hinblick auf Angemessenheit, Funktions-

fähigkeit und somit Wirksamkeit.
Die interne Revision sollte bei der finalen Abnahme der Risikomatrix beteiligt werden. Zudem muss
die Einhaltung der Prozesse und Änderungsbelege durch Internal Audit überprüft und überwacht
werden.
Informationstechnologie (SAP Competence Center):
Das-SAP Berechtigungsteam, das früher vor allem ausführende Befugnis hatte, wird durch den
Einsatz von SAP GRC Access Control in eine mehr beratende und überwachende Funktion zurück-
48
gedrängt. Es ist Aufgabe des SAP-Berechtigungsmanagement-Teams, das „Funktionieren“ der Pro-

zesse sicherzustellen und auch beratend für die Fachbereiche tätig zu sein. Zudem sollten nach
wie vor das Berechtigungsdesign und die dafür notwendigen technischen SAP-Rollen in der ersten
Implementierung durch Enterprise Role Management in der Führung bleiben. Es sollten hierzu
die fachlichen Anforderungen aus den Fachbereichen aufgenommen werden und anhand des vor-
gegebenen Rollenkonzepts in eine technische Umsetzung überführt werden. Bei entsprechender
Änderung einer bestehenden Rolle oder Aufsetzung einer neuen Rolle muss aber auf jeden Fall der
Rolleneigner des Fachbereichs zustimmen und entsprechend auf Vorhandensein eines Risikos hin
überprüfen. Auch muss der SAP-Betrieb die notwendigen technischen Änderungen für die Lösung
selbst durchführen und wie bei jeder anderen SAP-Software selbst die technische Überwachung
durchführen und somit den Betrieb sicherstellen.
6.1.3 CHANGE MANAGEMENT POLICY + RISIKOPOLICY
Durch die Einführung von SAP GRC Access Control werden Prozesse wie Benutzermanagement-
prozess, Rollenmanagementprozess und Superuser-Managementprozess in das Unternehmen
eingeführt. Des Weiteren müssen noch zusätzlich die Prozesse zur Verwaltung des Regelwerks
und der Zugriffsrisiken sowie die Verwaltung der kompensierenden Kontrollen festgelegt werden.
Sowohl die Aufbauorganisation als auch die Ablauforganisation und relevante Vorgaben sollten in
einer Richtlinie dokumentiert werden.
Die Richtlinie sollte Vorgaben hinsichtlich der Aufnahme und Festlegung von Zugriffsrisiken bein-
halten, d.h., wann wird ein Risiko mit welcher Risikostufe im System aufgenommen und welche
verantwortlichen Bereiche müssen zustimmen.
Vorgaben für Risikostufen:
Als Grundlage für die Festlegung von Risiken könnte beispielsweise eine Bewertung der im Ge-
schäftsprozess verarbeiteten Informationen vorgenommen werden, die auf Basis von Vertraulich-
keits-, Integritäts- und Verfügbarkeitsanforderungen bewertet werden. Dadurch könnte bereits ein
Zugriffsrisiko bei der Anzeige von Stücklisten für ein Unternehmen existieren, falls diese Information
einen bedeutenden Wettbewerbsvorteil für das Unternehmen darstellt. Auch bei Finanztransaktions-
daten kann es aufgrund der hohen Integritätsanforderung notwendig sein, dass ein Vier-Augen-
Prinzip bei der Weiterbearbeitung erforderlich ist, um betrügerischen Handlungen oder auch einfach
„fahrlässigen“ Freigaben entgegenzuwirken.
Risiken, die durch betrügerische Handlungen oder einfach durch Fahrlässigkeit begründet sind
und die demnach einen direkten hohen materiellen und/ oder finanziellen Schaden nach sich ziehen
können, sollten als hoch eingestuft werden.
Risiken, die zu einem Reputationsschaden führen können oder die z.B. auch durch die Verletzung
der Vertraulichkeit von Informationen (Preisinformationen, Materialstammdaten, spezifische Stück-
listeninformationen, Gehaltsdaten etc.) hervorgerufen werden, sollten als hoch eingestuft werden.
Zu dieser Klasse sollten auch Risiken in Hinblick auf Betrug zugeordnet werden, die nicht zu einem
49
direkten materiellen oder finanziellen Verlust führen können, wie z.B. fiktive Kundengeschäfte zur
„Steigerung“ des Unternehmenswertes.
Zu den mittleren und niedrigen Risiken gehören Risiken wie bspw. das Kontieren von Kosten auf eine
falsche Kostenstelle, was jedoch keine Auswirkungen auf die Gesamtbilanz hat.
Zusammengefasst ist es bei der Einführung von SAP GRC Access Control wichtig, dass Vorgaben
in Form einer Richtlinie den später im Änderungsmanagement von Rolleninhalten (also letztend-
lich den SAP-Berechtigungen) und Rollenzuordnungen zu Endanwendern beteiligten Entscheidern
(hauptsächlich Rolleneigner, Risikomanager und Linienvorgesetzte) hilft, die Entscheidungen auf
Basis einer klaren Richtlinie und nicht auf Grund von „Gefühlen“ zu treffen.
Das Gleiche gilt indes auch für die Definition der Risiken durch Risikoverantwortliche bzw. das
Risikomanagement. Hier sollten Vorgaben existieren, in welchem Fall ein Risiko als hoch, mittel
oder niedrig einzustufen ist.
Vorgaben für die Kompensierung von Zugriffsrisiken:
Im Benutzermanagementprozess werden im Betrieb Berechtigungen für Benutzer von SAP- und/

oder Nicht-SAP-Systemen beantragt. Im Falle, dass ein Antrag Risikoverletzungen beinhaltet,
müssen Vorgaben existieren, wie mit den Risiken basierend auf ihren Stufen umgegangen werden
muss. Beispielsweise könnte es die Vorgabe geben, dass hohe Risiken niemals eingegangen werden
dürfen und somit der Antrag immer abgelehnt werden müsste. Im Falle von mittleren Risiken
müsste zumindest eine kompensierende Kontrolle zugeordnet werden und niedrige Risiken dürfen
eingegangen werden.
Prozessdefinitionen:
Des Weiteren sollte die Richtlinie die folgenden Prozesse basierend auf den implementierten
Komponenten von GRC Access Control definieren, wobei mit Verwaltung immer das Anlegen,
Ändern oder Löschen des entsprechenden Geschäftsobjekts gemeint ist:
› ARA: Verwaltung der Zugriffsrisiken

› ARA: Verwaltung der kompensierenden Kontrollen
› BRM: Verwaltung der Rollen der angebundenen Systeme
› ARM: Verwaltung der Benutzer der angebundenen Systeme
› EAM: Superuser-Management: Für welche Szenarien wird das Superuser-Management eingesetzt.
› EAM: Superuser-Management: Verwaltung der Notfallbenutzer, Verantwortlichen und Kontrolleur
für ein entsprechendes Szenario
6.1.4 REPORTING / MONITORING
Einer der wichtigsten Vorteile, der durch den Einsatz von SAP GRC Access Control gegenüber
traditionellen SAP-Tools (PFCG, SU01 etc.) entsteht, ist die Möglichkeit, für alle durchgeführten
50
Änderungen an Rollen und Rollenvergaben Änderungsprotokolle zu führen, die für einen späteren
Audit die entsprechende Evidenz bereitstellen (Audit Trail). Durch die Änderungsbelege werden die
gesetzlichen Vorgaben und auch die Ziele der internen Kontrolle effizienter erreicht. Zudem können
auch freiwillige Compliance-Vorgaben für Security-Normen, wie z.B. der ISO 27001/2-Norm,
einfacher erfüllt werden.
Eine weitere und sehr wichtige Funktion von SAP GRC Access Control ist aber durch die geordnete
Protokollierung von Aktivitäten und durchgeführten Änderungen im SAP-System gegeben, wodurch
ein Superuser-Management erreicht werden kann. In diesem Fall werden höhere Berechtigungen
nur temporär an Antragsteller vergeben und der Antragsteller muss auch eine Begründung angeben,
warum sie/er die höheren Berechtigungen für den Geschäftsprozess benötigt. Diese Begründung ist
ebenfalls als Auditevidenz später verwendbar. Zudem wird bei der Annahme der höherwertigen
Berechtigungen auch die Protokollierung im SAP-System gestartet und die Aktivitäten des Benut-
zers mit protokolliert. Diese Änderungsbelege müssen dann durch den Eigner der Superuser-Id im
Nachgang ausgewertet werden und bei entdeckten Unregelmäßigkeiten müssen die Gegenmaß-
nahmen über die Eskalationswege ausgelöst werden.
Folgende Grundregeln sollten bei der Einführung eines Superuser-Access-Managements berück-

sichtigt werden, bzw. in der Richtlinie festgehalten werden:
1. Das Superuser-Access-Management darf nur für den Notfall verwendet werden, da ansonsten
die Gefahr besteht, dass die höherwertigen Berechtigungen für das Tagesgeschäft verwendet
werden und nicht für den Notfall. Das eigentliche Berechtigungskonzept würde auf diese Weise
unterlaufen werden.
2. Den Superuser-IDs sollten keine SAP_ALL-Berechtigungen zugeordnet werden, sondern

wirklich nur höherwertige Berechtigungen beinhalten, die für den jeweiligen Fachbereich im
Notfall notwendig sind. So z.B. für den IT-Bereich die Berechtigung „Öffnen des Mandanten“
in einer dedizierten Superuser-ID. Das Gleiche z.B. für den Fachbereich Finanzen und Cont-
rolling, wie z.B. „Kontenplan anpassen“.
3. Die Eigner der jeweiligen Superuser-IDs müssen verpflichtet sein, die Änderungsbelege nach
deren Gebrauch durch einen Antragsteller zu reviewen und nach entsprechenden Unregel-
mäßigkeiten zu untersuchen. Bei einer entsprechenden Identifikation einer solchen Unregel-
mäßigkeit sind die Eigner verpflichtet, über einen vorgegebenen Eskalationspfad Gegenmaß-
nahmen einzuleiten.
4. Bei jeder Beantragung einer Superuser-ID sollte eine nachvollziehbare Begründung durch den
Antragsteller gegeben werden.
5. Das Recht, eine bestimmte Superuser-ID für den Notfall verwenden zu dürfen, sollte nur auf Zeit
vergeben werden und nicht auf Dauer.
6.1.4.1 Reporting der Risikoanalyse
Eine wichtige Eigenschaft von SAP GRC Access Control ist die Möglichkeit des Reportings auf
51
verschiedenen Managementebenen. Aus grafisch aufbereiteten zusammenfassenden Berichten
für das obere Management besteht die Möglichkeit, im Drill-down-Verfahren bis auf Detailberichte
zu navigieren. Berechtigungsadministratoren werden durch Detailberichte der Benutzer-, Rollen-
und Profilanalyse in ihrer täglichen Arbeit unterstützt. Das Authorisierungskonzept im SAP GRC
Access Control ermöglicht dabei die Strukturierung der Zugriffsebenen. Die Reportingstrukturen
werden durch spezielle Risikoanalysen der Hintergrundverarbeitung (BRA – Batch Risk Analysis)
gefüllt und stehen dann bis zum nächsten BRA-Lauf unverändert zur Verfügung. Die Daten des
letzten BRA-Laufes eines Monats werden festgeschrieben und stehen anschließend für historische
Auswertungen und Vergleichsanalysen sowie für Trendanalysen zur Verfügung.
6.1.4.2 Berichte der Zugriffsanforderung
Die Aktivitäten der Benutzer- und Berechtigungsadministration im Bereich des GRC AC Access
Request Management werden lückenlos protokolliert und stehen insbesondere für Auditierungs-
zwecke zur Verfügung. Benutzer- und Rollenanforderungen werden mit Hilfe des SAP Standard
Workflow prozessiert, wobei jeder Anforderungs- und Genehmigungsschritt protokolliert wird
und detailliert ausgewertet werden kann. Die üblichen formularbasierten oder ticketbasierten
Protokollierungsverfahren sind somit obsolet oder dienen bei einem möglichen Ausfall des GRC-
AC-Systems als Ausnahmeverfahren. Für den Fall von auftredenden Risiken bei der Rollenvergabe
werden die Aktivitäten zur möglichen Mitigierung des Riskos ebenfalls protokolliert und stehen
dem Reporting zur Verfügung.
6.1.4.3 EAM-Verwaltungsberichte
SAP GRC Access Control ab Version 10.0 stellt ein zentrales Verfahren zur Einrichtung, Verwaltung
und zur Auswertung des Emergency Access Management (EAM, FireFighter) zur Verfügung. Die
zentrale Zuweisung von Benutzern zu FireFightern, die Nutzung von FireFightern und die Prozes-
sierung der Protokolle können im Reporting nachverfolgt und belegt werden. Gleiches gilt für die
Nutzung des rollenbasierten EAM.
6.1.5 OPERATIVE EINZELAUFGABEN UND PROJEKTPLANUNG
› Projektplan-Entwurf: Wie für jedes andere Projekt auch muss in der Strategie & Planungsphase
ein detaillierter Projektplan inkl. des Projektteams festgelegt werden. Ganz wichtig ist die Einbe-
ziehung der Fachbereiche in die Kommunikation und deren Unterstützung, da diese später
Veränderungsprozesse mitinitiieren (Rolleneigner). Themen des Projektplans sind Rollenkonzept
(inkl. Umgang mit den neuen Business Roles) und auch die Festlegung der Risikomatrix.
› Projekt-Kick-off: In einem initialen Meeting werden nochmals die genauen Ziele des Projektes,
der vorgesehene Zeitplan, die zu erarbeitenden Arbeitsergebnisse und das Team selbst vorgestellt.
› Analyse des bestehenden SAP-Berechtigungskonzepts: Mit Hilfe einer sorgfältigen Analyse

muss der derzeitige Status quo des SAP-Rollenkonzepts, Informationseigentümerprinzip,
Rollenstruktur, Vererbung, existierendes Beantragungswesen, Prozesse der Rollen- und
52
Berechtigungspflege und -administration sowie eventuell bestehende Risikomatrix und Risiko-

managementprozesse evaluiert werden. Ziel ist festzustellen, inwieweit der „Reifegrad“ für die
Einführung von SAP GRC Access Control in der Organisation vorhanden ist.
Das Berechtigungskonzept in einer IT-Landschaft ist die Basis für die Benutzerzuordnung und
damit für ein Identity-Management (IdM), für die Steuerung von Abläufen und Prozessen, für
Audits und Compliance, für das interne Kontrollsystem mit Risikomanagement, um nur einige
aufzuzählen. Dabei lauten die Anforderungen:
› sichere Zugriffe auf Funktionen und Daten

› Risikoüberwachung mit Funktionstrennung oder Kontrollen
› Flexibilität bei Rollenanpassung (z.B. bei organisatorischen Änderungen) und Transparenz
für die Fachbereiche (z.B. für die Beantragung)
› klare Verantwortlichkeit für die Rechte (Rolleneigner)
› einfache Bearbeitung, Change-Management und kontinuierliche Qualitätssicherung
› Risikoüberwachung /
Funktionstrennung
› Flexibilität und Transparenz
› klare Verantwortlichkeit
› Unternehmensleitung
(Data-Owner-Konzept)
› Organisation
› einfache Bearbeitung,
› Wirtschaftsprüfer
Change-Managment und
› interne Revision
Qualitätssicherung
› Gesetze und Verordnungen
› Investitionsschutz und
› ...
Wirtschaftlichkeit
Prozesse Benutzer- Audits IKS / Lizenzierung Programm- e SOA

Abläufe verwaltung Compliance Risiko-MGmt Navigation
Abbildung 7: Anforderungen an ein Berechtigungssystem

53
Allerdings ist es selbst bei einem zunächst sehr stringent aufgebauten Berechtigungswesen durch-
aus typisch, dass sich mit der Zeit Rechteanhäufungen ergeben. Ursache hierfür sind die normalen
Änderungsprozesse der funktionalen Rollen und Aufgaben im Unternehmen, die sich über Jahre
hinweg durch diverse Einflüsse (Upgrade, neue Organisationseinheiten, geänderte Prozesse, neue
Module, externe User) ergeben. SAP-ERP (ABAP-Stack) besitzt ein sehr umfangreiches Berechti-
gungs- und Rollensystem, durch das es möglich wird, beinahe alle Belange von Zugriffen einzu-
schränken und auch sehr selektiv Daten schützen zu können. Diese vielfältigen Möglichkeiten brin-
gen jedoch zwangsläufig auch eine Komplexität mit sich, die ab einem gewissen Verflechtungsgrad
von Rollen, Profilen und Berechtigungsobjekten kaum noch durchschaubar ist. Aus diesem Grund
ist eine genaue Analyse des Zustands des Berechtigungswesens zwingend erforderlich: Entweder
ergibt sich aus dieser als Ergebnis ein falsches Design (bzw. die Anforderung an einen mehr oder
minder vollständigen Neubau des Berechtigungswesens) oder lediglich eine überschaubare
Anhäufung von Verletzungen von Funktionstrennungsanforderungen mit der Möglichkeit einer einfa-
chen Bereinigung. Für beide Situationen kann dann GRC Access Control mittels der Risikoanalyse-
Komponente unterstützend eingesetzt werden.
Die Ergebnisse der Bewertung (Redesign oder Bereinigung) fließen dann entsprechend in die
endgültige Projektplanung ein.
Unterstützend sollte in dieser Phase GRC Access Control als Werkzeug bereits zum Einsatz kommen.
Dabei reicht die Installation eines Entwicklungssystems oder ggf. sogar eine Sandbox-Installation,
da lediglich die Risikoanalyse verwendet wird.
Die Strategiephase muss die technische Installation von SAP GRC Access Control berücksichtigen.
Dort wird das bestehende SAP-Rollenkonzept hinsichtlich seines „Reifegrades“ bezüglich beste-
hender Risiken (Segregation of Duties, kritischer Transaktionen) überprüft und auch das Kernpro-
jektteam hinsichtlich der Verwendung der Lösungskomponenten von SAP GRC Access Control
geschult. Zu diesem Zweck sollte die Lösung auf einer Entwicklungsumgebung installiert werden
und mit dem entsprechenden SAP-Backendsystem (am besten demjenigen, in dem die Hauptge-
schäftsprozesse implementiert sind) verbunden werden. Dieses Backendsystem sollte das Rollen-
konzept der Produktionsumgebung beinhalten.
Zwei Möglichkeiten zur Durchführung der ersten Risikoanalyse bieten sich an:
› man verwendet die mitgelieferten umfangreichen Standardprüfregeln (Normalfall) oder
› man erstellt – ggf. auf Basis des mitgelieferten Standards – unternehmensindividuelle Prüfregeln.
Welche Variante auch immer gewählt wird: Das Ergebnis wird eine Vielzahl von potenziellen
Risiken liefern, unabhängig davon, ob „nur“ auf Berechtigungsebene oder auch auf Benutzerebene
(mit oder ohne Einbeziehung der Berechtigungsobjekte) analysiert wird.
54
Die mitgelieferten Prüfregeln innerhalb von SAP GRC Access Control sind vollumfänglich für große
Unternehmen vorgefertigt und enthalten eine Vielzahl von Risiken mit kritischen Funktionskombi-
nationen – abgeleitet aus den Erfahrungen einer Vielzahl von Revisionsprüfungen. Jede dieser
dort beschriebenen Funktionen besteht aus einer bis zu mehreren Transaktionen. Bei der Analyse
werden diese Funktionen in ihre Transaktionen – und ggf. auch in die Berechtigungsobjekte –
aufgelöst, was die Risikomatrix erheblich vergrößert. Sollte jedoch dieser Ansatz gewählt werden,
empfiehlt es sich, ggf. gleich noch einige sehr kritische Funktionen (keine SoD-Konflikte) im Basis-
umfeld mit aufzunehmen. Dies sind insbesondere die Berechtigungen zum Debugging mit Replace,
die Berechtigungen zum Import von Transportaufträgen, die Berechtigungen zum Einstellen von
System- und Mandantenänderbarkeit sowie die Berechtigungen zum elektronischen Radieren
(Löschen von Änderungsbelegen, Version etc). Diese sind im SAP-Standardregelwerk in der Form
nicht enthalten.
Ein erster Durchlauf von ARA ergibt oft Risikoberichte mit Risikoverletzungen im fünf- und mehr-
stelligen Bereich. Dies sollte nicht abschrecken, denn solche Ergebnisse sind typisch und bei einem
gewachsenen Berechtigungswesen durchaus normal, selbst wenn dieses augenscheinlich gut ge-
pflegt sein sollte. Insbesondere SAP_ALL-Zuweisungen oder die Zuweisung ähnlich umfangreicher
Rollen und Profile ergeben eine erhebliche Anzahl von Risikoverletzungen, die aber mit einfachen
Mitteln dann auch schnell verringert werden können mittels Reduzierung des Rollenumfangs oder
Anpassung der Benutzer. Allerdings erschweren diese Ergebnisse, die ja zunächst nur für eine
Bewertung von Redesign vs. Bereinigung verwendet werden sollen, zunächst entsprechende Schluss-
folgerungen. Daher sollte dieser Ansatz mit Umsicht gewählt werden.
Grundsätzlich muss das Ergebnis dieser Risikoanalyse zuallererst so reduziert werden, dass
eine diskussionsfähige Auswertung nur noch die Risiken aufweist, die für IT, internes Audit und
Fachbereiche verständlich, bewertbar und entscheidungsfähig sind. Erst im weiteren Verlauf des
Projektes kann dann die Kontrollmatrix auf die Governance-Anforderungen des eigenen Unter-
nehmens angepasst werden, damit daraus letztendlich saubere, überschaubare und transparente
Funktionstrennungsvorschriften bzw. kompensierende Kontrollen ableitbar sind.
Die ersten umfänglichen Risikoanalyseergebnisse sollten nach folgender Methode überarbeitet

werden:
› Schritt Benutzer ausklammern: mögliche Poweruser (mit Administration- und Notfallrechten)

aus der Analyse ausschließen, da diese später sowieso mit Kontrollen versehen werden. Ebenso
die User ausschließen, die später keine Rolle mehr spielen (z.B. spezielle Notfalluser!).
› Schritt Transaktionsgleichheit: die Risiken nachbearbeiten bzw. löschen, in denen rechts und
links dieselbe Transaktion als Konflikt steht (dabei ggf. Berechtigungsausprägung beachten!).
› Schritt Kreuzkonflikte: die Kreuz-Risiken nachbearbeiten bzw. löschen, wo im Risiko (a) TR1
mit TR2 im Konflikt und im Risiko (b) TR2 mit TR1 im Konflikt stehen (dabei ggf. Berechtigungs-
ausprägung beachten!).
55
› Schritt prozessualer Verbund: Separierung der Transaktionen in unterschiedliche Einzelrollen,
wenn eine Trennung dieses Transaktionspaares operational unschädlich ist (der Prozessdurchlauf
dadurch nicht behindert wird!).
Ein weiterer Durchlauf der Risikoanalyse – nach Überarbeitung der Prüfregeln – wird den Erfolg
zeigen; ggf. muss dieses Verfahren ein weiteres Mal (iterativ) durchgeführt werden, um zum
gewünschten diskutablen Ergebnis zu gelangen.
Das geschilderte Verfahren bezieht sich auf die Standard-Transaktionen. Zusätzliche Risiken können
sich wegen der Nutzung eigenentwickelter Transaktionen ergeben. Hier hilft ein meist nur mittel-
fristig realisierbares Konzept der Analyse dieser Y-/Z-Transaktionen. Dabei erkennbare kritische
eigenentwickelte Transaktionen müssen in die Risiko- und Funktionsdefinition mit aufgenommen
werden, um später eine umfassende, unternehmensweite Kontrolle durchführen zu können.
Sind bei einem erneuten ARA-Durchlauf dieser dann „überarbeiteten und gefilterten“ Analyse
immer noch zu viele Risiken übrig geblieben und nicht mehr einfach aufzulösen (Anzahl sowie Art),
muss entschieden werden, ob das bestehende Rollenkonzept ggf. komplett neu entworfen werden soll.
Darüber hinaus sind folgende Risikomanagement-Richtlinien festzulegen:
› Verantwortung für die Definition von Risikoregeln wie Funktionstrennungsrisiken, kritische

Transaktionen und kritische Leseberechtigungen,
› Verantwortungen für die Definition von kompensierenden Kontrollen,
› Festlegung der Risikolevel und Bewertung der bestehenden Risiken,
› Festlegung der Richtlinie für die Ablehnung/Zustimmung mit kompensierenden Kontrollen
für Berechtigungsanfragen,
› Festlegung einer Richtlinie für den Superuser-Zugriff („Firefighter-Konzept“),
› Festlegung der Rollen im Risikomanagementprozess wie z.B. Compliance Management,
Risikoeigner und Verantwortlicher von kompensierenden Kontrollen.
Im Zusammenhang mit SAP GRC Access Control muss festgelegt werden, ob SAP GRC Access
Control das führende (zentrale) Benutzermanagement-System sein soll, das die weitere Provi-
sionierung der Identitäten in die Zielsysteme durchführt. Hierzu muss untersucht werden, ob SAP
GRC Access Control eventuell auch an ein bestehendes oder neu einzuführendes Identity-Manage-
ment-System angeschlossen werden soll. Ziel dieses Arbeitspakets ist es, die bestehenden Identity-
Management-Prozesse und Genehmigungs-Workflows für die Verwendung von SAP GRC Access
Control anzupassen.
Für SAP GRC Access Control muss ein Architekturkonzept in Abhängigkeit der gewünschten oder
vorgeschriebenen Systemarchitektur, z.B. „Drei Systemlandschaft“ wie Entwicklung, Qualitäts-
sicherung und Produktion, festgelegt werden. In Abhängigkeit der gewählten Systemlandschaft
müssen die Verfahren für technische Änderungen an der Lösung, Rollen- und Risikomatrixände-
rungen sowie Benutzermanagement definiert werden (wo wird getestet, wo wird genehmigt/verteilt
und mit was für Ständen).
56
Es ist ratsam, schon in der Strategiephase ein erstes Training für das Kernteam aller Komponenten
von SAP-GRC Access Control durchzuführen. Dies ermöglicht, die Übertragung der Konzepte auf
die Anforderungen der SAP-GRC-Lösung zu erleichtern.
Strategischer Meilenstein für Neuentwicklung Rollenkonzept oder Adaption des bestehenden

Konzeptes: Ein wichtiger Meilenstein ist die Entscheidung für die eventuell komplette Neuentwick-
lung des Rollenkonzeptes oder dessen sanfte Anpassung. Auf Grund des Resultats der initialen
Risikoanalyse mit dem bestehenden Rechtesystem und der Anzahl und Art von aufgetretenen
Risiken, der genauen Zuordnung von Rollen zu einem eindeutigen Rolleneigner und der Rollen-
struktur muss entschieden werden, ob eine komplette Überarbeitung des SAP-Rollenkonzeptes zur
Einführung von SAP GRC Access Control sinnvoll, machbar und wirtschaftlich vertretbar ist. Sind
die bestehenden Konflikte eher gering und können eindeutige Rolleneigner aus den Fachbereichen
zugeordnet werden, so kann das Rollenkonzept auch entsprechend durch einfacheres „Splitten“
von den Konflikten bereinigt werden. Falls sehr viele Konflikte vorhanden sind, kann mit einem
Reverse-Business-Engineering-Ansatz oder mit einem funktionsorientierten ReDesign-Ansatz das
SAP-Rollenkonzept recht effektiv auf die Anforderungen von SAP GRC Access Control angepasst
werden.
Es ist nicht einfach, den Ressourcenbedarf für Anpassung oder Überarbeitung bzw. Neuerstellung
bei hohem Sicherheits- und Qualitätsanspruch, Erfüllung der Vorschriften sowie einer sehr guten
Transparenz (verständliche revisionsgerechte Dokumentation) zu quantifizieren. Zwingend ist
jedoch, diese Zahlen zu ermitteln und miteinander zu vergleichen, das Für und Wider abzuwägen
und sich dann für einen der Wege festzulegen. Für das Reverse Business Engineering und auch
für das funktionsorientierte Redesign existieren auf dem Markt Werkzeuge und Methoden, die das
Projekt erleichtern und auch zeitlich deutlich verkürzen. „Nur“ eine einfache Überarbeitung der
betroffenen Rollen stellt sich bei komplexen Berechtigungskonzepten aus Erfahrung immer als
schwieriger und langwieriger dar als gedacht.
Finalisierung des Projektplanes: In Abhängigkeit von den getroffenen strategischen Entscheidun-

gen und Konzepten muss der Projektplan angepasst werden. Der Aufwand sollte neu evaluiert und
festgelegt werden, zudem muss der Zeitplan nochmals abgestimmt und verabschiedet werden.
Danach ist die Strategiephase abgeschlossen.
57
6.2 PHASE SOLLKONZEPTION („BUSINESS BLUEPRINT UND DESIGN“)
In der Business-Blueprint-Phase werden die getroffenen strategischen Konzepte weiter verfeinert

und im Detail festgelegt. Dies kann nun im Wesentlichen für die vier Hauptkomponenten von SAP
GRC Access Control „Risikoanalyse und Beseitigung“, „Unternehmensweites Rollenmanagement“,
„Management von Superuser-Berechtigungen“ sowie „Regel- und gesetzeskonforme Berechti-
gungsvergabe“ durchgeführt werden, wobei übergeordnete Aspekte wie technische Architektur und
auch Risikomanagementprozessdesign und Organisation (Definition von Rollen für die Verwendung
von SAP GRC Access Control selbst) für alle Komponenten betrachtet werden müssen. Auch sollte
in dieser Phase schon ein entsprechendes Testkonzept der Prozesse und Integrationsabläufe fest-
gelegt werden.
Die folgenden Hauptarbeitspakete sollten pro Komponente betrachtet werden.
6.2.1 ORGANISATORISCH/TECHNISCHER BETRIEB
Zunächst sollte festgelegt werden, ob auf einer zentralen Plattform ggf. ein verteilter Betrieb in der
Organisation notwendig ist und wie stark die jeweilige Separation der Anwendergruppen und Daten
im System ausgeprägt sein muss, ohne umfangreich administrativ doppelt Pflegetätigkeiten ausüben
zu müssen. Ergebnis dieser Überlegungen sollte sein:
› Werden ein oder mehrere Produktivsysteme benötigt? (Ggf. immer wieder Replikationen eines
Risikomatrix-Standards notwendig, dafür aber evtl. der Patch-Prozess auch einfacher)
› Werden bei einem Produktivsystem mehrere Mandanten benötigt?
› Kann ggf. mit einem Produktivsystem und einem Mandanten (und entsprechend gemeinsamen
Daten) gearbeitet werden mit reiner Aussteuerung der gewünschten Separation über das
Berechtigungswesen im SAP GRC Access Control?
Zur Bewertung dieser Punkte empfiehlt es sich auch, den Security Guide zu SAP GRC Access Control
zurate zu ziehen, um die Möglichkeiten bei der Berechtigungsaussteuerung abschätzen zu können.
Grundsätzlich muss hier auch bei der gewünschten organisatorischen Separation eine Abwägung
mit den Kosten der jeweiligen Lösung durchgeführt werden.
Ein wichtiger Punkt, den es dabei besonders zu berücksichtigen gilt, ist der von der SAP festgesetzte
Kopplungsbetrieb mit den in den Backends installierten Plug-ins: Bis SAP GRC Access Control
10.0 SP9 arbeiten die jeweiligen Frontend-SPs nur mit ausgewählten Backend-SPs zusammen,
eine Abwärtskompatibilität wurde nicht zugesichert. Dies hat insbesondere bei einer höheren
Anzahl von angeschlossenen Backends ganz erhebliche Auswirkungen auf die Patch-Strategie und
Wartungsfenster für die Applikation, da gerade bei großen verteilten Organisationen kaum ein ge-
meinsames Patch-Wochenende gefunden werden kann.Daher müssen bei AC5.3 und bei AC10.0
mit Patchständen kleiner SP10 vorab ggf. umfangreiche Tests mit SP-Kombinationen durchgeführt
werden, deren Kombinations-Betrieb die SAP nicht zusichert. Hierzu ist eine genaue Betrachtung
des Hinweises 1352498 („SAP GRC Access Control: Support-Package-Nummerierung“) ratsam.
Zu beachten gilt aber auch hier die Möglichkeit der Einspielung von Vorabkorrekturen, die diese
Problematik einigermaßen abschwächt.
58
6.2.2 ARCHITEKTUR & TECHNOLOGIE:
› Detaillierter Blueprint der technischen Architektur: In der Designphase sollte der Blueprint
der technischen Architektur festgelegt werden. Es sollte zudem ein Staging-Konzept inklusive
Entwicklungs-, Qualitätssicherungs- und Produktionsumgebung für die Lösung SAP GRC
Access Control festgelegt werden. Dies sollte auch die Änderungsmanagementprozesse für die
Rollen und technische Upgrades berücksichtigen. So sollte betrachtet werden, dass z.B. Rollen-
änderungsprozesse auf der Entwicklungsumgebung stattfinden und entsprechend nach Freigabe
über das Transportwesen in die Produktionsumgebung über den Schritt Qualitätssicherung
transportiert werden. Die Provisionierung zu den Anwendern kann in der Produktionsumgebung
erfolgen. Zudem muss der führende Benutzerspeicher festgelegt werden, von welchem aus die
Provisionierung in die Zielsysteme stattfinden kann. Diese Aspekte sind maßgebende Einfluss-
faktoren für die technische Architektur.
Des Weiteren muss die Integrationsarchitektur mit einem möglichen Identity & Access
Management System (z.B. SAP NetWeaver Identity Management) festgelegt werden. Hierzu
müssen die technischen Schnittstellen und Konnektoren für die Directory Services im Detail
ausgewählt werden.
Sollen Non-SAP-Systeme mit angebunden werden, so stehen beispielsweise für Oracle Finan-
cials, JD Edwards, Peoplesoft entsprechende Plug-ins zur Verfügung. Bei Anbindung einer ande-
ren Software sind ggf. eigenentwickelte Konnektoren zu verwenden. Bei den eigenentwickelten
Konnektoren ist das Matching der einzelnen Berechtigungselemente des Non-SAP Systems zu
den Feldern von SAP GRC Access Control zu beachten. Aufbauend auf diesem Matching ist auch
das Regelwerk entsprechend zu erstellen.
› Design der notwendigen Batchprozesse: Auch für SAP GRC Access Control müssen entspre-
chende Batchprozesse festgelegt werden, die z.B. den Abgleich der Berechtigungsvorschlags-
werte und Objekte aus den Zielsystemen regeln. Dies sollte entsprechend im Blueprint festgelegt
werden.
› Installations-, Konfigurations- und Betriebsmanual: Für die technische Installation und

Konfiguration muss ein kundenspezifisches Dokument erstellt werden, welches die notwendigen
Hauptschritte zur Installation und Konfiguration entsprechend dokumentiert. Dieses dient zudem
als Basis für ein Betriebshandbuch, das zum späteren Betrieb von SAP GRC Access Control
notwendig ist. Hier sollten z.B. die notwendigen Schritte zur Fehlerbehandlung und die Upgrade-
strategie (z.B. im Fall eines Upgrades auf einen neuen Regelsatz) festgelegt sein.
59
6.2.2.1 Harmonisierte Konfigurations- und Stammdatenverwaltung
Grundsätzlich bietet GRC Access Control eine vereinheitlichte Konfiguration und Stammdatenbasis
für alle Komponenten und Applikationen an. Hierzu ist daher in der Konzeptionsphase wichtig, zu
entscheiden, welche Komponenten und Applikationen ggf. gleichzeitig in einem Mandanten ver-
wendet werden. So ist z.B. zu beachten, dass bei einer gleichzeitigen Verwendung von GRC Access
Control und Process Control ggf. dasselbe Organisationsmanagement verwendet wird. Darüber
hinaus sind einige Schalter und auch Workflow-Elemente nur zentral konfigurierbar. Dies hat
einerseits Vorteile (keine Doppeltpflege), schränkt aber ggf. die Flexibilität ein.
6.2.2.2 Vereinheitlichtes User Interface & Bedienung
Die Einstiegspunkte und Funktionen der Komponenten (EAM, ARA usw.) sind auf einer für den NWBC
designten Oberfläche strukturiert und angeordnet. Über das Berechtigungswesen des ABAP-Sys-
tems gibt es hier umfangreiche Möglichkeiten, hier sowohl einzelne Einstiegslinks als auch ganze
Navigationsgruppen sichtbar oder unsichtbar (und damit nicht ausführbar) zu konfigurieren. Diese
Aussteuerung erfolgt dann rollenbasiert, d.h. je nach Rolle, die ein Anwender bekommt (SU01), kann
er Funktionen sehen und verwenden oder nicht. Dies sollte beim Design der Anwendergruppen und
der Benutzeroberflächengestaltung für diese berücksichtigt werden. Die zusätzlichen Bedienungs-
merkmale der Webdynpro-ABAP-Oberfläche sowie die Verwendung von personalisierten Queries
und ALV-Listen sollte in Trainingshandbücher für Endanwender mitaufgenommen werden, da sie
die Arbeit im SAP GRC Access Control erheblich vereinfachen und effizienter gestalten.
6.2.3 RISIKOANALYSE UND BEREINIGUNG
Bestimmung der wichtigsten Informationswerte der Geschäftsbereiche als Grundlage für die
Risikobewertung:
Eine wichtige Grundlage zur Bestimmung von Geschäftsrisiken, die durch betrügerische Hand-
lungen (wegen fehlender Funktionstrennung), kritische Transaktionen oder auch unberechtigte
Informationseinsicht hervorgerufen werden, ist die Bestimmung des Wertes der Informationen,
die in den Geschäftsprozessen verarbeitet werden. So sollte eine Vertraulichkeits-, Integritätsbe-
darfs- und Verfügbarkeitsklassifikation unter Mitwirkung der Fachbereiche festgelegt sein, die
entsprechend den Risikolevel bestimmen. Zum Beispiel kann auch schon die Einsicht in Konstruk-
tionsdaten in einem Maschinenbauunternehmen zu einem Risiko führen, wenn durch diese ein
bedeutender Wettbewerbsvorteil am Markt erzielt wird. Dieses Arbeitspaket wird empfohlen, ist
aber nicht unbedingt zwingend erforderlich, wenn das Unternehmen oder eine Organisation andere
Policies zur Risikobewertung eingeführt hat.
60
Festlegung der Zugriffsrisiken (kritische Displayrechte, Transaktionen und Betrugsrisiken

durch fehlende Funktionstrennung):
SAP GRC Access Control wird standardmäßig mit einem umfangreichen Satz an Prüfregeln aus-
geliefert, die ein Best-Practice-Katalog von Risiken darstellt. Viele Unternehmen übernehmen
diesen Risikoregelsatz direkt in ihren eigenen Risikokatalog. Trotzdem ist es sehr wichtig, dass
diese Risiken auf Grund der Bewertung der wichtigen Informationswerte und eigenen Geschäfts-
prozesse entsprechend mit den Fachbereichen auf deren Gültigkeit und auch des vorgegebenen
Risikolevels hin überprüft werden. Wird diese Risikobewertung nicht durchgeführt, ist oftmals die
Akzeptanz der Fachbereiche für die gewählten Risiken eher niedrig. Zudem sollten die Prüfregeln
durch kritische Berechtigungen und auch Displayrechte (welche über bestimmte Berechtigungsob-
jekte gesteuert werden können) sowie eigenerstellte Transaktionen ergänzt werden.
Die Festlegung der Risiken und Levels muss auf jeden Fall mit den Fachbereichen zusammen
geschehen. Zudem ist es von Vorteil, wenn ein Risikomanager die entsprechenden Workshops
leitet. Auch die Abteilung „Internal Audit“ sollte vor einer ersten Produktivsetzung die festgelegten
Risikodefinitionen akzeptieren.
Die Definition von Zugriffsrisiken muss als fortlaufender Compliance-Prozess innerhalb des Unter-
nehmens gesehen werden und fester Bestandteil des Gesamtrisikomanagements werden. Dies ist
dadurch begründet, dass sich Unternehmensprozesse ständig ändern und auch neue Funktionen
in SAP ERP, neue selbsterstelle Programme und andere Anwendungen ständig hinzukommen.
Festlegung von kompensierenden Kontrollen:
Für die im obigen Schritt festgelegten Risiken müssen entsprechende kompensierende Kontrollen
festgelegt werden, falls sich das Zugriffsrisiko z.B. durch Funktionstrennung (Trennung der SAP-
Rollen) oder auch durch entsprechenden Entzug der Berechtigungen nicht vermeiden lässt. Die
kompensierenden Kontrollen definieren dann die notwendigen detektivischen Maßnahmen, die
durchgeführt werden müssen, um z.B. betrügerische Handlungen schnell erkennen und entspre-
chend eindämmen zu können. Diese Kontrollen können teilweise manuell sein, wie z.B. die Durch-
führung einer Inventur des Lagerbestandes, oder aber auch mit Hilfe von SAP Reports, mit welchen
schnell analysiert werden kann, ob z.B. verdächtige Kontodaten bei Kreditoren eingepflegt wurden.
Die Durchführung von kompensierenden Kontrollen müssen einem Verantwortlichen zugeordnet
werden, der dafür Sorge trägt, dass die Kontrolle im vorgesehenen zeitlichen Intervall durchgeführt
und das Ergebnis der Kontrolle auch dokumentiert wird.
Die Ausarbeitung der kompensierenden Kontrollen sollte wiederum mit den Fachbereichen und
unter Beteiligung des Risiko-Managers erfolgen. Auch muss in diesem Zusammenhang eine
Richtlinie definiert werden, die genau in Abhängigkeit vom Risikolevel festlegt, ob ein Risiko im
Provisionierungsworkflow akzeptiert werden darf oder unbedingt mit einer kompensierenden
Kontrolle versehen werden muss.
61
Festlegung des Rollenkonzeptes für die Lösung SAP GRC Access Control selbst:
Auch für die produktive Anwendung der Lösung SAP GRC Access Control müssen über dessen
ABAP-basiertes Berechtigungswesen entsprechende Rollen definiert werden – siehe hierzu auch
die Anmerkungen oben zu ggf. gewünschten organisatorischen Separationen. Dies können z.B.
technischer Administrator, Risikomanager (Festlegung der Risikomatrix inkl. Level und kompensie-
renden Kontrollen), Approver (ist am Workflow z.B. beim Approval der Rollenzuordnung beteiligt)
und Auditor (Auswertung von Logs und Überprüfung der Einhaltung der Prozesse) sein. Bei einer
fein ausdifferenzierten Verteilung von Tätigkeiten bzw. Auftrennung von Organisationsbereichen
muss ein Namenskonzept z.B. für Risiken, Funktionen, Rollen, Regelwerke, mindernde Kontrollen,
Konnektoren usw. ein integraler Bestandteil des Berechtigungskonzeptes werden (z.B. Risikoad-
ministratoren aus Untergesellschaft A dürfen nur Risiken, die mit A* beginnen, pflegen und diese nur
an Regelwerke, beginnend mit A*, zuweisen). Die Rollen sollten entsprechend dokumentiert werden.
6.2.4 UNTERNEHMENSWEITES ROLLENKONZEPT
› Definition des Sollprozesses für die Änderung von Rollen: Der Prozessablauf von Änderungen
existierender Rollen sowie Erstellung neuer Rollen muss festgelegt werden, insbesondere mit
Hinblick auf die folgenden Fragestellungen:
I. Veränderungsmanagement: Wer kann Rollenänderungen beantragen / freigeben, wie

geschieht dies (z.B. über das Change Request Management des SAP Solution Managers)?
b. Abstraktionsebenen: Welche Rollentypen kommen zum Einsatz?

I. Einzelrollen
II. Masterrollen / Rollenableitungen
III. (SAP) Sammelrollen
IV. Businessrollen (nur mit externem Tool möglich – z.B. ID Mgmt oder BRM)
c. Rollendefinition: Wie ist die Namenskonvention für die Erstellung neuer Rollen, wer definiert
und klassifiziert die Rollen, welche Rollenattribute sind erforderlich / optional?
d. Berechtigungspflege: Wer führt die angeforderten Änderungen durch? Soll es möglich sein,
mithilfe des Business Role Management auf hinterlegte Funktionen zuzugreifen, die gleich-
artige Transaktionen zusammenfassen und auch im Rahmen der Risikoanalyse zum Einsatz
kommen?
e. Zugriffsrisikoanalyse: Welche Regeln gelten für die Risikoanalyse? Muss jede Einzelrolle /
Sammelrolle / Business Rolle konfliktfrei sein? Inwieweit kann die Risikoanalysesimulation
effektiv genutzt werden (Was für einen Impact hätte diese Rollenänderung auf Zugriffsrisiken
in der Produktivumgebung)?
f. Zugriffe auf Organisationen: Definition und Veränderungsmanagement für die Organisations-

sets, welche die Funktionen innerhalb der Rollen auf bestimmte Teilbereiche des Unter-
nehmens eingrenzen
62
g. Genehmigung: Muss die Rollenänderungen überprüft bzw. genehmigt werden? Durch wen?
h. Test: Welche Rollenänderungen müssen getestet werden? Wie sind die Dokumentations-
vorgaben?
i. Regelmäßige Überprüfung: In welchen Abständen müssen die Rollen überprüft werden?

Durch wen?
› Überprüfung verschiedener Funktionen des Business Role Management auf Mehrwerte im

Rahmen administrativer Prozesse / im Rahmen von Rollouts; Überprüfung der Funktionen
a. Massenpflege von Rollen
b. Massensynchronisation von Rollen
c. Massenableitung von Rollen
d. „Role Mining“
e. Verschiedene Reportingfunktionen
I. Beziehungen zwischen Stamm- und abgeleiteten Rollen (Vererbung)
II. Beziehung von Einzel- zu Sammelrolle
III. Rollen nach Generierungsdatum
IV. Transaktionen in Rollen
V. Transaktionen in Rollenmenü und produktive Berechtigung vergleichen
VI. Berechtigungen in Rollen zählen
VII. Änderungshistorie der Rollen (bis auf Feldebene)
VIII. Rollenvergleich (von 2 bestimmten Rollen – auch für Backend-Systeme
ohne Synchronisierung).
› Design des neuen Rollenkonzeptes für die Erfordernisse der Komponente „Unternehmensweites
Rollenmanagement“ (BRM): In Abhängigkeit des in der Strategiephase festgelegten Konzeptes
zum „Bereinigen“ der Risiken im Rollenkonzept können folgende Varianten in Betracht gezogen
werden:
Variante A: Das bestehende Rollenkonzept wird in seiner Struktur so belassen und später in der
Implementierungsphase entsprechend mit Hilfe von sukzessiv durchgeführten Risikoanalysen
(auf Grund der vorher festgelegten Risikomatrix) in risikofreie Rollen aufgeteilt. Für die spätere,
vollumfängliche Nutzung des BRMs müssen in der Designphase technische sowie organisatori-
sche Voraussetzung geprüft / geschaffen werden:
› Eine eindeutige Namenskonvention muss definiert werden

› Verantwortliche für den Inhalt der Rolle müssen definiert werden
› Die erforderlichen organisatorischen Zugriffe („Org Sets“) müssen pro Referenzrolle
definiert sein
63
Variante B: Falls eine große Anzahl von Risiken im bestehenden Konzept identifiziert wurden,
bietet sich ein Reengineering des Rollenkonzeptes mit Hilfe eines Reverse-Business-Engineering-
Konzeptes an. In diesem Fall wird durch entsprechendes „Tracing“ der Anwender festgestellt,
welche SAP-Funktionen von diesen wirklich benötigt werden und welche eigentlich nicht. Die
Erfahrung zeigt, dass durch dieses Verfahren ca. 50 – 70 % der bestehenden Risiken reduziert
werden können. Bei dieser Variante sollten folgende Arbeitspakete angewandt werden:
1. Analyse des Organisations-Charts mit der Identifikation der Positionen und deren Zuordnung
zu bestehenden SAP-Anwendern im System.
2. Analyse von eigenentwickelten Z-Transaktionen und deren Dokumentation

(falls nicht schon vorhanden).
3. Zuordnung aller SAP-Transaktionen zu Informationseignern der Fachbereiche,

die später entsprechend auch die Rolleneignerschaft übernehmen.
4. Durchführung der Reverse-Business-Engineering-Analyse im SAP-System zur Identifikation

anhand der gruppierten Positionen tatsächlich verwendeter SAP-Transaktionen im System
und deren Zuordnung zu entsprechenden Informationseignern. Ableitung des Rollenkonzeptes
basierend auf Hauptarbeitsplatzrollen plus zusätzlicher Aufgabenrollen, die entsprechend
innerhalb der Informationseignerbereiche gebildet werden können. Vorteil dieses Verfahrens
ist, dass im ersten Ansatz den bestehenden Anwendern keine Funktionalität entzogen wird,
welche sie tatsächlich in ihrer tagtäglichen Arbeit benötigen. Damit kann das Rollout-Risiko
der Lösung minimiert werden.
5. Festlegung der notwendigen organisatorischen und funktionalen Ausprägungseinschränkungen

(wie z.B. Company Code, Verkaufsorganisation etc.), welche später dann in der Rollenaus-
prägung benötigt werden. Dies muss mit den jeweiligen Fachbereichen erfolgen oder ist als
Dokumentation vom bestehenden Konzept noch vorhanden und kann entsprechend über-
tragen werden.
Variante C: Eine große Anzahl von Risiken im bestehenden Konzept wurde identifiziert. Die
existierenden Rollen sind i.d.R. über Jahre gewachsen, unstrukturiert und sehr mächtig geworden
und – wie analysiert – mit vielen Funktionstrennungskonflikten behaftet; dann bietet sich eine
Neustrukturierung (ReDesign) anhand von betrieblich exakt abgegrenzten Funktionsbausteinen
an. Die daraus ableitbaren Einzelrollen lassen sich später einfach zu Sammelrollen aggregieren
und mittels des ORG-Managements (HR) den Arbeitsplätzen zuordnen; darauf kann dann das
IdM und ARM sinnvoll aufsetzen.
Nach der Konzeption und Definition der im Unternehmen erforderlichen betrieblichen Funktions-
bausteine kommt man im nächsten Schritt zur Technikebene und zur Umsetzung in Einzelrollen.
Hierzu bieten sich sowohl der BRM (Business Role Management) wie auch der PFCG (Profil-
generator) an oder aber ein toolunterstütztes Vorgehen auf Basis bereits vorgefertigter Funkti-
onsbausteine. BRM hat den Vorteil, die Rollen nach der Erstellung sofort auf Funktionstrennungs-
anforderungen (SOD) verproben zu können und über einen Freigabeprozess auch genehmigen zu
64
lassen. Arbeitet man mit geeigneten – am Markt erhältlichen – bereits konfliktfreien Best-
Practice-Bausteinen, können die Einzelrollen aus diesen Funktionsbausteinen mit Hilfe von
Werkzeugen direkt abgeleitet und die Organisationsdaten zugesteuert werden.
Eine Namenskonvention der Einzel- und Sammelrollen sowohl im Kurz- wie auch im Lang-
namen ist verpflichtend. Der Kurznamen enthält Modulbereiche (wie SD, PP …), die betriebliche
Funktion und eine eindeutige Nummerierung. Wichtiger ist der Langname; dieser sollte immer
und durchgehend 3-teilig aufgebaut sein:
1. Modulkennzeichen und betriebliche Funktion

2. Funktionstyp mit Bearbeiten, Anzeigen…
3. Organisationsebene wie Buchungskreis, Sparte..., Kostenstelle
Eine betriebliche Funktion (Einzelrolle) ist nur dann hinreichend und vollständig beschrieben,
wenn sie alle benötigten Transaktionen und auch ihre zugehörigen abgrenzungsrelevanten
Organisationsdaten (Berechtigungsobjekte / Felder / Werte) beinhaltet. Teilfunktionale Rollen,
Rollen ohne Transaktionen oder Org-Werte, Rollen mit Transaktionsbandbreiten, Rollen mit
„Aktivitätscode*“ sollten nicht zugelassen werden. Hat man eine starke Verästelung mit vielen
Sparten, Kostenstellen etc. im Unternehmen, die eigens abgegrenzt werden müssen, entstehen
sehr wohl einige Kopien dieser Bausteine, die jedoch funktional identisch bleiben und sich nur
in der Organisationsausprägung unterscheiden. Ob später mit oder ohne Vererbung gearbeitet
werden soll, ist beim Design zu berücksichtigen.
Bei eigenentwickelten Transaktionen ist eine Prüfung unerlässlich, ob diese nach dem SAP-
Authorization-Check-Verfahren programmiert sind, ggf. eigene Berechtigungsobjekte besitzen
oder Standardtransaktionen aufrufen und welche davon überhaupt noch verwendet werden.
Kommt man zu dem Ergebnis, dass hier kritische oder unbekannte bzw. nicht dokumentierte
Eigenentwicklungen vorliegen und auch noch eingesetzt werden, empfiehlt es sich, diese in
eigene Einzelrollen – nach Modulgruppen getrennt – abzulegen und speziell zu benennen. Eine
Vermischung zwischen Standard- und den eigenen Y-/Z-Transaktionen sollte vermieden werden,
da diese später schwierig zu handhaben sind („die findet man fast nie mehr!“).
Zum Schluss ergänze man die so erstellten Rollen um die sog. Notfallrollen, d.h. Rollen zum
Customizing sowie zur Entwicklung im Produktivsystem, die Rollen für die Berater, WPs und
Steuerprüfer/Finanzamt, den Datenschutzbeauftragen etc. Notfallrollen sollen modulweise
abgegrenzt und eingeschränkt werden und die Verwendung nur über den SPM erfolgen.
Die Hauptarbeit eines Rollendesigns ist der Aufbau der Einzelrollen; nach Beendigung sind
alle betrieblichen Funktionen – unabhängig, wie und wo sie eingesetzt und verwendet werden –
vollumfänglich umgesetzt. Am besten beginnt man mit der größten Funktionsbreite einer Einheit
(Hauptgeschäftsprozesse), um ggf. später im Rollout-Verfahren davon neue Einheiten abzu-
leiten und anzupassen. Hier bieten sich dann zur Arbeitserleichterung Massenkopierverfahren an.
Arbeitsplätze sind in Arbeitsplatzfunktionen aufgeteilt; eine Arbeitsplatzfunktion ist die Aggre-

gierung (Zusammenfassung) betrieblicher Funktionen (Einzelrollen) z.B. in der Abteilung Vertrieb
der Vertriebsaußendienst für Deutschland. Wenn man alle Einzelrollen in einer Spalte (z.B.
Excel) aufführt und horizontal zusammen mit den Fachbereichsverantwortlichen die Arbeits-
65
platzfunktionen definiert, können die Arbeitsplätze einfach durch Ankreuzen zusammengestellt
werden. Das Excel dient später auch zur Transparenz und beschreibt im Detail die Inhalte dieser
Arbeitsplätze mit ihren einzelnen Funktionen. Organisationsänderungen sind leicht und ohne
großen Aufwand umzusetzen, wenn sich Funktionen innerhalb der Organisation verschieben;
dies bedeutet ein Umhängen der Einzelrollen - die Funktion selbst bleibt i.d.R. innerhalb des
Unternehmens unverändert. Bei dieser Vorgehensweise sind Benutzern immer nur Sammel-
rollen oder Business-Rollen zugewiesen und möglichst keine Einzelrollen. Fachbereiche kennen
somit nur eine in sich überschaubare Anzahl ihrer Sammelrollen und dadurch ist eine durch-
gängige Transparenz und effiziente Handhabung geschaffen.
› Bankbuchhaltung › Bestandsführung
› Wareneingang
› Rechnungsprüfung
› Anfragen / Angebote › Anfragen / Angebote
› Bestandsführung
› Debitorenbuchhaltung
› Debitorenbuchhaltung
› Bankbuchhaltung
Lokation 1 Lokation 2
Arbeitsplatz
AP1 AP2 AP3 AP4 AP5 AP...
ER1 x x
ER2 x x x
Einzelrolle
ER3 x
ER4
ER5 x x x
ER...
Abbildung 8: Aggregierung von Einzelrollen zu Sammelrollen (Arbeitsplätze)
Dieser Redesign-Prozess ist aufwendig und bindet nicht nur die Ressourcen der IT, sondern auch
die der Key-User aus den Fachabteilungen. Deshalb ist es wichtig, nach Freigabe und Produk-
tivsetzung der neu gewonnenen Rollen jede Veränderung durch einen Genehmigungsprozess
zu initiieren und diese mit Zeitstempel zu dokumentieren – nicht nur aus Revisionssicht, sondern
auch aus Investitionsschutz!
66
6.2.4.1 Gesetzeskonformes Benutzermanagement (User Lifecycle Management)
In diesem Arbeitspaket müssen die wichtigsten Änderungsmanagementprozesse zusammen mit

den Fachbereichen und dem Compliance Management festgelegt werden:
› Beantragung von Rollen und Berechtigungen durch die Fachbereichsanwender. Der Benutzer-
management-Workflow sollte hinsichtlich folgender Instanzen entworfen werden:
› Antragsteller
› Genehmigung durch Rollenverantwortliche und Fachbereichsverantwortliche
› IT-Administrationsstufen
› Risikomanagement, falls durch neue Rechte neue Risiken entstehen
› Einbindung von HR
› Passwort-Änderungs- oder-Rücksetzungsantrag
› Festlegung einer neuen Risikodefinition (in ARA) oder Änderung bzw. Löschung einer bestehen-
den Risikodefinition
› Zuordnung einer kompensierenden Kontrolle zu „risikobehafteten“ Anwendern, falls dies nicht
schon im Rollenbeantragungsprozess durchgeführt wurde
› Änderung oder Neuanlage bzw. Löschung von kompensierenden Kontrollen im bestehenden
Katalog
› Workflow für Superuser-Zugriff
› Abstimmung erforderlicher Integrationsszenarien (z.B. HCM, HCM-Org-Management, IDM,
CUA) unter Berücksichtigung des führenden Systems.
Durch die Einführung von SAP GRC Access Control muss es im Benutzermanagementprozess einen
Schritt zur Analyse der Zugriffsrisiken und deren Kompensierung geben. Insbesondere muss
entschieden werden, wer sich um die Zugriffsrisiken und deren Kompensierung kümmert.
6.2.5 NOTFALLZUGRIFF (EMERGENCY ACCESS MANAGEMENT)
Auch hier starten die Aktivitäten zunächst mit der Definition des Sollprozesses zusammen mit den
Fachbereichen. Dabei muss zunächst eine grundlegende Designfrage geklärt werden: Soll das
Emergency Access Management (EAM) rollenbasiert agieren oder User-ID-basiert?
Zur Erläuterung: Im rollenbasierten Modus weist das EAM den Benutzern Zusatzrechte über weitere
Rollen für den genehmigten Zeitraum zu. Technisch werden dabei weitere Rollen in den Benut-
zerstamm gelegt, nach Datum abgegrenzt. Der Benutzer kann dann, wenn der Gültigkeitszeitraum
erreicht ist, unter seiner eigenen User-ID die notwendigen Arbeiten verrichten.
Im User-basierten Modus hingegen werden vorab spezielle User-IDs mit erweiterten Rechten an-
gelegt (normale Useranlage über die SU01), die sog. „FireFighter-IDs“. Im genehmigten Zeitraum
können Anwender über das EAM-Cockpit dann nach Angabe eines Grundes und der Beschreibung
der durchzuführenden Tätigkeiten auf die genehmigte FireFighter-ID wechseln. D.h., die dann
folgenden Tätigkeiten werden unter dieser speziellen, oftmals weitreichend berechtigten User-ID
durchgeführt. Nach Beendigung der Arbeiten verlässt der Anwender den Modus der FireFighter-ID
und die Notfallsession wird geschlossen.
67
Eine Aufstellung der wesentlichen Unterschiede sieht wie folgt aus:
Rollenbasiert
› Die User-ID des durchführenden Benutzers ist direkt in den Belegen (FI-Korrekturen, Programm-
reparaturen etc.) gegeben und muss nicht über die EAM-Logs nachgeschlagen werden
› Die zusätzlichen Privilegien gelten nicht sessionbasiert, sondern durchgehend für den genehmigten
Zeitraum und lassen sich tagesgenau abgrenzen
› Ein gesonderter Notfallvorgang ist für den Anwender nicht notwendig
ID-basiert
› Für jeden Einsatz gibt es eine konkrete Session mit Angabe des Ursachencodes. Hier muss der
Anwender auch im Dialog zunächst eingeben, was er tun will. Es entsteht eine dokumentierte
Notfallsitzung mit entsprechender zeitlicher Abgrenzung und der Möglichkeit, bei Sessionende
bzw. fallbezogen Mails an den Überwacher/Verantwortlichen zu verschicken
› Die Aktivitäten werden mit der FireFighter-User-ID durchgeführt, nicht mit der des Anwenders
› Überwacher können jeweils gezielt über die Session-Details schauen, auch selektiert nach
Ursachencode
› Die eigene User-ID des Benutzers bekommt keine weiteren Berechtigungen zugewiesen, bringt
ihn damit aber später auch nicht in Erklärungsnot
› Es gibt in den Aufzeichnungen des Systems keine Vermengung von normalen, typischen Aktivitäten
des Benutzers und Notfallaktivitäten, wenn der Benutzer diese am selben Tag ausführt. Damit
werden auch Datenschutzbedenken bei der Überprüfung der Logs besser abgedeckt
› Risikoanalyen auf die User-IDs der Benutzer während der Gültigkeit der Notfallverfahrenszu-
ordnung sehen nach wie vor unkritisch aus, sofern sie es vorher auch waren
Erfahrungen mit vielen Unternehmen zeigen, dass derzeit der Einsatz der ID-basierten Variante
wesentlich häufiger ist als der Einsatz des rollenbasierten Verfahrens. Hintergrund ist, dass insbe-
sondere bei der Interaktion mit Prüfern (Interne Revision, Wirtschaftsprüfer) dieser Ansatz ganz
erheblich die Diskussionen unter den Beteiligten reduziert, weil die Sondernutzung jeweils wesentlich
klarer abgegrenzt ist. Daher kann die User-ID-basierte Verfahrensweise als Best Practice gelten,
wenn ein ordentliches Notfallverfahren aufgebaut werden soll. Soll das EAM hingegen vordringlich
dazu verwendet werden, zum Berechtigungswesen eine flexible Zusatzrollenmechanik abzubilden,
d.h. Anwendern bei ansonsten eher statischen, positionsbasierten Zuordnungen von Rollen eine
flexible, dynamische Möglichkeit zu bieten, temporär und kontrolliert weitere Berechtigungen zu
erhalten, dann kann hier die rollenbasierte Variante stark unterstützen. In diesem Umfeld wird sie
auch gerne von Unternehmen eingesetzt.
Zu Klärung der Frage rollen- vs. User-ID-basierter Nutzung des EAM ist es also zunächst notwendig
zu entscheiden, ob ein Notfalluserverfahren oder ein Zusatzberechtigungsverfahren gewünscht wird.
Allerdings wird in Unternehmen wiederum oftmals von verschiedenen Stellen Unterschiedliches in
dieser Hinsicht gefordert: Abteilungen aus dem SAP-Basis-Umfeld und Bereiche, die viel mit Prüf-
situationen beschäftigt werden, benötigen ein stabiles und klar abgrenzbares Notfalluserverfahren.
Fachbereiche mit besonderen Berechtigungsanforderungen hingegen wünschen sich oft ein flexibles
Erweiterungs- oder Zusatzberechtigungsmanagement. Wichtig vor diesem Hintergrund ist: Es ist
68
leider derzeit nicht möglich, beide Verfahren parallel zu betreiben, da dies ein globaler Customizing-
Schalter im GRC Access Control steuert. Daher muss hier als Erstes eine klare Entscheidung vor den
oben beschriebenen Einschränkungen der jeweiligen Variante getroffen werden (wir geben hierbei
auch zu bedenken, dass SAP diesem Werkzeug den Namen „Emergency Access Management“ und
nicht „Flexible Auxiliary Role Assignment Management“ gegeben hat).
Nachdem die Entscheidung bezüglich des verwendeten technischen Verfahrens vorliegt, muss dann
in Zusammenarbeit mit den Fachbereichen eine Richtlinie für den Zugriff auf höher berechtigte
Notfallbenutzer oder Zusatzberechtigungen (siehe Diskussion Rollen vs. User-ID-basiert) entworfen
werden. Der Zugriff sollte in der Tat nur für den jeweiligen begrenzten Einsatzweck erlaubt werden
und nicht für den Regelfall, da ansonsten das eigentlich definierte Berechtigungskonzept nach und
nach unterwandert wird.
Festzulegen ist dabei auch, ob bei der Verwendung der ID-basierten Variante die FireFighter-IDs
einzelnen Benutzern permanent zugeordnet werden oder ob für die jeweilige Nutzung einer ent-
sprechenden ID das Benutzerantragsverfahren genutzt werden soll.
Abschließende erfolgt das detaillierte Design des Emergency Access mit SAP GRC Access Control:
Die Richtlinie wird als Prozess-Blueprints entworfen und entsprechend die Eigner für die Superuser-
IDs/Zusatzrollen festgelegt. Zudem müssen die entsprechenden höherwertigen Berechtigungen pro
Superuser-ID oder Zusatzrolle bestimmt werden. Dies muss wiederum zusammen mit den Fach-
bereichen erfolgen. Auch die Reviewer bzw. Kontrolleure, die im Nachgang einer Verwendung die
Änderungsprotokolle auszuwerten haben, müssen pro Fachbereich festgelegt werden. Zudem sind
klare Vorgaben zur Auswertung festzulegen. Bei einer Identifikation von Unregelmäßigkeiten in den
Änderungsprotokollen müssen zudem die notwendigen reaktiven Schritte festgelegt werden.
In größeren, verteilt arbeitenden Organisationen muss geprüft und konzeptionell erarbeitet werden,
wer im zentralen GRC-Access-Control-System die Administrationsarbeiten auf die jeweilligen
Genehmiger durchführen darf.
6.2.6 TESTVORBEREITUNG FÜR ALLE KOMPONENTEN
Die Durchführung von Tests ist ein wichtiger Bestandteil einer jeden Software-Einführung, um die
Implementierung der Anforderungen im Blueprint zu überprüfen und eine hohe Qualität der Soft-
ware sicherzustellen. Fehler, die erst im späteren Betrieb der Software festgestellt werden, können
zur Beeinträchtigung der Akzeptanz der Systeme führen. An dieser Stelle muss einschränkend fest-
gehalten werde, dass auch ein erfolgreich abgeschlossener Abnahmetest keine Garantie für die
grundsätzliche Fehlerfreiheit der Software abliefern kann. Der Grund liegt in der Tatsache, dass ein
vollständiger Test in der Regel wenig wirtschaftlich oder auch nicht realisierbar ist. In der Design-
phase sollte mit der Vorbereitung der Tests begonnen werden. Unter Testing wird der Benutzerak-
zeptanztest oder auch Abnahmetest verstanden. Unit-Tests finden bereits bei der Implementierung/
Konfiguration der Funktion durch den Entwickler statt. Ein erster wichtiger Bestandteil der Testvor-
bereitung ist die Festlegung der Testorganisation, d.h. die Festlegung der Personen, die die Tests
durchführen, sowie der Person, die die Tests als Testleiter verantwortet. Bei der Testdurchführung
bieten sich die zukünftigen Key-User aus den Fachbereichen an, die auch bei der Aufnahme der
Anforderungen innerhalb des Blueprints mitgearbeitet haben. Dies hat zwei Vorteile: die Key-User
69
kennen bereits die Anforderungen an das System. Des Weiteren kann der Test auch als Schulungs-
maßnahme für die Key-User betrachtet werden. Weitere wichtige Rollen in der Testorganisation sind
die Testleitung/-verantwortliche sowie ein Fehlermanager, der später die Lösung von festgestellten
Fehlern vorantreibt. Je nach Einbindung der Mitbestimmungsseite und der internen Revisionsorga-
nisation kann es Sinn machen, Vertreter in die Testabläufe einzubinden. Als Beispiel wäre hier
die Kontrolle von Logdateien des Notfallmanagements zu betrachten (Revision) oder die Kontrolle
von Risikoanalyse-Ergebnissen auf Freiheit von Mechanismen der Verhaltenskontrolle (Nutzung
von Transaktionen). Nachdem die Testorganisation festgelegt wurde, sollten basierend auf den An-
forderungen im Blueprint die Testfälle festgelegt werden, welche später in Testskripten detailliert
ausgearbeitet werden. Die Testfälle sollten nach den Komponenten SAP GRC Access Control gruppiert
werden. Die Testfälle der einzelnen Komponenten sollten die folgenden Aspekte berücksichtigen,
welche anhand von Beispielen für die SAP GRC AC erklärt werden:
› Überprüfung von Eingabemasken:

› Inhalt: Die benötigten Eingabemasken sollten hinsichtlich des Designs überprüft werden.
Sind die Felder vorhanden, die benötigt werden, die ausgeblendet, die nicht benötigt werden
und / oder ggf. zusätzlich benötigte Felder konfiguriert worden.
› Beispiel: Beinhaltet die Eingabemaske für einen Benutzerantrag die geforderten Eingabefelder?
› Sind zusätzlich gecustomizte Felder vorhanden?
› Überprüfung von Workflows:

› Inhalt: Workflows, die speziell im Benutzerantragswesen spezifiziert wurden, sollten hinsichtlich
des Routings der Anträge überprüft werden.
› Beispiel: Erhalten die Benutzer den Workflow in der jeweiligen Genehmigungsstufe, welche
für die Genehmigung spezifiziert wurden? Funktionieren Workflow-Gabelungen, d.h., der
Antrag soll aufgrund einer Entscheidung den einen oder den anderen Weg nehmen.
›Überprüfung von Funktionen:

› Inhalt: Überprüfung der Funktion der einzelnen Funktionen (= Menüeinträge) innerhalb des
SAP-GRC-Menüs.
› Beispiel: Wird bei der Selektion des Menüs „Zugriffsrisiken“ die Verwaltung der Zugriffsrisiken
geöffnet und ist es mit den Funktionen innerhalb dieses Menus möglich, ein Zugriffsrisiko
anzulegen, zu ändern und zu löschen.
› Überprüfung der Berechtigungen und Menüs:

› Inhalt: Da Benutzer des Systems unterschiedliche Rollen einnehmen, sollte jede Rolle hin-
sichtlich der definierten Berechtigungen überprüft werden. Es muss zum einen überprüft
werden, ob die Rolle die Berechtigungen bietet, die definiert wurden, aber auch alle anderen
Berechtigungen unterbindet / ausschließt.
› Beispiel: Ein Genehmiger innerhalb des Benutzermanagementworkflows sollte Workflow-

aufgaben für seine Genehmigungsstufe empfangen und bearbeiten können, sollte aber nicht
in der Lage sein, das Regelwerk und Zugriffsrisiken zu bearbeiten.
70
› Überprüfung der Reports und Dashboards:

› Inhalt: Die benötigten Reports sollten überprüft werden, ob die benötigten Selektionskriterien
zur Verfügung stehen, sowie die erwarteten Daten mit den entsprechenden Attributen
(= Datenfeldern) dargestellt werden.
› Beispiel: Wird im Report für Benutzeranträge eine Suchfunktion via „Antragsnummer“ zur
Verfügung gestellt und im Ergebnisbereich der Anträge der „Antragsteller“ angezeigt.
›Batch-Prozesse:
› Inhalt: Überprüfung von benötigten Batchjobs, die im System ad hoc oder regelmäßig benötigt
werden.
› Beispiel: Zur Erstellung der Management-Dashboards wie „Risikoüberschreitung“ müssen im

System verschiedene Batchjobs in der richtigen Reihenfolge eingeplant und abgespielt werden.
› Schnittstellen:
› Inhalt: Überprüfung der Funktionsweise von Schnittstellen zu angebundenem System.
› Beispiel: Erhalten Benutzer eine E-Mail-Benachrichtigung durch das Workflowsystem oder

wird ein Benutzer am Ende des Benutzermanagementworkflows im angebundenen SAP-ECC-
System mit den richtigen Daten angelegt.
Nach der Festlegung der Testfälle, sollten diese mit Hilfe von detaillierten Testskripten abgeleitet
werden, mit deren Hilfe dann in der Implementierungsphase die Tests durchgeführt werden können.
Abbildung 9: Beispiel Testskript

71
Die Testfälle und -skripte können sowohl in MS Microsoft Excel dokumentiert werden oder in einer
Softwarelösung zur Verwaltung von Softwaretests. In vielen Unternehmen kommt hier der SAP
Solution Manager zum Einsatz.
Zu berücksichtigen ist insbesondere, dass die Testszenarien sowohl das zentrale GRC-Access-
Control-System betreffen, aber auch das angeschlossene Backend-System. Für den Fall, dass
die FireFighter-funktionaliät aus der Version 5.3 (dezentraler FireFighter) genutzt wird, muss
die korrekte Funktionsweise ausschließlich im Backend-System getestet werden. Die fehlerfreie
Synchronisation der Benutzer-, Rollen- und Profildaten sowohl im inkrementellen Modus als
auch in der vollen Synchronisation muss getestet werden.
6.2.6.1 Festlegung der Testskripte
Das Testskript beschreibt die tatsächlich zu testende Funktionalität und bestimmt die Eingabepa-
rameter und die zu erwartenden Ausgabeparameter.
Diese Testskripte lehnen sich an die im Business Blueprint definierten Prozesse an und bedienen
sich der Stammdaten in den Backend-Systemen und der zentralen Plattform. Vor allem die im User
Acceptance Test (UAT) genutzten Skripte benötigen eine detaillierte Ablaufbeschreibung und fehler-
freie Bereitstellung von notwendigen Stammdaten. Nicht durchführbare Testfälle im UAT aufgrund
von fehlenden oder fehlerhaften Stammdaten führen zu schweren Akzeptanzverlusten bei den
Testbenutzern und sollten unbedingt vermieden werden.
Komplexe Workflowszenarien bei der Benutzeranlage und Rollenzuweisung einschließlich der Miti-
gierungsprozesse erfordern eine Vielzahl von Testskripen. Jeder Zweig im Prozessablaufdiagramm
muss hier mit einem Testfall versehen und durchlaufen werden.
72
6.3 PHASE REALISIERUNG („IMPLEMENTIERUNG“)
In der Realisierungsphase werden nun die detaillierten Konzepte und Designs entsprechend in die
Entwicklungsumgebung implementiert und getestet. Dies kann wieder teilweise für die einzelnen
Komponenten parallel durchgeführt werden. Aber speziell ein mögliches notwendiges Neuerstellen
der Rollen muss mit der Risikoanalyse integriert bzw. teilweise auch iterativ durchgeführt werden.
Im Einzelnen sollten die folgenden Arbeitspakete angegangen werden.
6.3.1 ARCHITEKTUR & TECHNOLOGIE
1. Technische Installation aller SAP-GRC-Access-Control-Komponenten

Entsprechend des technischen Designs werden nun alle Komponenten für die vorgesehene
Systemlandschaft installiert. Dabei kann zum Teil die in der Strategiephase bereits installierte
Sandbox zur Entwicklungslandschaft weiter entwickelt werden. Je nach Design wird die Entwick-
lungslandschaft mit einer Qualitätssicherungslandschaft und finalen Produktion erweitert. Zudem
müssen die notwendigen Plug-ins, je nach gewählter GRC-Access-Control-Version und Zielsystem-
version auf den Backend-Systemen installiert werden.
Wird vor dem Hintergrund einer bestehenden Implementierung von GRC Access Control 5.3-
installiert, so sollte das Migrationskapitel beachtet werden. Zwar ist der AC5.3-Code in den
neuen Plug-ins enthalten, es ergeben sich jedoch ggf. kleinere Unterschiede über ein mögli-
cherweise mittelbar enthaltenes Anheben der AC5.3-SPs auf den Satellitensystemen.
Wenn geplant ist, GRC Access Control 10.0 auf einem Solution Manager System zu betreiben,
sollten die Hinweise 1583125 („Installation SAP GRC Access Control auf SAP Solution Manager“)
und 1658621 („Menu item tree for user is empty“) beachtet werden – bei letzterem wird die
technische Grundlage für den NWBC-Betrieb von GRC Access Control im Solution Manager gelegt.
2. Finale technische Konfiguration

Nach erfolgter technischer Installation werden die notwendigen Verbindungen zu den Zielsystemen
konfiguriert und zudem die notwendigen Batchjobs für die Berechtigungsdatensynchronisation
(USOBX_C und USOBT_C) etc. definiert. Zudem muss ggf. für die Risikoanalyse die Verwendung
der Workflow-Engine bei der Verwaltung von Zugriffsrisiken angeschaltet werden. Auch die
Transportmechanismen von Entwicklung zu Produktion für die Risikoregeln werden entsprechend
konfiguriert und spezifiziert.
6.3.2 RISIKOANALYSE UND BEREINIGUNG
1. Umsetzung der definierten Risiken und Zuordnung der kompensierenden Kontrollen im System:
Die in der Blueprint & Design-Phase definierten Risiken und die dazu korrespondierenden
kompensierenden Kontrollen werden entsprechend im Entwicklungssystem angelegt und in
die Produktionsumgebung transportiert.
73
Alternativ können Risiken und Kontrollen auch direkt in Produktion gepflegt werden, wenn dies
in der Blueprint-Phase beschlossen wurde – hierbei sollten dann aber Genehmigungsworkflows
für die Wahrung des 4-Augen-Prinzips eingesetzt werden. Abschließend müssen die regulär
laufenden Synchronisationsjobs eingeplant werden.
2. Einführung des Rollenkonzepts für SAP GRC Access Control: Die definierten Rollen für SAP
werden entsprechend in der Berechtigungsverwaltung des darunter laufenden SAP-NetWeaver-
ABAP-Systems umgesetzt (siehe auch den Security-Guide zu SAP GRC Access Control 10.0.).
Test der Risikoanalyse mit Beispielrollen: Mit speziellen Testrollen, die z.B. schon „wissentlich“
Risiken enthalten, werden Testrollen vorbereitet, mit deren Hilfe die implementierten Risiken
getestet werden.
6.3.3 UNTERNEHMENSWEITES ROLLENKONZEPT
1. Implementierung des Sollprozesses im Business Role Management: Die relevanten Prozess-

schritte müssen nun im Business Role Management umgesetzt werden.
a. Integration mit Change Management System: Eine (teil-)automatisierte Integration mit einem
Change Management System ist im Standard nicht vorgesehen. Es besteht aber die Möglichkeit,
im BRM bei jeder Rollenänderung die Eingabe eines Tickets obligatorisch einzufordern. Alternativ
wäre eine kundenspezifische Entwicklung einer entsprechenden Schnittstelle denkbar.
b. Scope: Für verschiedene Systemlandschaften / Rollentypen müssen im BRM ggf. verschiedene

Verfahren hinterlegt werden. Dies geschieht mithilfe von sog. BRF+-Regeln.
c. Rollendefinition: Hierfür muss neben den jeweiligen Rollenklassifizierungen (z.B. die verschiedenen
Kritikalitätsstufen einer Rolle), die im Customizing zu hinterlegen sind, auch die automatisch
generierte Namenskonvention hinterlegt werden. Hier ist es wichtig zu wissen, dass die jeweils
festgelegten Zeichen z.B. für das Modul oder die Ableitung an eine fest definierte Position gesetzt
werden (z.B. Ableitung: Zeichen 27-30),Variablen können hier im Standard nicht hinterlegt
werden. Dies muss bei der Wahl der entsprechenden Namenskonvention berücksichtigt werden.
d. Berechtigungspflege: Hier wird ein Absprung in die PFCG durchgeführt. Eine Pflege innerhalb
des BRM ist nur mithilfe der Funktionen vorgesehen und sollte bei Nicht-Nutzung abgeschaltet
werden.
e. Risikoanalyse: Das generelle Verbieten von Risiken bzw. das Erzwingen von Risikoanalysen sollte
wohlüberlegt sein. Die vielfache Risikoanalyse umfangreicher Entwickler / Customizing / Testrollen
kann zu Performanceproblemen führen und ist von überschaubarem Mehrwert
f. Rollenableitung: Hier ist es die Hauptaufgabe, die Organisationssets zu ermitteln und im Rollen-
management zu hinterlegen.
g. Genehmigung: Mithilfe von BRF+-Regeln kann der Genehmiger einer Rollenänderung z.B.
Abhängig vom Geschäftsprozess ermittelt werden. Die manuelle Pflege eines Genehmigers,
welche danach von demselben genehmigt wird, macht natürlich wenig Sinn.
74
Variante A:
2. Synchronisation der Backend-Rollen und sukzessive „Bereinigung“: Die bestehenden Backend-

Rollen werden entsprechend in SAP GRC Access Control hochgeladen und auf bestehende
Risiken analysiert. Beim Hochladen werden entsprechend die Rolleneignerattribute und weitere
Attribute wie organisatorische Zuordnungsinformationen (Division, Abteilung, Vertreter etc.)
zugeordnet. Bei der Analyse werden die Rollen in weitere Teilrollen (falls Funktionstrennungs-
konflikte bestehen) getrennt.
3. Notwendige Nachpflege der organisatorischen und sonstigen Berechtigungsreichweiten:

Organisatorische Berechtigungen (Buchungskreis, Kostenstellen etc.) plus weitere Berechtigungen
müssen mit Hilfe der Komponente „Unternehmensweites Rollenkonzept“ nachgepflegt werden.
Variante B und C:
2. Implementierung des neuen Rollenkonzepts: Die in der Designphase neu erstellten Rollen
werden entsprechend mit der Komponente „Unternehmensweites Rollenkonzept“ implementiert
und Rolleneigner und die weiteren organisatorischen Attribute (wie in Variante A) zugeordnet.
Mit Hilfe der Risikoanalyse werden, falls notwendig, bestehende Konflikte im Rollendesign
weiter bereinigt. Entsprechend wird auch nochmals das Rollendesign angepasst.
3. Notwendige Pflege der organisatorischen und sonstigen Berechtigungsreichweiten: Organisa-

torische Berechtigungen (Buchungskreis, Kostenstellen etc.) plus weitere Berechtigungen
müssen dann mit Hilfe der Komponente „Unternehmensweites Rollenkonzept“ oder im „Rollout-
Verfahren“ nachgepflegt werden.
6.3.4 NOTFALLZUGRIFF (EMERGENCY ACCESS MANAGEMENT)
Implementierung des Notfallzugriffs: Die definierte Richtlinie – Rollen- oder ID-basierter Ansatz,
Pflege als globaler Schalter im Customizing – und die entsprechenden Genehmiger, Kontrolleure
und Superuser-IDs (falls notwendig) werden mit Hilfe der Komponente Emergency Access umge-
setzt. Die entsprechenden Benutzer werden benannt und im System angelegt. Abhängig davon,
ob die Anlage von Zuweisungen von FireFightern zu Notfall-IDs (oder Rollen) direkt erfolgt oder per
Workflow, werden die entsprechenden Mechanismen eingerichtet und die Endanwenderrollen
für die Belegung des UIs entsprechend ausgearbeitet – siehe Security Guide zu SAP GRC Access
Control. Bei zu verwendenden Workflows müssen diese über das MSMP eingerichtet werden.
Darüber hinaus wird im Customizing hinterlegt, ob die FireFighter über das Zentralsystem arbeiten
oder über die jeweiligen Satelliten einsteigen. Falls ein zentraler Einstieg gewünscht wurde, müssen
alle potenziellen FireFighter im Zentralsystem angelegt werden. Abschließend müssen die Ursachen-
codes gepflegt und die Hintergrundjobs für die Einsammlung der FireFighteraktivitäten eingeplant
werden.
75
Allgemein ist für die Anbindung der Satellitensysteme zu beachten, dass das EAM hier Verbindun-
gen mit TrustedRFC erwartet. Die entsprechenden Vertrauensstellungen (Transaktion SMT1) und
Berechtigungen (Berechtigungsobjekt S_RFCACL – nicht Bestandteil von SAP_ALL, daher müssen
Notfalluser-IDs mit SAP_ALL noch eine zusätzliche Rolle bekommen) müssen daher vorab korrekt
hinterlegt werden.
6.3.5 TESTDURCHFÜHRUNG
In der Testdurchführung werden die Testfälle und Testskripts durch die festgelegten Personen in der
Testorganisation durchgeführt. Die Testergebnisse werden in den entsprechenden Testformularen
dokumentiert. Neben der Koordination der Testdurchführung ist die wichtigste Aufgabe in diese
Phase das Fehlermanagement, d.h., die festgestellten Fehler zu klassifizieren und für eine zeitnahe
Lösung der Fehler zu sorgen. Diese Aufgabe kann entweder durch die Testleitung oder durch einen
Fehlermanager durchgeführt werden.
Bei der Klassifizierung der Fehler bietet sich eine 3-stufige Skala an, wie beispielhaft in der
folgenden Abbildung dargestellt:
Schwerer Fehler
A
Der Produktivstart ist gefährdet. Die Fortsetzung des Tests ist nicht möglich.
Die Behebung des Fehlers erfolgt sofort.
Beispiel: Die Eingabe von Daten ist nicht möglich. Berichte werden nicht
ausgegeben. Eine Schnittstelle geht nicht.
Mittelschwerer Fehler
B
Die Fortsetzung des Test ist mit Hilfe eines Workaround (Zwischenlösung)
möglich. Die Behebung des Fehlers erfolgt spätestens innerhalb von einer
Woche nach Produktivstart.
Beispiel: ein Pausenzustand ist nicht erreichbar; Zwischenlösunge: Wahl
eines anderen Pausenzustands
Leichter Fehler
C
Die Durchführung des Tests ist nicht behindert. Die Behebung des Fehlers
muss zwei Wochen nach Produktivstart erfolgt sein.
Beispiel: Rechtschreibfehler im Dialog
Abbildung 10: Fehlerklassifizierung

76
Die Fehler sollten in einer zentralen Liste durch die Testleitung / Fehlermanager verwaltet werden.
Die Hauptaufgabe ist es nun, die Fehlerbehebung und den Wiederholungstest zu koordinieren.
Am Ende der Phase der Testdurchführung sollten alle Fehler entsprechend ihrer Fehlerklasse vor
oder nach Produktivstart behoben sein.
Fazit:
Keine Software und kein auf Software basierendes System funktioniert von vornherein genau so,
wie es auf Basis seiner Spezifikation entwickelt wurde. Im Laufe der Konfiguration geschehen immer
Fehler, und je komplexer ein System ist, desto größer und gravierender sind die zu erwartenden
Fehler. Erfolgreiche Abnahmetests sind daher eine wesentliche Grundlage für den stabilen und
weitestgehend störungsfreien Produktivbetrieb einer Softwarelösung.
6.3.6 FACHBEREICHS-TRAINING
Das Training der verschiedenen Fachbereiche sollte auf unterschiedlichen Trainingsmethoden auf-
gebaut werden, die je nach Zielgruppe zum Einsatz kommen. Administratoren werden in Präsenz-
schulungen intensiv mit der Funktionsweise der Software vertraut gemacht. Schlüsselbenutzer
werden ebenfalls in Präsenzschulungen unterrichtet, wobei die Möglichkeit bestehen sollte, diese
mit Hilfe von Online-Webschulungen, bei denen ein Trainer in direktem Kontakt mit den Benutzern
steht, zu unterrichten. Gerade bei weltweit ausgerollten Projekten ist diese Art der Schulung zweck-
mäßig, um Reisekosten und Reisezeiten zu minimieren. Für Endbenutzer, Genehmiger, Kontrol-
leure und deren Stellvertreter ist es sinnvoll, aufgezeichnete Online-Schulungen für klar definierte
Prozesse anzubieten. Diese sollten jederzeit über ein Schulungsportal abgerufen werden können.
Das Anbieten von regelmäßigen WebSessions mit einem persönlichen Trainer in Form von Frage-
und Antwortrunden hat sich in vielen Unternehmen als sinnvoll erwiesen.
Trainingsdurchführung für Administratoren: Die Administratoren der Anwendung SAP GRC

Access Control werden in Präsenzschulungen von fachlichen Spezialisten (ggf. Softwarelieferant)
geschult. Vermittelt wird die Funktionsweise der Software in ihren verschiedenen Modulen in einer
Detailtiefe, dass ein Second-Level-Support geliefert werden kann. Die täglichen Wartungsarbeiten
zur fehlerfreien Funktion der Anwendung und zur regelmäßigen Bereitstellung von Reportingdaten
(Batch-Risk-Analyse, BRA) sowie die Sicherstellung von funktionierenden Schnittstellen zu den
angeschlossenen Kundensystemen muss ebenfalls trainiert werden. Ein gut geschultes Team von
Administratoren kann neue Mitarbeiter(innen) im „Training on the job“ in die Aufgaben einweisen.
Trainingsdurchführung für Schlüsselbenutzer: Die Schlüsselbenutzer aus den Fachbereichen

sollten nun entsprechend in der Verwendung der neuen Lösungen geschult und eingeführt werden.
Hierzu sind vorher auf die Organisation abgestimmte Schulungsunterlagen zu erstellen, die die
Unternehmensspezifika abdecken. Das Training kann als „Train the Trainer“-Konzept ausgerollt
werden, um in späteren Phasen den neu ausgebildeten Trainern die Ausbildung der weiteren
Anwender zu übertragen. Auf diese Weise kann das „Buy In“ von Seiten der Fachbereiche gestärkt
werden. Schlüsselbenutzer erfüllen in vielen Organisationen eine wichtige Funktion als First-
Level-Support. Daher ist es von besonderer Bedeutung, diese Benutzergruppe, möglichst in Prä-
77
senzschulungen, intensiv mit der Applikation vertraut zu machen. Hierbei hat es sich als sinnvoll
erwiesen, die Schlüsselbenutzer auch in den Grundlagen von GRC Access Control zu unterrichten
(was ist ein Risko, was ist eine Funktion, wie funktionieren Risikoanalysen, was ist eine Mitigierende
Kontrolle…).
Trainingsdurchführung für Endanwender: Endanwender führen definierte Teilprozesse der GRC-

Access-Control-Anwendung durch. Für Endanwender sollte eine Schulungsunterlage entwickelt
werden, die jederzeit über ein Unternehmensportal abgerufen werden kann. Dieses kann in Form
von beschreibenden Dokumenten (Word, Visio…) oder in Form von Offline-Aufzeichnungen des
Prozesses, die interaktiv abgearbeitet werden können, bereitgestellt werden. Hier sollten die pro-
jektleitenden Einheiten die Verfahren mitnutzen, die in den sonstigen ERP-Projekten zur Verfügung
gestellt werden. Regelmäßige Frage- und Antwortrunden, die in Web-Sessions mit einem Trainer
durchgeführt werden, haben sich als wertvoll erwiesen.
Training sonstiger Zielgruppen: Die interne Revision sollte an den Schulungen für Schlüsselbe-
nutzer teilnehmen. Hier wird die wesentliche Funktionsweise der Anwendung erläutert und die
Prozesse zur Risikoanalyse und zu den Benutzer- und Rollenprovisionierungen werden tiefgehend
trainiert. Zusätzlich sollte die interne Revision im Umgang mit Reporting- und Auswertungsme-
chanismen geschult werden. Die Mitbestimmungsgremien sollten ebenfalls in den grundlegenden
Funktionen der Anwendung unterwiesen werden. Dieses schafft Vertrauen und Akzeptanz bei den
Fragestellungen zur Verhaltens- und Leistungskontrolle.
78
6.4 PHASE PRODUKTIONSVORBEREITUNG („ROLLOUT“)
In der Rollout-Phase wird nun ein Pilot für den User-Acceptance-Test ausgeführt und dann SAP GRC
Access Control in der Fläche ausgerollt. Hier stehen die Optionen „sukzessiver Rollout“ bzw. „Big
Bang“, deren Vor- bzw. Nachteile unten skizziert werden, als Alternativen zur Verfügung. Auch
werden in dieser Phase der spätere Support und der Betrieb der Lösung vorbereitet. Das für den
Support und den Betrieb der Lösung vorgesehene Team sollte dabei den User-Acceptance-Test
schon begleiten und entsprechend eigenständig eigenes Wissen aufbauen.
Die folgenden Arbeitspakete sollten nun durchgeführt werden:
1. Durchführung Pilot und User-Acceptance-Test: Nach erfolgreicher Implementierung aller

Risiken, Workflows und auch neu definierten Rollen müssen diese einem großen Kreis von
Fachbereichsteilnehmern, z.B. aus dem Finance & Controlling-Bereich zugeordnet werden.
Diese müssen dann anhand der definierten Testfälle und Testskripte die entsprechenden Tests
mit Begleitung des Supportteams durchführen.
Bei einem positiven Test kann dann eine Abnahme des Systems durch das Projektleitungs-
komitee erfolgen und die weiteren Rollouts angegangen werden.
2. Rollout-Vorbereitung: In der Vorbereitung des Rollouts müssen nun sämtliche notwendigen

Attribute der Benutzer (Rollenzuordnung), alle Rolleneigner, organisatorischen Ausprägungen
etc. erfasst werden und für die Rollouts dokumentiert werden.
Beim Start in die Produktion muss sichergestellt sein, dass störende Altprozesse nicht mehr
bedient werden. Die Abschaltung dieser Verfahren muss vorbereitet und kommuniziert werden.
3. Vorbereitung der Support- und Betriebsphase: Auf Grund der Erfahrungen des durchgeführten
Piloten und des Trainings werden der Support der Lösung und auch der Betrieb vorbereitet.
Hierzu wird der Helpdesk geschult und eine Knowledge-Datenbank aufgebaut.
4. Rollout der Lösung in die weitere Organisation:
Variante A: Sukzessiver Rollout: Hierbei wird schrittweise vorgegangen und die Lösung entweder
für weitere Systeme oder weitere Fachbereiche und Geographien ausgerollt. Hierzu werden
weitere Trainings und Schulungen durchgeführt.
Variante B: Big-Bang-Rollout: Hierbei wird für alle Systeme, Fachbereiche und Geographien ein
Rollout z.B. über ein Wochenende durchgeführt. Der Aufbau aller notwendigen Rollenzuordnungen,
Rolleneignerausprägungen etc. wird zuvor vorbereitet.
79
6.5 PHASE PRODUKTIVSTART („SUPPORT“)
Nach erfolgtem Rollout und offizieller Abnahme der eingeführten SAP-GRC-Access-Control-Lösung,

kann nun das System offiziell in die Support und Betriebsphase überführt werden.
Hierzu wird entsprechend der Helpdesk instruiert und das technische Supportteam überwacht die
Batchprozesse und Änderungsmanagementprozesse. Zudem überwacht das Risikomanagement
die Einhaltung der eingeführten Zugriffssteuerungsprozesse.
Insbesondere sollte in der Anfangsphase kontrolliert werden, ob E-Mails in Workflows korrekt zuge-
stellt werden und Workflows nicht überlang offenbleiben – letzteres wäre ein Indiz für eine Fehler-
situation, weil evtl. ein Workflow-Adressat diesen nicht zugestellt bekommen hat. Allgemein sollten
exklusive Workflow-Empfänger vermieden (mind. zwei Empfänger) und Delegationen geschult werden,
um die Zahl „hängende“ Workflows zu begrenzen, auch der Einsatz von Escape-Routes ist zu
empfehlen.
Beim Produktivstart ist es darüber hinaus wichtig, vor den ersten Access Requests, Rollenpflege-
aktionen etc. die Altverfahren stillzulegen. D.h., ggfs. muss bei bestimmten ehemaligen Benutzer-
verwaltergruppen der Zugriff auf die SU01 oder ähnlichen Transaktionen eingeschränkt werden
(nur lesen, SU01D usw.). Gleiches gilt ggfs. für Zugriffe auf die PFCG statt dem BRM. Anträge –
offline oder online – aus Altverfahren sollten archiviert und dokumentiert abgelegt werden für spätere
Nachfragen von Revision und Wirtschaftsprüfern. Kontrollaktivitäten über Security Audit Log (SM20)
sind ggf. zu beenden, wenn hier das EAM übernimmt. Hierbei ist allerdings nicht unbedingt gleich
die Abschaltung des Security Audit Logs zu empfehlen. Es hat sich als gewinnbringend gezeigt,
wenn das SAL weiterläuft für spätere Rückfragen und noch später reduzierte Audit-Klassen/Stufen.
Für das EAM ist es darüber hinaus wichtig, nachzuhalten, ob die Kontrolleure ihren Tätigkeiten nach-
kommen. Während Genehmiger typischerweise wegen der Natur der Notfälle schnell „gefunden“
werden, ist die Prüfung der durchgeführten Tätigkeiten kein attraktives Thema. Hier empfiehlt sich
auch der Einsatz von Workflows zur Abzeichnung von Protokollen.
Abschließend sollte die zuständige Projektleitung den Produktivstart dokumentieren; gut ist dabei
immer die Erhebung von Messwerten über die Zahl der Access Requests und Notfallprozeduren,
die ohne Papierweg und oft innerhalb kürzester Zeit realisiert wurden.
80
6.6 IMPLEMENTIERUNGSSZENARIO
Wie im vorigen Kapitel dargestellt, kann die Einführung von SAP GRC Access Control in die gesamte
Organisation eines Unternehmens schrittweise, in definierten Phasen oder über einen Big Bang
erfolgen. In beiden Fällen sollte eine entsprechende Vorbereitung mit der Strategie-, Design- und
Implementierungsphase des Piloten erfolgen.
Bei der schrittweisen Einführung in die Gesamtorganisation sollten folgende Faktoren zunächst
betrachtet und evaluiert werden:
› Auswahl der wichtigsten Geschäftsprozesse und der dabei involvierten Fachbereiche: Meist
bietet sich in der ersten Phase ein wichtiger Nebenprozess an, wie z.B. der Einkaufsprozess von
Gebrauchsgütern.
› Danach müssen die für diesen Geschäftsprozess notwendigen SAP- oder Nicht-SAP-Systeme
ausgewählt werden. Im optimalen Fall sollte dies nur ein System umfassen, um die Komplexität
nicht zu erhöhen.
› Auch müssen die Ländergesellschaften ausgewählt werden, die bei der ersten Ausrollphase
involviert sein sollen. Auch hier bietet sich an, dass zunächst mit einem Land begonnen wird.
Dies hängt vor allem davon ab, ob die Geschäftsprozesse harmonisiert worden sind und nicht
zu viele Ausnahmen existieren. Sind die Prozesse harmonisiert, so können auch mehrere
Länder in den Rollout einbezogen werden. Ein limitierender Faktor ist die Teamgröße des zur
Verügung stehenden Rollout-Supportteams, da eventuell an verschiedenen Standorten parallel
Unterstützung angeboten werden muss.
› Ein weiterer Faktor, der bei der schrittweisen Methode betrachtet werden muss, ist das Vor-
handensein eines SAP-Rollenkonzeptes, das schon zu einem hohen Maß harmonisiert ist und
für das eindeutig die organisatorischen Attribute und Rolleneigner zugeordnet werden können.
Ist dies nicht der Fall, so müssen die Abhängigkeiten des Rollendesigns mit anderen Geschäfts-
prozessen und Fachbereichen analysiert werden. Ist das Rollenkonzept auf Basis von Aufgaben-
rollen und nicht auf positionsbasierten Rollen aufgebaut, die auch Funktionalitäten und Berech-
tigungen anderer Fachbereiche angrenzender Geschäftsprozesse umfassen, so lässt sich ein
schrittweiser Rollout einfacher durchführen, da sich in diesem Fall der Umfang der zu migrie-
renden Rollen und auch die Organisationseinheiten leichter eingrenzen lassen. Die gegenseitigen
Abhängigkeiten sind somit geringer, sodass die notwendigen Abstimmungsaufwände zwischen
den Fachbereichen kleiner sind.
Wie der Name schon symbolisiert, werden bei einer Big-Bang-Einführung alle neuen Workflows
inklusive dem Risikomanagement und eventuell auch neu definierten Berechtigungen für alle
Geschäftsprozesse und daran beteiligten Fachbereiche, sowie SAP- und Nicht-SAP-Systeme z.B.
über einen definierten, kurzen Zeitraum (z.B. Wochenende) eingeführt. Alle Schritte der Imple-
mentierungsphase müssen durchlaufen und auch ein erfolgreicher Pilot durchgeführt sein. Die
Einführung kann speziell bei einem notwendigen Reengineering des Rollenkonzepts auch parallel
zum bestehenden Berechtigungskonzept erfolgen, wenn über einen gewissen Zeitraum von z.B. zwei
Wochen den Anwendern das neue bereinigte Rollenkonzept parallel zum bestehenden zugeordnet
wird und dann später die alten Rollen entzogen werden. Der limitierende Faktor bei einer Big-Bang-
81
Einführung stellt in der Regel der notwendige Support dar, der normalerweise unmittelbar nach
einer Einführung notwendig ist.
Folgende Vor- und Nachteile sind bei beiden Einführungsszenarien zu beachten.
Vorteile einer schrittweisen Einführung:
› Das gesamte Einführungsrisiko ist geringer, da erst nach einer Stabilisierung eines Geschäfts-
prozessbereichs mit dem nächsten begonnen werden kann. Zudem kann zunächst mit
Geschäftsbereichen begonnen werden, die für das Unternehmen weniger kritisch sind, wenn
eventuell Ausfallzeiten des SAP Systems auftreten würden oder einzelne Mitarbeiter ihre
geschäftskritischen Arbeiten nicht ausführen könnten.
› Es könnte ebenfalls zunächst mit einem weniger geschäftskritischen SAP-System begonnen

werden.
› Das Projektteam muss für den notwendigen Support nach dem Rollout nur einen überschaubaren
Fachbereich betreuen und nicht eine gesamte Organisation, z.B. eine Länderorganisation. Es
muss daher das Rollout-Team nicht verstärkt werden.
› Der Schulungsbedarf kann auf wenige Schlüsselanwender begrenzt werden.
Nachteile einer sukzessiven Einführung:
› Die Abgrenzung der Geschäftsprozesse und Bereiche sowie deren Abbildung auf die SAP-Systeme
können sich bei komplexen Organisationen schwierig gestalten.
› Speziell die Risikomatrixfestlegung muss schon für alle Geschäftsprozesse durchgeführt

werden, da die kritischen Funktionstrennungsprobleme auch quer zu parallel verlaufenden
Geschäftsprozessen auftreten können.
› Auch bei einer notwendigen Einführung eines überarbeiteten Rollenkonzepts lässt sich die
Abgrenzung zwischen den Geschäftsbereichen oftmals schwierig gestalten, sodass das Reen-
gineering eigentlich für die wichtigsten Geschäftsprozesse parallel durchgeführt werden müsste,
da auch Funktionstrennungskonflikte übergreifend zu Geschäftsprozessen vorhanden sind, falls
die Anwender (wie im Normalfall) in mehreren Prozessen involviert sind.
› Nach dem Ausrollen eines Fachbereichs ist es eigentlich noch nicht möglich, die entsprechenden
Workflows und Self-Services gesamtheitlich live zu schalten, da ansonsten in den betroffenen
SAP-Systemen eventuell eine nicht handhabbare Mixtur aus Alt- und Neukonzepten entsteht.
Die Änderungen in den ausgerollten Fachbereichen sollten daher minimal sein.
Die Vor- und Nachteile eines Big-Bang-Rollouts stellen sich gerade umgekehrt dar. In der Regel
kann in den meisten Fällen nur ein schrittweiser Rollout durchgeführt werden, da bei einem Big
Bang die notwendige Support- und Schulungsunterstützung nicht im Einführungsteam verfügbar
ist. Auch ist die Rollou-Koordination bei einem Big Bang nur mit entsprechend hohen Aufwänden
realisierbar.
82
7. WEITERFÜHRENDE DOKUMENTATION
Die Standard-Produkt-Dokumentation (Installation, Konfiguration, Master etc.) befindet sich auf

SAP Service Marketplace unter http://service.sap.com/instguides -> Analytics -> Governance, Risk,
and Compliance -> GRC Access Control.
Ein Sizing Guide befindet sich auf http://service.sap.com/sizing -> Sizing Guidelines -> Analytics.
SAP veröffentlicht auch zusätzlich eine große Anzahl von „How-to Guides“, auf die wir an dieser
Stelle hinweisen möchten. Diese befinden Sie unter http://www.sdn.sap.com/irj/bpx/grc -> Key
Topics -> SAP GRC Access Control.
Hier möchten wir im Speziellen auf folgende How-to Guides hinweisen:
› GRC 10.0 Pre-Installation

› GRC 10.0 Post-Installation
› AC 10.0 Post-Installation
› AC 10.0 - Installation Checklist
› SAP GRC Access Control 10.0 and NetWeaver Identity Management
Die Anwenderdokumentation befindet sich unter auf http://help.sap.com/grc.
Ein wichtiger Hinweis zur Kompatibilität von Plugins / RTAs zum Zentralsystem ist der Hinweis
1352498. Ab SAP GRC10.0 SP10 wird eine Abwärtskompatibilität ermöglicht.
83
8. PRAXISBERICHT THYSSENKRUPP AG
ThyssenKrupp ist ein Technologiekonzern mit hoher Werkstoffkompetenz. Bei ThyssenKrupp
arbeiten über 160.000 Mitarbeiter in rund 80 Ländern mit Leidenschaft und hoher Kompetenz an
Produktlösungen für nachhaltigen Fortschritt. Ihre Qualifikation und ihr Engagement sind die Basis
für unseren Erfolg. ThyssenKrupp erwirtschaftete im Geschäftsjahr 2012/2013 einen Umsatz von
rund 39 Mrd. EUR.
Innovationen und technischer Fortschritt sind für ThyssenKrupp Schlüsselfaktoren, um das globale
Wachstum und den Einsatz begrenzter Ressourcen nachhaltig zu gestalten. Mit unserer Ingenieur-
kompetenz in den Anwendungsfeldern „Material“, „Mechanical“ und „Plant“ ermöglichen wir
unseren Kunden, sich Vorteile im weltweiten Wettbewerb zu erarbeiten sowie innovative Produkte
wirtschaftlich und ressourcenschonend herzustellen.
ThyssenKrupp hat sich im Rahmen einer ausführlichen Produktauswahl im Jahr 2008 für SAP GRC
Access Control als Lösung zur Kontrolle von kritischen Berechtigungsvergaben im Geschäftsan-
wendungsumfeld entschieden. Zusammen mit einem im Anschluss ausgewählten Implementie-
rungspartner wurde ein Programm zur konzernweiten Einführung der Lösung aufgesetzt. Dieses
hatte im Kern zunächst vordringlich folgende Ziele:
1. Einführung der Komponente „Risk Analysis and Remediation“ (RAR). Je nach lokalem Bedarf
wird ggf. die Komponente „Superuser Privilege Management“ eingeführt.
2. Erstellung eines einheitlichen Regelwerks zur Abbildung der Risiken im Berechtigungswesen
von ERP-Systemen und möglicher Kompensierungsmechanismen.
3. Erarbeitung eines Rahmenkonzeptes für den Betrieb der Analyseplattform und den Change-
Prozess bei der Regelwerkspflege.
4. Aufbau eines Competence Centers für die Risikoanalyse mit SAP GRC Access Control.
5. Erstellung eines Roll-Out-Plans zum Anschluss der ERP-Systeme der Konzernunternehmen
(Priorität zunächst auf SAP-basierte Systeme).
Zu diesem allgemeinen Vorhaben, das letztlich die Produktivsetzung einer kompetent geführten,
konzerneinheitlichen Risikoanalyse auf ERP-Berechtigungen zum Ziel hat, kam eine Reihe von
wichtigen Nebenbedingungen hinzu:
› Es soll ein zentrales, konzerneinheitliches Regelwerk verpflichtend Verwendung finden, aller-

dings mit der Möglichkeit von Erweiterungen durch die einzelnen Konzernunternehmen.
› Die Risikoanalyse soll auf einer konzernweit zentralen Plattform betrieben werden, mehrere
dezentrale Installationen sind nicht vorgesehen.
› Im Rahmen der konzernweiten Einführung soll das Programm etabliert werden mit der grund-
sätzlichen Pflicht aller Konzernunternehmen, ihre ERP-Systeme an die Risikoanalyse anzu-
schließen, wobei hinreichend Übergangsfristen für die Anschlusstätigkeiten, die ersten Analysen,
Bewertungen, Planungen und die anschließende Bereinigung vorzusehen sind.
› Eine verteilte Struktur für das Change Management der Regelwerke ist aufzubauen, die den
Konzernunternehmen die Möglichkeit einräumt, an den Analysevorgaben und Risikodefinitionen
mitzuwirken, um so von Anfang an die Akzeptanz im Konzern zu erhöhen.
84
Zentrale
Risikoanalyse-
plattform
Risikoverantwortlicher Berechtigungen Fachverantwortlicher
Abbildung 11: Zielarchitektur einer zentralen Risikoanalyseplattform mit dezentralen Teams in den lokalen Einheiten
Nach der erfolgreichen Programminitiierung wurden für den Aufbau der notwendigen Kenntnisse
und Erfahrungen für das Competence Center und die Prüfung möglicher Alternativen beim Betrieb
und der Regelwerkspflege zunächst einige Pilotunternehmen im Konzern gewonnen, mit denen erste
Versuche einer zentralen Risikoanalyse durchgeführt wurden. Dabei wurden sowohl technische
Erfordernisse (RTA-Installation) getestet als auch fachliche Diskussionen zum zentralen Risikokatalog
geführt. Darüber hinaus konnten die Pilotunternehmen die Erstellung individueller Regelwerke und
Mitigationen testen.
Abbildung 12: Vorgehen zum Aufbau des GRC Access Control Competence Centers - Zusammenarbeit mit Piloten
85
Im Rahmen dieses Zusammenarbeitsmodells in der Pilotphase konnten so einerseits die Erfor-
dernisse im Betrieb festgestellt werden, andererseits konnten im neu gegründeten zentralen
Competence Center wichtige Erfahrungen mit der Lösung und dem Umgang der Problematik im
Konzern gesammelt werden.
März April Mai Juni Juli August September Oktober November

Start-up Kickoff MR 1st Draft MR validiert
Aufbau Masterregelwerk (MR) Validierung

Rahmenkonzept
Aufbau Risikokatalog
Technische Architektur
Anpassungen AG
Anpassungen KU 1
Anpassungen KU 2
Rollout Feinplan
Rahmen-
konzept MR-Draft
(Entwurf)
Schulung
Projekt-
team
Projektteam
geschult
Abbildung 13: Programmplanung mit Pilotunternehmen
Ein weiteres wichtiges Element bei der Einführung war die Etablierung einer Programmstruktur und
des Change Managements. Bereits bei der Produktsuche und Auswahl waren bei ThyssenKrupp die
Bereiche Zentrales Rechnungswesen, Internal Auditing und IT gleichermaßen beteiligt, diese stellten
innerhalb der Programmstruktur auch den Lenkungskreis als maßgebliches Entscheidungsgre-
mium. Durch die damit erfolgte indirekte Einbindung der Fachbereiche wurde ein wesentlicher
Baustein für die Akzeptanz einer Risikoanalyse auf Berechtigungen im ERP-Umfeld geschaffen.
Innerhalb der Programmstruktur wurden für das Change Management der Regelwerksinhalte für
die einzelnen Business Areas von ThyssenKrupp sog. Risikokoordinatoren benannt. Hierbei wurden
nicht dezidierte Positionen, aber Aufgaben geschaffen, um einerseits die Kommunikation zwischen
dem zentralen Competence Team und den Konzernunternehmen zu bündeln und andererseits
effiziente Feedback- und Entscheidungswege zu ermöglichen. Wenn etwa ein Konzernunternehmen
eine Risikodefinition und die Prüfsemantik aus dem zentral verbindlichen Master-Regelwerk
anpassen möchte, so müssen die Änderungen vor Produktivsetzung von den Risikokoordinatoren
gesichtet und letztendlich vom Lenkungskreis genehmigt werden. Diese können die Änderungen
vorab in ihren jeweiligen Business Areas und den dortigen Konzernunternehmen auf etwaige
Nebeneffekte prüfen.
86
Um den konzernweiten Rollout sowohl inhaltlich als auch vom Anschluss- und Betreuungsaufwand
her in einem akzeptablen Rahmen zu halten und um die Fachorganisation nicht mit umfangreichen
Änderungen im Berechtigungswesen zu überfordern, wurde ein Rollout-Plan in inhaltlichen und
regionalen Phasen entwickelt. Zum einen wurden zunächst nicht alle ERP-Komponenten mit einem
Risikokatalog und entsprechendem Master-Regelwerk zur Prüfung versehen, sondern nur der
Einkaufsprozess, also Teile von FI/CO und MM. Auch hiermit konnte die Akzeptanz maßgeblich
gesteigert werden, insbesondere weil Risiken im Einkaufsprozess wohlbekannt und seit vielen
Jahren von Wirtschaftsprüfern begutachtet werden (Standardbeispiel: Die Stammdatenpflege von
Kreditoren sollte nicht zusammen mit der Pflege von Belegen, etwa Rechnungen, vergeben werden).
Zum anderen wurde die Anschluss- und Bereinigungspflicht zunächst nur für inländische Konzern-
unternehmen vorgesehen, außerdem standen nur SAP-Systeme im Fokus, also noch keine Non-
SAP-Systeme.
Für die formale Einordnung der Risikoanalyse von Berechtigungen in ERP-Systemen in die konzern-
internen Vorgaben, etwa zum Betrieb von IT-Verfahren, wurde eine Konzernrichtlinie erstellt und
verabschiedet, die den phasengesteuerten Rollout, die Verpflichtung der Teilnahme und den dazu-
gehörigen Zeitrahmen definiert: Alle inländischen ERP-Systeme, die einen Einkaufsprozess abwi-
ckeln, mussten sich – vom Beginn der Gültigkeit der Richtlinie an – innerhalb von zwei Jahren an
die zentrale Risikoanalyseplattform anschließen. Nach Anschluss hatten die Unternehmen jeweils
ein Jahr Zeit, ihr Berechtigungswesen von aufgezeigten Konflikten zu bereinigen – dies konnte so-
wohl in Form von Berechtigungsüberarbeitungen als auch durch die Einstellung von mitigierenden
Kontrollen durchgeführt werden.
Der so initiierte Rollout wurde darüber hinaus begleitet durch Kommunikationsmaterial, vorab
geführte Gespräche mit Datenschutz und Betriebsrat. Für jedes Konzernunternehmen wurden –
nach einer ersten Analyse – Workshops zur Interpretation der Ergebnisse durchgeführt und weiter-
führende Schulungen der Fachbereiche und Berechtigungsteams zur Bedienung der Werkzeuge
angeboten.
Als Programmergebnisse waren nach fast vier Jahren – in diesem Zeitraum kamen noch die Regel-
werke zu Basis und HR/Datenschutz und Verkauf dazu – folgende zu verzeichnen:
1. Risikokataloge bzw. Masterregelwerke für Einkauf, Basis, HR/Datenschutz und Verkauf
› Erarbeitung eines Risikokatalogs für den Einkauf

› Erstellung Masterregelwerk im Analysesystem
› Anpassung und Validierung mit drei Piloten:
Masterregelwerk war abgestimmt und kann nun im Rollout verwendet werden
87
2. Erarbeitung eines Risikokatalogs für Basis, HR/Datenschutz und Verkauf
Rahmenkonzept zur Risikoanalyse
› Analyse der organisatorischen Rahmenbedingungen bei ThyssenKrupp

› Erarbeitung der Aufgabenverteilung zentrales GRC Access Control Team vs.
dezentraler Fachverantwortlicher und Berechtigungsteams in den Konzernunternehmen
› Entwurf geeigneter Support- und Change-Management-Prozesse
› Verortung der Aufgabenverteilung in der Organisation von ThyssenKrupp
› Abstimmung mit ThyssenKrupp IT Service GmbH, dem internen IT-Dienstleister,
und den Konzernunternehmen
› Abstimmung mit Datenschutz und Betriebsrat
› Abstimmung mit Wirtschaftsprüfern
Programmverortung sichergestellt, Organisation des Changemanagement verabschiedet und
produktiv
3. Anschlussplanung und -durchführung
› Planung der Teilnahmereihenfolge in Absprache mit den Konzernunternehmen ist erfolgt

› Anschlüsse der Konzerunternehmen durchgeführt (sofern bereits Anschlusszeitpunkt erreicht)
› Analyseworkshops und Schulungen durchgeführt
› Konzernunternehmen bereinigen Berechtigungskonflikte planungsgemäß
Produktiver Betrieb der zentralen Plattform ist erfolgt
Vor diesem Hintergrund wurde die gesamte Programmdurchführung 2008 – 2012 als erfolgreich
angesehen, die zentrale Risikoanalyse auf Berechtigungen in ERP-Systemen war inländisch etab-
liert und Teil der Gesamtstrategie.
Im Rahmen einer bei ThyssenKrupp ab 2012 erfolgten Reorganisierung des Konzerns wurden einige
der oben beschriebenen Programmelemente organisatorisch verlagert und umbenannt.
88
9. ANHANG:
Im Folgenden werden die Migration von SAP GRC Access Control 5.3 nach 10.0 sowie die Integration
von SAP GRC Access Control und Identity Management am Beispiel von SAP NetWeaver Identity
Management einschließlich möglicher Synergieeffekte dargestellt.
9.1 MIGRATION VON SAP GRC ACCESS CONTROL 5.3
Während GRC Access Control 5.3 primär eine Java-Applikation ist, läuft GRC Access Control 10.0
auf einem ABAP-basierten System. Daher gibt es keinen Upgradepfad von einer Version zur anderen,
sondern nur die Möglichkeit einer Migration. Dabei wird ein Großteil der Konfigurationen und Daten
aus dem 5.3er-System exportiert und in das 10.0er-System wieder importiert. Hierfür stellt SAP ab
5.3 SP 13 eine entsprechende Migrationsapplikation zur Verfügung, die einen strukturierten Export
der Daten erlaubt.
Dieses Migrationstool findet sich auf dem Servicemarketplace der SAP unter SAP GRC Access
Control 10.0, wird aber auf dem Java-Stack der AC-5.3-Installation eingespielt:
Abbildung 14: Datenmigrationsapplikation in AC5.3 SP13 (Java)

89
Beim Superuser Privilege Management wiederum wird über das GRC10.0-Plug-in für die ange-
schlossenen Backend-Systeme ein Migrationswerkzeug zur Verfügung gestellt, mit dem sich die
lokale FireFighter-Konfiguration exportieren und dann in das zentrale System wieder einspielen
lässt.
Folgende Daten können mittels dieser beiden Werkzeuge übernommen werden:
RAR EPM CUP SPM
› Regelwerk (SoDs, › Konfigurationsdaten › Konfigurationsdaten › FireFighter-Tabellen

kritische Aktionen / › Rollenattribute › Workflowtypen › Verantwortliche
Berechtigungen) › Organisationswert- › Genehmiger › Kontrolleure
› Kritische Rollen und zuordnungen › Stages und Pfade › Ursachencodes
Profile › Rollen › Eskalationskonfi-
› Organisationsregeln › Pflegevorgänge gurationen und
› Genehmiger › Zuordnung von -Ausnahmerouting
› Mindernde Rollen zu Pflege- › Rollen
Kontrollen schritten
› Kontrollzuweisungen
Der Migrationsprozess sollte daher mit einem Schritt beginnen, der berücksichtigt, welche Daten
überhaupt übernommen werden, sollen und können und wie jeweils mit anderen Daten zu verfahren
ist. So muss beachtet werden, dass die Workflows mit der ABAP-basierten Workflow-Engine nach-
gebaut werden müssen. Historische Daten wie Antragsgenehmigungen / Audit Trails oder Manage-
mentberichte sind nicht übertragbar und sollten passend archiviert werden. Hier ist zu empfehlen,
von den Management-Berichten evtl. Screenshots anzufertigen und die Daten früherer Anträge aus
der Datenbank zu exportieren und etwa als PDF abzulegen für zukünftige Anfragen von Prüfern.
Als weiterer Vorbereitungsschritt wird die Installation des Migrationswerkzeugs benötigt. Hierfür
muss die AC5.3-Version auf SP13 angehoben werden. Das Migrationstool wird separat im Java-Stack
deployt. Die 10.0er-Plug-ins müssen überall eingespielt werden für den Export der SPM-Daten.
Anschließend müssen im 10.0er-Zentralsystem die Benutzer für die Genehmiger, Kontrolleure etc.
angelegt werden sowie die kundenindividuellen Felder, die im CUP verwendet werden. Bevor die
eigentlich Migration beginnt, müssen die 5.3er-Aktivitäten eingestellt werden, damit nicht weitere
Produktivdaten nach Export anfallen. Der Enduser-Zugriff sollte daher ebenfalls geschlossen werden.
90
Der Ablauf der Migration selbst sieht dann folgendermaßen aus:

› Datenexport relevanter Inhalte von AC5.3 und lokalen SPM-Konfigurationen
› Kopie der Datendateien in einen Importordner auf dem GRC10.0-System
› Import der Konfigurationsdaten
› Konnektoren- und Konnektorengruppenpflege im GRC10.0-System
› Organisationseinheit anlegen für die mindernden Kontrollen
› Import der Applikationsdaten für die Komponenten
Nach der Datenmigration müssen die nicht übertragbaren Konfigurationen im GRC10.0-System

nachgezogen bzw. neu aufgebaut werden. So müssen insbesondere für ARM für jeden Initiator und
Approver Determinator und für BRM für jede Konditionengruppen und Genehmigerkriterien jeweils
die dazugehörigen BRF+-Regeln (oder Funktionsbausteine) erstellt werden. Dann müssen ggf. noch
die E-Mail-Templates angelegt werden, wenn in AC5.3 welche verwendet wurden. Abschließend
müssen die Daten und die Funktionsweise der Workflows geprüft und intensiv getestet werden.
Da der Umstieg auf SAP GRC Access Control 10.0 ein völlig verändertes Benutzerinterface mit sich
bringt, sind Anwenderschulungen durchzuführen und ggf. noch User Acceptance Tests einzuplanen.
Ist die Migration erfolgreich durchgeführt worden, sollten die oben angeführten Archivierungs-
vorgänge auf Managementberichte und Audit-Trails / Altanträge durchgeführt werden, bevor das
AC5.3-System aus dem Betrieb genommen wird.
Weitere Tipps für die Go-live-Strategie im Rahmen einer Migration von GRC Access Control 5.3:
Wenn die Plug-ins für 10.0 auf die Satellitensysteme eingespielt werden, werden die RTAs (Kompo-
nenten VIRSA*) dabei gelöscht. Dennoch können die jeweiligen Backends weiter im AC5.3-Szenario
betrieben werden. Dies funktioniert, weil der Code der 5.3er-RTAs in den 10.0er-Plug-ins enthalten
ist. Allerdings muss dabei beachtet werden, dass die 10.0er Plug-ins hier immer einen bestimmten
5.3er-SP-Level enthalten. Prüfen Sie daher unbedingt den Zentralhinweis 1680268 („Kompatibilität
von Paketen zu SAP GRC Access Control“) und die darin referenzierten Einzelhinweise.
Der Vorteil des Verfahrens besteht dann allerdings darin, dass die Namensräume AC5.3 vs. AC10.0
getrennt sind und beide Szenarien vollkommen parallel betrieben werden können. Dies vereinfacht
den Rollout der Migration: Systeme können bereits Monate vorher mit der Software bestückt werden,
werden dann aber nur in Teilrollouts von einem Verfahren auf das andere umgestellt. Hier muss
allerdings im Vorfeld genau überlegt werden, ob etwa Workflows über zwei verschiedene Verfahren
angeboten werden sollen, dies hängt stark von der Differenzierung der Verfahren in der Organisation ab.
91
9.2 INTEGRATION GRC ACCESS CONTROL/IDENTITY MANAGEMENT
Schon unter SAP GRC Access Control 5.3 gab es die Möglichkeit, die Provisionierungsmechanik von
CUP mit anderen Identity-Management-Systemen zu verknüpfen. Hierfür stellt GRC Access Control
Webservices zur Verfügung, die von diesen anderen Systemen zur Datenübergabe gerufen werden
können, etwa um eine Risikoanalyse durchzuführen. GRC Access Control wiederum kann aktiv einen
Workflow in ein anderes Identity-Management-System übergeben.
Die Gründe für die Kopplung von GRC Access Control mit solchen Systemen sind vielfältig. SAP GRC
Access Control 5.3 fehlte im Vergleich zu guten Identity-Management-Produkten die Flexibilität im
Workflow-Betrieb, hier konnten neben dem Standard kaum kundenindividuelle Anpassungen vorge-
nommen werden. Darüber hinaus war die Anzahl der Non-SAP-Konnektoren vergleichsweise über-
schaubar. Während diese Argumente bei SAP GRC Access Control 10.0 an Gewicht verlieren – hier
ermöglicht die BRF+-Workbench die Formulierung komplexer Auswertungen und Bedingungen für die
Workflowsteuerung, außerdem sind mehr Non-SAP-Konnektoren verfügbar und über das Konnektor-
Framework auch selbst herstellbar – bleiben weitere Gründe nach wie vor erhalten:
› Oft werden in Unternehmen bereits Identity-Management-Systeme im Non-SAP-Umfeld betrie-

ben, die nicht abgelöst werden können oder sollen, dennoch will man für die SAP-Systeme
Gebrauch von der Risikoanalyse und dem Notfallbenutzerverfahren von SAP GRC Access Control
machen, die Provisionierung jedoch aus dem übergreifenden Identity Management steuern.
› Mitunter sind auch die organisatorischen Strukturen, die solche Plattformen betreiben, nach
Applikationsumfeld unterschiedlich und eine einheitliche Werkzeugauswahl im Großkonzern-
bereich weder einfach herstellbar noch anstrebenswert: Die Einführung eines einzigen, einheitlich
übergreifend über alle Applikationsbereiche hinweg arbeitenden Identity-Management-Produktes
ist hochkomplex, dauert typischerweise Jahre, ein durchgehender Projekterfolg ist selten. Gerade
im Großunternehmensumfeld hat es sich daher bewährt, eher mehrere bereichsweit agierende
Identity-Management-Systeme miteinander zu verbinden, als einen Monolithen aufzubauen.
› Die Integration von HCM-Merkmalen (Position, Abteilungszuordnung, Integration des Org-

Managements usw.) ist bei Identity-Management-Systemen teilweise besser gelöst und stellt
mehr Auswertungsmöglichkeiten zur Verfügung als bei SAP GRC Access Control. Hier gilt es,
noch einmal darauf hinzuweisen, dass die Benutzer- und Rollenprovisionierung über SAP GRC
Access Control rein antragsbasiert erfolgt. Eine komplexe interne Identitätsdatenbank etwa mit
HCM-Merkmalen an Mitarbeitern wird nicht vorgehalten.
92
IDM angestoßen durch HR-Prozesse Geschäftsprozess benötigt korrekte Benutzeranlagen

und Daten und Rollenzuweisungen in Systemen
z.B. Order2Cash
HCM
z.B. Neueinstellungen
Identity-Virtualisierung
SAP Business Suite und Identity-Servise
Konformitäts- Integration Genehmigungen
prüfung durch GRC
SAP Access Control SAP NetWeaver

(GRC-Suite Identity Management
Zentraler
Identity-Store
Identity-Mgmt. Passwort-
Monitoring & Audit Provisionierung an SAP-
management
Regelbasierte und Non-SAP-Systeme
Zuweisung von
Businessrollen
y
Legac
Email
Web
App
SCM HCM ERP Java Porta
l
DB OS
Abbildung 15: Integrationsbild der verschiedenen Funktionen von SAP GRC Access Control und einem Identity-Manage-
ment-System am Beispiel SAP NetWeaver Identity Management
› Wenn man sich nun zu dem Schritt entschieden hat, ein vorhandenes oder zukünftiges Identity-
Management-System mit SAP GRC Access Control zu verbinden, stellen sich zunächst einige
allgemeine Fragen, die maßgeblich für die Lösungsarchitektur sind:
› In welchem Werkzeug sollen Endanwender die Anträge stellen? Es ist immer davon abzuraten,
Endanwender für die Beantragung von Benutzern und Berechtigungen verschiedener Applikationen
auf unterschiedliche Antragsverfahren zu schicken. Dies stiftet nur Verwirrung, führt zu Akzeptanz-
problemen und beim Helpdesk zu erheblichen Mehraufwänden bei der Anleitung der Anwender.
93
› In welchem Werkzeug sollen Genehmigungen durchgeführt werden? Hier ergeben sich ähnliche
Probleme wie beim ersten Punkt. Die Menge der Genehmiger ist allerdings typischerweise kleiner
als die der Endanwender und ggf. auch disjunkt, d.h., Genehmiger können ggf. jeweils auf „ihr“
Werkzeug geschult werden und müssen nur selten zwei oder drei verschiedene benutzen. Darüber
hinaus werden Genehmiger oft über E-Mail-Benachrichtigungen in die Workflows eingebunden
und müssen „das richtige“ System nicht erst suchen.
› Welche technischen Restriktionen gibt es ggf. bei der Kopplung, die bestimmte Szenarien
erschweren? Welche Konnektorentypen sind notwendig und können von welchem Produkt
am besten geliefert werden?
› Wie komplex sind der Betrieb und die Fehlerdiagnose bei bestimmten Lösungsarchitekturen?
Ist der Aufbau noch mit vertretbarem Aufwand zu warten?
Grundsätzlich gibt es drei verschiedene Lösungsarchitekturen bei der Integration von GRC Access
Control mit einem anderen Identity-Management-System: Head-, Tail- oder Sandwich-Aufbau:
1. Beim Head-Verfahren steht SAP GRC Access Control „vorne“ und dient als Einstiegspunkt den
Endanwendern für die Antragsstellung zur Verfügung. Es baut den dazugehörigen Workflow
auf und erstellt die Risikoanalyse, sofern Benutzer oder Berechtigungen für SAP-Applikationen
beantragt werden (ggf. auch für Non-SAP-Applikationen, wenn die Risikoanalyse hierfür möglich
ist), die Analyseergebnisse kann der Genehmiger dann zur Entscheidungsfindung verwenden.
Wurde der Antrag genehmigt, wird der Workflow an das Identity-Management-System zur Weiter-
vermittlung in die SAP- und Non-SAP-Backendsysteme übergeben. Eine Untervariante ist hierbei,
dass nur die Non-SAP-Workflows übergeben werden und die SAP-Workflows die SAP-Systeme
direkt provisionieren.
Dieser Ansatz wird auch als AC-Driven-Integration bezeichnet und erfordert die vollständige
Synchronisation des IDM-Systems durch SAP GRC Access Control.
2. Bei der Sandwich-Variante steht SAP GRC Access Control in der Mitte und wird für die Risiko-
analyse eingeschleift, d.h., die Antragsstellung erfolgt im Identity-Management-System, die
abschließende Provisionierung ebenfalls. Innerhalb des Workflows wird entschieden, ob eine
Risikoanalyse erforderlich ist, diese wird dann mit SAP GRC Access Control durchgeführt.
94
Anlage eines Rollenzuweisungsantrags im Identity Management
Automatisch (regelbasiert, ggf. über HCM) Manuell (Endbenutzerantrag)
Vorverarbeitung des Antrags im Identity Management
Zuweisung erfordert Risikoprüfung Zuweisung erfordert keine weitere Prüfung
Antragsverarbeitung & Risikoanalyse in Access Control
Risikoverletzung gefunden Keine Risikoverletzung gefunden
Antragsumleitung in
manuelle Genehmigung
abgelehnt angenommen
Identity Management liest Antragsstatus
Keine Provisionierung Identity Management startet Provisionierung
Abbildung 16: Sandwich-Architektur
Wenn im Sandwich-Verfahren jedoch auch Workflows für Non-SAP-Systeme ohne die Einschlei-
fung von SAP GRC Access Control verwendet werden, stellt sich wieder die eingangs erwähnte
Frage, ob die Gruppen der Genehmiger im IDM und im SAP GRC Access Control disjunkt sind
oder ob den Genehmigern zwei verschiedene Werkzeuge zumutbar sind.
Im Sandwich-Verfahren ist sowohl ein Polling des Status der Anträge im SAP GRC Access Control
durch das IDM möglich als auch ein Callback vom SAP GRC Access Control in das IDM, wenn der
Workflow im SAP GRC Access Control beendet wurde.
3. Beim Tail-Verfahren steht SAP GRC Access Control „hinten“ und führt hier nur die Provisionie-
rung in die SAP-Systeme durch. Dies wird zum einen dort betrieben, wo das Identity-Manage-
ment-Produkt keinen guten SAP-Konnektor besitzt, zum anderen kann hier noch eine Risiko-
analyse eingeschleift werden (wobei sich dann das Problem der Genehmiger von Workflows
einstellt). Ein Nachteil dieses Verfahrens ist, dass das Identity-Management-System typischer-
weise immer noch an die einzelnen Backend-Systeme angeschlossen werden muss, um
Schiefstände zwischen den letztlich in die Systeme provisionierten Daten und ggf. sogar lokal
vorgenommenen Änderungen (z.B. nach Systemkopie) zu vermeiden und den korrekten Daten-
stand im Identity-Management-System sichtbar zu machen.
95
Anlage eines Rollenzuweisungsantrags im Identity Management
Automatisch (regelbasiert, ggf. über HCM) Manuell (Endbenutzerantrag)
Vorverarbeitung des Antrags im Identity Management
Zuweisung erfordert Risikoprüfung Zuweisung erfordert keine weitere Prüfung
Antragsverarbeitung & Risikoanalyse in Access Control
Risikoverletzung gefunden Keine Risikoverletzung gefunden
Antragsumleitung in
manuelle Genehmigung
abgelehnt angenommen
CUP startet Provisionierung
Identity Management liest Antragsstatus
Identity Management sichert Datenkonsistenz IDM startet Provisionierung
Abbildung 17: Beispiel einer Tail-Architektur
Grundsätzlich besteht die Komplexität des Aufbaus darin, dass keines der Systeme die Datenkon-
sistenz bezüglich der Benutzer und Rollen verlieren darf, um weiterhin korrekte Abläufe durchführen
zu können. Hierbei müssen manuelle Korrekturen an Benutzerstämmen, Rollenpflegeaktivitäten in
den Backends – mit Synchronisation von Rollenänderungen in den jeweiligen Rollenshop des IDM-
Systems und von SAP GRC Access Control – oder etwa Systemkopien berücksichtigt werden. Die
einzelnen Provisionierungsschritte und Workflows müssen auch den Ausnahme- bzw. Fehlerfall
abdecken. Dies ist bei einer Architektur mit zwei Benutzer- bzw. Rollenprovisionierungswerkzeugen
wesentlich schwieriger einzuhalten. Ein Beispiel: Wenn bei der Benutzerpflege ein technischer
Fehler passiert – etwa weil der Benutzerstamm im Zielsystem aus nicht bekannten Gründen gegen
Änderungen gesperrt ist –, so muss dieser Fehler an alle beteiligten Systeme zurückvermittelt
werden. Komplexer wird dieser Vorgang, wenn nicht nur eine Änderung durchgeführt werden soll,
sondern mehrere. Ein Beispiel hierzu etwa ist die Ausnahmebehandlung bei der Risikoanalyse. So
kann ein Endanwender auch mehrere Rollen, z.B. fünf gleichzeitig, in einem Antrag anfragen. Wird
von diesen Rollen allerdings eine vom Genehmiger abgelehnt wegen zu hohem Risiko, so ist nur
diese eine betroffen, nicht die anderen vier. Diese geänderte Provisionierungslogik muss dann bei
96
einer zweistufigen Lösung auch dem Antragserfassungswerkzeug zurückgemeldet werden. Eine

weitere Komplikation kann entstehen, wenn der Genehmiger eine Rolle ablehnt, aber stattdessen
eine andere alternativ in den Antrag aufnimmt. Hier gibt es oft Unzulänglichkeiten in den Mecha-
nismen der IDM-Systeme, die ein solches Verhalten nicht erwarten. Daher sollte das IDM-Produkt
vorab auf entsprechende Features hin geprüft werden.
Diese Schilderung soll nicht die Möglichkeit der Integration eines Identity-Management-Systems mit
SAP GRC Access Control diskreditieren. Allerdings sollte die Komplexität der Use Cases und die
der möglichen Sonderfälle im Workflow nicht unterschätzt werden. Inzwischen haben etliche SAP-
Kunden erfolgreich entsprechende Integrationsszenarien produktiv laufen, daher ist der Betrieb
durchaus beherrschbar. Bekannte Produkte, mit denen dies gelungen ist, stammen dabei von SAP
(NetWeaver Identity Management), Novell (Identity Manager), IBM (Tivoli).
Die Liste der von SAP GRC Access Control 10.0 angebotenen Webservices für die Integration umfasst
etliche nützliche Services, die hier einmal zur Bewertung aufgelistet werden:
Schnittstelle Beschreibung Technischer Name
Abrufservice Nachschlagen von möglichen GRAC_LOOKUP_WS

Aufrufswerten zu Schnittstellen,
z.B. Werte für den Antragsstatus
Rollensuche Suche nach Rollen vor Antrags- GRAC_SEARCH_ROLES_WS

stellung im GRC Access Control
Rollendetails Gibt Details der Rollenbeschrei- GRAC_ROLE_DETAILS_WS

bung und der Attribute einer
Rolle zurück
Applikationsauswahl Gibt die konfigurierten Applika- GRAC_SELECT_APPL_WS

tionen (Konnektoren, Systeme)
zurück
FireFighter Liste der FireFighter-IDs und GRAC_FIRE_FIGHTER_WS

Owner
Benutzerzuweisungen Gibt die derzeitigen Rollen eines GRAC_USER_EXISTING_ASS-

Benutzers zurück GN_WS
Provisionierung Webservice zum Start einer GRAC_USER_ACCES_WS

Provisionierung
Risikoanalyse Durchführung einer Risikoanalyse GRAC_RISK_ANALYSIS_WITH_

(mit Antragsnummer) mit Antragsreferenz NO_WS
97
Schnittstelle Beschreibung Technischer Name
Orgsanisationszuwei- Zuweisung von Rollen an GRAC_ORG_ASSGN_REQUEST_

sungsantrag OIM-Objekte wie Stellen, OUs etc. WS
Provisionierungslog Gibt die Daten zum Stand eines GRAC_PROV_LOGS_WS

Benutzers zurück (wann ange-
legt, durch wen, mit welchen
Rollen etc.)
Antragsstatus Gibt den Status eines Antrags GRAC_REQUEST_STATUS_WS

zurück
Auditlog Gibt Workflowdaten über GRAC_AUDIT_LOGS_WS

Genehmiggsstufen, -pfade und
Genehmigerentscheidungen
zurück sowie die Provisionie-
rungsresultate
Antragsdetails Antragsdetails mit Risikoanaly- GRAC_REQUEST_DETAILS_WS

seergebnis
Risikoanalyse (ohne Rollen- und Benutzeranalyse GRAC_RISK_ANALYSIS_WOUT_

Antragsnummer) NO_WS
Provisionierungsaus- Service, der vom IDM gerufen GRAC_EXIT_FROM_IDM_WS

gang wird, um AC über das Ergebnis
eines Requests zu informieren
98
9.3 AUSBLICK SAP GRC ACCESS CONTROL 10.1

Die Version 10.1 von SAP GRC Access Control bringt im Wesentlichen ein verbessertes User Interface
mit: SAP GRC Access Control 10.1 nutzt das neue UI5-Framework des NetWeaver 7.40, das auch
Voraussetzung für die Installation ist. UI5 ermöglicht es Endanwendern, mit der verfügbaren Client-
Technologie – NetWeaver Business Client 4 oder etwa Internet Explorer 9 oder 10 – noch interaktiver
mit den Applikationen zu agieren, Drag-&-Drop-Vorgänge direkter durchzuführen und Kontextmenüs
mit Side-Panels flexibel einzusteuern.
Abbildung 18: Beispiel für ein einblendbares Side-Panel

99
Darüber hinaus bringt SAP GRC Access Control 10.1 eine Reihe von Verbesserungen und Erweite-
rungen für einzelne Komponenten mit:
Übergreifend: Berechtigungen für Reporting & Dashboards
Zum einen wurden hier weitere Berechtigungsprüfungen eingeführt, die es ermöglichen, Dashboard-
Sichten und Reports voneinander abzugrenzen. Kann ein Teil der Ergebnismenge eines Berichtes
wegen fehlender Berechtigungen nicht in den Bericht integriert werden, wird dies nun eindeutig
mit einer Meldung angezeigt. Zum anderen gibt es nun die Möglichkeit für den Endanwender, sich
die konkret fehlenden Berechtigungswerte im Folgenden anzeigen zu lassen. Dieses Verhalten ist
konfigurierbar.
BRM/ARM: Umgebungskontext
Im BRM gibt es mit SAP GRC Access Control 10.1 die Möglichkeit, Systeme zu Umgebungsgruppen
zusammenzufassen. So können Rollen system- und landschaftsübergreifend bezogen auf einen
bestimmten Kontext erstellt werden. Z.B. können die Entwicklungssysteme eines ERP-Landschafts-
verbunds zur Umgebung „Entwicklung“ zusammengefasst werden, während die Produktivsysteme
zur Umgebung „Produktion“ zusammengefasst werden. Auf beiden Gruppen lassen sich dann Rollen
pflegen, aber auch die Zuweisung im ARM steuern.
100
ARM: Konfiguration der Attribute bei der Rollensuche
Für die Beantragung von Rollen im ARM ist es nun möglich, die Suchfelder für die Endanwender
vorab besser einzustellen. So können Kriterien komplett ausgeschaltet werden und andere dafür
verpflichtend gemacht werden.
ARM: Vereinfachter Antrag
Sowohl bei der Auflistung der offenen Work Items in der Inbox als auch für die Beantragung von
Benutzeranlagen, -änderungen und Rollenzuweisungen wird nun eine vereinfachte Ansicht anboten.
Dabei kann die Anzahl der sichtbaren Felder erheblich reduziert werden (konfigurierbar) sowie
Standardfelder für die Anzeige umbenannt werden. Für die Antragsgründe können Textbausteine
zur Auswahl voreingestellt und per Drop-Down zur Verfügung gestellt werden. Diese Maßnahmen
können den Zugang zur Applikation für den allgemeinen Endanwender erheblich vereinfachen.
Abbildung 19: Vereinfachter Antrag

101
Root Cause Analysis & Remediation
Für eine gezieltere Risikoanalyse können vorab kundenindividuelle Benutzergruppen erstellt

werden, auf die die Analyse durchgeführt wird. Im nun verfügbaren UI5-Interface der Risikoanaly-
seergebnisse können per einfachem Drill-Down sowohl die Analysedetails eingeblendet werden als
auch über eine direkte Was-wäre-Wenn-Simulation die Ursache einer Risikoverletzung festgestellt
werden. So kann die direkte Simulation auf einer Risikoverletzung etwa der Entzug einer Rolle
sein, aber auch die Erstellung einer mindernden Kontrolle.
Abbildung 20: Root Cause Analysis mit Drill-Down hinunter auf Berechtigungsebene und Simulation eines Rollenentzugs
Systemspezifische Organisationsregelanalyse und Organisationsregel-Assistent
Organisationsregeln können in SAP GRC Access Control 10.1 nun systemspezifisch angegeben
werden. Darüber hinaus unterstützt ein Schritt-für-Schritt-Assistent mit Organisationsregeln
bei deren Erstellung: Zunächst wird das Zielsystem ausgewählt und dann die für dieses System
geltenden Organisationsebenen und -werte. Dabei werden zunächst auch Organisationsebenen
angeboten, bei denen bereits Risikoverletzungen vorliegen. Die Bündelung dieser Features macht
die Handhabung dieser eher komplexen Technik wesentlich überschaubarer.
102
9.4 DEZENTRALES NOTFALLBENUTZERVERFAHREN, AUFNAHME DES

DBTABLOGS
Die in der Version 10.0 SP10 eingeführte Möglichkeit, sowohl zentral über die GRC-Applikation als
auch dezentral im zu reparierenden System in die Notfallbenutzerverwendung einzusteigen, wird
fortgeführt. Außerdem werden Tabellenänderungsprotokolle aus dem DBTABLOG nun in der Proto-
kollierung der Notfallbenutzertätigkeiten verfügbar gemacht.
9.5 FUNKTIONEN FÜR HANA-APPLIKATIONEN
Mit SAP GRC Access Control 10.1 können nun Benutzeranlagen und -änderungen sowie Rollenzu-
weisungen in HANA-Systemen durchgeführt werden. Darüber hinaus können HANA-Privilegien mit
der Risikoanalyse auf kritische Berechtigungen und SoD-Verletzungen hin geprüft werden.
Abbildung 21: Beispiel einer Risikoanalyse von HANA-Privilegien

103
DSAG – Deutschsprachige SAP ® Anwendergruppe e. V.
Altrottstraße 34a © DSAG e. V.
69190 Walldorf
Deutschland
Fon: +49 (0) 6227 – 358 09 58
Fax: +49 (0) 6227 – 358 09 59
www.dsag.de I [email protected]

Publication

Hochgeladen von

Copyright:

Verfügbare Formate

Publication

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Publication

Hochgeladen von

Copyright:

Verfügbare Formate

SAP® GRC Access Control 10.

SAP® GRC Access Control 10.0

© COPYRIGHT 2015 DSAG E.V.

DEUTSCHSPRACHIGE SAP® ANWENDERGRUPPE E.V.

4. RAHMENBEDINGUNGEN FÜR EIN ERFOLGREICHES GRC-PROJEKT 27

Die Best-Practice-Empfehlungen erheben keinen Anspruch auf Vollständigkeit, sondern geben

@ Copyright 2015 der Autoren:

› Siegfried Filla PricewaterhouseCoopers AG WPG

› Marco Geisenberger Protiviti GmbH

› Rolf-Udo Gilbert dobis GmbH & Co. KG

› Markus Griem SAP Deutschland SE & Co. KG

› Matthias Middrup ThyssenKrupp AG

› Birger Tödtmann SAP Deutschland SE & Co. KG

› Dr. Alexander Ziesemer ThyssenKrupp AG

GRC 10.0 Landscape Synopsis

Front End Client optional

Recommended for GTS/SPL optional

Die GRC-Suite umfasst folgende Applikationen:

Front End Client optional

Global Trade Services

Abbildung 2: SAP GRC Access Control Applikationen

Compliance Calibrator Risk Analysis and Access Risk

Firefighter Superuser Privilege Emergency Access

Access Enforcer Compliant User Access Request

Role Expert Enterprise Role Business Role

Abbildung 3: SAP GRC Access Control Komponenten

› Access Risk Analysis (ARA)

› Emergency Access Management (EAM)

› Access Request Management (ARM)

› Business Role Management(BRM)

› die handels- und steuerrechtlichen Vorschriften zur Ordnungsmäßigkeit der Buchführung

› die IDW-Stellungnahme zur Rechnungslegung „Grundsätze ordnungsmäßiger Buchführung bei

› die IDW-Stellungnahme zur Rechnungslegung „Grundsätze ordnungsmäßiger Buchführung bei

› der IDW-Prüfungsstandard zur „Abschlussprüfung bei Einsatz von Informationstechnologie“

Deutscher Corporate Governance Kodex (DCGK Juni 2014)

Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) 1. Mai 1998

beurteilten Fehlerrisiken“ (IDW PS 261, Stand 6. September 2006).

Dieser GRC Best-Practice-Leitfaden möchte lediglich in Kurzform auf wesentliche zu beachtende

› SAP® Access Control, 2008, ISBN 978-3-8362-1141-3

Alle DSAG-Leitfäden finden Sie unter folgendem Link: www.dsag.de/Handlungsempfehlungen

3.1. DEUTSCHER CORPORATE GOVERNANCE KODEX

› Abschnitt 3 „Zusammenwirken von Vorstand und Aufsichtsrat“

› Abschnitt 5.3 „Bildung von Ausschüssen“

3.3. IDW RS FAIT 15

IDW RS FAIT 1 definiert u.a. Sicherheitsanforderungen an rechnungslegungsrelevante Daten. Im

IT-Systeme haben daher die folgenden Sicherheitsanforderungen zu erfüllen:

3.4. IDW RS FAIT 26

› Unzureichender Schutz vor Verfälschung (Verlust der Integrität)

technologie“ (IDW RS FAIT 1, Stand: 24. September 2002).

3.5 IDW RS FAIT 37

› Unzureichende organisatorische Festlegungen und Verfahrensanweisungen können die Nach-

3.6 IDW PRÜFUNGSSTANDARD PS 261 N.F.

Archivierungsverfahren (IDW RS FAIT 3)

Internes Steuerungssystem Internes Überwachungssystem

Abbildung 4: Elemente des internen Kontrollsystems

3.7 IDW PS 33010

In diesem Zusammenhang werden u.a. folgende Risiken des IT-Einsatzes hervorgehoben:

› IT-Anwendungsrisiken (fehlende oder nicht aktuelle Verfahrensregelungen und -beschreibungen,

› IT-Geschäftsprozessrisiken (u.a. unzureichende Transparenz der Datenflüsse, unzureichende

› IT-Geschäftsprozessrisiken (u.a. unzureichende Transparenz der Datenflüsse, unzureichende