BESt-PRACtiCE-LEitfADEn Zur EinfühRunG DER. SAP BuSinESSOBjECtS GRC-LöSunGEn

Best-Practice-Leitfadenreihe zur Einfhrung der SAP BusinessObjects GRC-Lsungen
Deutschsprachige SAP-Anwendergruppe e.V.
DSAG-ARBEITSGRUPPE GOVERNANCE, RISK MANAGEMENT UND COMPLIANCE

TEIL 2: SAP BUSINESS OBJECTS RISK MANAGEMENT, STAND 15. AUGUST 2011
SAP BusinessObjects Risk Management

BEST-PRACTICE-LEITFADENREIHE ZUR EINFHRUNG DER SAP BUSINESSOBJECTS GRC-LSUNGEN TEIL 2, STAND 15. AUGUST 2011
DSAG e. V. Deutschsprachige SAP-Anwendergruppe
Seite 2
1 Einleitung
Der Best-Practice-Leitfaden SAP BusinessObjects Risk Management setzt die DSAG-Leitfadenreihe zur SAP BusinessObjects GRC Suite fort mit dem Ziel, Empfehlungen zu Einfhrung und Betrieb von SAP BusinessObjects Risk Management 10.0 zu geben. Die Best-Practice-Empfehlungen erheben keinen Anspruch auf Vollstndigkeit, sondern geben die Projektund Praxiserfahrung der Autoren wieder, die Mitglieder der DSAG-Arbeitsgruppe Governance, Risk Management, Compliance (GRC) innerhalb des Arbeitskreises Revision und Risikomanagement sind. Insofern ist das Autorenteam auch dankbar fr jede Art von Anregungen und Hinweisen zur weiteren Vervollstndigung und Verbesserung des Leitfadens. Dieser Leitfaden soll insbesondere den Unternehmen eine Hilfestellung bieten, die sich mit verschiedensten Anforderungen gesetzlicher, fachlicher und organisatorischer Art bei der Gestaltung ihres Risikomanagementsystems konfrontiert sehen. Hinzuweisen ist hier insbesondere auf die Anforderungen des Bilanzrechtsmodernisierungsgesetzes (BilMoG) mit der Gestaltung und berwachung von internen Kontroll- und Risikomanagementsystemen sowie generell auf Anforderungen eines modernen Compliance-Managements bei der Sicherstellung von wirksamen Kontrollen zur Risikoerkennung und -minimierung innerhalb der Unternehmensorganisation. Die Autoren sind Mitglieder der Arbeitsgruppe Governance, Risk Management & Compliance (GRC) innerhalb des DSAG-Arbeitskreises Revision und Risikomanagement. Die Verantwortung fr den Inhalt tragen die Autoren. Die redaktionelle Bearbeitung und das Layout liegen bei der DSAG.
COPYRIGHT 2011 DER AUTOREN:

Herr Oliver Derksen Herr Siegfried Filla Herr Marko Hamel Herr Dr. Gero Mder SAP Deutschland AG & Co. KG PricewaterhouseCoopers AG SAP AG SAP AG
Hinweis: Die vorliegende Publikation ist urheberrechtlich geschtzt (Copyright). Alle Rechte liegen soweit nicht ausdrcklich anders gekennzeichnet bei: DEUTSCHSPRACHIGE SAP ANWENDERGRUPPE E. V. Altrottstrae 34a 69190 Walldorf Deutschland Jede Verwertung auerhalb der engen Grenzen des Urheberrechts ist ohne Zustimmung der Urheber unzulssig und strafbar. Das gilt insbesondere fr Vervielfltigungen, bersetzungen, Mikroverlmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen / digitalen Medien. Die Autoren des vorliegenden Best-Practice-Leitfadens sind fr Verbesserungs- sowie nderungs- und Ergnzungswnsche dankbar. Dies gilt sowohl fr Vorschlge zur Vertiefung der einzelnen Kapitel als auch fr die Nennung von Beispielen aus konkreten Projekt- oder Prfungserfahrungen. Nutzen Sie hierzu bitte das entsprechende Forum der AG GRC im DSAGNet unter INFO/Service Foren AG Governance, Risk Management, Compliance.
Seite 3
Inhaltsverzeichnis
1 EINLEITUNG 2 BERBLICK 3 REGULATORISCHE ANFORDERUNGEN
3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 Deutscher Corporate Governance Kodex (DCGK) Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) IDW RS FAIT 1 IDW RS FAIT 2 IDW RS FAIT 3 IDW Prfungsstandard PS 261 (u.a. internes Kontrollsystem) IDW PS 330 IDW PS 340 IDW PS 525 IDW PS 980 Bundesdatenschutzgesetz (BDSG) Bilanzrechtsmodernisierungsgesetz (BilMoG) 3.12.1 Lagebericht ( 289, 315 HGB n.F.) 3.12.2 Pichten des Aufsichtsrates 3.12.3 Handlungsfelder fr den Vorstand Basel II Basel III Mindestanforderungen an Compliance MaComp Mindestanforderungen an das Risikomanagement MaRisk Markets in Financial Instruments Directive MiFiD Solvabilittsverordnung SolvV Solvency II Sarbanes-Oxley Act (SOX) Normen (DIN ISO / IEC) 3.21.1 ISO / IEC 27001 3.21.2 ISO 27002 (vorher ISO 17799) 3.21.3 ISO 27005 3.21.4 Weitere Standards der Reihe ISO 2700x 3.21.5 Zertizierung nach ISO 27001 auf Basis von IT-Grundschutz 3.21.6 Risikomanagement nach ISO 31000
3 6 8
9 10 10 11 11 12 13 13 14 15 16 17 17 17 17 18 19 19 19 20 20 20 20 21 21 21 21 21 22 22
3.13 3.14 3.15 3.16 3.17 3.18 3.19 3.20 3.21
4 ZIELMARKT
4.1 Mittelstand 4.2 Grounternehmen / Konzerne
24
24 25
5 MOTIVATION FR IT-GESTTZTES RISIKOMANAGEMENT 6 RAHMENBEDINGUNGEN / ERFOLGSFAKTOREN

6.1 6.2 6.3 6.4 Organisatorischer Rahmen RMS / IKS-Methodik Risiko-Governance- und Risikostrategie GRC-Organisation
26 27
27 27 29 30
7 UMSETZUNG DES RISIKOMANAGEMENTPROZESSES IN RM

7.1 Grundlegende berlegungen und Einstellungen 7.2 Erstellen der zentralen Kataloge 7.3 Zielmanagement
Seite 4
32
33 35 36
7.4 7.5 7.6 7.7 7.8 7.9 7.10 8.1 8.2 8.3 8.4 8.5 8.6
Risikoidentikation Risikobewertung Risikoadressierung / Gegenmanahmen Reporting Monitoring Chancenmanagement Incident Management Projektvorbereitung (Strategie & Planung) Sollkonzept (Business Blueprint und Design) Weitere Projektphasen (Implementierung, Roll-out, Go-Live) Einfhrung eines zentralen integrierten Risk-Management- und Process-Control-Systems Einfhrungsvarianten (schrittweise versus Big Bang) Weiterfhrende Informationen
39 41 44 45 45 46 47
8 EINFHRUNGSMANAGEMENT
48
48 48 49 49 50 51
9 PHASE SOLLKONZEPTION (BUSINESS BLUEPRINT UND DESIGN)

9.1 Risk Management 9.1.1 Projekt Scoping & SWOT-Analyse 9.1.2 Planung 9.1.3 Risiko-Assessment 9.1.4 Risikoidentikation 9.1.5 Risikoanalyse 9.1.6 Steuerung 9.1.7 Monitoring & Reporting 9.2 Berechtigungskonzept Risk Management / Process Control 9.2.1 ABAP-Basisrollen 9.2.2 ABAP-Entittsrollen 9.2.3 SAP NetWeaver Portal Roles 9.2.4 SAP NetWeaver Business Client
52
52 52 53 56 56 57 58 58 59 61 62 67 67
10 PHASE REALISIERUNG (IMPLEMENTIERUNG)

10.1 RM standalone 10.1.1 Grundstzliches Aufsetzen des Systems 10.1.2 Einrichten der Risikomanagement-Applikation 10.1.3 Wichtige Einstellungen fr die Analyse 10.1.4 Einstellungen fr Risikomanahmen 10.1.5 Einstellungen fr Risikofrhwarnindikatoren 10.2 Besonderheiten bei der Einfhrung eines integrierten Szenarios 10.2.1 berlegungen beim Aufsetzen der Stammdaten 10.2.1.1 Organisationseinheiten 10.2.1.2 Verwendung eines gemeinsamen Risikokatalogs in beiden Applikationen 10.2.1.3 Aktivitts-Hierarchie 10.2.2 Gemeinsame Softwarekomponenten 10.2.3 Kontrollen als Risikomassnahmen 10.2.4 Kontrollvorschlge als permanente Verbesserung des Risikomanagement-Prozesses 10.2.5 Automatische Bewertung der Effektivitt von Risikogegenmanahmen aus Kontrolltests und Kontrolldesign-Assessments
69
69 69 70 71 75 76 78 78 78 78 79 79 79 80 81
11 TECHNISCHE RAHMENBEDINGUNGEN / INFRASTRUKTUR
83
Seite 5
BEST-PRACTICE-LEITFADEN SAP BUSINESSOBJECTS RISK MANAGEMENT, STAND 15. AUGUST 2011, DSAG e. V.
2 berblick
SAP hat die Standard-Softwarelsungen fr den Themenbereich Governance, Risk Management und Compliance (GRC) im SAP BusinessObjects-Portfolio gebndelt (siehe Abb. 1). Das SAP BusinessObjects-Portfolio enthlt Lsungen, um mehr Transparenz in Geschftsablufen zu erreichen, um die Performance innerhalb von Geschftsprozessen zu managen und um die Risiken und die Compliance von Unternehmen zu berwachen und zu steuern. Im Einzelnen sind dies Business-Intelligence- und Information-Management-Lsungen, Anwendungen fr Governance, Risikomanagement und Compliance sowie Lsungen zum Management der Unternehmensperformance. GRC umfasst dabei die Applikationen fr Access Control, Process Control, Risk Management, Global Trade Services und Environment, Health and Safety.
Das SAP BusinessObjects-Portfolio
Seite 6
Die SAP BusinessObjects GRC-Lsungen basieren auf der SAP NetWeaver Technologie-Plattform und den entsprechenden sog. content shipments. Sie sollen Unternehmen dabei helfen, ihre strategische und operative Effektivitt durch die Verdichtung und Steuerung von Aktivitten bezglich signikanter Risiken (key risks) sowie durch die Automatisierung von Kontrollen ber alle Geschftsprozesse hinweg und die berwachung von Risiken und Kontrollen ber verschiedenste Systeme hinweg zu maximieren. Die SAP Release und Wartungsstrategie fr die hier besprochenen GRC-Lsungen kann unter folgendem Link eingesehen werden: http://service.sap.com/PAM
Mit SAP BO Risk Management knnen Unternehmensrisiken identiziert, bewertet, minimiert und berwacht werden. Die entsprechenden Funktionsbausteine umfassen > Risikoplanung (u.a. Denition risikorelevanter Geschftsaktivitten, Risikoklassizierung, Einrichtung von Risikoindikator-Frameworks), > Risikoidentizierung (u.a. Risiken und Chancen identizieren, Risikoindikatoren zuordnen, Risikozusammenhnge denieren), > Risikoanalyse (u.a. Risiken qualitativ und quantitativ analysieren, Risiken priorisieren, Risikoszenarios erstellen), > Risikomanahmen (u.a. Risikomanahmen dokumentieren, Manahmen zur Risikominierung festlegen, Prozesskontrollen zuordnen), > Risikoberwachung (u.a. Risikoindikatoren berwachen, Wirksamkeit der ergriffenen Manahmen berwachen, eingetretene Risikovorflle und Verluste dokumentieren).
Seite 7
3 Regulatorische Anforderungen
In Deutschland haben sich Gesetzgeber, das Institut der Wirtschaftsprfer in Deutschland (IDW) sowie das DRSC Deutsches Rechnungslegungs Standards Committee e.V. schon seit vielen Jahren mit den Themen Governance, Risk Management und Compliance beschftigt. Hervorzuheben sind dabei die Regelungen zum Deutschen Corporate Governance Codex1, zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG2), zum internen Kontrollsystem von Unternehmen3, zum Bilanzrechtsmodernisierungsgesetz (BilMoG)4 und aktuell zum Compliance-Management.5 Den Mastab fr die Umsetzung regulatorischer Anforderungen in deutschen Unternehmen bilden im Rahmen der Prfung der Finanzberichterstattung durch Wirtschaftsprfer im Wesentlichen folgende gesetzliche Regelungen und Prfungsstandards des Instituts der Wirtschaftsprfer (IDW): > die handels- und steuerrechtlichen Vorschriften zur Ordnungsmigkeit der Buchfhrung ( 238 f. und 257 HGB sowie 145 bis 147 AO), > die IDW-Stellungnahme zur Rechnungslegung Grundstze ordnungsmiger Buchfhrung bei Einsatz von Informationstechnologie (IDW RS FAIT 1, Stand: 24. September 2002), > die IDW-Stellungnahme zur Rechnungslegung Grundstze ordnungsmiger Buchfhrung bei Einsatz von Electronic Commerce (IDW RS FAIT 2, Stand: 29. September 2003), > der IDW-Prfungsstandard Feststellung und Beurteilung von Fehlerrisiken und Reaktionen des Abschlussprfers auf die beurteilten Fehlerrisiken (IDW PS 261, Stand 6. September 2006), > der IDW-Prfungsstandard zur Abschlussprfung bei Einsatz von Informationstechnologie (IDW PS 330, Stand: 24. September 2002), > der IDW-Prfungsstandard Die Prfung des Risikofrherkennungssystems nach 317 Abs. 4 HGB (IDW PS 340 vom 11.09.2000), > der IDW-Prfungsstandard Die Beurteilung des Risikomanagements von Kreditinstituten im Rahmen der Abschlussprfung (IDW PS 525 vom 26.06.2010) > sowie die von der Arbeitsgemeinschaft fr Wirtschaftliche Verwaltung e.V. erarbeiteten Grundstze ordnungsmiger DV-gesttzter Buchfhrungssysteme (GoBS) sowie das dazu ergangene Schreiben des Bundesministers der Finanzen vom 7. November 1995. Die vorgenannten gesetzlichen Vorschriften und fachlichen Stellungnahmen sind generell zu beachtende Anforderungen und beziehen sich berwiegend auf rechnungslegungsrelevante Sachverhalte. Gleichwohl sind sie aufgrund gleicher Kontrollziele geeignet, auch Aussagen zur Ordnungsmigkeit bei Fragestellungen auerhalb der Buchfhrung zu treffen. Darber hinaus knnen im Einzelfall weitere Prfungsstandards anzuwenden sein (z.B. fr Dienstleistungsunternehmen oder Shared Service Center, die administrative Aufgaben u.a. im Bereich der Benutzeradministration und des Zugriffsschutzes bernommen haben (z.B. der IDW-Prfungsstandard zur Prfung des internen Kontrollsystems bei Dienstleistungsunternehmen fr auf das Dienstleistungsunternehmen ausgelagerte Funktionen (IDW PS 951, Stand: 19. September 2007). Dieser GRC-Best-Practice-Leitfaden mchte lediglich in Kurzform auf wesentliche zu beachtende regulatorische Anforderungen insbesondere in jngerer Zeit eingehen und erhebt deshalb auch keinen Anspruch auf Vollstndigkeit der hier vorgestellten Regelungen. Wer sich intensiver mit diesem Thema beschftigen mchte, kann dies u.a. in folgenden Bchern nachlesen:
Seite 8
1 2 3 4 5
Deutscher Corporate Governance Kodex (DCGK Juni 2009) Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) 1. Mai 1998 IDW-Prfungsstandard Feststellung und Beurteilung von Fehlerrisiken und Reaktionen des Abschlussprfers auf die beurteilten Fehlerrisiken (IDW PS 261, Stand 6. September 2006) Bilanzrechtsmodernisierungsgesetz (BilMoG) vom 25. Mai 2009 (BGBl. I S. 1102) IDW Prfungsstandard: Grundstze ordnungsmiger Prfung von Compliance Management Systemen (IDW PS 980, Stand: 11.03.2011)
> > > > > >
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-2004 Datenschutz in SAP-Systemen: Konzeption und Implementierung, 2011, ISBN 978-3836216852 Handbuch SAP-Revision: IKS, Audit, Compliance, 2010, ISBN 978-3836216036 Corporate Governance, Risk Management und Compliance: Innovative Konzepte und Strategien, 2010, ISBN 978-3834915580 > 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 ergnzende Lektre empfehlen wir die folgenden DSAG-Leitfden, jeweils als E-Book: Den DSAG-BestPractice-Leitfaden zu SAP BO GRC Access Control (www.dsag.de/go/e-grc), den DSAG-Datenschutzleitfaden SAP ERP 6.0 (www.dsag.de/go/e-datenschutz) sowie den DSAG-Preitfaden SAP ERP 6.0 (www.dsag.de/ go/e-prueeitfaden). Alle Leitfden der DSAG sind unter www.dsag.de/go/leitfaeden verffentlicht.
3.1 DEUTSCHER CORPORATE GOVERNANCE KODEX (DCGK)

Die Themen Risikomanagement und Compliance sind im DCGK in folgenden Abschnitten angesprochen: > Abschnitt 3 Zusammenwirken von Vorstand und Aufsichtsrat Der Vorstand informiert den Aufsichtsrat regelmig, zeitnah und umfassend ber alle fr das Unternehmen relevanten Fragen der Planung, der Geschftsentwicklung, der Risikolage, des Risikomanagements und der Compliance. > Abschnitt 4 Aufgaben und Zustndigkeiten des Vorstands Der Vorstand hat fr die Einhaltung der gesetzlichen Bestimmungen und der unternehmensinternen Richtlinien zu sorgen und wirkt auf deren Beachtung durch die Konzernunternehmen hin (Compliance). Der Vorstand sorgt fr ein angemessenes Risikomanagement und Risikocontrolling im Unternehmen. > Abschnitt 5 Aufgaben und Befugnisse des Aufsichtsratsvorsitzenden Der Aufsichtsratsvorsitzende soll mit dem Vorstand, insbesondere mit dem Vorsitzenden bzw. Sprecher des Vorstands, regelmig Kontakt halten und mit ihm die Strategie, die Geschftsentwicklung und das Risikomanagement des Unternehmens beraten. > Abschnitt 5.3 Bildung von Ausschssen Der Aufsichtsrat soll einen Prfungsausschuss (Audit Committee) einrichten, der sich insbesondere mit Fragen der Rechnungslegung, des Risikomanagements und der Compliance befasst.
Seite 9
3.2 GESETZ ZUR KONTROLLE UND TRANSPARENZ IM UNTERNEHMENSBEREICH (KONTRAG)
Kern des KonTraG ist eine Vorschrift, die Unternehmensleitungen dazu zwingt, ein unternehmensweites Frherkennungssystem fr Risiken (Risikofrherkennungssystem) einzufhren und zu betreiben sowie Aussagen zu Risiken und zur Risikostruktur des Unternehmens im Lagebericht des Jahresabschlusses der Gesellschaft zu verffentlichen. Die Einrichtung eines Risikofrherkennungssystems (RFS) gem. 91 Abs. 2 AktG ist unmittelbar nur fr Aktiengesellschaften gesetzlich vorgeschrieben. Das RFS muss demnach gewhrleisten, dass alle bestandsgefhrdenden Unternehmensrisiken frhzeitig identiziert, bewertet, kommuniziert und lfd. berwacht werden. Das Risikofrherkennungssystem unterscheidet sich von einem Risikomanagementsystem (RMS) durch die fehlende Risikosteuerungsfunktion, d.h. Risiko-Gegenmanahmen sind in einem RFS nicht vorgesehen. Sie wren Teil eines Risikomanagementsystems. Die Einrichtung, Funktionsweise und Dokumentation des Risikofrherkennungssystems ist durch den Abschlussprfer im Rahmen der Jahresabschlussprfung zu beurteilen. Die Prfung wird nach dem IDW-Prfungsstandard PS 340 durchgefhrt.
3.3 IDW RS FAIT 16

RS FAIT 1 deniert u.a. Sicherheitsanforderungen an rechnungslegungsrelevante Daten. Im Einzelnen werden gefordert: IT-Systeme haben daher die folgenden Sicherheitsanforderungen zu erfllen: > Vertraulichkeit verlangt, dass von Dritten erlangte Daten nicht unberechtigt weitergegeben oder verffentlicht werden. Organisatorische und technische Manahmen wie bspw. Verschlsselungstechniken umfassen u.a. Anweisungen zur Beschrnkung der bermittlung personenbezogener Daten an Dritte, die verschlsselte bermittlung von Daten an berechtigte Dritte, die eindeutige Identizierung und Verizierung des Empfngers von Daten oder die Einhaltung von Lschfristen gespeicherter personenbezogener Daten. > Integritt von IT-Systemen ist gegeben, wenn die Daten und die IT-Infrastruktur sowie die IT-Anwendungen vollstndig und richtig zur Verfgung stehen und vor Manipulation und ungewollten oder fehlerhaften nderungen geschtzt sind. Organisatorische Manahmen sind geeignete Test- und Freigabeverfahren. Technische Manahmen sind z.B. Firewalls und Virenscanner. Die Ordnungsmigkeit der IT-gesttzten 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. > Verfgbarkeit verlangt zum einen, dass das Unternehmen zur Aufrechterhaltung des Geschftsbetriebs die stndige Verfgbarkeit der IT-Infrastruktur, der IT-Anwendungen sowie der Daten gewhrleistet. Zum anderen mssen die IT-Infrastruktur, die IT-Anwendungen und Daten sowie die erforderliche IT-Organisation in angemessener Zeit funktionsfhig bereitstehen. Daher sind z.B. geeignete Back-up-Verfahren zur Notfallvorsorge einzurichten. Manahmen zur Sicherung der Verfgbarkeit sind erforderlich, um den Anforderungen nach Lesbarmachung der Buchfhrung gerecht zu werden.
Seite 10
IDW-Stellungnahme zur Rechnungslegung Grundstze ordnungsmiger Buchfhrung bei Einsatz von Informationstechnologie (IDW RS FAIT 1, Stand: 24. September 2002).
> Autorisierung bedeutet, dass nur im Voraus festgelegte Personen auf Daten zugreifen knnen (autorisierte Personen) und dass nur sie die fr das System denierten Rechte wahrnehmen knnen. Diese Rechte betreffen das Lesen, Anlegen, ndern und Lschen von Daten oder die Administration eines IT-Systems. Dadurch soll ausschlielich die genehmigte Abbildung von Geschftsvorfllen im System gewhrleistet werden. Geeignete Verfahren hierfr sind physische und logische Zugriffsschutzmanahmen (z.B. Passwortschutz). Organisatorische Regelungen und technische Systeme zum Zugriffsschutz sind die Voraussetzung zur Umsetzung der erforderlichen Funktionstrennungen. Neben Identittskarten werden zuknftig biometrische Zugriffsgenehmigungsverfahren an Bedeutung gewinnen. > Authentizitt ist gegeben, wenn ein Geschftsvorfall einem Verursacher eindeutig zuzuordnen ist. Dies kann bspw. ber Berechtigungsverfahren geschehen. Beim elektronischen Datenaustausch bieten sich fr eine Identizierung des Partners bspw. digitale Signatur- oder passwortgesttzte Identikationsverfahren an. > Unter Verbindlichkeit wird die Eigenschaft von IT-gesttzten Verfahren verstanden, gewollte Rechtsfolgen bindend herbeizufhren. Transaktionen drfen durch den Veranlasser nicht abstreitbar sein, weil bspw. der Geschftsvorfall nicht gewollt ist.
3.4 IDW RS FAIT 27

Risiken knnen sich innerhalb des E-Commerce insbesondere aus der fehlenden Kontrolle ber den Datentransfer im Internet ergeben: > > > > > > Unzureichender Schutz vor Verflschung (Verlust der Integritt) Unsichere Datenverschlsselung (Verlust der Vertraulichkeit) Gefhrdung der Verfgbarkeit (Verlust der Verfgbarkeit) Unwirksame Authentisierungsmechanismen (Verlust der Authentizitt) Unauthorisierte Zugriffe mit Hilfsprogrammen (Verlust der Autorisierung) Unzureichende Protokollierung der Transaktionsdaten (Verlust der Verbindlichkeit)
Mangelnde Authentizitt und Autorisierung bewirken bspw., dass Geschftsvorflle inhaltlich unzutreffend abgebildet werden (Verletzung des Grundsatzes der Richtigkeit). Die Autorisierung soll insbesondere sicherstellen, dass keine unberechtigten bzw. keine ktiven Geschftsvorflle in das System eingehen. Es ist festzulegen, wann, wie und durch wen die Autorisierung erfolgt. Autorisierungsverfahren sind Teil der Verfahrensdokumentation und fr zehn Geschftsjahre aufbewahrungspichtig. Im Rahmen des durch den Anwender zu erstellenden Sicherheitskonzeptes sind auch fr E-CommerceAnwendungen Sicherungsmanahmen abzuleiten, die physische Sicherungsmanahmen und logische Zugriffskontrollen sowie Datensicherungs- und Auslagerungsverfahren umfassen.
3.5 IDW RS FAIT 38

Konkretisiert werden die aus 257 HGB resultierenden Anforderungen an die Archivierung aufbewahrungspichtiger Unterlagen sowie die in FAIT 1 dargestellten Aufbewahrungspichten beim Einsatz von elektronischen Archivierungssystemen.
7 8
Seite 11
IDW Stellungnahme zur Rechnungslegung: Grundstze ordnungsmiger Buchfhrung bei Einsatz von Electronic Commerce (IDW RS FAIT 2) IDW Stellungnahme zur Rechnungslegung: Grundstze ordnungsmiger Buchfhrung beim Einsatz elektronischer Archivierungsverfahren (IDW RS FAIT 3)
Technische und organisatorische Risiken aus dem Einsatz von Archivierungsverfahren knnen die Sicherheit und Ordnungsmigkeit der Rechnungslegung beeintrchtigen: > Unzureichende organisatorische Festlegungen und Verfahrensanweisungen knnen die Nachvollziehbarkeit und Anwendbarkeit der Archivierungsverfahren gefhrden. > Mangelhafte Zugriffskontrollen innerhalb des Archivierungssystems ermglichen die missbruchliche oder unauthorisierte Einsichtnahme der archivierten Dokumente und Daten. > Durch Vernderungen, Manipulationen oder Lschung der archivierten Daten und Dokumente wird deren Integritt, Authentizitt oder Verfgbarkeit verletzt.
3.6 IDW PRFUNGSSTANDARD PS 261 (U.A. INTERNES KONTROLLSYSTEM)

Gem. IDW PS 261 werden unter einem internen Kontrollsystem die vom Management im Unternehmen eingefhrten Grundstze, Verfahren und Manahmen (Regelungen) verstanden, die gerichtet sind auf die organisatorische Umsetzung der Entscheidungen des Managements > zur Sicherung der Wirksamkeit und Wirtschaftlichkeit der Geschftsttigkeit (hierzu gehrt auch der Schutz des Vermgens, einschlielich der Verhinderung und Aufdeckung von Vermgensschdigungen), > zur Ordnungsmigkeit und Verlsslichkeit der internen und externen Rechnungslegung sowie > zur Einhaltung der fr das Unternehmen mageblichen rechtlichen Vorschriften.9 Als organisatorische Sicherungsmanahmen sind z.B. deniert laufende, automatische Einrichtungen. Sie umfassen fehlerverhindernde Manahmen, die sowohl in die Aufbau- als auch die Ablauforganisation eines Unternehmens integriert sind und ein vorgegebenes Sicherheitsniveau gewhrleisten sollen (z.B. Funktionstrennung, Zugriffsbeschrnkungen im IT-Bereich)10. Damit sind u.a. alle im Rahmen von Zugriffsberechtigungen getroffenen Manahmen Teil des internen Kontrollsystems und damit auch wesentlicher Bestandteil der Umsetzung der Compliance-Anforderungen durch das Management eines Unternehmens. Die Regelungsbereiche des internen Kontrollsystems werden lt. IDW PS 261 wie folgt deniert:
INTERNES KONTROLLSYSTEM (IKS)
INTERNES STEUERUNGSSYSTEM
INTERNES BERWACHUNGSSYSTEM
Prozessunabhngige berwachungsmanahmen
Prozessunabhngige berwachungsmanahmen
Organisatorische Sicherheitsmanahmen
Kontrollen
Interne Revision
Sonstige
Elemente des internen Kontrollsystems
9 IDW PS 261, Tz. 19 10 IDW PS 261, Tz. 20
Seite 12
Neben den o.g. organisatorischen Sicherungsmanahmen sind auch Kontrollen prozessintegrierte berwachungsmanahmen, z.B. die berprfung der Vollstndigkeit und Richtigkeit verarbeiteter Daten (u.a. nderungen von Berechtigungen und Benutzerprolen).
3.7 IDW PS 33011

Dieser Prfungsstandard beschftigt sich im Wesentlichen mit den Anforderungen an ordnungsmige und sichere Rechnungslegungssysteme und der Sicherstellung der Vollstndigkeit, Richtigkeit, der in diesem 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-Geschftsprozessrisiken (u.a. unzureichende Transparenz der Datensse, unzureichende Integration der Systeme oder mangelhafte Abstimm- und Kontrollverfahren in Schnittstellen zwischen Teilprozessen mit der Gefahr, dass IT-Kontrollen bspw. Zugriffsrechte, Datensicherungsmanahmen, nur hinsichtlich der Teilprozesse, jedoch nicht hinsichtlich der Gesamtprozesse wirksam werden.) Wesentliches Beurteilungsobjekt sind im Hinblick auf SAP BusinessObjects Access Control die logischen Zugriffskontrollen. Logische Zugriffskontrollen sind wesentliche Elemente der Datensicherheit und des Datenschutzes und Voraussetzung zur Gewhrleistung der Vertraulichkeit. Die Sicherheitsanforderungen Autorisierung und Authentizitt bedingen zwingend logische Zugriffskontrollen: > Implementierung eines organisatorischen Verfahrens zur Beantragung, Genehmigung und Einrichtung von Benutzerberechtigungen in IT-Systemen > Berechtigungen auf Betriebssystemebene (Anmeldung gegenber Rechnern in einem Netzwerk) > Rechte zur Ausfhrung 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 Sicherheitskonzept entsprechen und damit unberechtigte Zugriffe auf Daten sowie Programmablufe zur Vernderung von Daten ausgeschlossen sind. Zudem mssen Zugriffskontrollen so ausgestaltet sein, dass sie die Identitt des Benutzers eindeutig feststellen und nicht autorisierte Zugriffsversuche abgewiesen werden.
3.8 IDW PS 34012

Dieser Prfungsstandard regelt die Systemprfung des Risikofrherkennungssystems nach 91 Abs. 2 AktG (das berwachungssystem ist durch den Vorstand einzurichten) bei brsennotierten Aktiengesellschaften ( 3 Abs. 2 AktG) im Rahmen der Abschlussprfung ( 317 Abs. 4 HGB). Das Risikofrherkennungssystem soll bestandsgefhrdende Risiken frhzeitig erkennen und dem Management rechtzeitig die Mglichkeit zur Gegensteuerung erffnen. Die Manahmen zur Einrichtung eines solchen Systems sind auch Prfungsgegenstand fr die interne Revision, die z.B. folgende Bereiche abdeckt:
Seite 13
11 IDW-Prfungsstandard zur Abschlussprfung bei Einsatz von Informationstechnologie (IDW PS 330, Stand: 24. September 2002) 12 IDW Prfungsstandard: Die Prfung des Risikofrherkennungssystems nach 317 Abs. 4 HGB (IDW PS 340, Stand: 11.09.2000)
> > > > Erfassung der Risikofelder im Unternehmen Beurteilung der Manahmen zur Risikoerfassung und Risikokommunikation Beurteilung der Nachhaltigkeit der getroffenen Manahmen Einhaltung der integrierten Kontrollen
Alle getroffenen Manahmen zur Einrichtung eines Risikofrherkennungssystems sind vom Unternehmen zu dokumentieren. In diesem Zusammenhang verdeutlicht ein Urteil des Landgerichts Mnchen die entsprechenden Vorstandspichten: Der Vorstand einer Aktiengesellschaft ist nicht nur verpichtet, ein funktionsfhiges Warnsystem hinsichtlich der wirtschaftlichen Entwicklung des Unternehmens einzurichten, sondern hat auch dafr zu sorgen, dass unmissverstndliche Zustndigkeiten begrndet, ein engmaschiges Berichtssystem eingefhrt und eine entsprechende Dokumentation sichergestellt werden. Hat der Vorstand dies versumt, kann das Gericht auf Klage eines Aktionrs einen Hauptversammlungsbeschluss zur Entlastung des Vorstands fr nichtig erklren (Urteil des LG Mnchen I vom 05.04.2007, 5 HKO 15964/06, ZIP 2007, 1951). Es liegt auf der Hand, dass fr eine systematische Erfassung und Steuerung aller bestandsgefhrdenden Risiken eines Unternehmens eine IT-Untersttzung unabdingbar ist. Gerade bei komplexen brsennotierten Unternehmen reichen dafr Ofce-Produkte nicht mehr aus, obwohl sie noch vielfach im Einsatz sind.
3.9 IDW PS 52513

Der Prfungsstandard PS 525 regelt die Prfung des Risikomanagementsystems bei Kreditinstituten. Geprft wird, inwieweit das Kreditinstitut die Grundstze zur Zielsetzung, zum Umfang und zu den verantwortlichen Organisationseinheiten fr die zu ttigenden Geschfte und einzugehenden Risiken (Strategie) schriftlich xiert und ein Bewusstsein ber diese Risiken in der Gesamtorganisation (Risikobewusstsein) geschaffen hat. Es wird beurteilt, inwieweit das Kreditinstitut hinsichtlich der Einrichtung und Funktionsfhigkeit des Risikomanagements folgende Kriterien erfllt: > > > > Risikoerkennung (frhzeitiges und vollstndiges Erkennen aller wesentlichen Risiken) Risikoanalyse (Beurteilung der Risiken bezglich der Bedeutung fr die geschftspolitischen Ziele) Risikosteuerung (gezielte Steuerung im Einklang mit der Strategie und der Risikotragfhigkeit) Risikokommunikation (systematische und entscheidungsorientierte Aufbereitung und Berichterstattung an das Management) > Risikoberwachung Darber hinaus haben auch Aktiengesellschaften nach 91 Abs. 2 AktG eine gesetzliche Verpichtung zur Einfhrung eines Risikomanagementsystems. Diese bezieht sich jedoch nur auf die Vermeidung bestandsgefhrdender Risiken. Sofern die Aktiengesellschaft brsennotiert ist, besteht auch eine Prfungspicht durch den zustndigen Abschlussprfer. Art und Umfang der notwendigen Prfungshandlungen ergeben sich aus dem IDW PS 340, welcher hinsichtlich der Anforderungen dem IDW PS 525 weitgehend entspricht.
13 IDW Prfungsstandard: Die Prfung des Risikomanagements von Kreditinstituten im Rahmen der Abschlussprfung (IDW PS 525, Stand: 26.06.2010)
Seite 14
3.10 IDW PS 98014

Am 11. Mrz 2011 wurde vom Institut der Wirtschaftsprfer (IDW) der Prfungsstandard Grundstze ordnungsmiger Prfung von Compliance-Management-Systemen verabschiedet. Dieser Standard ist erstmals fr Prfungen anzuwenden, die nach dem 30. September 2011 durchgefhrt werden. Dabei handelt es sich um freiwillige Prfungen, d.h., es besteht derzeit keine Prfungspicht. Man kann jedoch davon ausgehen, dass sich zunehmend Unternehmen einer Prfung ihres CMS unterziehen, um zumindest von Aufsichtsrats- oder Vorstandsseite nachzuweisen, dass alle Aufsichtspichten erfllt worden sind und man sich z.B. kein pichtwidriges Verhalten nach 93 Absatz 1 AktG vorzuwerfen hat. Der Prfungsstandard legt einen einheitlichen Rahmen fr Compliance-Management-Systeme (CMS) fest. Damit gibt es jetzt erstmalig in Deutschland ein seitens der Wirtschaftsprfung deniertes Rahmenkonzept mit Leitlinien und Vorgaben fr Unternehmen, die sich zur Verbesserung ihrer Compliance mit der Einrichtung eines Compliance-Management-Systems oder hnlichen Strukturen beschftigen oder dies bereits weitgehend umgesetzt haben. Damit ist davon auszugehen, dass durch diesen Prfungsstandard auch eine zunehmende Standardisierung der Compliance-Organisation erzielt wird und die ComplianceAufgaben innerhalb der Corporate Governance deutscher Unternehmen wirksam und nachhaltig erfllt werden knnen. Als eines der ersten Unternehmen unterzieht z.B. ThyssenKrupp sein Compliance-System in 2011 einer Wirksamkeitsprfung seines CMS nach IDW PS 980 mit den Schwerpunkten Kartellrecht und Korruptionsbekmpfung15. Nachfolgend sind einige Kernelemente des Prfung des Compliance-Management-Systems nach dem Prfungsstandard IDW PS980 dargestellt, die derzeit auch in der Arbeitsgruppe GRC der DSAG behandelt werden mit dem Ziel, den DSAG Mitgliedsrmen praktische Hilfestellung bei der nachhaltigen Einrichtung und dem Management von Compliance-Systemen zu geben.
Audit Compliance Management (nach IDW PS 980)

> Compliance-Management-System (CMS) ist ein Teilbereich des Risikomanagementsystems (RMS) > IDW PS 980 ersetzt nicht > Die Prfung des Risikofrherkennungssystems nach 317 Abs. 4 HGB (IDW PS 340) > Die Beurteilung des Risikomanagements von Kreditinstituten im Rahmen der Abschlussprfung (IDW EPS 525) > Auftrags-(Prfungs-)typen > Prfung der Konzeption des CMS > Prfung von Angemessenheit und Implementierung des CMS > Prfung von Angemessenheit, Implementierung und Wirksamkeit des CMS > Prfungsgebiete (Aufbau- und Funktionsprfung abhngig vom Auftragstyp) > Compliance-Kultur > Grundlagen fr die Angemessenheit und Wirksamkeit des CMS > Grundeinstellung und Verhaltensweisen des Managements (Tone from the Top) > Compliance-Ziele > Festlegung wesentlicher Ziele, die mit dem CMS erreicht werden sollen
Seite 15
14 IDW Prfungsstandard: Grundstze ordnungsmiger Prfung von Compliance-Management-Systemen (IDW PS 980, Stand: 11.03.2011) 15 Vgl. Prsentation ThyssenKrupp Compliance-Programm, Dr. Thomas Kremer, Chefjustitiar und Chief Compliance Ofcer ThyssenKrupp AG, 26. Mai 2011
> > Festlegung wesentlicher Teilbereiche und in den Teilbereichen einzuhaltenden Regeln Compliance-Organisation > Rollen und Verantwortlichkeiten > Aufbau- und Ablauforganisation > Ressourcenplanung Compliance-Risiken > Identikation von wesentlichen Compliance-Risiken > Systematische Risikoerkennung mit Risikobeurteilung Compliance-Programm > Auf Grundlage der identizierten Risiken werden Grundstze und Manahmen eingefhrt, die risikominimierend wirken Compliance-Kommunikation > Betroffene Mitarbeiter und ggfs. Dritte werden ber das Compliance-Programm sowie Rollen/ Verantwortlichkeiten informiert > Festlegung eines Berichtsweges ber identizierte Risiken, festgestellte Regelverste sowie eingehende Hinweise Compliance-berwachung und Verbesserung > berwachung der Angemessenheit und Wirksamkeit (inkl. Reporting) > Voraussetzung: ausreichende Dokumentation > Management trgt Verantwortung
>
>
>
>
3.11 BUNDESDATENSCHUTZGESETZ (BDSG)

Gem 9 BDSG sind zur Sicherstellung des Datenschutzes bei personenbezogenen Daten technische und organisatorische Manahmen erforderlich. Hinsichtlich der Zugriffskontrollen wird gefordert, dass die zur Benutzung eines Datenverarbeitungssystems Berechtigten ausschlielich auf die ihrer Zugriffsberechtigung unterliegenden Daten zugreifen knnen und dass personenbezogene Daten bei der Verarbeitung, Nutzung und nach der Speicherung nicht unbefugt gelesen, kopiert, verndert oder entfernt werden knnen (Zugriffskontrolle). Ferner ist zu gewhrleisten, dass personenbezogene Daten bei der elektronischen bertragung oder whrend ihres Transports oder ihrer Speicherung auf Datentrger nicht unbefugt gelesen, kopiert, verndert oder entfernt werden knnen und dass berprft und festgestellt werden kann, an welche Stellen eine bermittlung personenbezogener Daten durch Einrichtungen zur Datenbertragung vorgesehen ist (Weitergabekontrolle), Gem. Ziff. 5 der Anlage zu 9 BDSG ist zu gewhrleisten, dass nachtrglich berprft und festgestellt werden kann, ob und von wem personenbezogene Daten in Datenverarbeitungssysteme eingegeben, verndert oder entfernt worden sind (Eingabekontrolle), Weiterhin ist lt. Ziff. 7 zu gewhrleisten, dass personenbezogene Daten gegen zufllige Zerstrung oder Verlust geschtzt sind (Verfgbarkeitskontrolle). Einzelheiten zum Datenschutz im SAP-Umfeld knnen Sie im DSAG Datenschutzleitfaden nachlesen.16
16 Leitfaden Datenschutz SAP ERP 6.0 (Stand 20. September 2009), Download ber DSAGNet
Seite 16
3.12 BILANZRECHTSMODERNISIERUNGSGESETZ (BILMOG)

Die neuen Bilanzierungsregelungen sind verpichtend fr Geschftsjahre ab dem 01. Januar 2010 anzuwenden. Sie sind anzuwenden durch kapitalmarktorientierte Konzernunternehmen im Sinne des 264d HGB n.F. 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 rcken durch BilMoG strker in den Blickpunkt von Vorstnden und Aufsichtsrten und insofern stehen in den Unternehmen die entsprechenden aufbau- und ablauforganisatorischen Fragestellungen (auch zu Themen wie Funktionstrennung und sichere Berechtigungskonzepte und -systeme) im Fokus. Bei unzureichender Ausbung der Managementpichten mit entsprechenden Schadensfllen knnen sich Haftungsansprche ergeben (Organisationsverschulden gem. 130 OWiG, 93 Abs. 2 AktG bzw. 43 GmbHG).
3.12.1 LAGEBERICHT ( 289, 315 HGB N.F.)

Im Lagebericht sind die wesentlichen Merkmale des rechnungslegungsbezogenen internen (IKS) und des Kontroll- und Risikomanagementsystems (RMS) zu beschreiben.
3.12.2 PFLICHTEN DES AUFSICHTSRATES

Der Aufsichtsrat hat die Verpichtung zur berwachung folgender Bereiche: > > > > Rechnungslegungsprozess Internes Kontrollsystem (IKS) Risikomanagementsystem (RMS) Internes Revisionssystem (Interne Revision)
Diese berwachungspichten werden dazu fhren, dass sich Aufsichtsrte entsprechende Berichtswege mit wirksamen berwachungsstrukturen einrichten und dies auch Auswirkungen auf efziente und effektive Kontrollen insbesondere in solchen Unternehmensbereichen haben wird, die Daten zur Finanzberichterstattung beisteuern (insbesondere Rechnungs- und Finanzwesen, Personalwesen, Materialwirtschaft, Produktion, Vertrieb).
3.12.3 HANDLUNGSFELDER FR DEN VORSTAND

Der Vorstand trgt die Verantwortung fr 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. Softwareuntersttzung) und deren Verzahnung > Analyse der Angemessenheit, insbesondere der Nachweisfhigkeit > Manahmen zur Verbesserung des IKS/RMS
Seite 17
Darber hinaus ist ein Nachweis der Wirksamkeit von IKS/RMS zu fhren: > Externe Zertizierung der internen Revision (IR) > Etablierung eines Regelprozesses zum Monitoring der Wirksamkeit (Self Assessment, Prfungsplanung der IR, Prfung durch Externe, Konsolidierung der berwachungsergebnisse) > Initiierung von Verbesserungsmanahmen bei festgestellten Schwchen > Berichterstattung an den Aufsichtsrat Durch eine mglichst integrierte Steuerung und berwachung der Risiken und Kontrollen innerhalb fr das Unternehmen besonders kritischer Geschftsablufe mit Hilfe von SAP BO GRC Access Control, Process Control und Risk Management kann ein effektives und efzientes Management der Risiken und Kontrollen erreicht werden. Dies ist eine wesentliche Voraussetzung fr die praktische Umsetzung der BilMoG-Anforderungen an Vorstand und Aufsichtsrat im Rahmen der berwachung des internen Kontrollsystems und internen Risikomanagementsystems. Eine der wesentlichen Manahmen zur Verbesserung des internen Kontrollsystems ist die Beseitigung 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 nanzkritischer Geschftsprozesse. Eine unter IKS-Gesichtspunkten wirksame Funktionstrennung in der Ablauforganisation eines Unternehmens lsst sich durch ein entsprechendes Benutzerkonzept mit auf den Arbeitsplatz zugeschnittenen Benutzerberechtigungen erreichen. Der geschilderte Handlungsbedarf gilt brigens nicht nur fr groe brsennotierte Unternehmen, sondern ist auch fr kapitalmarktorientierte Mittelstandsunternehmen verpichtend, die ein funktionierendes internes Kontroll- und Risikomanagementsystem sicherstellen wollen.
3.13 BASEL II
Unter dem Begriff Basel II werden die Eigenkapitalvorschriften fr Kreditinstitute zusammengefasst, die vom Basler Ausschuss fr 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 Solvabilittsverordnung und die MaRisk (Mindestanforderungen an das Risikomanagement). Die Rahmenvereinbarung von Basel II basiert auf den drei Sulen > Mindestkapitalvorschriften (Berechnung einer angemessenen Eigenkapitalausstattung) > aufsichtsrechtliche berprfungsverfahren > Marktdisziplin (hheres Ma an Transparenz bei der Offenlegung von Informationen der Bank. Sie verlangt die Offenlegung quantitativer und qualitativer Aspekte der von der Bank verwendeten Methoden fr das Management ihrer Eigenkapitalanforderungen)
Seite 18
Kreditinstitute mssen zu jedem einzelnen Risikobereich (z.B. Kredit-, Markt-, operationelles Risiko, Zinsnderungsrisiko des Anlagebuchs und Beteiligungspositionen) die internen Ziele und Grundstze des Risikomanagements beschreiben. Dazu gehren: > > > > Strategien und Prozesse Struktur und Organisation der relevanten Risikomanagement-Funktion Art und Umfang der Risikomeldungen und/oder -messsysteme Grundstze der Absicherung und/oder Minderung von Risiken sowie Strategien und Prozesse zur berwachung der fortgesetzten Effektivitt dieser Absicherungen/Risikominderungen
Innerhalb der Mindestanforderungen an das Risikomanagement (MaRisk) ist hinsichtlich der internen Kontrollverfahren festgelegt, dass Adressausfallrisiken, Marktpreisrisiken, Zinsnderungsrisiken, Liquidittsrisiken und operationelle Risiken anhand wirksamer Risikosteuerungs- und Controllingprozesse zu berwachen sind und darber zu berichten ist.
3.14 BASEL III

Die neuen Empfehlungen (Basel III) wurden im November 2010 verabschiedet und basieren einerseits auf den Erfahrungen mit Basel II und andererseits auf den Erkenntnissen und Erfahrungen aus der weltweiten Finanz- bzw. Wirtschaftskrise. Sie sind bis 2018 umzusetzen. Von den Banken wird die Erhhung der Mindesteigenkapitalanforderungen und die Einfhrung von Kapitalpuffern gefordert. Damit sollen die Banken im Falle einer Krise besser gewappnet sein.
3.15 MINDESTANFORDERUNGEN AN COMPLIANCE MACOMP

Am 7.Juni 2010 wurden von der Bundesanstalt fr Finanzdienstleistungsaufsicht (BaFin) die Mindestanforderungen an Compliance und die weiteren Verhaltens-, Organisations- und Transparenzpichten nach 31 ff. WpHG (MaComp) verffentlicht17. Die neuen Vorgaben sind bis Ende 2010 umzusetzen. Durch die Anforderungen sollen insbesondere Unsicherheiten innerhalb der Wertpapier-Compliance ausgerumt werden. Die MaComp richten sich an alle Wertpapierdienstleistungsunternehmen im Sinne des 2 Abs. 4 WpHG. Eine Compliance-Funktion, die prozessbegleitend und prventiv arbeiten soll, ist einzurichten. Dabei ist die Compliance-Funktion Teil des internen Kontrollsystems.
3.16 MINDESTANFORDERUNGEN AN DAS RISIKOMANAGEMENT MARISK

Die aktuellen MaRisk wurden mit BaFin-Rundschreiben vom 15. Dezember 2010 verkndet. Im Einzelnen sind u.a. folgende Handlungsfelder przisiert18 : > Risiken > Geschfte > Gesamtverantwortung der Geschftsleitung > Allgemeine Anforderungen an das Risikomanagement > Internes Kontrollsystem mit Aufbau- und Ablauforganisation, Risikosteuerungs- und -controllingprozesse, Stresstests > Interne Revision > Risikomanagement auf Gruppenebene > Organisationsrichtlinien
Seite 19
17 BaFin: Rundschreiben MaComp WA 4/2010 vom 07. Juni 2010 18 BaFin: Rundschreiben 11/2010 (BA) - Mindestaforderungen an das Risikomanagement MaRisk vom 15. Dezember 2010
> Technisch-organisatorische Ausstattung (u.a. mssen die IT-Systeme und die IT-Prozesse die Integritt, die Verfgbarkeit, die Authentizitt sowie die Vertraulichkeit der Daten sicherstellen) > Outsourcing (Regelung der Modalitten bei Auslagerung von Dienstleistungen an Dritte, wie z.B. Festlegung von Informations- und Prfungsrechten, Sicherstellung der Datenschutzbestimmungen)
3.17 MARKETS IN FINANCIAL INSTRUMENTS DIRECTIVE MIFID

Bei der MiFiD handelt es sich um eine EU-Richtlinie, die in Deutschland im Wesentlichen in 2007 mit dem Finanzmarktrichtlinie-Umsetzungsgesetz (FRUG) in nationales Recht berfhrt worden ist. Das FRUG regelt insbesondere die Verhaltens-, Organisation- und Transparenzpichten der Wertpapierdienstleistungsunternehmen. Damit sind entsprechende Informations- und Berichtspichten sowie Dokumentatons- und Archivierungsanforderungen verbunden, die letztlich nur durch geeignete IT-Systeme und Applikationen umzusetzen sind.
3.18 SOLVABILITTSVERORDNUNG SOLVV

Hierbei handelt es sich um eine Verordnung ber die angemessene Eigenmittelausstattung von Instituten, Institutsgruppen und Finanzholding-Gruppen des Bundesministeriums der Finanzen vom 14. Dezember 2006. Die SolvV deckt die erste und dritte Sule aus Basel II ab. Die vom Gesetzgeber geforderte Markttransparenz wird durch spezielle Offenlegungsvorschriften untermauert.
3.19 SOLVENCY II
Mit Solvency II (Solvabilitt II) wird zurzeit ein neues europisches Aufsichtssystem fr Versicherungsunternehmen entwickelt. Es wird insbesondere die Kapitalanforderungen an Versicherungsunternehmen grundlegend reformieren. Das bestehende Solvenzmodell, Solvency I, wurde in den frhen 1970er-Jahren eingefhrt und deniert pauschale Kapitalanforderungen (Solvenzspannen) auf relativ einfach Weise. Diese bilden nur bedingt die tatschlichen Risiken des Versicherungsgeschfts ab. In einigen Fllen stehen die heutigen Regelungen im Widerspruch zu gutem Risikomanagement.19 Solvency II ist eines der wichtigsten Projekte im Bereich Aufsicht ber Finanzdienstleistungen auf EU-Ebene. Ziel des Projektes ist es, die heutigen Solvabilittsvorschriften (Eigenmittelanforderungen) fr Versicherungsunternehmen zu einem konsequent risikoorientierten System der Finanzaufsicht weiterzuentwickeln. Die Versicherer werden animiert, ihr eigenes, internes Risikomanagement zu verbessern. Versicherer mssen das Vorhandensein einer Risikostrategie, einer angemessenen Aufbau- und Ablauforganisation, eines internen Steuerungs- und Kontrollsystems und einer internen Revision nachweisen. Darber hinaus wird mit Solvency II eine angemessene Harmonisierung der Aufsicht in Europa angestrebt. Solvency II wird voraussichtlich zum 1. Januar 2013 in Kraft treten.20
3.20 SARBANES-OXLEY ACT (SOX)

SOX ist ein Oberbegriff fr gesetzliche Anforderungen an interne Kontrollen der Finanzberichterstattung und betrifft alle an US-Brsen gelisteten Unternehmen. Insofern fallen auch deutsche Unternehmen unter dieses US-Gesetz von 2002, sofern ihre Wertpapiere an einer US-Brse gelistet sind. Unternehmen mssen gem. SOX nachweisen, dass wirksame interne Kontrollen (unternehmensweite Kontrollen und Geschftsprozesskontrollen) zur Sicherstellung einer zutreffenden und vertrauenswrdigen Finanzberichterstattung eingerichtet sind. Dieser Nachweis ist durch das Management gegenber der amerikanischen Brsenauf-
Seite 20
19 Siehe Gesamtverband der Deutschen Versicherungswirtschaft e.V. (GDV) 20 Auszge BaFin Solvency II 21 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 verfgbar: http://www.coso.org/guidance.htm.
sicht (SEC) zu erbringen und durch einen Wirtschaftsprfer zu besttigen. Die mit der berwachung der Einhaltung von SOX befasste amerikanische Aufsichtsbehrde ist die PCAOB (Public Company Accounting Oversight Board). Ein von der SEC und dem PCAOB empfohlener Standard zur Einrichtung und berwachung interner Kontrollen ist das sog. COSO-Framework21, das detaillierte Kontrollstrukturen und Umsetzungsvorschlge enthlt und in Deutschland in der Regel auch Mastab fr 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 Gegenberstellung von COSO-Regelungen zu den Kontrollempfehlungen von COBIT wurde vom amerikanischen IT Governance Institute (ITGI) mit dem Leitfaden IT Control Objectives for Sarbanes-Oxley22 empfohlen.
3.21 NORMEN (DIN ISO/IEC)

3.21.1 ISO/IEC 27001
Die ISO/IEC 27001:2005 wurden auf Basis des britischen Standards BS 7799-2:2002 entwickelt und erstmals am 15. Oktober 2005 verffentlicht. 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 management systems requirements specication ist der erste internationale Standard zum Informationssicherheitsmanagement, der auch eine Zertizierung ermglicht. 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 fr die praktische Umsetzung.
3.21.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 fr das Informationssicherheitsmanagement zu denieren. ISO 27002 befasst sich daher hauptschlich mit den erforderlichen Schritten, um ein funktionierendes Informationssicherheitsmanagement aufzubauen und in der Organisation zu verankern. Die erforderlichen Informationssicherheitsmanahmen werden kurz auf den ca. 100 Seiten des ISO-Standard ISO/IEC 27002 angerissen. Die Empfehlungen sind auf Management-Ebene und enthalten kaum konkrete technische Hinweise. Ihre Umsetzung ist eine von vielen Mglichkeiten, die Anforderungen des ISO-Standards 27001 zu erfllen.
3.21.3 ISO 27005

Dieser ISO-Standard Information security risk management enthlt Rahmenempfehlungen zum Risikomanagement fr Informationssicherheit. Unter anderem untersttzt er bei der Umsetzung der Anforderungen aus ISO/IEC 27001. Hierbei wird allerdings keine spezische Methode fr das Risikomanagement vorgegeben. ISO/IEC 27005 lst 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.
22 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
Seite 21
3.21.4 WEITERE STANDARDS DER REIHE ISO 2700X
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 Verstndnis und zur praktischen Anwendbarkeit der ISO 27001 beitragen. Diese beschftigen sich beispielsweise mit der praktischen Umsetzung der ISO 27001, also der Messbarkeit von Risiken oder mit Methoden zum Risikomanagement.
3.21.5 ZERTIFIZIERUNG NACH ISO 27001 AUF BASIS VON IT-GRUNDSCHUTZ

Das Bundesamt fr Sicherheit in der Informationstechnik bietet seit Januar 2006 die ISO 27001-Zertizierung auf der Basis von IT-Grundschutz an. Hierber kann nachgewiesen werden, dass in einem Informationsverbund die wesentlichen Anforderungen ISO 27001 unter Anwendung der IT-Grundschutz-Vorgehensweise (BSI-Standard 100-2) und ggf. einer ergnzenden Risikoanalyse (BSI-Standard 100-3) umgesetzt wurden. Nach Umsetzung aller fr die Zertizierung relevanten Manahmen kann die Institution einen beim BSI lizenzierten ISO-27001-Auditor beauftragen, den Informationsverbund gem dem Prfschema des BSI zu berprfen. Die Ergebnisse dieser unabhngigen Prfung werden in einem Auditreport festgehalten. Ein ISO-27001-Zertikat auf der Basis von IT-Grundschutz kann zusammen mit der Einreichung des Auditreports beim BSI beantragt werden. Nach Prfung des Reportes durch Experten des BSI erteilt die Zertizierungsstelle das Zertikat, das ebenso wie die Auditor-Testate vom BSI verffentlicht wird. Alle zertizierungsrelevanten Informationen wie das Zertizierungsschema und die Namen der lizenzierten Auditoren sind ffentlich verfgbar und knnen unter www.bsi.bund.de/gshb/zert eingesehen werden.
3.21.6 RISIKOMANAGEMENT NACH ISO 31000

Die Ende 2009 eingefhrte ISO-Norm 31000 Risk management Principles and guidelines regelt die Anforderungen und deren Umsetzung fr ein international anerkanntes Risikomanagementsystem.
Establish the Context
Communicate and Consult
Risk Assesent
Identify Risks
Analyse Risks
Monitor and Review
Evaluate Risks
Treat Risks
Risikomanagement nach ISO 31000

Seite 22
ISO 31000
Eine deutsche bersetzung wird im Laufe des Jahres 2011 verfgbar sein. Fr sterreich liegt bereits seit Februar 2010 eine deutschsprachige Version als NORM ISO 31000 Risikomanagement Grundstze und Richtlinien vor. Es handelt sich um ein Regelwerk im Sinne einer Best Practice, das nicht zertiziert wird. Die Norm ist auf alle Unternehmens- und Organisationformen anwendbar und deniert folgende Risikomanagementprozesse, ber die ein Unternehmen verfgen sollte: > > > > > > > Kommunikation und Konsultation der Risiken Erstellung des Zusammenhangs Risikoidentikation Risikoanalyse Risikobewertung Risikobewltigung berwachung und berprfung der Risiken
Das sterreichische Normungsinstitut (ON) hat darber hinaus mit der ONR 49000 Risikomanagement fr Organisationen und Systeme Begriffe und Grundlagen Umsetzung von ISO 31000 in die Praxis (siehe auch 49001, 49002, 49003) ein Rahmenwerk zur praktischen Umsetzung der ISO 31000 bei Unternehmen, Behrden und Institutionen geschaffen. Ziel ist dabei auch die Integration mit anderen Regelwerken: > ISO 9000:2008 Qualittsmanagement > ISO/IEC 50051:1999 Safety aspects > ISO/IEC Guide 73:2002 Riskmanagement > ISO 14001 Umweltmanagement > ISO27001/17799/(BS7799) Informationssicherheitsmanagementsysteme Insbesondere sollen Qualitts- und Risikomanagement verbunden werden, wobei sich die ONR 49000 sehr stark beim Aufbau an der Norm ISO 9001 orientiert.
Seite 23
4 Zielmarkt
4.1 MITTELSTAND
In Kapitel 3 ist ausfhrlich von Gesetzen, Vorschriften und Verordnungen die Rede, die sich in erster Linie an brsennotierte grere Unternehmen sowie grere GmbHs richten. Der Ursprung der Compliance-Idee und des Risikomanagements kommt aus den USA; in Europa wurde diese Idee in einer etwas gemilderten Version (8. EU-Richtlinie)23 in nationale Gesetze umgesetzt. Im Mittelstand ist insbesondere bei den kleineren und mittleren Unternehmen (KMU) das Risikomanagement vielfach immer noch nicht ausreichend ausgeprgt und organisiert. Zunehmend wird man jedoch aufgrund des Drucks der Banken aktiv, da eine fehlende oder unzureichende Risikoorganisation notwendige Kreditvergaben beeintrchtigt bzw. verteuert oder verhindert. Mittelstndische Unternehmen mit eigenverantwortlicher IT-Infrastruktur sind oftmals gesellschaftlich vernetzt und somit an die Vorschriften der Mutter oder des zentralen Audits gebunden mit i.d.R. unternehmensweiten Governance- und Compliance-Richtlinien. Hier stellt sich nicht die Frage ob, sondern eher wann die Umsetzung und in welcher Form durchzufhren ist. Mittelstndische Unternehmen sind oftmals Zulieferer fr Konzerne oder deren Vertriebspartner. Diese Konzerne achten verstrkt darauf, dass auch die Partner ihre Regelwerke akzeptieren und vielleicht nicht in vollem Umfang implementieren und einhalten. Fast jedes grere mittelstndische Unternehmen ist international aufgestellt und deniert fr die Zentrale wie auch fr die nationalen Gesellschaften ein internes Kontrollsystem und ein Risikomanagement, um das Zusammenwirken auf eine einheitliche, nachvollziehbare Geschftsgrundlage zu stellen. Der globale Wettbewerb zwingt zur Spezialisierung und damit zunehmend als Wettbewerbsvorteil auch zu einer Zertizierung der Produkte und Ablufe; sensible Produktionsverfahren und geschftskritische Rezepturen sind in mittelstndischen Unternehmen genauso verbreitet wie in Grounternehmen und existenziell zu schtzen. Eine Zertizierung ohne verlssliche und sichere Finanz- und Geschftsprozesse mit wirksamem Datenschutz ist nicht mehr zu erlangen und hierzu gehren als wesentlicher Bestandteil ein wirksames internes Kontroll- und Risikomanagement mit Transparenz und Nachvollziehbarkeit. Prfungsgesellschaften sind verpichtet, die Unternehmensprozesse mit in ihre Prfverfahren aufzunehmen und zu bewerten. Da der Mittelstand sich in nicht unerheblichem Mae ber Kredite nanziert, ist gelebte Ordnungsmigkeit und Sicherheit in den Unternehmensprozessen und damit ein gutes Prfungsergebnis auch ausschlaggebend fr die Kreditvergabe der Banken und Investoren. Darber hinaus erfolgen im Rahmen von Basel II Risikobeurteilungen durch die Kreditinstitute (Ratings). Die Liste lsst sich beliebig fortsetzen; es gibt viele Grnde fr die Einfhrung von SAP BusinessObjects GRC bei mittelstndischen Unternehmen.
23 RICHTLINIE 2006/43/EG DES EUROPISCHEN PARLAMENTS UND DES RATES vom 17. Mai 2006
Seite 24
4.2 GROSSUNTERNEHMEN/KONZERNE
Eine wirksame und efziente Corporate Governance zur Sicherstellung einer verantwortungsbewussten, transparenten und risikominimierenden Unternehmensfhrung steht heutzutage ganz oben auf der Priorittenliste der brsennotierten deutschen Unternehmen. Danach hat der Vorstand fr die Einhaltung der gesetzlichen Bestimmungen und der unternehmensinternen Richtlinien zu sorgen und wirkt auf deren Beachtung und Einhaltung durch die Konzernunternehmen hin (Compliance).24 Die operative Umsetzung der Corporate Governance erfolgt durch ein unternehmensweites Compliance-Management. ComplianceVerste knnen Schadensersatzforderungen, Geldbuen, Strafverfahren und bleibende Imageschden nach sich ziehen. Mit der Einfhrung des Bilanzrechtsmodernisierungsgesetzes (BilMoG) wurden insbesondere Prfungsausschsse bzw. Aufsichtsrte dazu verpichtet, Compliance-Elemente wie internes Kontrollsystem, internes Risikomanagementsystem sowie das interne Revisionssystem zu berwachen. Diese Regelung verstrkt die bisher schon bestehenden Empfehlungen des Deutschen Corporate Governance Kodex, wonach der Aufsichtsrat einen Prfungsausschuss (Audit Committee) einrichten soll, der sich u.a. mit Fragen des Risikomanagements und der Compliance beschftigen soll.25 Hilfreich ist in diesem Zusammenhang der neue Prfungsstandard des IDW Grundstze ordnungsmiger Prfung von Compliance-ManagementSystemen (IDW PS980), der anerkannte Standards fr Compliance-Systeme schafft und sieben Grundelemente eines Compliance-Management-Systems przisiert (siehe auch Seite 18 ff.). Wesentlicher Schutz- und Kontrollbereich im Rahmen des Compliance-Managements sind die Schlsselkontrollen in den Unternehmensprozessen und das Erkennen und Abwehren von Unternehmensrisiken. Aufgrund der Komplexitt und fehlenden Transparenz der Prozessablufe und der Risiken sind untersttzende Tools mit prventiven und detektivischen Schutzmechanismen erforderlich. Ideal sind unternehmensweite, integrierte Lsungen mit einem breiten Anwendungsspektrum. Gerade in Grounternehmen und Konzernen ist ein wirksames, proaktives Risiko- und Kontrollmanagement nur mit Softwareuntersttzung umzusetzen.
Seite 25
24 Deutscher Corporate Governance Kodex, Abschnitt 4.1.3 in der Fassung vom 18. Juni 2009 25 Deutscher Corporate Governance Kodex, Abschnitt 5.3.2 in der Fassung vom 18. Juni 2009
5 Motivation fr IT-gesttztes Risikomanagement

Bis vor einigen Jahren wurde Risikomanagement in den Unternehmen im Wesentlichen zur Erfllung gesetzlicher Vorgaben durchgefhrt. Insbesondere die deutschen Aktiengesellschaften waren mit der Einfhrung des Gesetzes zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) im Jahr 1998 ( 91 II AktG) verpichtet, ein Risikofrherkennungssystem einzufhren mit einer entsprechenden Chancen- und Risikoberichterstattung, die zu verffentlichen ist. Das zugrundeliegende Risikomanagement dieser Unternehmen war zumeist high-level bzw. strategisch ausgerichtet, d.h., ein operatives Risikomanagement fand eher weniger oder gar nicht statt. Das Bilanzrechtsmodernisierungsgesetz (BilMoG) ging dann 2009 ber diesen Ansatz hinaus, indem der Begriff des Risikomanagementsystems eingefhrt wurde und jetzt insbesondere der Aufsichtsrat verpichtet wurde, sich mit der Wirksamkeit des RMS zu beschftigen ( 107 III AktG). Neuere Studien zeigen, dass die Anzahl der Firmen abnimmt, welche Risikomanagement im Wesentlichen aufgrund gesetzlicher Vorgaben verfolgen.26 Danach wird Risikomanagement zunehmend als unverzichtbares Instrument der Unternehmenssteuerung gesehen, wobei durchaus die damit einhergehende IT-Untersttzung als notwendig, aber auch als herausfordernd gesehen wird. Bei den Unternehmen auch im Mittelstand steigt die Einsicht, dass hier sog. Ofce-Produkte nicht mehr ausreichen, sondern dass es zunehmend professioneller Risikomanagement-Software bedarf, um die komplexen Risikozusammenhnge in den Unternehmen transparent zu erfassen und ihre Auswirkungen auf die Ertrags- und Vermgenslage zeitnah zu bewerten. Eine Studie von PricewaterhouseCoopers kommt zu dem Ergebnis, dass nur 38 Prozent der befragten Unternehmen eine professionelle Risikomanagement-Software einsetzen.27 Hier ist wohl noch groer Handlungsbedarf. Die Wirtschaftskrise der vergangenen Jahre scheint auch zu einem Umdenken bei den Verantwortlichen gefhrt zu haben. Whrend vorher eher Einzelrisiken mehr oder weniger isoliert bewertet worden sind, will man zuknftig Wechselwirkungen bercksichtigen und damit einen mehr ganzheitlichen Ansatz erreichen.28 Nicht zuletzt wird auch zunehmend ein funktionierendes Risikomanagementsystem als strategischer Wettbewerbsvorteil gesehen. Insgesamt sind folgende Motivationsfelder im Hinblick auf die Einfhrung und Ausgestaltung oder auch Verbesserung eines Risikomanagementsystems in der deutschen Unternehmenspraxis anzutreffen: > > > > > > Optimierung und Beschleunigung von Entscheidungsprozessen Minimierung von Schadensfllen und Haftungsrisiken Wirksameres Notfall- und Krisenmanagement Erzielung gnstigerer Kredit- und Versicherungskonditionen Erreichung einer besseren Unternehmensreputation am Markt Mehr Risikotransparenz und damit rechtzeitiges Gegensteuern in allen Kernprozessen eines Unternehmens (z.B. kostengnstige und sichere Beschaffung, weniger Produktionsausflle, bessere Ergebnisse im Treasury) > Schaffung einer Risikokultur mit positiven Auswirkungen auf die Unternehmensentwicklung und die Akzeptanz bei den Mitarbeitern
Seite 26
26 Studie Risikomanagement im Unternehmen, BeOne und Risk Management Association RMA e.V., Heise Verlag, Januar 2010 27 Vgl. PwC Studie Risk-Management-Benchmarking 2010, Seite 28 28 Vgl. auch die PwC Studie Risk-Management-Benchmarking 2010
Die im Folgenden dargestellten Rahmenbedingungen und Erfolgsfaktoren fr die Einfhrung von SAP BO Risk Management basieren auf den Erfahrungen durchgefhrter Implementierungsprojekte bei Unternehmen aus unterschiedlichen Branchen und unterschiedlicher Unternehmensgren. Dabei hat sich gezeigt, dass Projekte dieser Art als bergreifend anzusehen sind und nicht von der IT alleine durchgefhrt werden knnen. Aus diesem Grund ist es notwendig, alle Interessensgruppen frhzeitig einzubinden (z. B.: Fachbereichsverantwortliche, IT, Internal /External Audit). Fr eine erfolgreiche Projektdurchfhrung muss das Top-Management die Verantwortung tragen und das Projekt bei notwendigen Entscheidungen begleiten. Es hat sich als vorteilhaft erwiesen, frhzeitig die Einfhrungsstrategie festzulegen.
6.1 ORGANISATORISCHER RAHMEN

Um hier die richtige Lsung entwickeln zu knnen, muss in einem ersten Schritt die Unternehmung an sich und deren Geschftsfelder sowie die organisatorischen Rahmenbedingungen betrachtet werden. Da die inhrenten Risiken wesentlich vom Geschftsfeld beeinusst werden, sind die Risiken eines produzierenden Unternehmens andere als die eines Dienstleistungsunternehmens. Eine rein technische Implementierung ohne Betrachtung dieser Gesichtspunkte fhrt zu erheblichen Kosten, ohne das gewnschte Ziel die Bereitstellung eines effektiven und efzienten RMS/IKS zu realisieren. Hierfr ist eine Erhebung smtlicher Risikofelder und deren Gewichtung im Rahmen der Risikostrategie/Kontrollstrategie notwendig. Aufgrund der Komplexitt wird empfohlen, hier in Teilschritten vorzugehen, um frhzeitig Erfolge fr das Unternehmen und die beteiligten Mitarbeiter zu generieren.
6.2 RMS / IKS-METHODIK

Im Folgenden wird die RMS/IKS Methodik beispielhaft dargestellt. Diese beschriebene Vorgehensweise ist grundstzlich auch relevant fr Unternehmen, die nicht der BilMoG oder SOX Gesetzgebung unterliegen, aber dennoch im Sinne einer guten Unternehmensfhrung wirksame Risikomanagement- und Kontrollmechanismen einrichten oder optimieren mchten. Welche Inhalte fr das Risikomanagement bzw. Kontrollsystem relevant sind, kann mittels eines Top-downAnsatzes ermittelt werden. In einem ersten Schritt sind die relevanten Bereiche festzustellen, die im Unternehmen betroffen sind. Externe Anforderungen ergeben sich nach herrschender Ansicht, zumindest mittelbar, aus 91 Abs. 2 AktG und den 76 Abs. 1, 93 Abs. 1 AktG. Wesentlicher Treiber fr die Inhalte eines Risikomanagementsystems ist darber hinaus die Strategie des Unternehmens mit den dafr erforderlichen Erfolgsfaktoren und den daraus abgeleiteten operativen Zielen. Risikomanagement wird hug auf nanzielle Risiken eingegrenzt. Dabei wird bersehen, dass eine Reihe weiterer Betrachtungsrume existieren:
Seite 27
6 Rahmenbedingungen/Erfolgsfaktoren
6 Rahmenbedingungen /Erfolgsfaktoren
> Unternehmensstrategie (Dynamik der Mrkte und Globalisierung, Markteintritt neuer Wettbewerber) > Informationssysteme (Umsetzung von Compliance-Anforderungen, Untersttzung neuer Geschftsablufe, Wertbeitrag der IT) > Politische & geopolitische Einsse (wechselnde Politikziele, Terrorismus) > Umwelt & Gesundheit (Klimawechsel und Umweltverschmutzung, Seuchen) > Finanzen (schwankende Wechselkurse, vernderte Bilanzierungsregeln) > Betrieb (Unterbrechung der Fertigung, Ausfall eines Hauptlieferanten, Zerstrung einer Lagersttte) > Regeleinhaltung (Betrug, Produktsicherheit, nicht fristgerechte Umsetzung neuer Vorschriften) > Imageverlust Zur Umsetzung eines solchen ganzheitlichen IKS/RMS-Systems hat sich das COSO-Rahmenwerk als De-facto-Standard bewhrt. Bei COSO (Committee of Sponsoring Organizations of the Treadway Commission) handelt es sich um eine freiwillige privatwirtschaftliche Organisation in den USA, die helfen soll, Finanzberichterstattungen durch ethisches Handeln, wirksame interne Kontrollen und gute Unternehmensfhrung qualitativ zu verbessern. Gem des COSO-IC-Modells von 1992 umfasst ein internes Kontrollsystem fnf Komponenten. Im Jahr 2004 hat COSO das COSO-ERM-Framework als eine Ergnzung zu seinem ursprnglichen Modell publiziert und den Bereich Risikobeurteilung weiter untergliedert und so mittels der denierten acht Bestandteile prozessorientierter ausgestaltet: Internes Kontrollumfeld, Zielsetzung, Ereignisidentikation, Risikobeurteilung, Risikoreaktion, Kontrollaktivitten, Information und Kommunikation sowie berwachung. Es bietet sich zur Einfhrung eines IKS/RMS nach COSO die folgende Vorgehensweise an: 1. Kontrollumfeld: Die Unternehmenskultur als wichtiger Bestandteil des Kontrollumfelds bildet die Grundlage fr das Kontrollbewusstsein der Mitarbeiter. In diesem Zusammenhang ben die Faktoren Integritt, Ethik- und Sachkompetenz des Personals, Organisationsstruktur sowie der Fhrungsstil den grten Einuss aus. Der Aufbau eines Kontrollumfelds ist der entscheidende Schritt auf dem Weg zur Errichtung eines efzienten IKS/RMS. 2. Denition der Ziele: Das Management legt eindeutige Kriterien fest, anhand derer die Erreichung der strategischen Unternehmensziele gemessen werden kann. Bei den Zielen werden drei Gruppen unterschieden: Betriebliche Ziele wie Effektivitt und Efzienz der operativen Geschftsprozesse; Ziele der Berichtserstattung und Konformittsziele im Hinblick auf die Befolgung von Gesetzen und Vorschriften. 3. Evaluierung der Risiken: Organisationen sind einer Vielzahl von Risiken ausgesetzt, welche die Erreichung der Unternehmensziele im Hinblick auf die festgelegte Geschftsstrategie gefhrden knnen. Diese Risiken mssen identiziert, anhand ihres Schadenpotenzials und ihrer Eintrittswahrscheinlichkeit beurteilt und mittels entsprechender Kontrollen auf ein akzeptables Ma gemindert beziehungsweise gnzlich vermieden oder gar akzeptiert werden knnen. 4. Integration der Kontrollaktivitten: Zur Minderung des Schadens bzw. der Wahrscheinlichkeit des Eintritts eines Risikos sind bestimmte Manahmen und damit verbunden Kontrollaktivitten notwendig. Die entsprechenden Kontrollen nden in allen relevanten Organisationseinheiten und Prozessebenen statt und betreffen Ttigkeiten wie: Funktionstrennung, berprfen und Abstimmen, Genehmigung, Vermgensschutz. Um efzient zu sein, mssen die Kontrollaktivitten auch konsequent bis in alle Prozessschichten vordringen. Die in einem Reglement oder einer Weisung festgelegte Funktionentrennung muss sich neben der Unterschriftenregelung auch in der Form der Zugangsrechte zu Transaktionen und Informatikdaten uern.
Seite 28
5. Informations- und Kommunikationsmanagement: Zur Wahrnehmung von Verantwortung durch den Mitarbeiter mssen wichtige Informationen gesammelt, verarbeitet und zeitgerecht zur Verfgung gestellt werden. Das Informationssystem eines Unternehmens leistet in diesem Zusammenhang einen kritischen Wertbeitrag. Dieses kann die effektive und efziente Ausgestaltung eines IKS/RM aber nur untersttzen, wenn es von Seiten des Managements klare Vorgaben fr den Informationsuss von oben nach unten, von unten nach oben und quer durch das Unternehmen sicherstellt. 6. berwachung: Ein Internes Kontrollsystem ist kein Fhrungsinstrument, das einmalig in einer bestimmten und unabnderlichen Form errichtet wird. Bestimmte Vernderungen in den Unternehmensprozessen oder der Unternehmenskultur knnen Anpassungen notwendig machen. Aus diesem Grund muss das IKS/RMS periodisch berprft werden, um die Wirksamkeit und die kontinuierliche Nutzung auf allen Ebenen in der Organisation sicherzustellen.
6.3 RISIKO-GOVERNANCE UND RISIKOSTRATEGIE

Steigende Ansprche der Stakeholder, eine zunehmende Dynamik und Komplexitt des Umfelds und nicht zuletzt als eine Reaktion auf die jngste Finanz- und Wirtschaftskrise haben viele Unternehmen ihre Einstellung zum Risikomanagement gendert oder planen eine entsprechende Adjustierung ihrer Systeme. Damit Risikomanagement gezielt als ein Instrument der Unternehmenssteuerung eingesetzt werden kann, gilt es, die vorhandenen und oft gewachsenen Silos fr das Management von Risiken und Kontrollen zu einem unternehmensweit ausgestalteten System zu integrieren und die an Bedeutung gewinnenden Anforderungen an eine werte- und risikoorientierte Unternehmensfhrung zu untersttzen. Risikoorientierte Unternehmensfhrung beschreibt dabei einen ganzheitlichen Ansatz, der alle Funktionen, Bereiche und Prozesse eines Unternehmens umfasst.29 Ausgehend von einem gemeinsamen Konsens, dass ein Unternehmen, ohne Risiken einzugehen, nicht berlebensfhig ist, gilt es, die richtigen Risiken einzugehen, ohne dabei die Risikotragfhigkeit des Unternehmens zu berlasten, und so den Erfolg des Unternehmens nachhaltig und damit langfristig zu sichern. Dabei sind die Anforderungen an ein modernes Risikomanagement vielfltig: Es ist unternehmensweit eingefhrt, werteorientiert und nachhaltig. Nachhaltigkeit bedeutet in diesem Zusammenhang nicht, nur einen groen Nutzen durch efzienten Einsatz der Ressourcen zu bieten, sondern auch im Sinne einer Corporate Responsibility die Anforderungen eines erweiterten Kreises an Interessenvertretern zu bercksichtigen, wie seit der nderung des Deutschen Corporate Governance Kodex im Jahr 2009 gefordert wird.30 Risikomanagement dient also letztendlich dazu, das Erreichen der Unternehmensziele abzusichern und die Unternehmenswerte zu schtzen. Die Risiko Governance formuliert die Leitlinien des unternehmensweiten Risikomanagements, ihre Hauptbestandteile sind die Risikostrategie sowie die Anforderungen an eine Risikokultur, wobei Letztere darauf ausgerichtet sein sollte, Risikomanagement nicht als eine Funktion einzelner Mitarbeiter oder Bereiche, sondern vielmehr als eine Aufgabe der gesamten Belegschaft zu formulieren und Risikobewusstsein aktiv zu frdern. Der sog. Tone from the Top hat hier eine wichtige Vorbildfunktion: Nur wenn die Unternehmensfhrung Risikomanagement lebt, bildet sich bei den Mitarbeitern ein entsprechendes Bewusstsein. Dazu zhlen nicht zuletzt ein transparenter Umgang mit Risiken, ein offener Kommunikationsstil und regelmige Schulungen als ankierende Manahmen. Risiko beschreibt Planung unter Unsicherheit. Ein ganzheitliches Risikoverstndnis bedeutet Risiko als die volle Bandbreite positiver und negativer Abweichungen, um geplante oder erwartete Werte zu betrachten. Insbesondere sind negative Risiken, also Gefahren, unter denen die Nichterreichung eines Zieles verstanden wird, von Bedeutung. Der Schutz der Unternehmenswerte ist also das bergeordnete Ziel von
Seite 29
29 Vgl. Romeike, Hager: Erfolgsfaktor Risikomanagement 2.0, Seite 105f. 30 Vgl. Farbisch: Neuausrichtung des DCGK mit Schwerpunkt auf Nachhaltigkeitsmanagement, ZCG 3/10, Seite 119f.
6 Rahmenbedingungen /Erfolgsfaktoren
Risikomanagement. Dies setzt einen bewussten Umgang mit Risiken in allen Bereichen voraus. Basis fr die Ausrichtung des Risikomanagements ist die Risikostrategie. Die Risikostrategie beschreibt die grundstzliche Haltung zur Erkennung von und zum Umgang mit Risiken. Die Risikostrategie als eigenstndiges Regelwerk ist aus der Unternehmensstrategie abzuleiten, um so das Risikomanagement an den Unternehmenszielen zu orientieren. Zugleich ist sie Ausgangspunkt fr die unternehmensweite Umsetzung des Risikomanagements. Die Risikostrategie stellt damit einen integralen Bestandteil unternehmerischen Handelns dar und ist daher analog zur Unternehmensstrategie regelmig zu berprfen, um daraus abgeleitete Vorgaben ggf. anzupassen und so deren Aktualitt zu sichern. Neben der Vision und den Zielen des Unternehmens beeinusst auch die jeweilige Branche, in der das Unternehmen ttig ist, bspw. ber spezische regulatorische Anforderungen, die Formulierung der Risikostrategie und damit die Ziele des Risikomanagements. Mgliche Bestandteile einer Risikostrategie knnen u.a. folgende Aspekte sein > Etablieren und strken eines Risikobewusstseins im Unternehmen > Denition der fr die Unternehmensperformance mageblichen Risikofelder > Harmonisierung gewachsener siloartiger Einzellsungen zu einem unternehmensweiten und integrierten Risikomanagement > Integration von Performance und Strategy Management mit dem Risikomanagement Mgliche Anforderungen und Ziele hinsichtlich der konkreten Ausgestaltung eines Risikomanagementsystems als Teile der Strategie sind bspw. > Steuerung und berwachung von Einzelrisiken > Aggregation der Einzelrisiken zur Gesamtrisikoposition und berwachung aller ergebnis- und bestandsgefhrdenden Risiken > Berichterstattung an den Risikoausschuss und die Geschftsfhrung > Funktionstrennung zwischen risikobernehmenden und risikosteuernden Akteuren einerseits (bspw. den Fachbereichen) und der Risikomanagementorganisation andererseits > Ad-hoc-Berichte > Regelmige berprfung der Wirksamkeit der Systeme > berwachung durch die interne Revision > Dokumentation der wesentlichen Elemente des Systems in verbindlichen Anweisungen Verantwortlich fr die Risikostrategie ist das Top-Management. Die starke Untersttzung der Unternehmensleitung ist fr das Etablieren eines nachhaltigen unternehmensweiten Risikomanagements unerlsslich.
6.4 GRC-ORGANISATION
Compliance- und Risikomanagement sind Aufgabenfelder, die das gesamte Unternehmen betreffen. Oft werden Mitarbeiter danach unterschieden, ob sie aktiv in das Risikomanagement involviert sind oder lediglich innerhalb der normalen Geschftsablufe ttig sind. Die Sichtweise ist nicht unproblematisch, da alle Mitarbeiter in Geschftsprozesse involviert sind, die sich auf die Erreichung der Unternehmensziele auswirken. Es ist daher von groer Wichtigkeit, dass Risikomanagement sowie das damit im direkten Zusammenhang stehende Compliance Management im Bewusstsein der Organisation und ihrer Mitglieder fest verankert ist. Die Aufsichtsorgane berwachen die Geschftsleitung und setzen Leitlinien fr das Management. In dieser Rolle deniert der Aufsichtsrat Werte hinsichtlich Integritt und Ethik. Zudem kommt dem Aufsichtsrat eine berwachende Funktion zu. Als Anforderung aus dem BilMoG ergibt sich fr den Aufsichtsrat die Picht zur
Seite 30
Prfung, ob seine Anforderungen erfllt wurden, indem er kontrolliert, ob die Geschftsfhrung ein wirksames Risikomanagement implementiert hat. Die oberste Geschftsfhrung ist unmittelbar verantwortlich fr alle Aktivitten im Unternehmen und dafr, dass ein RMS/IKS implementiert ist. Der Vorstand/CEO trgt die Gesamtverantwortung fr die Managementsysteme und muss fr die Schaffung eines gnstigen Kontrollumfeldes sorgen und durch die Aufstellung und Befolgung von unternehmensweiten Verhaltensregeln mit gutem Beispiel vorangehen. In zunehmendem Mae installieren Unternehmen zentrale Risikomanager, um das Risikomanagement in der Organisation zu verankern und fortzuentwickeln. Der zentrale Risikomanager sollte als Stabsstelle direkt dem Vorstand angegliedert sein und ist somit fr die Umsetzung der festgelegten risikopolitischen Vorgaben im Konzern verantwortlich. Als zentraler Risikomanager berichtet er sowohl dem Konzernvorstand als auch dem Risikoausschuss des Aufsichtsrats regelmig ber die Gesamtrisikolage der Organisation. Aber auch die Fhrungskrfte der Hauptgeschftsprozesse Rechnungswesen, Controlling, Einkauf, Fertigung und Vertrieb haben wesentlichen Einuss auf die einzelnen Bereiche des Unternehmens, da sie hug an unternehmensweiten Planungen und Budgetierungen beteiligt sind. Sie sollten daher in den Aufbau und den Betrieb des IKS/RMS eingebunden sein und als Prozessverantwortliche einen wesentlichen Beitrag zu Wirksamkeit der beiden Managementsysteme liefern. Diese Fhrungsebene verantwortet somit die Entwicklung und Umsetzung der internen Kontrollverfahren, die in ihrer Abteilung bzw. ihren Prozessen die Zielerreichung gewhrleisten sollen. Innerhalb der Geschftsbereiche sind lokale Risikomanager zu benennen, welche innerhalb eines unternehmensweiten Netzwerks an Risikomanagern organisiert sind und um Interessenskonikte zu vermeiden, organisatorisch direkt an den zentralen Risikomanger berichten. Eine weitere wichtige Einheit bildet die Interne Revision: zu deren Aufgaben die berprfung der Zuverlssigkeit und Integritt der Finanzinformationen, die Konformitt des Unternehmens mit gesetzlichen Anforderungen sowie die Wirtschaftlichkeit und Wirksamkeit der operativen Geschftsablufe gehrt. Des Weiteren prft und berichtet die Interne Revision regelmig ber die Wirksamkeit des unternehmensweiten RMS/IKS. Alle Mitarbeiter des Unternehmens sind explizit oder implizit beteiligt. Zum einen spielen praktisch alle Mitarbeitenden bei der Umsetzung der Kontrollen eine Rolle, sei es bei der Durchfhrung von Abstimmungen oder physischen Kontrollen, bei der Nachkontrolle von Anomalien oder Fehlern sowie bei der Analyse verschiedener Abweichungen oder anderer Leistungsindikatoren. Die Sorgfalt, mit der die Mitarbeitenden diese Ttigkeiten ausfhren, beeinusst direkt die Wirksamkeit des IKS. Zum andern sollten alle Mitarbeitenden angehalten werden, Verletzungen des Verhaltenskodex oder der internen Vorschriften und Weisungen sowie jede gesetzwidrige Handlung mitzuteilen. Hierzu bietet sich die Bestellung eines Ombudsmanns an. Zu den externen Teilnehmern am Risikomanagementprozess zhlen Wirtschaftsprfer und externe Auditoren, der Gesetzgeber und sonstige Regulierungsbehrden sowie Geschftspartner, externe Dienstleister, Finanzanalysten, RatingAgenturen und die Medien. Mit SAP BO GRC Risk Management knnen smtliche organisatorischen Strukturen in jeder gewnschten Detailtiefe dargestellt werden. Der jeweiligen Organisationsebene werden die entsprechenden Prozesse, Subprozesse und Kontrollen zugeordnet. Hierbei gibt es drei Mglichkeiten der Zuordnung (Kopie, Referenz und Ohne Kontrolle zuordnen). Die Zuordnungsmethode bestimmt, wie die zentral verknpften Daten des Prozesskatalogs zu den betreffenden Organisationen transferiert bzw. zugeordnet werden. Darber hinaus knnen auch direkt in der jeweiligen Organisationseinheit Kontrollen deniert werden. Unsere Empfehlung ist es, aus Grnden der bersichtlichkeit Kontrollen weitgehend referenzierend anzulegen. Dadurch werden bei einer zentralen nderung auch die Inhalte in der jeweiligen Kontrolle in den Organisationseinheiten gendert. Diese Vorgehensweise erfordert eine entsprechende Standardisierung in der Vorbereitungsphase.
Seite 31
7 Umsetzung des Risikomanagementprozesses in RM

SAP BusinessObjects Risk Management untersttzt als Tool die Einfhrung eines geordneten, berichtsorientierten Risikomanagementprozesses in einer zentralen Installation. Dies kann auch in einer engen Abstimmung mit der Einfhrung eines internen Kontrollsystems stehen, welches als Bestandteil der GRC-Suite Teil einer umfassenden Lsung fr Governance Risk und Compliance ist. Besonderes Augenmerk der SAP-Lsung liegt hier auf der Untersttzung einer groen Anzahl von Benutzern, automatisierten Workows zur Koordination und Untersttzung von regelmigen Aktualisierungen des Datenbestandes, einem revisionssicheren System und automatisierten Datenerhebungen fr Risikofrhwarnindikatoren aus angeschlossenen Vorsystemen. Der untersttzte Prozess im Tool folgt der Methodologie aus Risikoplanung Risikoidentikation Risikoanalyse Risikogegenmanahmen treffen Monitoring und Reporting.
BERWACHUNG
Proaktives Risikomonitoring ber bestehende Geschftsprozesse und strategische Aktivitten
MASSNAHMEN
Entwicklung von Lsungsstrategien fr Toprisiken, um eine hohe Kapitalrendite zu erzielen
IDENTIFIKATION/ ANALYSE
Identizieren und Bewertung aller Toprisiken innerhalb des Unternehmens
PLANUNG
Festlegung von Toprisiken, Schwellenwerten und Risikobereitschaft
Risikomethodologie
Seite 32
7.1 GRUNDLEGENDE BERLEGUNGEN UND EINSTELLUNGEN

Bevor ein Risikomanagementprozess im Unternehmen implementiert wird, ist es notwendig, sich im Vorfeld Gedanken ber verschiedene Aspekte des Prozesses zu machen und grundlegende Annahmen zu treffen, so z.B.: > Wer ist der Auftraggeber des Risikomanagementprozesses und was sind seine Erwartungen bezglich der Ergebnisse des Risikomanagements? > Welche Unternehmensbereiche und Prozesse sollen in das Risikomanagement einbezogen werden? > Welche Managementmethodologie soll untersttzt werden? > Welche Klassikation und Meldestufen werden im Unternehmen verwendet? > Welche Berichtsfrequenz und welche Berichtsumfnge sind zu untersttzen? > Wie viel Risikoexposure kann sich das Unternehmen leisten ohne in eine bestandsgefhrdende Situation zu gelangen? All diese Fragen werden im Allgemeinen VOR Beginn der Implementierung zu klren sein, indem man den Scope des Implementierungsprojektes festlegt. Nheres dazu im Kapitel Business Blueprint weiter unten. Eines der Hauptziele von SAP BO Risk Management ist ein unternehmensweites konsistentes Berichtswesen ber Risiken und ihre Gegenmanahmen hinweg. Zur Sicherstellung dieses konsistenten Berichtswesens mssen in der Startphase des Implementierungsprojektes Einstellungen festgelegt werden. Das betrifft zentrale Einstellungen wie: > Wie viele Risikostufen sollen verwendet werden, z.B. 3 (niedrig, mittel, hoch), oder ist eine feinere Abstufung gewnscht? > Wie viele Stufen in der Eintrittswahrscheinlichkeit sind gewnscht? > Welche Benutzer/Rollen nehmen am Risikomanagementprozess teil? > Welche Schadenskategorien sollen verwendet werden, um eine einheitliche Nomenklatur zu erreichen? > Welche Analyseverfahren werden im Unternehmen angewendet (z.B. qualitative, quantitative oder gemischte Analysen)? > Ist eine Integration mit dem internen Kontrollsystem gewnscht? Hierbei knnen dann interne Kontrollen als Risikogegenmanahmen hinterlegt und bewertet werden All diese Einstellungen im Einfhrungsleitfaden haben einen zentralen und verbindlichen Charakter fr den spteren operativen Betrieb des Risikomanagementsystems. SAP liefert beispielhaft Einstellungen ber BC-Sets aus, die auf den Empfehlungen des Customer Advisory Ofces basieren. Diese knnen im Implementierungsprojekt bernommen werden.
Seite 33
GRC-Einstellungen im IMG 1
Seite 34
7.2 ERSTELLEN DER ZENTRALEN KATALOGE

Nachdem die grundstzlichen Systemeinstellungen ber den IMG getroffen wurden, ist es notwendig fr ein unternehmensweites System die entsprechenden Klassizierungen und zentralen Kataloge aufzubauen. Dies betrifft die Organisationsstruktur mit ihren relevanten Einstellungen fr das Risikomanagement, den Katalog der Risikoklassizierungen, den Katalog der Unternehmensziele, den Katalog der gemeinsamen Gegenmanahmenvorschlge etc. All diese Kataloge knnen entweder von Hand ber Webmasken eingepegt werden, oder ber File-UploadSchnittstellen als csv-Dateien in das System en bloc hochgeladen werden. Die Struktur speziell der Organisationshierarchie ist wichtig, denn sie deniert auch die Berechtigungen innerhalb der Applikation. In SAP BO Risik Management knnen alle organisatorischen nderungen leicht nachvollzogen werden, denn sie sind zeitlich abgegrenzt und knnen ber die Webmaske leicht gendert werden. Durch die Stammdaten-Integration innerhalb GRC knnen auch Organisationseinheiten des internen Kontrollsystems verwendet werden, eine Doppelpege und damit potenzielle Dateninkonsistenz ist damit ausgeschlossen.
Pege der Organisationsstruktur 1
Seite 35

Fr jede dieser Organisationseinheiten werden nachfolgend die relevanten Einstellungen fr das Risikomanagement getroffen. Insbesondere sind hier die Schwellwerteinstellungen von Interesse, die festlegen, wie die Risikostufen pro Organisationseinheit berechnet werden. Es ist natrlich von der Gre und dem Geschftsvolumen einer Organisationseinheit abhngig, ab welcher Hhe ein Schaden als bestandsgefhrdend gilt. Somit kann auch fr kleinere Geschftseinheiten ein lokales angepasstes Berichtswesen ermglicht werden.
Pege der Schwellwerte Schadensstufen 1
7.3 ZIELMANAGEMENT
Es ist zunehmend wichtig, Risikomanagement nicht allein zu betreiben, sondern es in den Kontext unternehmerischen Handelns zu stellen, um die Relevanz der Risikoinformation klar herauszustellen und dem Management klarzumachen, welche Unternehmensziele derzeit stark risikobehaftet sind. In einigen Risikodenitionen spricht man auch dediziert vom Risiko als potenzieller Abweichung von der Zielerreichung eines Performance-Indikators. Um diesen Prozess zu untersttzen, ist es mglich, in SAP BO Risik Management die Risiken mit Unternehmenszielen zu verknpfen.
Seite 36
Setzt man dieses konsequent um, hat man einen Prozess prventiven Strategiemanagements etabliert, und damit schafft ein strategisches Risikomanagement einen echten Mehrwert, da die Unternehmensleitung Entscheidungsalternativen fr immer berraschend vorkommende Abweichungen im Geschft vorgeplant hat, Prozesse beschleunigt (denn Risikogegenmanahmen sind schon vorbereitet oder bereits implementiert) und eine stndige Beobachtung kritischer Faktoren veranlasst hat. Die Vorgehensweise besteht hier im Aufsetzen der Zielhierarchie mit Strategien und Zielen, welche sich spter als Attribute an Risiken wiedernden.
Pege der Unternehmensziele 1
Risikoklassikation und Klassizierung von Aktivitten/Prozessen

Um ein unternehmensweites Risikomanagement betreiben zu knnen, ist es wichtig, eine Konsistenz der verwendeten Terminologie und eine Vergleichbarkeit von Klassizierungen herzustellen, anderenfalls kann fr das Management kein einheitliches Berichtswesen aufgebaut werden. Ein besonderes Augenmerk sollte auf eine konsistente Denition des zentralen Risikokatalogs gelegt werden. Der zentrale Risikokatalog enthlt die Risikoklassikationen fr das Reporting (anderenfalls wrde es nicht gelingen, bereichsbergreifend gleichartige Risiken zu nden) und auf unterster Ebene zustzlich Risikotemplates. Risikotemplates sind Beispielrisiken, die als Kopier- oder Referenzvorlage dienen. Sie bieten fr ein Unternehmen die Mglichkeit, eine klare Struktur bezglich der Risikoanalyse vorzugeben (welche Schadenskategorien sind fr ein spezielles Risiko zu verwenden), sie erlauben, es Gegenmanahmen vorzuschlagen (im Sinne von Best Practice wenn Risiko A im Bereich eintreten knnte, hat es sich als gnstig erwiesen, folgende Gegenmanahmen zu implementieren) und damit im Allgemeinen eine grere Konsistenz und beschleunigte Einfhrung und Akzeptanz der Lsung zu erreichen. Tipp: Man kann an einer Risikokategorie einstellen, welche Analysemethoden fr bestimmte Risikoarten erlaubt sind, sodass man z.B. Reputationsrisiken nur qualitativ, aber niemals quantitativ schtzen muss.
Seite 37
Risikotemplate
Ausschnitt Risikoklassizierung 1
Seite 38
Eine gleichartige Klassizierung nimmt man auch fr Geschftsaktivitten vor, um im Sinne eines Benchmarking risikobehaftete Aktivitten zwischen Unternehmensbereichen vergleichen zu knnen. Gleiches gilt natrlich auch fr den Bereich der Chancen, der weiter unten noch erlutert wird.
7.4 RISIKOIDENTIFIKATION
Als nchster logischer Schritt wird entweder eine initiale Bestandsaufnahme von wichtigen Risiken im Unternehmen durchgefhrt oder bereits vorhandene Risiken werden in SAP BO Risk Management bernommen. Dabei sind evtl. notwendige Transformationen in das GRC-Datenmodell vorzunehmen. SAP BO Risk Management untersttzt die Anlage von Risiken direkt im System, falls diese mit qualizierten Informationen vorliegen, wobei zuerst nur eine strukturelle Beschreibung des Risikos vorgenommen werden muss. Dies umfasst eine textuelle Beschreibung des Risikos, der Zuordnung des Risikos zu Organisationseinheiten, Geschftszielen, Risikoklassikation, Prozessen oder Geschftsaktivitten, bei denen dieses Risiko auftritt, und eine optionale Analyse der Risikotreiber und Schadenskategorien.
Risikoidentikation 1 Die Hinterlegung im System wird durch grasche Mglichkeiten untersttzt, die sich auch gut eignen, im Rahmen eines Workshops Risiken mit einer greren Gruppe zu besprechen und zu modellieren. Weitere Details zum Risiko knnen spter durch Risikoexperten in der normalen Webmaske hinzugefgt werden.
Seite 39
Weiterbearbeitung des Risikos in der Detailmaske Um das Anlegen von Risiken fr Gelegenheits-Benutzer zu erleichtern, knnen Risiken auch mit einer Kopiervorlage (sogenannte Risikotemplates) angelegt werden, hierbei hat man den Vorteil, dass schon Voreinstellungen fr das Risiko getroffen sind, wie z.B. die Vorauswahl der Risikoklassizierung, die richtigen Risikotreiber/Schadenskategorien etc. und evtl. Risikogegenmanahmen. Wenn die Philosophie des Unternehmens darin besteht, smtliche Mitarbeiter potenzielle Risiken melden zu lassen, gibt es die Mglichkeit, ber einen Self-Service Risiken vorzuschlagen. Diese Vorschlge wandern nicht direkt ins Risiko-Gesamtverzeichnis des Unternehmens, sondern werden per Workow zuerst zu einem Risikomanager zur Begutachtung weitergeleitet, welcher dann entscheidet, ob das Risiko wichtig und substanziell genug ist, um es stndig zu berwachen und zu berichten. Eine Vielzahl der von Unternehmen ber Umfragetechniken oder Workshops identizierten Risiken, werden danach in das System bernommen. SAP BO Risk Management untersttzt beide Vorgehensweisen, in dem sogenannte Activity-Surveys zur Risikoidentikation verwendet werden knnen. Diese Surveys werden als ein Mail-Attachement automatisiert an eine grere Anzahl Mitarbeiter versendet, sodass man auch Mitarbeiter erreicht, die normalerweise nicht im GRC-System arbeiten. Nach dem Ausfllen der Surveys werden diese als E-Mail zurck an das GRC-System geschickt, welches die Antworten extrahiert und ins System verbucht. Weiterhin stehen Excel-Importschnittstellen bereit, um Daten ins System zu bringen, die in Workshops identiziert worden sind oder Altdatenbestnde darstellen.
Seite 40
7.5 RISIKOBEWERTUNG
Das Risiko zu benennen ist in den seltensten Fllen ausreichend. Vielmehr wird versucht, die Auswirkungen des (potenziellen) Risikoeintritts auf Geschftsprozesse und Aktivitten zu bewerten, um Schaden oder Zielabweichung abzuschtzen und entsprechende Gegenmanahmen abzuleiten. Unternehmen haben unterschiedliche Philosophien bei der Abschtzung des Einusses von Risiken. Allgemein verwendet man qualitative oder quantitative Abschtzungen fr Eintrittswahrscheinlichkeit und Schadenshhe. In Abhngigkeit von der verwendeten Methodologie werden Brutto/Netto-Abschtzungen oder reine Nettoabschtzungen verwendet, all dies ist exibel im SAP BO Risk Management ber die Analyseprole einstellbar. Es ist auch mglich, zu einem spteren Zeitpunkt die Analysemethode zu wechseln, falls die Organisation im Risikomanagementprozess einen hheren Reifegrad erreicht hat. Tipp: Man kann die Analysemethodik im Laufe der Zeit ndern, z.B. von qualitativer auf quantitative oder ScoringMethodik umstellen. Einmal verwendete Anaylseprole werden nicht mehr gelscht.
Verschiedene Analyseprole 1 Um eine einheitliche Metrik fr die Risiko-Bewertungen zu erzeugen und eine Aggregation zu ermglichen, werden nur vordenierte Werte fr Wahrscheinlichkeits- und Schadensstufen zugelassen. Es hat sich als sinnvoll erwiesen, nicht zu viele Stufen fr die Auswahl durch die Benutzer zuzulassen, im Allgemeinen kommt man mit 3 bis 5 Stufen gut aus. Ein Merkmal der Anwendung ist die Mglichkeit, den Schaden eines Risikoeintritts verschiedenen Kategorien zuzuordnen. Es muss also nicht nur ein nanzieller Schaden von 300.000 EUR entstehen, sondern man kann den Schaden entsprechend aufsplitten, etwa nach den Bereichen > Einuss auf das Betriebsergebnis, > Einuss auf die ffentliche Reputation, > Potenzielle legale Auseinandersetzungen. Nicht alle diese Bereiche werden sich quantizieren lassen, sodass die Software auch gemischte Analyseverfahren zulsst.
Seite 41
Gemischte Einschtzung des Schadens 1 In einigen Unternehmensbereichen mchte man zwar eine quantitative Abschtzung eines potenziellen Schadens erhalten, aber es ist z.B. bei einem Projektverzug schwer, den genauen Betrag des Schadens anzugeben. Auerdem kann es mentale Hrden bei der direkten Quantizierung geben, denn Mitarbeiter denken in ihren eigenen, nicht immer monetren Dimensionen. Um diesen Anwendungsfall zu ermglichen empehlt es sich, eine Schadensabschtzung in Maeinheiten anzugeben, also z.B. Anzahl Arbeitstage, Anzahl der beschdigten Produkte etc. In den Systemeinstellungen sind entsprechende Verrechnungsstze hinterlegt, die dann zur Berechnung eines (Durchschnitts-) Schadens herangezogen werden. Diese Verrechnungsstze sind natrlich organisationsspezisch verschieden.
Seite 42
Pege der Verrechnungsstze 1 Hat man diese Bestandsaufnahme der relevanten Risiken eines Unternehmens einmal vorgenommen, hat man eine erste Grundlage, um auf Basis dieser Risikoeinschtzungen weiterzuarbeiten.
Seite 43

7.6 RISIKOADRESSIERUNG/GEGENMASSNAHMEN
Risikogegenmanahmen sollen entweder die Eintrittswahrscheinlichkeit eines Risikos minimieren oder aber fr den Fall eines Risikoeintritts den tatschlich eintretenden Schaden minimieren. Auerdem dienen sie zur Dokumentation bestimmter Antwortstrategien auf erkannte Risiken, die in einigen Fllen einfach auch nur die wissende Akzeptanz des Risikos sein kann. Im Allgemeinen kann man zwischen prventiven und mitigierenden (recovery) Manahmen unterscheiden. Es ist mglich, Risikogegenmanahmen lokal oder unternehmensweit zu klassizieren. Bestimmte Risikogegenmanahmen, die mehr als ein Risiko mitigieren, knnen in einem zentralen Katalog abgelegt werden und stehen damit fr andere Risikomanager zur Mitigation zur Verfgung, damit kann man Redundanzen und Doppelpege vermeiden. Da SAP BO Risik Management auch Funktionalitten eines Richtlinienmanagements enthlt, kann man auch Policies, Arbeitsanweisungen etc. als Risikogegenmanahme hinterlegen. Wie spter erlutert, knnen im Falle einer gemeinsamen Verwendung von Risikomanagement und internem Kontrollsystem auch Kontrollen des IKS als Risikogegenmanahme hinterlegt werden. Tipp: Risikogegenmanahmen sind entweder lokal im Risikomanagement angelegt, vorhandene Kontrollen aus dem internen Kontrollsystem (sofern implementiert) oder Policies aus dem Richtlinienmanagement. Risikogegenmanahmen sind nicht von Anfang an als vollstndig implementiert und wirksam zu betrachten (abhngig von den Einstellungen im Analyseprol). Die Software untersttzt einen eigenen Lebenszyklus der Risikogegenmanahme mit Zuordnung von verantwortlichen Personen. Diese knnen dann regelmig und wenn gewnscht auch mittels Workow-Trigger Bericht erstatten ber den Implementierungsstand und die Wirksamkeit der Kontrollen etc. Entsprechende Berichte zum Reporting stehen zur Verfgung, sodass es mglich ist, einen aktuellen Status ber alle im Unternehmen vorhandenen Gegenmanahmen zu erhalten. Tipp: Die Software gestattet also nicht nur alle Gegenmanahmen als bereits implementiert und vollstndig wirksam zu betrachten, sondern ermglicht ein effektives Management der Risikogegenmanahmen ber ihre Lebensdauer hinweg. Man kann im Rahmen einer Risikoanalyse den Einuss jeder Gegenmanahme auf das zu mitigierende Risiko bzw. auf dessen Schadenskategorien schtzen. Nicht alle Unternehmen folgen jedoch diesem Ansatz. Einige verwenden auch eine Philosophie, bei der prinzipiell nur Nettobetrachtungen durchgefhrt werden, d.h., man interessiert sich nur fr das verbleibende Restrisiko, nachdem alle Gegenmanahmen implementiert und effektiv sind. Ein Hauptvorteil der Brutto-Netto-Betrachtungen ist die Mglichkeit des aktiven Managements von Risikomitigationen. nderungen in der Effektivitt von Kontrollen werden automatisch auf die Netto-Risikoanalyse angewendet, sodass man unabhngig von laufenden Mitigations-Update-Zyklen immer einen aktuellen Datenbestand vorndet, vor allem in integrierten Szenarien mit dem IKS.
Seite 44
7.7 REPORTING
Zu jeder Lsung gehren auch Funktionalitten fr das geordnete Berichtswesen. Hierzu bietet SAP BO Risk Management einen kompletten Satz vordenierter Berichte, der das Risikoprol des Unternehmens unter unterschiedlichen Gesichtspunkten analysiert. Diese Berichte umfassen nicht nur den berblick ber die Liste aller Risiken, sondern auch Berechtigungsanalysen, Log-Reports sowie Druckberichte und Dashboards. Weiterhin kann man mittels des optionalen Business Warehouse Contents alle dort bekannten Mglichkeiten ausnutzen, den Zielgruppen mageschneiderte Berichte zukommen zu lassen.
7.8 MONITORING
Ein wesentlicher Bestandteil eines funktionierenden Risikomanagement-Systems ist dessen Nachhaltigkeit; Risiken mssen permanent berwacht und beobachtet werden, sofern ihre Natur nicht singulr ist. Risiken knnen aus der berwachung genommen werden, wenn das risikotragende Objekt nicht mehr im Fokus steht, bspw. eine Firmenbernahme abgeschlossen wurde oder ein Kredit vollstndig bezahlt wurde. Eine grere Menge Risiken wird jedoch ber einen lngeren Zeitraum relevant sein und somit einer berwachung und periodischen Neubewertung bedrfen. Risiken sind von Natur aus nicht statisch, ndert sich das Umfeld, knnen sich auch Eintrittswahrscheinlichkeit und/oder potenzieller Schaden eines Risikos ndern. Beispielsweise ndert sich die Eintrittswahrscheinlichkeit eines Totalverlustes eines Gebudes durch Feuer, nachdem eine Sprinkleranlage eingebaut wurde. SAP BO Risk Management stellt die entsprechenden Tools und Methoden zur permanenten berwachung des Risikozustandes eines Unternehmens bereit. Dazu zhlen Workow- und Surveytechniken, die zu einer periodischen (Neu-)Bewertung von Risiken auffordert und entsprechende Prozesskontrolle fr die Wirksamkeit eines Risikomanagementsystems darstellen. Auch die Wirksamkeit und Vollstndigkeit der zugeordneten Risikogegenmanahmen kann periodisch durch Workows abgefragt werden, sodass man jederzeit einen aktuellen Stand des verbleibenden Restrisikos erhlt. Weiterhin gibt es fortgeschrittene Verfahren der automatisierten Berechnung des Restrisikos, wenn eine Kopplung mit SAP BO Process Control eingerichtet ist. Ist eine Risikogegenmanahme eine interne Kontrolle, werden deren DesignAssessments und Tests der Effektivitt direkt fr die Berechnung der Wirksamkeit der Gegenmanahme herangezogen, sodass die Berechnung unmittelbar erfolgt. Mit der Verwendung des Richtlinien(Policy)managements als potenzieller Gegenmanahme kann auch aus dem Status der Richtlinie oder Arbeitsanweisung ein automatischer Update der Wirksamkeit der Risikomanahme erfolgen. Gerade diese automatisierten Prozesse ermglichen es, das Monitoring eines Risikomanagementsystems wesentlich zu vereinfachen und von manuellen, zeitaufwendigen Ttigkeiten zu befreien.
Seite 45

Wichtig und als prventive Manahme unerlsslich ist die Beobachtung sog. Frhwarnindikatoren (Key Risk Indicators KRI). Hierbei werden interne und externe Informationen herangezogen, die als Indikatoren dienen und somit ankndigen knnen, ob es eine wesentliche nderung in der Einschtzung des Risikos geben sollte. Diese Informationen knnen entweder manuell oder automatisiert eingesammelt werden. Der Mehrwert liegt in der automatisierten berwachung der angeschlossenen Systeme. ndert sich dort ein Zustand oder liegen neue Informationen vor, kann sofort ein Risiko alarmiert werden und die Aufmerksamkeit der Risikoverantwortlichen wird direkt auf das Ereignis gelenkt. SAP BO Risk Management kann aus einer Vielzahl von berwachten KRI-Korrelationen ableiten und Geschftsregeln verarbeiten, sodass z. B. nur aus der Kombination zweier KRI ein Risikoalarm abgeleitet wird. Tipp: Automatisieren Sie die Frhwarnindikator-berwachung aus den angeschlossenen Business-SuiteSystemen. Auch externe Systeme sind ber Webservices anschliebar. Nach nderungen in den Quellsystemen werden Risikomanager automatisch benachrichtigt und knnen Manahmen einleiten oder intensiv beobachten.
7.9 CHANCENMANAGEMENT
Risiken werden im Allgemeinen als negative Abweichung von einem Zielwert deniert, aber es gibt auch positive Abweichungen von einem Zielwert, quasi eine Zielwertbererfllung. Diese werden als Chancen bezeichnet. Man kann Risiken und Chancen als 2 Seiten der gleichen Medaille betrachten. Damit ergibt sich fr die Risikomanager die Mglichkeit, nicht nur die negativen Seiten des Business darzustellen, sondern fr bestimmte Geschftsentscheidungen ein holistisches Bild aufzuzeigen und somit eine echte Entscheidungsuntersttzung fr das Management anzubieten. Chancen knnen genauso bewertet werden wie Risiken, nur dass die Abweichung hier werterhhend wirkt. Es gibt auch entsprechende Manahmen, die die positiven Effekte nochmals verstrken knnen, sodass eine komplette Dualitt zum Risiko gegeben ist.
Seite 46
Chancen als Dualitt zum Risiko 1
7.10 INCIDENT MANAGEMENT

SAP BO Risk Management enthlt ein integriertes Management fr eingetretene Risiken, sog. Schden /Incidents. Tritt ein Risiko ein, wandelt sich also von einer hypothetischen Annahme in ein reales Ereignis, wird das Ereignis im System dokumentiert, die eingetretenen realen Verluste werden im System erfasst und klassiziert. Dieser Datenbestand kann spter weiter analysiert werden, um die Risikobewertungen mit der Realitt abzugleichen (also wie hoch war die Eintrittswahrscheinlichkeit wirklich in den letzten Jahren und stimmen die Schadensschtzungen mit den letzten eingetretenen Fllen in ihrer Grenordnung berein) sowie die Risikomitigation (ein Kostenfaktor) auf die entscheidenden Stellen (wo die grten Schden auftauchten) zu fokussieren. Selbstverstndlich stehen auch hier systemgesttzte (workowbasierte) Meldeprozesse zur Verfgung, um jedem Mitarbeiter zu ermglichen, eingetretene Schden zu melden. War der Schaden noch mit keinem vorhandenen Risiko zu verknpfen, kann dann auch ein neues Risiko in der zentralen Datenbank zur weiteren berwachung aufgenommen werden, das System adaptiert sich also selbst an die Realitt. Tipp: Nutzen Sie die Datenbank der eingetretenen Schden, um die Risikobewertungen mit der Realitt abzugleichen und so die notwendigen Rckstellungen fr Mitigationskosten/Projekte zu minimieren.
Seite 47
8 Einfhrungsmanagement
Auf Grundlage der etablierten SAP-ASAP-Methodik (Accelerated SAP), die fr ein standardisiertes Vorgehen bei der Einfhrung von SAP-ERP-Lsungen entwickelt wurde, entstanden Zusatzmodule fr die Einfhrung von GRC Risk Management. Gem der SAP-ASAP-Methodik und der jeweiligen GRC-Add-Ons (diese sind auf dem SAP Service Marketplace verfgbar (http://service.sap.com/roadmaps ASAP Business Add-Ons / Solution) ergeben sich die nachfolgenden Projektphasen.
8.1 PROJEKTVORBEREITUNG (STRATEGIE & PLANUNG)

> Organisation: In dieser Phase entsteht die Projektorganisation, es werden das Team, die Verantwortlichkeiten und die Berichtswege festgelegt. Idealerweise entsteht eine Projektcharta, die dem Team durch das Management bzw. die Stakeholder kommuniziert wird. Diese deniert u.a. die Grundstze und Ziele des Projekts (SMART: Specic, measurable, achievable, relevant, time-bound), die Einordnung des Projekts in das Business sowie Prozesse zur Entscheidungsndung. Bedeutsam bei GRC-Projekten ist zudem die frhzeitige und umfassende Integration der Fachbereiche und eine projektinterne und -externe Kommunikationsstrategie. > Projektplan: Wie in jedem SAP-Einfhrungsprojekt muss frhzeitig ein soweit als mglich detaillierter Projektplan erstellt werden. Der Projektplan ist regelmig zu berarbeiten und an neue Gegebenheiten anzupassen. Gerade bei einem Pilotansatz werden zu diesem Zeitpunkt nicht alle Anforderungen abschlieend identiziert und beschrieben sein. Hier kommt es auf ein konsequentes Anforderungsmanagement an, da neu aufgenommene Funktionalitt in der Regel zu weiteren Aufwnden fhren und sich somit ggf. Termine verschieben. > Kick-off: Mit dem Projektteam sollte ein initiales Meeting durchgefhrt werden, bei dem nochmals die Projektziele, die Charta und der Projektplan vorgestellt werden. Insbesondere bei gemischten Projektteams, bestehend aus Mitarbeitern der IT und der Fachseite, ist es wichtig, eine gemeinsame Sicht auf das Projekt entstehen zu lassen. > Training: Es ist sinnvoll, dass das Projektteam von Beginn an ein gutes Verstndnis bzgl. der Funktionalitten und der Arbeitsweise der neuen Software erhlt. Dieses Wissen untersttzt ungemein im Rahmen der Anforderungsanalyse und bei der Erstellung des Blueprints.
8.2 SOLLKONZEPT (BUSINESS BLUEPRINT UND DESIGN)

> Anforderungsanalyse: Im Rahmen dieser Phase werden, bspw. im Rahmen von Workshops, sowohl die geschftsseitigen als auch die technischen Anforderungen ermittelt und dokumentiert. > Sollkonzeption: Der Blueprint besteht aus einer Reihe von Dokumenten, die beschreiben, wie die relevanten Geschftsprozesse mit Hilfe der Software abzubilden sind. Bestandteile des Blueprint sind neben dem Lastenheft die technische Architektur und die Feinspezikation, die als Basis fr die Implementierung und Konguration dienen. Auf Basis des Blueprint entstehen die Arbeitspakete fr die Realisierung, die Testplne und das Change Management. Zudem dient der Blueprint als Grundlage fr die Aufstellung und Detaillierung des Projektplans. > Systemarchitektur: Fr SAP-Systeme sollte ein Architekturkonzept in Abhngigkeit der gewnschten oder vorgeschriebenen Systemarchitektur, z.B. einer Drei-Systemlandschaft mit Entwicklungs-, Qualittssicherungs- und Produktionssystem deniert werden. In dem Zusammenhang sind auch die notwendigen Change-Management-Prozesse fr technische und organisatorische nderungen zu erstellen.
Seite 48
8.3 WEITERE PROJEKTPHASEN (IMPLEMENTIERUNG, ROLL-OUT, GO-LIVE)

> Realisierung (Implementierung): Gegenstand der Realisierungsphase ist die eigentliche Installation und Konguration der Risk-Management- und /oder Process-Control-Lsung gem den Vorgaben des Blueprint. Zudem erfolgen die Durchfhrung der Tests und die Abnahme durch das Business. Weiterhin werden Schulungsunterlagen und die Endbenutzer-Dokumentation erstellt. > Produktionsvorbereitung (Roll-out):Im Rahmen des Roll-out erfolgt die Vorbereitung des Systems und der Anwender auf die produktive Nutzung. Am Ende dieser Phase erfolgt die Entscheidung ber den Go-Live. > Produktivstart (Go-Live und Support): Mit der Produktivsetzung geht die Verantwortung ber auf die Fachseite. Das Projekt untersttzt Anwender und Betrieb, bis die fachlichen Organisationseinheiten (etwa der Help Desk) diese Aufgabe bernommen haben und der Betrieb stabilisiert ist. Prozesse zur berwachung der Prozessperformance und der produktiven System-Umgebung werden etabliert. Das Projekt schliet mit einem Projekt-Review und der Dokumentation von lessions learned.
8.4 EINFHRUNG EINES ZENTRALEN INTEGRIERTEN RISK-MANAGEMENT-UND PROCESS-CONTROL-SYSTEMS

Wie bereits an anderer Stelle ausgefhrt, nutzen sowohl Risk Management als auch Process Control Funktionalitten der jeweils anderen Lsung. Zwar knnen sowohl Risk Management als auch Process Control und Access Control separat installiert und betrieben werden, die Architektur der Software ist in der aktuellen Version 10 jedoch bereits so weit integriert, dass nur eine integrierte Nutzung von SAP GRC alle Vorteile der Einzellsungen gewhrleisten, wie hier am Beispiel eines Betrugsszenarios dargestellt ist:
Enterprise Risk Management
Enterprise Risk: Fraud Responses
Accept
Avoid
Transfer
Control
Reduce
Coompliance Management
Regulations Process
Procure to Pay Vendor Mgmt AP Invoicing
Process Risks
Fraudulent invoices paid Valid invoices not entered
Controls
Review of new vendors and related invoice support Review of uninvoiced good receipts AP SOD rules in CCM
Policies
Update and roll out new security policy
Access Management (CCM-SOD)
Access Risks
User can enter vendor and PO User can enter invoices & payments
Mitigate Access Violations Monitor Access Status
Betrugsszenario
Seite 49
8 Einfhrungsmanagement
Im Rahmen einer integrierten Installation bietet SAP GRC die Mglichkeit, vertikale Szenarien abzubilden: vom Management eines Betrugsrisikos (Risk Management) ber die Zuordnung entsprechender Kontrollen in Compliance-Initiativen (Process Control) bis hin zur Vermeidung IT-seitiger Zugriffsgefahren (Access Control).
8.5 EINFHRUNGSVARIANTEN (SCHRITTWEISE VERSUS Big Bang)

Die Einfhrung von Risk Management ermglicht die Etablierung unternehmensweit einheitlicher Prozesse durch die Nutzung einer zentralen Software-Lsung. In der Regel werden in diesem Zuge bestehende Prozesse optimiert und bis dahin verwendete Werkzeuge ersetzt. Die Einfhrung und damit die Ablsung bestehender Prozesse und Werkzeuge kann fr eine Organisation schrittweise oder ber einen Big Bang erfolgen. In beiden Fllen sollte eine entsprechende Vorbereitung der Strategie-, Design- und Implementierungsphase mittels eines Piloten erfolgen. In jedem Fall ist vor einer Implementierung ein Blueprint zu erstellen, der u.a. die zu implementierenden Prozesse, Datenstrukturen, Analysemethoden, Workows, Berichtsstrukturen und das Berechtigungskonzept deniert. Der nale Blueprint liefert die Vorlage fr eine unternehmensweite Implementierung. Der Blueprint speziziert auch die Vorgaben fr die Pilotierung. Ggf. ist der Blueprint auf Grund von im Piloten gewonnenen Erkenntnissen fortzuentwickeln oder anzupassen. Idealerweise ist der Pilot hinsichtlich den abgebildeten Strukturen und Prozessen fr das Risiko- und Kontrollmanagement soweit als mglich reprsentativ fr das Unternehmen, um Referenzwerte fr weitere Einfhrungsphasen zu liefern. Auf Grund der Relevanz dieser Systeme fr das Unternehmen kann, in Abhngigkeit der spezischen Gegebenheiten, fr die Einfhrung von Risk Management oder Process Control durchaus ein Phasen-orientiertes Modell in Betracht gezogen werden. Weiterhin sind Abhngigkeiten des Pilotbereichs mit anderen Bereichen zu prfen und zu bercksichtigen: Gibt es bspw. Abhngigkeiten von Risiken des Pilotbereichs mit denen andere Unternehmensteile, so ist dies im Rahmen von Simulationen bzw. dem Berichtswesen zu bercksichtigen. Zur Sammlung von Erfahrungswerten im Umgang mit der neuen Lsung und zum Abgleich der Risikobzw. Kontrollinformationen kann es sinnvoll sein, den Piloten eine gewisse Zeit, bspw. ein bis zwei Quartale, vor dem Periodenabschluss quasi-produktiv zu setzen und parallel zu den bisherigen Prozessen und Werkzeugen zu betreiben. Dem hierdurch entstehenden Mehraufwand stehen die Eingewhnung der Endanwender, deren Akzeptanz sowie die Verikation der Prozesse und Informationen gegenber. Der so hinsichtlich seiner Prozesse und Funktionalitten validierte Pilot wird im Fall eines Phasen-orientierten Ansatzes gem der Unternehmensvorgaben in den Regelbetrieb berfhrt und im Rahmen von weiteren Projektabschnitten auf weitere Unternehmensbereiche bertragen.
Seite 50
8.6 WEITERFHRENDE INFORMATIONEN

Zum Thema Einfhrungsmanagement bietet SAP ber den Service-Marktplatz bzw. die verschiedenen Communities eine groe Zahl von weiterfhrenden Dokumenten: > > > > > > WebEx Prsentation ASAP Add-On GRC: https://sap.emea.pgiconnect.com/p44496796/ ASAP Methodik (Service-Marktplatz): http://service.sap.com/asap ASAP Business-Add-Ons (Service-Marktplatz): http://service.sap.com/asap-business-add-ons PBX Community - Einstiegsseite ASAP Roadmap: http://www.sdn.sap.com/irj/bpx/asap PBX Community - Einstiegsseite GRC: http://www.sdn.sap.com/irj/bpx/grc Installations- und Sicherheitsleitfaden (Service-Marktplatz): http://service.sap.com/instguides > SAP Business-Objects > SAP Business-Objects Governance, Risk, and Compliance (GRC) > Risk Management
Seite 51
9 Phase Sollkonzeption (Business Blueprint und Design)

In dieser Phase werden die unternehmerischen Strategien fr das Risikomanagement und das interne Kontrollsystem in eine konkrete Vorlage fr die sich daran anschlieende Implementierung der Software berfhrt. Werden sowohl Risk Management als auch Process Control eingefhrt, so kann dies in weiten Teilen unabhngig und parallel erfolgen. Entscheidend fr den Grad der Unabhngigkeit ist das gewhlte Szenario: Fllt die Entscheidung zu Gunsten eines integrierten Managementsystems fr Risiken und interne Kontrollen, so arbeiten Risk Management und Process Control in einigen Bereichen auf gemeinsam genutzten Stamm- und Bewegungsdaten. Abstimmungen, etwa bei der Denition der Stammdaten fr die GRC-Organisation, sind im Rahmen der Erstellung des Blueprints und in den Folgephasen des Projekts erforderlich.
9.1 RISK MANAGEMENT

Im Rahmen einer Anforderungsanalyse gilt es, die strategischen Vorgaben herunterzubrechen auf die Ebene der Geschftsprozesse und der Anwendungsflle und herauszuarbeiten, wie diese durch Risk Management und ggf. Process Control efzient, umfassend und nachhaltig umgesetzt werden knnen.
9.1.1 PROJEKT SCOPING & SWOT ANALYSE

Abhngig von Gre, Struktur und Politik des Unternehmens existieren verschiedene Anstze, um den Umfang eines Projektes zu bestimmen. Bei dezentralen Strukturen kann es ein Ansatz sein, einen Geschftsbereich als Piloten zu identizieren. Typisch bspw. fr Holdingumgebungen ist jedoch, dass die Prozesse in den einzelnen Gesellschaften inhomogen sind und teils unterschiedliche Reifegrade aufweisen. Es muss daher Bercksichtigung nden, ob der Pilot reprsentativ fr die anderen Bereiche und als Vorlage wiederverwendbar ist. Fr den zu betrachtenden Bereich ist nun eine Inventur der bestehenden Prozesse und Werkzeuge fr Risikomanagement durchzufhren, damit diese klassiziert und analysiert werden. Ziel dieses Projektschrittes ist es, alten Wein in neuen Schluchen zu vermeiden. Der Einsatz von SAP GRC ermglicht in vielen Fllen ein Re-Design der Prozesse hin zu mehr Transparenz und Efzienz und die berfhrung technologischer Insellsungen hin zu einer einheitlichen Plattform.
Seite 52
SWOT-Analyse des Risikomanagementprozess Je nach Art, Umfang und Homogenitt von Prozessen und Werkzeugen kann auf dieser Basis entschieden werden, ob das anstehende Einfhrungsprojekt von GRC Risk Management phasenorientiert oder als Big Bang erfolgt.
9.1.2 PLANUNG
Bevor ein Blueprint erstellt werden kann, ist es notwendig, im Rahmen der Anforderungsanalyse die verschiedenen Aspekte der Prozesse fr Risikomanagement im Unternehmen zu betrachten, zu analysieren, ggf. grundlegende Annahmen zu treffen und diese abzustimmen. > Organisationsstruktur: Speziell die Struktur der Organisationshierarchie ist wichtig, denn sie deniert neben den teilnehmenden Einheiten und deren Rollen im Prozess z.B. auch die Berechtigungen innerhalb der Applikation. In SAP GRC Risik Management knnen alle organisatorischen nderungen leicht nachvollzogen werden, denn sie sind zeitlich abgegrenzt und knnen leicht gendert werden. > Risikokategorien: Bei der Risikokategorisierung handelt es sich um einen Systematisierungsvorgang, der Risiken anhand vordenierter Kriterien katalogisiert: konomische Risiken, Marktrisiken, Risiken der Geschftsstrategie, personalwirtschaftliche Risiken, Organisations- und Governance-Risiken,
Seite 53
Phase Sollkonzeption: (Business Blueprint und Design)
Kommunikations- und Informationsrisiken, Finanzrisiken, Projektrisiken, Produktrisiken und sonstige Betriebsrisiken. > Risikoschema: Es sind Klassizierungen hinsichtlich der Bewertung und Einteilung von Risiken zu entwickeln. Hierzu zhlt neben der Einteilung von Risikostufen, deren Grenzwerten auch die Klassizierung der Eintrittswahrscheinlichkeiten oder die Denition von Schadenskategorien. > Analysearten: Welche Analyseverfahren werden im Unternehmen angewendet (z.B. qualitative, quantitative oder gemischte Analysen)? Welche Management-Methodologie soll untersttzt werden? > Berichtswesen: Welche Auswertewege sind gefordert und in welcher Frequenz bzw. Layout sind diese zu erstellen? Welche Klassikation und Meldestufen werden im Unternehmen verwendet? > Risikofreude: Wie hoch ist die Risikotragfhigkeit des Unternehmens, ab wann sind Risiken als bestandsgefhrdend einzustufen? > Integration des IKS: Ist eine Integration mit dem internen Kontrollsystem gewnscht, bspw. um interne Kontrollen als Gegenmanahmen fr Risiken zu hinterlegen? > Key-Risk-Indikatoren, KRI: Frhwarnindikatoren deuten auf ein mglicherweise eintretendes Risiko hin. KRIs werden i. d. R. automatisiert aus ERP und anderen Systemen bernommen und ausgewertet. Mgliche KRIs sind u.a.: > Der Tagesnanzstatus (SAP ERP Financials) > Der Grad von Servicebereitstellungen (SAP Supply Chain Management) > Die Zahl der Garantieansprche (SAP ERP Operations) > Krankenrate, Fluktuation (SAP ERP Human Capital Management) > Risikomanagement RACI: RACI-Charts bilden Zustndigkeiten und Verantwortlichkeiten im Prozess ab: > R, responsible: Zustndig fr die operative Durchfhrung > A, accountable: Rechenschaftspichtig und verantwortlich im rechtlichen und kaufmnnischen Sinn > C, consulted: Spezialisten, die auf Grund ihrer Expertise eingebunden werden > I, informed: Verteiler fr Informationen
Risk Manager Planung Identikation Analyse Steuerung berwachung Berichtswesen
Risk Expert
Geschftseinheit
Leiter der Geschftseinheit
C R C R R C
I C R C C
C R R R R I
A I I A I A
Mgliche Verantwortlichkeiten im Risikomanagementprozess

Seite 54
Wesentlich fr die Arbeit mit einem Risiko ist das Verstndnis des sogenannten BowTie-Modells, des grundlegenden Datenmodells fr die Risikoerfassung und Analyse:
BUSINESS STRATEGY
Objectives
BUSINESS PROCESS
Production
KPIs
Optimise production process Customer satisfaction index Safety and environmental protection
DRIVERS
Equipment Maintenance Failure
RISK EVENT
IMPACTS
Unfullled Orders/Service [Customer Satisfaction]
Accident in Facility A (chemicals contamination) Use of untrained Staff
Decreased Income [Revenue]
Cost of Clean Up [Costs]
Preventive responses Key Risk Indicators (KRIs)

1-1) Overdue maintenance 1-2) Training days below target reduce probability of event
Recovery responses
reduce impact of event
Underlying Systems
Response Catalgoue (RM)
Responses
Controls Catalgoue (PC)
Mitigate
Avoid
Transfer
Accept
PC/AC Control
Disaster Recovery Plan
Insurance Cover
Maintenance Schedule On Track
Risiko Bow-Tie Ein Risiko wird klassiziert nach der Entitt, in der es auftritt (z.B. Organisationseinheit, Werk, Lager, Geschftsbereich) sowie einer Klassizierung des Risikos fr sptere Anforderungen im Berichtswesen (z.B. gehrt es in die Gruppe der Marktrisiken oder operationalen Risiken etc.). Jedes Risiko wird weiterhin einer oder mehreren Schadenskategorien zugeordnet sowie einer oder mehreren Treibern und/oder Auswirkungen, die das Risiko potenziell auslsen knnen. Somit ergibt sich in einer graschen Darstellung der sogenannte Bow-Tie (die Fliege). Weiterhin knnen im Rahmen der Risikoidentikation auch Beziehungen zwischen Risiken hinterlegt werden. Diese werden spter zur Erstellung von Risikoszenarien verwendet. Zu den Attributen des Bow-Tie-Schemas gehren u.a.: > Die Risikokategorie zur Einordnung in den unternehmensweiten Risikokatalog > Eine przise Beschreibung und die Zuordnung zu einer Entitt > Risikotreiber (ggf. auch mehrere) beschreiben die Ursachen fr einen eventuellen Eintritt des Risikos. Die Treiber erlauben die Verwendung von Key-Risk-Indikatoren (KRIs) als Eintrittsparameter > Die prozentuale Wahrscheinlichkeit, mit der das Risiko eintritt > Das Schadensausma deniert die quantitativen Auswirkungen > Der Auswirkungsgrad beschreibt die qualitativen Auswirkungen > Gegenmanahmen zur Vermeidung bzw. Minimierung des Risikos
Seite 55
9.1.3 RISIKO-ASSESSMENT
Die Risikoplanung setzt die Rahmenbedingungen fr den Risiko-Assessment-Prozess. Der Planungsprozess erfolgt auf zwei grundstzlichen Ebenen. Die Planung eines unternehmensweiten Risikomanagements inklusive seiner Aufbauorganisation, allgemeinen Prozessdenitionen und Berichtswegen sowie seiner bestndigen Weiterentwicklung etc. Im Rahmen des eigentlichen Risikomanagementprozesses bezieht sich Planung auf die Vorbereitung und Durchfhrung eines Risiko-Assessments, bestehend aus den drei aufeinander aufbauenden Phasen Risikoidentikation, Risikoanalyse und Risikosteuerung. Das Risk Assessment ist methodisch unternehmensweit einheitlich auszuprgen. Je nach Betrachtungsgegenstand wird die Durchfhrung an die speziellen Gegebenheiten adaptiert, insbesondere bzgl. der Risikoidentikation und der Risikoanalyse. Im Rahmen der Planung ist zunchst der Betrachtungshorizont fr das Assessment zu denieren (Scoping). Risk Assessments werden i.d.R. fr sehr verschiedene Entitten durchgefhrt. Entitten oder Aktivitten knnen Entwicklungslabore oder Vertriebsstandorte, einzelne Geschftsprozesse oder ganze Geschftsbereiche, Mrkte, Produkte, Kunden oder Lieferanten sein. Je nach Iteration erfolgt ein initiales Assessment fr die gesamte Entitt bzw. daraus abgeleitete speziellere Assessments fr denierte Teilbereiche. Im Rahmen des Scopings erfolgt zudem die Benennung von Verantwortlichkeiten. Hier wird unter anderem die Verantwortlichkeit fr das Assessment selbst, die Teilnehmer der Workshops fr Risikoidentikation und deren Moderation bestimmt.
9.1.4 RISIKOIDENTIFIKATION
Der Identikationsprozess setzt sich aus einer Reihe von Teilschritten zusammen. > Kick-off-Workshops: Als Rahmen fr das Vorgehen zur Identizierung von Risiken haben sich Workshops bewhrt. Workshops werden insbesondere als Startpunkt fr den Identikationsprozess gewhlt. Neben der Kommunikation von Ziel und Umfang des Assessments wird zudem ein gemeinsames Verstndnis bzgl. der verwendeten Terminologie und des Zeitrahmens Einvernehmen erzielt. Ein wichtiger Aspekt bei der Planung solcher Workshops ist die Auswahl der Teilnehmer. Die Teilnehmer sollten gute Kenntnisse der betrachteten Entitt besitzen und idealerweise direkt involviert sein. Zudem ist die richtige Gruppengre von Bedeutung, insbesondere im Hinblick auf die im Workshop durchzufhrenden Arbeiten, wie etwa ein Brainstorming. > Identikationsmethoden: Wenngleich es keinen allgemeingltigen Ansatz zur Identikation von Risiken geben kann, so hat sich doch eine Reihe von Hilfsmitteln bewhrt. Im Allgemeinen wird unterschieden zwischen Instrumenten der strategischen und operativen Risikoidentikation: > Hilfsmittel im Bereich der operativen Risikoidentikation sind u.a. standardisierte Vorlagen, Checklisten, Fragebgen, Interviews, Selbstbeurteilungen, Workshops, SWOT-Analysen oder Berichte ber Strflle. > Suchmethoden zur Identikation unbekannter Risikopotenziale werden weiter unterschieden in analytische Methoden, wie etwa morphologische Verfahren oder die FMEA-Methodik (Auswirkungsanalyse), und Kreativmethoden wie z.B. Brainstorming, Delphi-Methode oder Szenariotechnik.
Seite 56
9.1.5 RISIKOANALYSE
Das Hauptziel der Analyse ist die Evaluierung der Risikoattribute und die Priorisierung der Risiken. Risiken sollen regelmig hinsichtlich ihrer Ursachen, Treiber und Indikatoren; der Eintrittswahrscheinlichkeit und dem Schadensausma, sowohl in qualitativer als auch in quantitativer Hinsicht; dem geschtzten Zeitraum bis zum Eintritt sowie geeigneter Manahmen zur Risikosteuerung, geprft werden. Weiterhin erfolgen regelmig Reviews der Organisation, bestehender Prozesse und laufender Projekte im Rahmen von Workshops, Interviews und Workow-gesttzten Umfragen und Analysen hinsichtlich der Identikation relevanter korrespondierender KPIs. > Eintrittswahrscheinlichkeit und Eintrittsgeschwindigkeit: Risiko ist als Produkt aus Eintrittswahrscheinlichkeit und dem Schadensma bei Eintritt eines Ereignisses deniert. Die Eintrittswahrscheinlichkeit ist das prozentuale Ma fr die Wahrscheinlichkeit, mit der das Risiko innerhalb einer denierten Zeitperiode eintritt. Weiterhin wird der Eintritt in Bezug auf die Eintrittsgeschwindigkeit qualiziert. Hierfr wird eine fest denierte Skala verwendet, mittels der ein Eintritt auf der Zeitachse qualiziert werden kann. Diese wird verwendet, um die Implementierung von Gegenmanahmen zu priorisieren. > Schadensma: Je nach Eigenschaft eines Risikos erfolgt eine Qualizierung oder Quantizierung des Risikos hinsichtlich seines Schadens(aus)maes. Die quantitative Abschtzung des Bruttoverlusts, also des zu erwartenden Schadens bei Eintritt des Risikos ohne Implementierung von Gegenmanahmen, kann unter Verwendung der Drei-Punkt-Analyse erfolgen, in der Literatur auch als Drei-Werte-Verfahren bezeichnet. Fr die Drei-Punkt-Analyse werden drei verschiedene Szenarien herangezogen: Bester Fall, schlechtester Fall und der wahrscheinlichste Fall der Hhe des Bruttoverlusts. In die weitere Berechnung iet dann der gewichtete Durchschnitt dieser drei Werte ein, wobei die Gewichtung des wahrscheinlichsten Falls hher ist als die der beiden Extremwerte. Fr die Drei-Punkt-Analyse sprechen ihre einfache Handhabung und die groe Akzeptanz bei den Anwendern. Sie verlangt keinerlei statistische Vorkenntnisse und ist schnell durchzufhren. Allerdings erfolgt hierbei die Betrachtung eines Risikos eher aus der historischen Perspektive. Risiko-Experten ermitteln die drei Szenarien auf Grund von Erfahrungswerten und nicht ber Prognosemodelle. > Risikotreiber und Risikoindikatoren: Risikotreiber indizieren, welche Prozesse oder Gegebenheiten ein Risiko auslsen knnen. Typische Risikotreiber in Entwicklungsprozessen sind ungengend spezizierte Lasten- und Pichtenhefte oder neue Technologien. > Abhngigkeiten zwischen Risiken: Risiken wirken selten isoliert, oftmals strahlen sie auf andere Risiken ab. Die Modellierung dieser Abhngigkeiten ist notwendig, um spter komplexe Risikoszenarien simulieren zu knnen. > Aggregation und Simulation: Zur Bestimmung der Gesamtrisikoposition eines Unternehmens sind die Einzelrisiken zu aggregieren. Dies kann mittels einer Simulation auf Basis des Monte-Carlo-Modells erfolgen. Bei diesem stochastischen Verfahren werden unter Anwendung der Wahrscheinlichkeitstheorie die Wirkungen aller Einzelrisiken mit ihren jeweiligen Abhngigkeiten betrachtet.
Seite 57
9.1.6 STEUERUNG
Nachdem ein Risiko identiziert und analysiert wurde, ist zu entscheiden, wie mit dem Risiko umzugehen ist. Manahmen Die sich dabei stellenden Fragen sind: Welche Risikogegenmanahmen gibt es? Welche dieser Manahmen knnen und sollten implementiert werden? Wer ist verantwortlich fr die Umsetzung dieser Manahmen? Dabei werden fr die Entwicklung einer Risikogegenmanahme zwei grundstzliche Anstze unterschieden: Existieren Manahmen, die den Eintritt des Risikos prventiv verhindern? Und welche Manahmen gibt es, die die Auswirkungen eines Risikos reduzieren bzw. seine Eintrittswahrscheinlichkeit vermindern? Einem Risiko knnen mehrere Gegenmanahmen zugeordnet werden, u.a. auch Kontrollen aus dem internen Kontrollsystem. Es existiert eine Reihe von Vorgehensweisen fr die Implementierung einer Gegenmanahme. Ursachenbezogene Manahmen sind: > Vermeiden des Risikos: Der Geschftsprozess, der das Risiko birgt, wird nicht weiter verfolgt. Diese Manahme ist nicht immer umsetzbar, dies liegt in der Natur eines Unternehmens. Wenn mglich sollte der betroffene Prozess um- oder neugestaltet werden > Reduzieren des Risikos: Reduzieren des Risikos durch Minimierung der Eintrittswahrscheinlichkeit oder des Schadensausmaes > Teilen des Risikos: Intern knnen Risiken ganz oder teilweise an andere Geschftseinheiten bertragen werden, das Einverstndnis der aufnehmenden Geschftseinheit vorausgesetzt Zu den wirkungsbezogenen Manahmen zhlen: > Akzeptieren des Risikos: Das Risiko wird akzeptiert. Weitere Manahmen zur Vermeidung oder Minimierung von Eintrittswahrscheinlichkeit und Schadensausma werden nicht gettigt. Das Risiko wird intensiv hinsichtlich kritischer Vernderungen bei Eintrittswahrscheinlichkeit, Schadenswirkung oder Zeithorizont berwacht > bertragen des Risikos: Ein Teil oder auch das gesamte Risiko kann in Form einer Versicherung nach extern bertragen werden Fr jede Gegenmanahme werden die mit einer Implementierung verbundenen Kosten ausgewiesen. Die Implementierung einer Gegenmanahme ist nicht sinnvoll, wenn die Kosten fr die Implementierung den erwarteten Schaden bersteigen. Das Ergebnis eines Risiko-Assessments ist ein fr die betrachtete Entitt vollstndiges Risikoregister.
9.1.7 MONITORING & REPORTING

Die berwachung der Risiken und der implementierten Manahmen ist ein mageblicher Teil des Risikomanagementprozesses, sie beinhaltet das Nachverfolgen der Risiken und die Prfung der Effektivitt der Gegenmanahmen. Die berwachungsttigkeit ist eine stndige Aufgabe, die sicherstellt, dass alle Aktivitten des Reaktionsplans fr identizierte Risiken abgearbeitet und neue Risiken identiziert werden. Dazu gehrt:
Seite 58
> Stndiges Sammeln von Informationen ber die zu berwachenden Risiken hinsichtlich Eintrittswahrscheinlichkeit, Auswirkungen und Zeithorizont > Die berwachung von Risikoindikatoren > Das Erstellen von Risikoberichten > Die berwachung der Implementierung von Gegenmanahmen und deren Effektivitt > Die Prfung, ob Risiken zu eskalieren sind > Die Prfung der Risikomanagementaktivitten der Geschftseinheiten hinsichtlich der bereinstimmung mit der Risikomanagementrichtlinie
9.2 BERECHTIGUNGSKONZEPT RISK MANAGEMENT/PROCESS CONTROL

Auf die Komponenten der SAP BusinessObjects GRC Solutions kann seit der Version 10.0 wahlweise direkt ber den SAP NetWeaver Business Client oder mittels der Integration in das unternehmensweit genutzte SAP NetWeaver Portal zugegriffen werden. Die Integration in das Unternehmensportal stellt bei den meisten Kunden den Standardweg dar und wird daher als erstes beschrieben. Der direkte Zugriff mittels des NetWeaver Business Client wird am Ende dieses Kapitels vorgestellt. SAP BusinessObjects Process Control und Risk Management nutzen ein dreistuges Berechtigungskonzept, bestehend aus ABAP-GRC-Basisrollen, ABAP-GRC-Anwendungsrollen und Portalrollen. Die ABAP-Rollen, welche mit Hilfe des Prolgenerators beliebig an die Wnsche des Kunden angepasst werden knnen, erlauben den Zugriff auf das eigentliche Datenmodell wie Kontrollen, Risiken, Organisationseinheiten. Die Strukturierung und Anordnung der einzelnen Elemente innerhalb der fr den Endbenutzer relevanten Webansicht erfolgt durch die Portalrolle. Die nachfolgende Tabelle zeigt diesen Zusammenhang im Detail:
Seitenelemente Navigation Menu Work Set Work Center Menu Group Menu Item
Zugriff erfolgt mittels Rollentyp Portalrolle Portalrolle Portalrolle Anwendungsrolle Anwendungsrolle
Innerhalb der Weboberche erhlt der Endbenutzer abhngig von seiner Rolle innerhalb der Risikomanagement-Organisation Zugriff auf die bentigten Informationen. Der folgende Bildschirmabgriff stellt die verschiedenen Seitenelemente am Beispiel von SAP BO GRC Risk Management 10.0 dar.
Seite 59
Flexibel anpassbare Navigationsstruktur Die nachfolgende Abbildung zeigt im Gegensatz dazu die in das SAP NetWeaver Portal integrierte SAP BO GRC Suite 10.0, welche nicht mehr strikt nach den Komponenten Risk Management, Process Control und Access Control trennt und das Thema GRC ganzheitlich unter Nutzung eines harmonisierten Stammdatenmodells umsetzt. Auch hier lassen sich bei Bedarf die einzelnen Work Sets, Menu Groups und Menu Items entsprechend den Anforderungen der Kunden anpassen.
Integrierte GRC-Sicht mit Process Control

Seite 60
Fr eine weitere feingranulare Aussteuerung der Berechtigung innerhalb der Risk-Management-/ Compliance-Management-Organisation erfolgt eine Zuweisung von Benutzern zu sogenannten Entitten, wie beispielsweise Prozesse, Bereiche, Kontrollen, ber die GRC-Endbenutzeransicht im Portal. Die fr die Anwendung relevanten Entitten sind hierarchisch angeordnet. Somit ergibt eine Zuweisung der Anwendungsrolle zu einem Benutzer auf hoher Entittsebene auch den Zugriff auf alle darunterliegenden Bereiche. ber diesen Ansatz knnen bspw. verschiedene Prozessverantwortliche fr die Debitorenbuchhaltung, die Kreditorenbuchhaltung sowie den bergeordneten Finanzbereich festgelegt werden.
9.2.1 ABAP-BASISROLLEN
SAP BusinessObjects Process Control /Risk Management wird mit den folgenden ABAP-Standardrollen ausgeliefert:
Rollenname
SAP_GRC_FN_BASE SAP_GRC_FN_BUSINESS_USER
Beschreibung
Diese Basis-Backend-Rolle fr Process Control wird von jedem Benutzer von SAP GRC bentigt. Diese Rolle erhlt jeder Endbenutzer. Sie bildet die Voraussetzung fr die Zuweisung von Entitten zu Usern ber das Portal. Rolle erlaubt lesenden Zugriff auf alle Entitten ohne separate Zuweisung im Portal und kann fr Auditoren genutzt werden. Power-User-Rolle ermglicht vollen Zugriff auf alle Entitten ohne separate Zuweisung im Portal. Erlaubt die Anpassung (Customizing) der Applikation mittels der Transaktion SPRO im Backend. Ermglicht die Einplanung von BackgroundJobs.
SAP_GRC_FN_DISPLAY
SAP_GRC_FN_ALL
SAP_GRC_FN_CUSTOMIZING
SAP_GRC_SPC_SCHEDULER
Der Standard-Endbenutzer erhlt somit die Rollen SAP_GRC_FN_BASE und SAP_GRC_FN_BUSINESS_ USER. Fr die genaue Festlegung der Verantwortlichkeiten innerhalb der Applikation werden im nchsten Schritt die ABAP-Entittsrollen genutzt.
Seite 61
9.2.2 ABAP-ENTITTSROLLEN
Diese Rollen dienen der Entitten-basierten Zuweisung von Berechtigungen abhngig von dem jeweiligen Verantwortungsbereich des Endbenutzers innerhalb der Compliance- bzw. Risikomanagement-Organisation. Eine Denition erfolgt im Customizing mittels der Transaktion SPRO ber den Pfad: > SAP Customizing Einfhrungsleitfaden Governance, Risk and Compliance lungen Berechtigungen Entittsrollenzuordnung bearbeiten Allgemeine Einstel-
Innerhalb dieser Customizingtabelle knnen jeder Entitt SAP-ABAP-Rollen zugewiesen werden, welche die Zugriffsrechte im Detail festlegen. Die SAP-Standardrollen mit dem Prx SAP_GRC_SPC sind fr die Process-Control-Anwendung relevant, whrend sich der Prx SAP_GRC_RM auf Verantwortlichkeiten innerhalb der Risk Management Anwendung bezieht. Die genauen Zusammenhnge werden am Beispiel einer mglichen Risikoorganisation bestehend aus einem zentralen, unternehmensweiten Risikomanager, lokalen Risikomanagern sowie Risikoverantwortlichen im Folgenden nher erlutert: Im angegebenen Beispiel gibt es fr die Entitt CORPORATE und daher auf Unternehmensebene einen zentralen Risikomanager mit der Rolle SAP_GRC_RM_API_CENTRAL_RM. Des Weiteren knnen pro Organisationseinheit eigene lokale Risikomanager mit der Rolle SAP_GRC_RM_API_RM zugewiesen werden. Fr die Entitt des Risikos, welches mehrfach innerhalb verschiedener Organisationseinheiten verwendet werden kann, soll ein Risikoverantwortlicher zugewiesen werden. Daher wird hier eine neue Rolle deniert SAP_GRC_RM_API_RISK_OWNER. Da hier das Kennzeichen Unique gesetzt wurde, ist nur die Zuweisung eines einzigen Risikoverantwortlichen pro Risiko mglich. Die Tabelle sollte entsprechend der Risikomanagementorganisation bzw. der Compliance-Management-Organisation des Kunden gepegt werden.
Zuordnung von SAP-Berechtigungsrollen zu Entitten

Seite 62
Sollten Anpassungen an den Standardrollen notwendig sein, empehlt sich die Erstellung einer Kopie im Kundennamensraum sowie die Ersetzung des SAP-Standardrollennamens durch die kopierte Rolle in der beschrieben Customizingtabelle fr die Entittsrollenzuordnung. Das zentrale Berechtigungsobjekt fr die Aussteuerung der Entittsrollen lautet GRFN_API.
Ausprgung der Rolle eines Risikomanagers mit Berechtigungsobjekten und -werten Die Rolle SAP_GRC_RM_API_RISK_OWNER, wie sie im Bildschirmabgriff dargestellt wird, berechtigt zum lesenden Zugriff auf Aktivitten, Kontrollen, Risiken und KRI-Implementierungen. Zustzlich knnen Risikomanahmen bezogen auf die Risiken seines Verantwortungsbereichs vom Risikoverantwortlichen angelegt, angezeigt und gelscht werden. Im Gegensatz dazu knnen im angegebenen Beispiel Risikovorflle (engl. Incidents) angelegt, gendert und angezeigt werden. Ein Lschen ist hier aufgrund der fehlenden Aktivitt 06 nicht mglich. Nachdem die Rollen kopiert, gem den eigenen Anforderungen im Prolgenerator angepasst und im Customizing den Berechtigungsaktivitten zugewiesen worden sind, erfolgt die Zuweisung zu Endbenutzern ber die Portaloberche. Hierbei werden grundlegende Zuweisungen auf der Ebene des Gesamtunternehmens sowie der darunterliegenden Organisationseinheiten im Bereich Organisationen gepegt: > Stammdaten Organisationen
Seite 63
Rollenzuordnung ber die Stammdatenpege Alle Anwendungen der GRC Suite greifen auf das gleiche Datenmodell zurck und liefern somit eine einheitliche Sichtweise auf die gesamte Risikomanagementorganisation bzw. Compliance- ManagementOrganisation.
Benutzerzuordnung fr Organisationseinheiten
Seite 64
Durch Auswhlen eines Hierarchieknotens und anschlieendes Bettigen der Schaltche ffnen knnen die Details pro Organisationseinheit gepegt werden. Im Reiter Rollen werden schlielich den denierten Rollen tatschliche Endbenutzer fr diesen Hierarchieknoten zugewiesen. hnlich wie im HR-Modul erfolgt die Zuweisung zeitabhngig. Der angezeigt Rollenname in der Portaloberche entspricht der Kurzbezeichnung der Rolle im ABAP Prolgenerator und wird direkt abgeleitet von der Rollenbeschreibung im ABAP-Backendsystem. Somit lsst sich mittels der frei kongurierbaren Rollenkurzbeschreibungen im Prolgenerator die Ansicht in der Weboberche beliebig an die Organisationsnamen anpassen. Mit Hilfe der Schaltchen Zuordnen, Ersetzen und Entfernen kann der berechtigte Administrator jedem angelegten Benutzer einer Rolle zuweisen.
Denition der Rolle eines internen Auditors innerhalb der Rollenpege
Seite 65
Zuordnung der PFCG-Rolle zu einem GRC-Benutzer
Wichtig: Die ABAP-Entittsrollen werden hierbei nicht dem Benutzerstammsatz hinzugefgt. Es handelt sich ausschlielich um eine logische Zuweisung auf Anwendungsebene. Abhngig von den Einstellungen ber die Entittsrollenzuordnung im Customizing sind neben der Organisationseinheit auch bei den Prozessen, Subprozessen, Risiken und Kontrollen etc. die verantwortlichen Personen zu pegen. Dies erfolgt in der Regel bei der Anlage des entsprechenden Objektes im Reiter Rollen. Zustzlich bietet der Bereich Zugriffsverwaltung die Mglichkeit der Massenpege: > Zugriffsverwaltung GRC-Rollenzuordnung
Einstiegspunkt fr GRC-Rollenzuordnungen Mit Abschluss der initialen Implementierung des Berechtigungskonzeptes, hat jedes Mitglied der Risikomanagement-Organisation nur genau die Zugriffsrechte, welche es zur Erfllung seiner spezischen Aufgaben bentigt. Als weitere Sicherungsmanahme ist es mglich, das Konzept der Second-Level-Berechtigungen im Customizing zu aktivieren. Als Resultat knnen nur noch diejenigen Benutzer einer Entittsrolle zugewiesen werden, welche vorab die korrespondierende ABAP-PFCG-Rolle erhalten haben. Ist diese Voraussetzung nicht erfllt, stehen sie nicht fr eine Auswahl innerhalb der Entittsrollenzuordnung in der Portalansicht von RM/PC zur Verfgung.
Seite 66
9.2.3 SAP NETWEAVER PORTAL ROLES

Wie innerhalb des einleitenden Teils erwhnt, wird der Endbenutzer mittels der zugewiesenen Portalrollen dazu berechtigt, die fr Risk Management/Process Control relevanten Work-Sets im Portal angezeigt zu bekommen. In den meisten Fllen sind die beiden Standardrollen fr Risikomanagement und Process Control ausreichend, da der granulare Zugriff ber die Entittszuweisungen gesteuert wird.
Release
RM 3.0 PC 3.0 RM 10.0 & PC 10.0
Rollenname
GRC Risk Management GRC Process Control com.sap.grc.GRC_Suite
Sinnvoll ist eine Anpassung der Standardrollen, wenn ein Unternehmen innerhalb des Multi Compliance Frameworks viele verschiedene Regularien deniert und hier im Zuge der Benutzerfreundlichkeit die Sicht auf die Menstruktur vereinfachen mchte.
9.2.4 SAP NETWEAVER BUSINESS CLIENT

Der SAP NetWeaver Business Client (NWBC) erlaubt einen einheitlichen Zugriff sowohl auf transaktionsbasierte SAP-GUI als auch Web-Dynpro Anwendungen. Er verwendet im Gegensatz zum SAP-GUI kein proprietres Protokoll, sondern HTTP und tauscht mit dem Server HTML- und XML-Inhalte aus. Unternehmen welche kein SAP NetWeaver Portal im Einsatz haben, knnen daher als Alternative mittels des SAP NetWeaver Business Clients ab der Version 10.0 der GRC-Suite auf SAP GRC Applikationen Risk
Alternativer Benutzerzugriff ber Transaktion NWBC

Seite 67
Management, Process Control und auch Access Control zugreifen. Den einfachsten Weg fr den Zugriff auf ABAP-basierte Systeme bietet der NWBC for HTML, welcher die im ABAP-Backend-Server bereits integrierte Umsetzung von ABAP-Transaktionen in HTML nutzt und durch die Nutzung des Web-Browsers keine weitere Installation von Software auf den Clients erfordert. Die URL lautet https://<Full Qualied Domain Name>:<Port>/nwbc/. Als Voraussetzung ist die ABAP-Backend-Rolle SAP_GRC_NWBC dem Benutzer zuzuweisen. Auch diese Rolle kann durch den Kunden unter Nutzung des Rollenmens an die unternehmensinternen Anforderungen angepasst werden.
Seite 68
10 Phase Realisierung (Implementierung)

10.1 RM STANDALONE
Eine isolierte Einfhrung von Risikomanagement kommt immer dann in Betracht, wenn eine Einfhrung eines internen Kontrollsystems nicht gewnscht ist, derzeit nicht im Scope ist oder auch aus datenschutztechnischen Grnden separiert gehalten werden soll.
10.1.1 GRUNDSTZLICHES AUFSETZEN DES SYSTEMS

Es handelt sich bei SAP BO Risik Management um ein Add-on auf der technischen Plattform NetWeaver von SAP. Hiermit ergibt sich, dass grundstzlich kein ERP-System vorhanden sein muss, um das System in Betrieb zu nehmen. Die IT des implementierenden Unternehmens wird dann ein NetWeaver-System in der Ausprgung ABAPApplikationsserver in Betrieb nehmen und danach nur noch die entsprechenden Softwarekomponenten fr SAP BO Risikomanagement aus dem Service-Marktplatz herunterladen und installieren. Grundstzlich empehlt es sich, gleich das aktuellste Support-Package fr NW und GRC mit zu installieren. Fr die Installation des Systems sind die folgenden Fragen von grundstzlichem Interesse: 1. Soll der Zugriff auf das System fr Endbenutzer ber das SAP-Portal erfolgen oder gengt der Zugang ber den SAP NetWeaver Business Client (quasi ein portalloser Zugang ber einen Weblink)? Wird kein Portal bentigt oder gewnscht, kann man die Installation des entsprechenden NetWeaver-Stack berspringen und spart sich die entsprechende Infrastruktur. 2. Sollen Berichte/Fakt-Sheets als PDF-Dateien exportiert werden? Wenn ja, muss in der Unternehmenslandschaft ein Adobe Document Server(ADS) installiert sein, nur fr GRC allein ist bei Vorhandensein einer derartigen Infrastruktur keine weitere Installation erforderlich. Die Funktionalitt zum Generieren der PDF-Printouts ist ohne ADS-Server nicht vorhanden. 3. Sollen Surveys zum Bewerten von Risiken und Aktivitten verwendet werden? Wenn ja, sind hier zwei Installationen zu beachten: a. Die Surveys knnen ofine als PDF-Attachments verschickt werden. Dazu muss wie oben erwhnt ein ADS-Server in der Landschaft installiert worden sein, ein schon vorhandener kann eingebunden werden. b. Die Surveys werden ber E-Mail als Attachments versendet. Folglich muss auch noch fr ein Transportmittel gesorgt werden. Der NW-ABAP-Server ist gleichzeitig auch noch ein Mailserver, der die PDF-Attachments versendet und auch die ausgefllten Surveyantworten wieder aus den Antwort-E-Mails der Surveyteilnehmer extrahiert und anschlieend verbucht. Folglich muss der Mailserver im NW-ABAP-Stack entsprechend der Systemadministration in Betrieb genommen werden. Wichtig: SAP BO Risik Management ist ein NetWeaver-Add-on, welches keine ERP-Funktionalitt voraussetzt. Dies gibt Flexibilitt bei der Installation.
Seite 69
10 Phase Realisierung: (Implementierung)

10.1.2 EINRICHTEN DER RISIKOMANAGEMENT-APPLIKATION
Fr das Einrichten des Systems nach der technischen Installation des ABAP-Add-on empehlt es sich, das Grundcustomizing vorzunehmen. Dazu ist der Einfhrungsleitfaden (IMG) abzuarbeiten. Fr die entsprechenden Tabellen liefert SAP Beispiel-Tabelleneintrge als BC-Sets aus, die verwendet werden knnen, falls es sich um eine Standardimplementierung des Prozesses handelt. Hierbei ist zu beachten, dass es sich bei GRC um eine integrierte Auslieferung handelt. Die Software enthlt auch Bestandteile von Access Control und Process Control. Demzufolge ndet man im IMG auch einige Kapitel, die GRC-anwendungsbergreifend zu pegen sind, da sie Einuss auf mehrere Produkte haben.
Grundkonguration des Systems mittels SAP Einfhrungsleitfaden Im Allgemeinen sollte man die Aktivitten der Unterpunkte Allgemeine Einstellungen, Gemeinsame Stammdateneinstellungen, Reporting und Gemeinsame Komponenteneinstellungen abarbeiten. Entscheidend ist hier auch, den ersten Punkt Anwendungen aktivieren im Mandant auf Risikomanagement zu setzen, da hiermit der Zugriff auf bestimmte Applikationsbereiche gesteuert wird, anderenfalls erscheinen Funktionalitten im Men, die nichts mit Risikomanagement zu tun haben.
Seite 70
Aktivieren der verwendeten GRC-Applikationen Wichtig: Beim Abarbeiten des IMG-Baumes auch gemeinsame Komponenten mit kongurieren, die nicht unter dem Ast Risikomanagement stehen.
10.1.3 WICHTIGE EINSTELLUNGEN FR DIE ANALYSE

Wichtig fr einen effektiven Betrieb ist das Verstndnis des Analysekonzeptes und deren entsprechende Einstellungen im IMG. Die verschiedenen Analyseeinstellungen werden unter sogenannten Prolen zusammengefasst und steuern die am User-Interface zur Verfgung stehenden Felder und Funktionen. Wichtig ist dabei zu verstehen, dass man nicht alle Risiken nach der gleichen Methodologie zu bewerten hat. Fr einen Teil der Risiken mag es eine quantitative Abschtzung des Schadens geben, andere mgen sich nur qualitativ abschtzen lassen.
Seite 71
Denition von Analyseprolen Entscheidend ist hier das Verstndnis der Anwendung der Analyseprole: Ein Analyseprol kann als systemweiter Default gesetzt werden, jedoch knnen mehrere Analyseprole gleichzeitig verwendet werden. Dazu wird ein Analyseprol an einer Risikokategorie hinterlegt.
Seite 72
Zuweisung von Analyseprolen zu Risikokategorien Damit ist fr den Verfasser einer Risikoanalyse stets vorgegeben, in welchem Umfeld er sich bendet bzw. wie die Schadensauswirkung und die Eintrittswahrscheinlichkeit zu schtzen sind. Wie kommt das Unternehmen trotz verschiedener Analysetechniken fr unterschiedliche Risikoklassen bzw. trotz unterschiedlichen Ansatzes in verschiedenen Organisationseinheiten zu einer einheitlichen Bewertungssicht fr Risiken? Dieses wird ber die sogenannten Schadensstufen und Wahrscheinlichkeitsstufen abgebildet, auf die letztlich alles zugeordnet wird. Diese Stufen werden im Einfhrungsleitfaden festgelegt und sind systemweit gltig, hier gibt es keinen lokalen Anpassungsaufwand. Bei den meisten Implementierungen hat sich eine Einteilung der Schadensstufen und Wahrscheinlichkeitsstufen im Bereich von 3 bis 5 als Best Practice herausgestellt. Dabei ist es NICHT zwingend erforderlich, dass man fr Schden bzw. Eintrittswahrscheinlichkeiten die gleiche Anzahl Stufen whlt.
Denition von Wahrscheinlichkeitsgraden
Seite 73
Denition von Schadensstufen Im vorliegenden Beispiel ndet man beispielsweise 4 Stufen fr die Eintrittswahrscheinlichkeit, aber 5 Stufen fr die Schadensstufen. Der Vollstndigkeit halber sei erwhnt, dass diese Einstellungen auf Grund der Dualitt von Risiko und Chance auch auf die positiven Effekte bei einer Chance (den Nutzen) angewendet werden knnen. Dadurch dass unabhngig von der Analysemethode alles auf die Schwellwerte abgebildet werden kann, lsst sich dann fr das Unternehmen eine Risikomatrix als Kombination von Eintrittswahrscheinlichkeitsklassen und Schadensstufen bilden, die nal die Risikostufe bestimmt. Auch hier ist es wichtig zu wissen, dass die Anzahl der Risikostufen im Unternehmen vllig unabhngig ist. Man kann also 5 Schadensstufen haben, aber 3 Risikostufen oder aber mehr als 6.
Seite 74
Denition von Risikostufen
Im angegebenen Beispiel gibt es 4 Risikostufen von sehr gering (very low) bis hoch (high). Diese Stufen knnen dann zur besseren Visualisierung z.B. in einer Heatmap mit Farbcodes hinterlegt werden. Wichtig: Die Analyse von Risiken ist eine Hauptfunktionalitt. Es gibt exible Einstellungsmglichkeiten bezglich der Analyseart (qualitativ, quantitativ, Scoring) sowie exible Mglichkeiten, die Stufen (Wahrscheinlichkeiten, Schadensstufen, Risikostufen) zu kongurieren. Alle Einstellungen gelten dann global fr das System.
10.1.4 EINSTELLUNGEN FR RISIKOMASSNAHMEN

Wichtig fr einen spteren reibungslosen Ablauf des Risikomanagementprozesses sind die Einstellungen fr die Risikomanahmen. Hier sind folgende Einstellungen sinnvoll: Will das Unternehmen Best Practice implementieren und Struktur in den Prozess bringen, empehlt sich das Anlegen eines zentralen Kataloges von Risikomanahmen als Templates. Hier kann man ein Verzeichnis von Best-Practice-Manahmen als Kopiervorlage vorhalten. Konzeptionell empehlt es sich, dann die Risikotemplates gleich mit entsprechenden Manahmentemplates zu versehen (im Katalog der Risikokategorien), sodass man, wenn man ein Risiko erfasst, nicht nur die unternehmensweit abgestimmten Schadenskategorien verwendet, sondern auch gleich entsprechende Vorschlge fr Gegenmanahmen mitgeliefert bekommt (die man natrlich auch abwhlen kann). Um Redundanzen und mehrfachen Aufwand im System zu reduzieren, empehlt sich auch die Verwendung gemeinsamer Gegenmanahmen. Setzt z.B. die IT-Abteilung eine neue Archivierungsstrategie inkl. Toolbeschaffung auf, kann damit das Risiko von Datenverlusten in mehreren Abteilungen gleichzeitig mitigiert und diese Mitigation dokumentiert werden, allerdings nur an einer Stelle und nicht mehrmals. Damit ergeben sich auch klare Zustndigkeiten, wer ber Implementierungsfortschritt und erfolgte Mitigation zu berichten hat (der Verantwortliche der gemeinsamen Manahme). Das Unternehmen kann sich entscheiden, Manahmen nur zu dokumentieren, aber ihre Auswirkungen auf das Risiko nicht getrennt zu bewerten. Hier spielt der Ansatz des Restrisikos eine Rolle. Fr die Betrachtung werden dann alle Manahmen als bereits vollstndig implementiert und 100 % effektiv angenommen und die Risiko-Analyse betrachtet dann nur noch den unmitigierten restlichen Teil des Risikos. In diesem Fall vereinfacht sich die Analyse sehr und man spart sich auch einen getrennten Workow-Zyklus fr die Dokumentation des aktuellen Implementierungsstandes der Manahme. Die entsprechende Einstellung ndet sich im Analyseprol (Schadensreduzierung). Man kann mit Hilfe von SAP-Technologien auch an der automatisierten Rckmeldung des Status von Gegenmanahmen teilnehmen, sei es durch Kopplung mit dem ERP (bspw. kann aus dem Status eines Projektes im PS der Manahmenstatus abgeleitet werden). In gekoppelten Szenarien mit dem internen Kontrollsystem bzw. dem Richtlinienmanagement macht das aber nur Sinn, wenn der Restrisikoansatz NICHT benutzt wird. Die entsprechenden Einstellungen nden sich im Einfhrungsleitfaden im Bereich Manahmenautomatisierung und Manahmen fr Richtlinien.
Seite 75
Einstellungen zur Manahmenautomatisierung Empfehlung: Es empehlt sich, einen Katalog von Best-Practice-Risikomanahmen anzulegen, aus dem fr konkrete Risiken Templates zugeordnet werden knnen. Es ist mglich, Gegenmanahmen zwischen Risiken zu teilen.
10.1.5 EINSTELLUNGEN FR RISIKOFRHWARNINDIKATOREN

Frhwarnindikatoren sind ein probates Mittel, um rechtzeitig auf Entwicklungen im Risikoprol des Unternehmens reagieren zu knnen. Sie gehren zu den prventiven Mitteln und werden zur Einfhrung empfohlen. Es ist vor der technischen Implementierung zu prfen, welche Frhwarnindikatoren zur Verfgung stehen. Zum Teil knnen diese automatisiert aus SAP-Systemen abgezogen werden, zum Teil kann man sie auch ber Survey-Techniken abfragen. KRI-Vorlagen (Templates) knnen bereits bei der Erstellung des zentralen Kataloges der Risikokategorien an die Risikovorlagen angehangen werden, sodass die entsprechende Einheit nicht nur ein Beispielrisiko mit entsprechenden Manahmentemplates bekommt, sondern auch einen Vorschlag, welche Frhwarnindikatoren fr das Risiko passend sind. Dies erleichtert die unternehmensweite konsistente Einfhrung und erhht die Datenqualitt.
Seite 76
Denition von Systemverbindungen fr Frhwarnindikatoren Die entsprechenden Einstellungen im IMG werden unter dem Kapitel Risikoindikatoren vorgenommen. Durch eine zentrale Denition der Queries ist es mglich, einen hohen Wiederverwendungswert der Queries zu erreichen und damit den Wartungsaufwand gering zu halten. Fr Informationen, die nicht in SAP-Systemen enthalten sind, empehlt sich entweder die Datenkonsolidierung im Data Warehouse bzw. die Implementierung ber Webservices. Hier hat der Anbieter von Frhwarninformationen einen Webservice gem den SAP-Vorgaben zu implementieren. Hinweis: Die Benutzung von Frhwarnindikatoren fr Risiken ist ein probates Mittel, um Risikomanagement prventiv zu betreiben. Hier lsst sich vieles automatisiert betreiben.
Seite 77

10.2 BESONDERHEITEN BEI DER EINFHRUNG EINES INTEGRIERTEN SZENARIOS
Bei der Einfhrung eines integrierten Risikomanagements und internen Kontrollsystems sind einige Aspekte zu beachten, die wichtigsten sollen hier angefhrt werden. Eine derartige Integration kann nur gelingen, wenn sich beide Zielgruppen (Risikomanagement und internes Kontrollsystem) vorher entsprechend abgestimmt haben. Im Allgemeinen kmmert sich das IKS System vorranging um Prozesskontrollen bei innerbetrieblichen Prozessen und Compliance-Anforderungen, whrend ein Ansatz im Risikomanagement meist breiter gefasst ist, d.h. auch Risiken betrachtet, die nichts mit innerbetrieblichen Prozessen zu tun haben, z.B. externe Risiken. Man kann durch eine gemeinsame Einfhrung Synergien im Bereich der Datenhaltung und im Bereich der Prozesse erreichen. Aus Sicht eines GRC-Verantwortlichen lsst sich erst durch eine strukturierte Datenverknpfung ein Komplettberblick ber Risiken und zugeordnete Kontrollen erreichen. Weiterhin sind auch zeitliche Aspekte der Implementierung zu beachten, ob also beispielsweise zuerst ein Risikomanagement-, ein Prozesskontrollsystem oder beide zusammen eingefhrt werden. Im Nachfolgenden werden zuerst die Datenintegrationsaspekte besprochen, nachfolgend die Prozessintegration.
10.2.1 BERLEGUNGEN BEIM AUFSETZEN DER STAMMDATEN 10.2.1.1 ORGANISATIONSEINHEITEN

In einem gemeinsamen Szenario sollen Risiken und zugeordnete Kontrollen aus einem harmonisierten Datenmodell heraus ohne Verdopplung der Datenbestnde zu bearbeiten sein. Dazu werden die Organisationseinheiten in einem gemeinsamen Datentopf gehalten, d.h. in einem SAP-System in einem gemeinsamen Mandanten. Um jetzt eine gemeinsame Verwendung etwa einer Organisationseinheit International Tax oder Einkauf Spanien in beiden Applikationen zu erreichen, werden fr diese Organisationseinheit die Attribute beider Applikationen gepegt, also die fr Risikomanagement wie auch Process Control wichtigen Stammdatenattribute, beispielsweise fr Risikomanagement die Schwellwerte fr die Schadensstufen, im Process Control die Einstellungen fr Management-Kontrollen fr diese Organisationseinheit. Werden also diese Attribute an einer Organisationseinheit zur Verfgung gestellt, kann diese fr beide Applikationen benutzt werden. Die Pege der Attribute erfolgt dabei ber eine jeweils applikationsspezische Sicht, so dass man notwendige Attribute erst dann pegt, wenn man die entsprechende Applikation einfhrt. Die in der Applikation zu verwendenden Organisationseinheiten werden ber eine Anzeigehierarchie zusammengefasst. Es sind mehrere verschiedene Hierarchien mglich, sodass es auch gelingt, die Anzahl der ins Process Control einbezogenen Organisationseinheiten nur teilweise mit den im Risikomanagement benutzen Organisationseinheiten zu berlappen. Damit kann man den Scope einer Implementierung auch in einem gemischten Szenario getrennt halten.
10.2.1.2 VERWENDUNG EINES GEMEINSAMEN RISIKOKATALOGS IN BEIDEN APPLIKATIONEN

Den Begriff des Risikos gibt es in beiden Applikationen. Im Process Control ist das Risiko immer im Zusammenhang mit einem Prozess zu sehen, d.h., es werden Prozessrisiken betrachten, die die Erreichung der Kontrollziele gefhrden. Im gemeinsamen Anwendungsfall mit dem Risikomanagement ist es natrlich wnschenswert, einen zentralen Katalog aller Risiken im Unternehmen aufzustellen, der von beiden Applikationen gemeinsam genutzt werden kann. Dies fhrt spter auch im Reporting zu grerer Konsistenz.
Seite 78
Der Risikokatalog kann in beiden Applikationen benutzt werden, wenn er einmal zentral eingerichtet worden ist. Dabei wird im Process Control die Liste der Risikotemplates aus dem Risikomanagement wiederverwendet. Der Risikokatalog kann in beiden Applikationen benutzt werden, wenn er einmal zentral eingerichtet worden ist. Dabei wird im Process Control die Liste der Risikotemplates aus dem Risikomanagement wiederverwendet. Hier wird also Aufwand zur Duplikation vermieden.
10.2.1.3 AKTIVITTS-HIERARCHIE
Risiken im Risikomanagement knnen mit weiteren Attributen versehen werden, bspw. mit dem Prozess, fr den sie typischerweise auftreten. Wenn man bereits Process Control eingefhrt hat, ist es nicht notwendig, den zentralen Prozesskatalog nochmals als Aktivittskategorie im Risikomanagement nachzutragen. Durch Konguration der Applikation kann man den zentralen Prozesskatalog verfgbar machen, so dass in der Liste der Aktivittskategorien neben Projekten u.. auch die Prozesse verfgbar sind.
10.2.2 GEMEINSAME SOFTWAREKOMPONENTEN

Process Control und Risikomanagement sind Teil einer GRC-Software-Komponente. Dies fhrt zu einer signikanten Reduktion des technischen Einfhrungsaufwandes und der laufenden Betriebskosten. Beide Komponenten haben eine sehr hnliche Benutzeroberche und das gleiche Berechtigungskonzept, der Trainingsaufwand lsst sich also bei einer Einfhrung reduzieren. Teilweise haben die Applikationen auch gemeinsam genutzte Software-Funktionalitten, so z.B. bei der Pege der Organisationseinheiten, beim gemeinsamen Risikokatalog, gemeinsames Reporting, Verwendung von gemeinsamen Komponenten zum Management von Dateianhngen usw. Auch in der Methodologie lassen sich Synergieeffekte heben, so wird z.B. beim Risikoassessment im Process Control die Methodologie und das Customizing des Risikomanagements verwendet, sodass unternehmensweit nach einheitlichen Richtlinien ausgewertet und gleiche Mastbe angewendet werden knnen.
10.2.3 KONTROLLEN ALS RISIKOGEGENMASSNAHMEN

Einer der wesentlichen Vorzge eines integrierten Ansatzes ist eine enge Verzahnung von Risiken und internen Kontrollen, welche die Auswirkungen oder den Eintritt eines Risikos wesentlich mindern knnen. Damit braucht der Datenbestand (das Verzeichnis) fr beide Anwendungsflle nicht doppelt gehalten werden wie in verschiedenen Excel-Sheets. Wird eine Kontrolle neu im System angelegt, ist sie auch sofort im Risikomanagement sicht- und verwendbar. Weiterhin ist es durch diesen Ansatz auch ermglicht, unternehmensweit sichtbar Verantwortlichkeiten fr Risiken und Kontrollen zu hinterlegen.
Seite 79
Verwendung von Kontrollen des IKS als Risikogegenmanahmen Erfasst man im Risikomanagement ein materielles Prozessrisiko, welches mitigiert werden soll, dann ist es mglich, eine bereits existierende Kontrolle aus dem PC-Umfeld als mitigierende Manahme zuzuordnen, sodass nicht aus Dokumentationsgrnden eine neue Manahme angelegt werden muss. Ein weiterer Vorteil ergibt sich aus dem Real-Time-Ansatz ber ein integriertes System: Smtliche Informationen ber Risiken, Kontrollen und Prozesse sind mit ihrem aktuellen Status jederzeit abrufbar, und quasi auf Knopfdruck knnen die entsprechenden Berichte generiert werden.
10.2.4 KONTROLLVORSCHLGE ALS PERMANENTE VERBESSERUNG DES RISIKOMANAGEMENT-PROZESSES

Bisher wurden nur Datenverknpfungen bzw. gemeinsame Nutzung von Daten zwischen Risikomanagement und Process Control betrachtet. Im Nachfolgenden werden Prozessintegrationen zwischen Risikomanagement und Process Control beschrieben. Eine mgliche Interaktion betrifft das Vorschlagen neuer Prozesskontrollen aus einem erkannten Risiko heraus. Dabei ist es mglich, interaktiv das bestehende interne Kontrollsystem zu verbessern, in dem bei einem Risiko nicht eine neue Risikogegenmanahme angelegt wird (die keine Kopplung mit dem internen Kontrollsystem hat), sondern eine potenzielle neue Prozesskontrolle vorgeschlagen wird. Aus Grnden der Governance handelt es sich hier nicht um das automatische Erstellen einer neuen Kontrolle, sondern nur um einen Vorschlag, der zum Review gesendet wird. Das IKS-Team wird dann den Vorschlag bewerten und falls erforderlich eine neue interne Kontrolle im System anlegen, die dann als Standardmitigation das Risiko minimieren kann. Durch den integrierten Workow ist sichergestellt, dass die Kontrollanforderung im System nachvollziehbar bleibt und zeitnah vom IKS-Team bearbeitet wird.
Seite 80
Maske zum Vorschlag neuer Kontrollen 1
10.2.5 AUTOMATISCHE BEWERTUNG DER EFFEKTIVITT VON RISIKOGEGENMASSNAHMEN AUS KONTROLLTESTS UND KONTROLLDESIGN-ASSESSMENTS
Ein proaktives und zeitnahes Risikomanagement sollte den Risikostatus nicht nur aus quartalsweisen Updates der Risikoeinschtzungen beziehen, sondern mglichst real time einen neuen Risikostatus berechnen knnen. Auf Grund des integrierten Datenmodells ist es mglich, die Bewertung von Risiken (hier insbesondere des Restrisikos nach Implementierung von Kontrollen/Gegenmanahmen) sofort zu ndern, wenn Ergebnisse eines Kontrolltests und eines Kontrolldesign-Assessments vorliegen. Hier ist in der Software die Mglichkeit einer direkten Kopplung von Process-Control-Kontroll-Assessments und Testergebnissen mit der Vollstndigkeit und Effektivitt von Risikogegenmanahmen gegeben. Dazu werden im Einfhrungsleitfaden die entsprechenden Kongurationen vorgenommen. Die Ergebnisse eines Kontroll-Designassessments werden hierbei mit der Vollstndigkeit der Implementierung einer Risikogegenmanahme(Fertigstellung) verknpft erkannte Fehler bei der Implementierung einer Kontrolle lassen auch die Vollstndigkeit der Gegenmanahme nicht realistisch erscheinen.
Seite 81
Einstellung der Kopplung von PC mit RM 1 Zuordnungen von IKS-Testergebnissen zur Effektivitt von Risikomanahmen Wenn der Test der Wirksamkeit einer Kontrolle fehlschlgt, sind auch Zweifel an der Effektivitt einer Risikogegenmanahme angebracht. GRC Risk Management verfolgt hier das Konzept einer zweistugen Bewertung des Netto-Risikos (nach Wirkung der Gegenmanahme). Es gibt einen geplanten Status der Wirksamkeit der Gegenmanahme (wenn alles vollstndig und 100%ig wirksam implementiert ist) und den aktuellen Stand der Gegenmanahme, der dann eben auch die aktuellsten Daten aus einer Process-ControlBewertung bercksichtigen kann. Damit ist aber auch die Risikobewertung immer der aktuellen Lage im Unternehmen angepasst, sofern es um die Auswirkungen von Aktivitten im internen Kontrollsystem geht. Wichtig: Durch ein integriertes IKS und Risikomanagementsystem knnen Synergien zwischen beiden Anwendungen erreicht werden. Dies reicht von typischen TCO-Themen wie gemeinsam benutztes SoftwareSystem, gemeinsamen Stammdaten bis zu integrierten Prozessen (Kontrollen als Risikomitigation, Kontrollvorschlge aus Risikomanagement heraus) und gemeinsamen Reportings, um einen Gesamtberblick ber IKS und Risikomanagement zu erreichen.
Seite 82
11 Technische Rahmenbedingungen / Infrastruktur

Die technischen Rahmenbedingungen fr die Einfhrung von SAP BO Risikomanagement sind vergleichsweise einfach. Es handelt sich bei der Landschaft um eine normale, von SAP empfohlene 3-stuge Systemlandschaft, die nur aus einer einzigen Softwarekomponente besteht. Diese ist als Add-on auf eine NetWeaver-Installation abgebildet.
Front End Client NWBC 3.0 (Optional) Web Browser http
Optional Optional
SAP GUI 7.10
http
SAP NW Portal 7.02 GRC Portal Content

(Business Package)
DIAG
SAP NetWeaver BW (7.06 Target) GRC BI Content
RFC
RM & PC 10.0
(Software Component: GRCFND_A)
SAP ERP (4.6C 7.1) NW Function Modules RFC

(Plug-in: GRCPINW)
Optional
SAP NetWeaver AS JAVA 7.02 Adobe Document Server SAP NetWeaver AS ABAP 7.02
Optional
HR Function Modules
(Plug-in: GRCPIERP)
TREX 7.10 or above SAP Business Objects GRC Suite 10.0

Adapter
Optional
Non-SAP Business Applications
Darstellung der technischen Architektur fr das GRC Release 10 Die jeweils gltigen Betriebssystemplattformen, untersttzten Datenbanken, NetWeaver-Versionen etc. entnimmt man der Product Availability Matrix (PAM) der SAP AG unter http://service.sap.com/PAM . Fr die Funktionalitt des Risikomanagements (GRC enthlt auch noch Access Control und Process Control) bentigt man keine ERP-Installation, alle vorhandene Funktionalitt ist in der Softwarekomponente GRCFND_A enthalten. Fr die weiter oben beschriebenen Standardprozesse muss dann neben dem Customizing des NW-ABAPServers (der auch die Funktionalitt eines Mail-Server enthlt) noch fr die Surveys und das Drucken eine RFC-Verbindung zu einem Adobe-Dokument-Server (ADS) hergestellt werden, der dann die entsprechenden Druckberichte und Surveys generiert. Dafr ist aber keine extra Installation ntig, vielmehr kann ein schon vorhandener ADS angeschlossen werden.
Seite 83
11 Technische Rahmenbedingungen / Infrastruktur

Fr folgende Funktionalitt ist eine Anbindung des GRC-Systems an weitere vorhandene Systeme notwendig: > Export der Berichtsdaten in ein SAP-BW-System fr das Reporting > Schnelle Suche von Dokumenten mittels eines TREX > Anschluss von Business-Suite-Systemen zur Ausnutzung der Funktionalitt von automatisierten Frhwarninformationen (ber Key-Risk-Indicator). Hier ist auf den Business-Suite-Systemen nichts zu installieren, die in der Darstellung weiter oben erwhnten Plug-ins enthalten Funktionen fr das interne Kontrollsystem und Access Control. Fr den Frontend-Bereich auf den Rechnern der Endbenutzer gilt Folgendes: Grundstzlich erfolgt der Zugang zur Applikation ber einen Webbrowser. Die jeweils untersttzten Releases ndet man wie immer in der PAM http://service.sap.com/PAM. Nur zur Grundkonguration des Systems ber IMG wird ein SAP-GUI verwendet. Fr die Endbenutzer gibt es zwei Zugnge zum System, einen ber ein bereits im Unternehmen vorhandenes Enterprise Portal in der Version 7.02 (dabei muss der entsprechende GRC-Rollencontent dort eingespielt werden) sowie ber die Browserversion des NetWeaver-Business-Client NWBC 3.0. Diesen erreicht man unter der URL https://<fully qualied domain>:portnr/nwbc/ Um alle Funktionen erreichen zu knnen, mssen auf dem Frontend-PC noch zwei zustzliche Softwaresysteme eingespielt werden > Adobe Flash Player (fr die Untersttzung der graschen Risikomodellierung und Dashboardgraken (z.B. der Heatmap-Grak) > Ein Viewer-Plug-in fr Crystal Reports, um die tabellarischen Reports im Crystal-Format sehen zu knnen. Dies ist optional, da ansonsten die Berichte im SAP-nativen Format ausgegeben werden.
Seite 84
Seite 85
Copyright 2011 DSAG e. V. Alle Rechte vorbehalten. Namen von Produkten und Dienstleistungen sind Marken der jeweiligen Firmen.
Deutschsprachige SAP Anwendergruppe e. V. Altrottstrae 34 a 69190 Walldorf Deutschland
Fon: +49 (0) 62 27 358 09 58 Fax: +49 (0) 62 27 358 09 59 E-Mail: info@dsag.de Internet: www.dsag.de

BESt-PRACtiCE-LEitfADEn Zur EinfühRunG DER. SAP BuSinESSOBjECtS GRC-LöSunGEn

Hochgeladen von

Dokumentinformationen

Originaltitel

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

BESt-PRACtiCE-LEitfADEn Zur EinfühRunG DER. SAP BuSinESSOBjECtS GRC-LöSunGEn

Hochgeladen von

Copyright:

Verfügbare Formate

Best-Practice-Leitfadenreihe zur Einfhrung der SAP BusinessObjects GRC-Lsungen

Deutschsprachige SAP-Anwendergruppe e.V.

DSAG-ARBEITSGRUPPE GOVERNANCE, RISK MANAGEMENT UND COMPLIANCE

SAP BusinessObjects Risk Management

COPYRIGHT 2011 DER AUTOREN:

3.13 3.14 3.15 3.16 3.17 3.18 3.19 3.20 3.21

5 MOTIVATION FR IT-GESTTZTES RISIKOMANAGEMENT 6 RAHMENBEDINGUNGEN / ERFOLGSFAKTOREN

7 UMSETZUNG DES RISIKOMANAGEMENTPROZESSES IN RM

9 PHASE SOLLKONZEPTION (BUSINESS BLUEPRINT UND DESIGN)

10 PHASE REALISIERUNG (IMPLEMENTIERUNG)

11 TECHNISCHE RAHMENBEDINGUNGEN / INFRASTRUKTUR

Das SAP BusinessObjects-Portfolio

> > > > > >

3.1 DEUTSCHER CORPORATE GOVERNANCE KODEX (DCGK)

3.3 IDW RS FAIT 16

3.4 IDW RS FAIT 27

3.5 IDW RS FAIT 38

3.6 IDW PRFUNGSSTANDARD PS 261 (U.A. INTERNES KONTROLLSYSTEM)

Elemente des internen Kontrollsystems

9 IDW PS 261, Tz. 19 10 IDW PS 261, Tz. 20

3.7 IDW PS 33011

3.8 IDW PS 34012

3.9 IDW PS 52513

3.10 IDW PS 98014

Audit Compliance Management (nach IDW PS 980)

3.11 BUNDESDATENSCHUTZGESETZ (BDSG)

3.12 BILANZRECHTSMODERNISIERUNGSGESETZ (BILMOG)

3.12.1 LAGEBERICHT ( 289, 315 HGB N.F.)

3.12.2 PFLICHTEN DES AUFSICHTSRATES

3.12.3 HANDLUNGSFELDER FR DEN VORSTAND

3.14 BASEL III

3.15 MINDESTANFORDERUNGEN AN COMPLIANCE MACOMP

3.16 MINDESTANFORDERUNGEN AN DAS RISIKOMANAGEMENT MARISK

3.17 MARKETS IN FINANCIAL INSTRUMENTS DIRECTIVE MIFID

3.18 SOLVABILITTSVERORDNUNG SOLVV

3.20 SARBANES-OXLEY ACT (SOX)

3.21 NORMEN (DIN ISO/IEC)

3.21.2 ISO 27002 (VORHER ISO 17799)

3.21.3 ISO 27005

3.21.5 ZERTIFIZIERUNG NACH ISO 27001 AUF BASIS VON IT-GRUNDSCHUTZ

3.21.6 RISIKOMANAGEMENT NACH ISO 31000

Establish the Context

Communicate and Consult

Monitor and Review

Risikomanagement nach ISO 31000

5 Motivation fr IT-gesttztes Risikomanagement

6.1 ORGANISATORISCHER RAHMEN

6.2 RMS / IKS-METHODIK

6.3 RISIKO-GOVERNANCE UND RISIKOSTRATEGIE

7 Umsetzung des Risikomanagementprozesses in RM

Proaktives Risikomonitoring ber bestehende Geschftsprozesse und strategische Aktivitten

Entwicklung von Lsungsstrategien fr Toprisiken, um eine hohe Kapitalrendite zu erzielen

Identizieren und Bewertung aller Toprisiken innerhalb des Unternehmens

Festlegung von Toprisiken, Schwellenwerten und Risikobereitschaft

7.1 GRUNDLEGENDE BERLEGUNGEN UND EINSTELLUNGEN

7 Umsetzung des Risikomanagementprozesses in RM

7.2 ERSTELLEN DER ZENTRALEN KATALOGE

Pege der Organisationsstruktur 1

7 Umsetzung des Risikomanagementprozesses in RM

Pege der Schwellwerte Schadensstufen 1

Pege der Unternehmensziele 1

Risikoklassikation und Klassizierung von Aktivitten/Prozessen

7 Umsetzung des Risikomanagementprozesses in RM