Gouvernance, risque & conformité PROGIFORUM

Présentation au sujet: "Gouvernance, risque & conformité PROGIFORUM"— Transcription de la présentation:

1 Gouvernance, risque & conformité PROGIFORUM
12 Juin 2008 Construire un contrôle interne informatique optimisé et aligné sur vos risques métiers. Comment les nouveaux modules SAP GRC y contribuent ? Lorraine GEVREY SAP : Solution Principal GRC Jean Louis BRUN D’ARRE BMA : Associé, Expert Comptable Animateur de la ligne de service Processus, Risques et Conformité Alain NAULEAU BMA : Directeur de mission Associé Ligne de service Processus, Risques et Conformité  

2 AGENDA Partie I Quelques constats sur les pratiques actuelles
Partie II Quelques points d'attention à surveiller lors de la construction Partie III Les apports de l'approche Partie IV Les apports de SAP - GRC Partie V Questions / Réponses

3 Comment ont été appréhendés les risques IT durant les 20 dernières années ?
Les entreprises n‘ont pas attendu les lois Sarbanes-Oxley et et la publication du cadre de référence de l’AMF (encadrant la LSF) pour s'intéresser au contrôle interne : Métier Informatique Depuis une vingtaine d'années de nombreuses entreprises ont fait des efforts importants dans ce domaine. Ces travaux se sont appuyés sur de nombreuses méthodes, la plupart focalisées sur les aspects Sécurité. Parmi les plus connues : Ebios Méhari Marion … 1970 1980 1990 2000 2010 Procédures Réf. sécurité COSO 1 SOX/LSF

4 Quels sont les impacts des nouvelles réglementations depuis 2003 ?
Depuis 2003, les règlementations SOX et le cadre de référence de l’AMF sont venus élargir les besoins en terme de dispositif de contrôle interne voire de contrôle interne informatique. Effort Croissant Maitrise des risques opérationnels Conformité Amélioration de la performance

5 Quels sont les impacts des nouvelles réglementations depuis 2003 ?
La part du contrôle interne informatique reste toutefois limité : Dans le cas de SOX A une certaine taille d’entité (entités cotées) Aux applications produisant les informations financières ou supportant des contrôles automatisés A certains processus informatiques (Accès aux données, Gestion des changements, Gestion des opérations, Gestion des projets informatiques) Dans le cas de la LSF A une certaine taille d’entité (entités cotées uniquement) En terme de processus ou d’applications à couvrir (Nb : Les pages 18 du cadre de référence et p31 du guide d’application décrivent les attentes en terme d’IT) Sécurité Conformité Réglementaire Sur les ressources IT Sur les applications Toutes les entités Certains processus Certaines applications Certaines entités Autres processus Autres applications Autres entités Contrôle interne IT

6 Comment les entreprises cotées communiquent elles sur leur contrôle interne ?
Le cadre de référence de l’AMF impose aux sociétés cotées, au travers du rapport du Président, de communiquer sur le dispositif de contrôle mis en place ainsi que sur le dispositif de gestion des risques. Nous avons sélectionné (*) un échantillon de 50 rapports du Président portant sur les comptes 2007 : Compartiment A : 30 Compartiment B : 16 Compartiment C : 4 * « BMA - Analyse comparée de 50 Rapports du Président au 30/04/2008 »

7 Comment les entreprises cotées communiquent elles sur leur contrôle interne ?
Constat 1 : L’appréciation du dispositif de contrôle interne reste très générale dans la grande majorité des cas Quelques commentaires significatifs figurant dans les rapports ( 7 cas)

8 Comment les entreprises cotées communiquent elles sur leur contrôle interne ?
Constat 2 : Très peu d’entreprises expriment un avis sur leur dispositif de contrôle interne

9 Comment les entreprises cotées communiquent elles sur les risques technologiques ?
Constat 3 : Moins de 50 % des entreprises communiquent de manière précise sur leurs risques

10 Comment les entreprises cotées communiquent elles sur les risques technologiques ?
Constat 4 : Près de 95 % des entreprises ne communiquent pas ou de manière succincte sur le dispositif de mise sous contrôle du système d’information 94 %

11 Quelle perception les entreprises ont-elles de leurs risques IT ?
L’activité de votre entreprise dépend-elle des systèmes d’information ? * La grande majorité de l’activité des entreprises dépend de leur système d’informations. Votre organisme/entreprise vous semble-t-elle exposée à des risques informatiques ? * Plus de 80 % se perçoivent comme étant exposées à des risques informatiques. * « Risques technologiques et risk management » - AFAI

12 Où en est la réflexion portant sur les risques IT ?
Existe-t-il au sein de votre entreprise une définition des risques technologiques ? * Près de 70% d’entre elles n’ont pas de définition des risques technologiques. Existe-t-il au sein de votre entreprise un référentiel de risques technologiques ? * Près de 80% d’entre elles n’ont pas de référentiels des risques technologiques. * « Risques technologiques et risk management » - AFAI

13 Lorsqu’il existe, le dispositif de contrôle interne IT est il pertinent ?
Un manque de pertinence … Bien que les contrôles IT soient jugés pertinents pour couvrir les risques IT, une part importante des contrôles IT est encore jugée non pertinente pour couvrir les risques métiers. Pour la prévention de la fraude, 27% des contrôles IT sont jugés non pertinents * Mais aussi un manque d’efficacité Sur l’ensemble du dispositif de contrôle interne IT seuls 56 % des contrôles sont jugés efficaces *. Sur la gestion du changement seuls 40 % des contrôles IT sont jugés efficaces. * * « Étude sur les pratiques des entreprises européennes en matière de contrôle interne » – Ernst &Young 2007

14 Pourquoi ces insuffisances?
Les méthodes informatiques actuelles n’ont pas été construites pour ! Les référentiels sécurité n’abordent qu’une partie de la problématique Cas de MEHARI ou MARION centrées sur l’aspect sécurité Les référentiels tels que COBIT doivent être complétés L’ISACA (Information Systems Audit and Control Association) recommande : De procéder à une analyse des risques des processus par l’application d’une « démarche complémentaire centrée sur l’identification des risques liés aux processus ». Et ainsi, de cibler la mise en place des contrôles ITGC là où les risques sont importants : « Ne traiter les contrôles généraux informatiques (IT general controls) que dans la mesure où ils conditionnent le bon fonctionnement d’applications sensibles des processus métiers » Les nouveaux référentiels réglementaires (AMF par exemple) sont encore embryonnaires et ne constituent à ce jour : Ni une démarche d’analyse de risques Ni un catalogue de risques IT * «CobiT 4.0 apporte-t-il une réponse aux attentes du PCAOB ?» – ISACA 2006

15 AGENDA Partie I Quelques constats sur les pratiques actuelles
Partie II Quelques points d'attention à surveiller lors de la construction Partie III Les apports de l'approche Partie IV Les apports de SAP - GRC Partie V Questions / Réponses

16 Les caractéristiques de l’approche
L’approche mise en œuvre doit être partagée entre l’informatique et les métiers : Compréhension de processus réciproques Partage des notions de facteurs de risques, de conséquences et de leur cotation (selon une échelle commune) Accord sur la localisation de la résolution des problèmes : soit du côté informatique soit du côté métier

17 Les caractéristiques de l’approche
Elle se focalise sur quatre axes de travail Adéquation par rapport aux risques IT Adéquation par rapport aux risques métier Satisfaction des objectifs de conformité Capacité à être mis en place : besoin de conserver un dispositif de contrôle interne « léger » Adéquation du dispositif de contrôle interne IT aux risques métier Objectifs de conformité réglementaire Légèreté du dispositif Adéquation du dispositif de contrôle interne IT aux risques IT Situation actuelle Situation cible

18 Quelques points d'attention à surveiller lors de la construction
Une approche en quatre étapes Description des processus IT Identification des « zones de risques » Évaluation des risques Définition du dispositif de contrôle

19 Quelques points d'attention à surveiller lors de la construction
Description des processus IT Identification des « zones de risques » Évaluation des risques Définition du dispositif de contrôle 1 Modéliser les processus IT de l’entreprise La modélisation des processus est dorénavant communément répandue pour l’identification des risques métier : l’IT doit être appréhendé de la même manière Les processus IT ainsi modélisés deviennent le socle du contrôle interne IT. Celui-ci est compréhensible par les opérationnels métier. La modélisation doit être réalisée au niveau suffisant pour assurer ce partage IT / Métier. Elle ne doit pas sombrer dans un niveau de détail trop important et inutile.

20 Quelques points d'attention à surveiller lors de la construction
Illustration d’un processus IT Cas simplifié du processus« Gestion des changements » de l’application de consolidation Enregistrement d’une demande de changement Approbation Réalisation du changement Validation technique (unitaire, intégration, …) Recette fonctionnelle Approbation pour Mise en production Mise en production

21 Quelques points d'attention à surveiller lors de la construction
Description des processus IT Identification des « zones de risques » Évaluation des risques Définition du dispositif de contrôle 2 S’accorder sur la notion de risque et sa modélisation Dans la plupart des outils d’évaluation voire des outils de modélisation, la notion de risque est portée par un seul objet alors que la définition du risque met en évidence deux notions : La probabilité d’un événement (que nous appellerons facteur de risque) Les conséquences Ainsi, dans les définitions ISO : « Combinaison de la probabilité d’un événement et de ses conséquences » (ISO/CEI 73), « Combinaison de la probabilité d’un dommage et de sa gravité » (ISO/CEI 51) Nous préconisons lors de la phase de modélisation de représenter les deux objets de manière distincte ; quitte à ce que l’évaluation porte ultérieurement sur la combinaison des deux.

22 Quelques points d'attention à surveiller lors de la construction
Description des processus IT Identification des « zones de risques » Évaluation des risques Définition du dispositif de contrôle Exemples de facteurs de risques et de conséquences : Le facteur de risque « Altération accidentelle des données par l’exploitation» a pour conséquence «Indisponibilité majeure des informations à usage public (Web…) » (Risque IT). Le facteur de risque « Départ ou disparition d’un collaborateur stratégique  » a pour conséquence «Indisponibilité majeure des informations  » (IT).

23 Quelques points d'attention à surveiller lors de la construction
Description des processus IT Identification des « zones de risques » Évaluation des risques Définition du dispositif de contrôle 3 Veiller à lier les facteurs de risques IT aux conséquences métier Lors des analyses de risques IT les Conséquences IT des Facteurs de risques IT sont toujours abordées. Ce qui intéresse les métiers, c’est le lien entre un facteur de risque IT et une conséquence métier.

24 Quelques points d'attention à surveiller lors de la construction
Illustration du positionnement des facteurs de risques Cas simplifié du processus« Gestion des changements » de l’application de consolidation Enregistrement d’une demande de changement FR01-Demande de changement non enregistrée C1 : «Indisponibilité majeure des informations » C1 : «Indisponibilité majeure des informations » FR02- Etude d’impact du changement non réalisée FR03-Demande de changement lancée sans approbation Approbation C1 : «Indisponibilité majeure des informations » Réalisation du changement C1 : «Indisponibilité majeure des informations » FR04-Absence de validation fonctionnelle d’une modification portant sur la saisie des liasses de consolidation Validation technique (unitaire, intégration, …) FR05-Absence de validation fonctionnelle d’une règle de consolidation Groupe C3 : «Résultats financiers non-conformes à la réalité  » Recette fonctionnelle Nb : L’identification des « facteurs de risques IT » peut s’appuyer sur des référentiels tels que COBIT notamment grâce à sa liste « d’objectifs de contrôle ». Approbation pour Mise en production FR06-Accès à l’environnement de production non contrôlé Mise en production C1 : «Indisponibilité majeure des informations » C2 : «Fraude  » C3 : «Résultats financiers non-conformes à la réalité  »

25 Quelques points d'attention à surveiller lors de la construction
A l’issue du rapprochement des facteurs de risques et des conséquences Facteur de risque Conséquence IT Conséquence Métier FR01-Demande de changement non enregistrée C1 : «Indisponibilité majeure des informations » FR02- Etude d’impact du changement non réalisée FR03-Demande de changement lancée sans approbation FR04-Absence de validation fonctionnelle d’une modification portant sur la saisie des liasses de consolidation FR05-Absence de validation fonctionnelle d’une règle de consolidation Groupe C2 : «Fraude  » C3 : «Résultats financiers non-conformes à la réalité  » FR06-Accès à l’environnement de production non contrôlé

26 Quelques points d'attention à surveiller lors de la construction
Description des processus IT Identification des « zones de risques » Évaluation des risques Définition du dispositif de contrôle 4 Définir des échelles de fréquence et de gravité qui aient un sens pour le métier L’évaluation de la criticité du risque passe par la définition de deux types d’échelle : Échelle de probabilité Échelle de gravité L’échelle de probabilité ne pose en général pas de problème particulier Probability Definition Level Ongoing Every day 4 Frequent Between once a month and once a week 3 Occasional Between once a year and once a month 2 Rare Less than once a year 1

27 Quelques points d'attention à surveiller lors de la construction
Une échelle de gravité est définie au niveau de chaque conséquence Ci-dessous un exemple d’échelle de gravité tel que l’on en trouve souvent et qui ne tient pas compte de l’impact du facteur de risque sur le métier Cette échelle a peu de sens pour le métier : qui dans certains cas peut attendre 48 heures sans souci et qui lors de certaines périodes, ne peut rester 5 minutes sans son système. Il convient alors que l’IT et les métiers définissent une échelle de gravité qui ait un sens pour tous. Voici un exemple d’échelle de gravité construite en commun.

28 Le résultat : une matrice de criticité partagée entre l’IT et les métiers
Impact G=3 G=4 G=4 G=4 Criticité = Probabilité x Gravité I=4 La matrice est partagée : au niveau de sa structure : En ligne : processus, facteurs de risques En colonnes : conséquence au niveau des cotations qui y figurent G=2 G=3 G=3 G=3 I=3 G=1 G=2 G=2 G=3 I=2 G=0 G=0 G=1 G=1 I=1 Probabilité P=1 P=2 P=3 P=4 L’évaluation est réalisée par processus et par application.

29 AGENDA Partie I Quelques constats sur les pratiques actuelles
Partie II Quelques points d'attention à surveiller lors de la construction Partie III Les apports de l'approche Partie IV Les apports de SAP - GRC Partie V Questions / Réponses

30 Zone de risque à couvrir
1 - Obtenir une vision unifiée de la couverture des risques métier et IT 4/ Alléger le dispositif Zone de risque à couvrir 2/ Identifier et couvrir les zones de risques résiduelles Dispositif de contrôle IT Dispositif de contrôle métier 3/ Transferer la couverture du risque 1/ Obtenir une vision unifié du dispositif de contrôle : - Les contrôles IT contribuent à couvrir des risques métiers - Les contrôles métiers contribuent à limiter la criticités des risques IT

31 2 - Adapter le niveau de protection au niveau de risque métier et IT.
État du dispositif Corrections possibles Sous Protection Les contrôles n’existent pas Mettre en place un ou des contrôles complémentaires Les contrôles existent Ajuster les attributs des contrôles existants : Préventif vs Détectif Automatisation du contrôle Fréquence de contrôle Changement du mode de test Changement de point de vue en fonction des acteurs concernés : Transfert de la couverture du risque Sur Protection Inapproprié Suppression du contrôle Trop fréquent Réduction de la fréquence de contrôle Trop systématique Réduction du périmètre des populations ou activités à contrôler Trop éclaté Regroupement de contrôles et ou de tests Trop lourd Changement du mode de test Changement du niveau de contrôle (Environnement de contrôle vs contrôle applicatif)

32 3 - Identifier et traiter les zones de risques de non-conformité
La capacité à identifier les zones de risques de non-conformité engendrés par l’IT L’approche permet de typer les risques et les facteurs de risques en fonction des référentiels de conformité auxquels ils se rattachent. Différents référentiels de conformité peuvent être pris en compte simultanément: Conformité règlementaire Conformité par rapport à des normes internes Illustration : Le PRA (Plan de reprise d’activité) est un élément de conformité requis par Sarbanes Oxley. L’absence de PRA constitue un facteur de risque de conformité. L’identification et l’évaluation des contrôles en liaison avec ce facteur de risque sont primordiaux lors d’une mesure de conformité.

33 Exemple de résultats issus d’un cas réel d’optimisation et de recentrage mené par BMA sur un dispositif de contrôle informatique Sarbanes Oxley Appli1 Appli2 Appli3 Appli4 Appli5 Appli6 Appli7 Appli8 … Contrôles avant Contrôles après Impacts sur les tests

34 AGENDA Partie I Quelques constats sur les pratiques actuelles
Partie II Quelques points d'attention à surveiller lors de la construction Partie III Les apports de l'approche Partie IV Les apports de SAP-GRC Partie V Questions / Réponses

35 Les objectifs de la présentation des modules SAP GRC
Comment SAP GRC peut-il venir en support à une telle approche ? Les points clé de l’approche que nous avons souhaité illustrer au travers des modules SAP GRC sont les suivants : La nécessité de modéliser les processus métier et IT avec leurs activités de contrôle respectives Faciliter et accélérer l’analyse de risques et la conception des contrôles IT dans votre entreprise Automatiser la réalisation de certains contrôles afin de les rendre plus efficaces et directement auditables La nécessité de disposer d’une vision claire de la séparation des tâches La construction partagée d’un modèle de risques IT c’est-à-dire en quoi un dysfonctionnement IT a une incidence sur le déroulement du métier.

36 Illustration d’un processus de gestion de sinistre:
Pour une même personne: - Impossibilité de créer, régler et décaisser un sinistre…. - Impossibilité de créer un expert puis de régler ses honoraires …. Ouverture Création Identification du contrat Vérification de Couverture Données générales du sinistre Garanties touchées Evaluation du sinistre Centre d’appels Instruction du dossier Recherche d’intervenant Création d’intervenant Mission expert Mission réparateur Saisie tiers et témoins Saisie des bénéficiaires Règlement Demande de règlement Vérification des plafonds Saisie du bénéficiaire Saisie du règlement Modification Décaissement Saisie des honoraires Annulation Recours Evaluation Saisie du bénéficiaire Saisie du règlement Décaissement / encaissement Back office de gestion © SAP 2007 / Page 36

37 Des contrôles automatiques IT pour prévenir des risques métiers
Configuration, Master Data and Transaction Data Any Form, Tab or Field ... Multiple Controls Check that control value exists Is the Duplicate Voucher flag turned ON? Has the duplicate Voucher control changed? How often? Monitor changes to control Have any duplicate vouchers been processed over the past 30, 60, 90 days? Monitor change frequency First there is a framework for testing. Realize that within every ERP system there lies this concept of configurable controls. Within SAP, generally speaking, these controls are found within the IMG tables. The second level of testing has to be performed at the transaction level. Let’s take a traditional AP example. Within SAP, Oracle, PeopleSoft, JDE, etc …… there is a configurable control at the system level to turn on or turn off – duplicate voucher checking. Auditors need to test how this controls is set. Next there is a Master Data switch where the system level switch can be over-ruled at, in this example, the vendor master level. Auditors need to test how this these “master data” switches are set. Lastly …. Auditors need to pull a sample size, usually in the form of a report to test if over the last days, any “duplicate vouchers’ were processed in the system. Maybe we want to qualify that test by dollar value … any dollar amount over $1,000. This would be very time consuming if done manually! Apply absolute value threshold Apply percentage threshold Hide / Disable / Query Only 37

38 Enables management by exception - Effectively manage business risk
SAP GRC Process Control - Convergence of Controls Process Management and Continuous Controls Monitoring Perform Assessments Test Automated Controls Test Manual Controls Document Test Monitor Certify Certify and Sign-off (302, Designs,…) Process-Control-Objective-Risk IT Infrastructure Business Processes … Review Exceptions Remediate Issues ü Has production been improved with the installation and implementation of SAP? S U R V E Y Yes No 1 3 4 5 6 9 10 11 12 15 16 17 18 19 7 8 13 14 22 23 24 25 26 20 21 29 30 27 28 2 Single Solution for end-to-end enterprise control management - Increase confidence in the effectiveness of controls Provides centralized control management for automated and manual controls - Reduce cost without compromising compliance Enables management by exception - Effectively manage business risk prioritizes remediation activities provides management insight into the control environment 38

39 SAP GRC Process Control: Centralized Control Management
Perform Assessments Test Automated Controls Test Manual Controls Document Test Monitor Certify Certify and Sign-off (302, Designs,…) Process-Control-Objective-Risk IT Infrastructure Business Processes … Review Exceptions Remediate Issues ü Has production been improved with the installation and implementation of SAP? S U R V E Y Yes No 1 3 4 5 6 9 10 11 12 15 16 17 18 19 7 8 13 14 22 23 24 25 26 20 21 29 30 27 28 2 Centralized Control Management One system for managing automated and manual controls System can manage Financial Controls Operational Controls IT Controls Controls can be monitored across multiple enterprise systems Increased confidence in controls with regular assessments 39

40 Select Pre-delivered Test Re-use Custom Test Construct Ad-hoc Test
Three Ways to Monitor Automated Controls Across Critical Business Processes Select Pre-delivered Test Re-use Custom Test Construct Ad-hoc Test Pre-delivered tests with flexible rule criteria for SAP and Oracle Create control tests on-the-fly with custom query builder Plug-and-play your existing test scripts Order to Cash Order Capture Order Fulfillment Billing & Returns Revenue Recognition Procure to Pay Demand Planning Operational Procurement Inventory Management Payables Management Reconcile to Report Budgeting Planning Subledger Transactions Financial Close Consolidation& Reporting IT Basis Application Security Change Control 40

41 Actionable Intelligence from Compliance Analytics
Role-based dashboards provide actionable insight to control status Global heat map highlights exceptions from all control tests and assessments Management level reports highlights exceptions from all control tests and assessments Enterprise transparency across multi-instance and multi-platform environments Samples of standard reports include: Global heat map for control exceptions Status of assessments for control design, process design, entity-level control by period Remediation status by process, role, and location Results of all reports can be exported to PDF and spreadsheet output 41

42 SAP GRC Access Control Sustainable prevention of segregation of duties violations
Minimal Time To Compliance Continuous Access Management Effective Management Oversight and Audit (Get Clean) (Stay Clean) (Stay in Control) Risk Identification and Remediation Rapid, cost-effective and comprehensive initial clean-up Enterprise Role Management Enforce SoD compliance at design time Compliant User Provisioning Prevent SoD violations at run time Superuser Privilege Management Close #1 audit issue with temporary emergency access Periodic Access Review and Audit Focus on remaining challenges during recurring audits Risk analysis, remediation and prevention services Cross-enterprise library of best practice segregation of duties rules <SAP Solution> More than 500 companies worldwide have chosen SAP GRC Access Control to manage their compliance process for access and authorization control. SAP GRC Access Control provides an end-to-end access control application that not only supports the initial clean-up effort, but ensure continuous compliance through day-to-day access management (stay clean) and support for periodic access audits (stay in control). 1) The entire solution is built on two core components: Cross-Enterprise Library Of SoD Rules To increase efficiency, the application delivers the most comprehensive database of segregation of duties (SoD) rules available for applications from SAP, Oracle, PeopleSoft, and JD Edwards. It also makes it easy for non-IT security experts to extend the rules library custom rules using common business language. This is where a substantial part of the value for SAP’s solution lies. Developed over 10 years, this best practice library ensures effective and comprehensive cross-enterprise SoD analysis. The rules library also allows guarantuees customers a quickstart on the initial controls clean-up. Risk analysis, detection, alert, remediation and prevention services All capabilities of SAP GRC Access Control rely on a core set of enterprise services support real-time compliance around the clock and prevent security and controls violations before they occur. Implementation and deployment of the risk analysis and remediation software takes one week, after which businesses can analyze real-time data, find hidden issues, and help ensure the effectiveness of access and authorization controls across the enterprise. Rather than relying upon data downloads from disparate applications, SAP GRC Access Control uses real-time data to assess risk, enabling businesses to identify conflicts immediately, drill down into root causes, and achieve resolutions swiftly. 2) In the area of access management, key capabilities include Enterprise Role Management SAP GRC Access Control addresses the root cause of access control problems through standardized and centralized role design, testing, and maintenance. As a result, the software helps to eliminate manual errors and makes it easier to enforce best practices. Technical experts as well as business process owners can document role definitions, perform automated risk assessments, track changes, and conduct maintenance with ease, which increases consistency and lowers IT costs. Compliant User Provisioning As companies provision and deprovision access to enterprise systems, they often overlook how these changes can impact SoD requirements. SAP GRC Access Control enables fully compliant user provisioning throughout the employee life cycle and prevents new SoD violations. Businesses can automate provisioning, test for SoD issues, streamline approvals, and reduce the workload for IT staff. Superuser Privilege Management How can businesses give users privileged emergency access to enterprise systems without committing regulatory violations? In emergencies, SAP GRC Access Control enables users to perform activities outside their role under superuser-like privileges in a controlled, auditable environment. A temporary ID can be assigned that grants the user privileged, yet regulated, access. The software is easily deployed and administered, and it delivers a user experience consistent with other SAP software. The application tracks, monitors, and logs every activity a superuser performs with a privileged user ID. Web-based reporting provides business process owners and auditors with detailed multisystem usage reports across their SAP software landscape. Activity logs track input down to the field value level and enable easy filtering, sorting, and downloading of input information. 3) In the area of access audit, SAP GRC Access Control provides Capabilities for Management Oversight Managers need to run periodic access reviews. This includes reaffirmation of user access, reviewing access risks and mitigations, to make sure SoD mitigations are effective Capabilities Internal Audit Internal auditors need to ensure that the business complies with all policies. They need be able review that a) all access was properly authorized and that all SoD risks are properly mitigated (i.e. controls are in place and are regulary checked). 42

43 SAP GRC Risk Management Providing the framework for an integrated approach to ERM
Automates and integrates GRC in business processes Standardizes controls based on content, rules and technology Helps identification of issues while providing a framework for emerging regulations Transforms GRC in a strategic weapon– allows a competitive differenciation and a higher level of performance SAP GRC Risk Management GRC Repository Global Trade Access / Process Environment / Safety Supply Risk xApp Others… Business Process Platform External Provider KRIs / Content Sources This slide shows the high level architecture of SAP GRC Risk Management. Starting at the bottom, SAP GRC Risk Management covers cross-system risk processes (internal systems and external systems/content). This connectivity is provided by SAP NetWeaver and enterprise SOA (service oriented architecture). SAP and SAP partners provide several applications for detailed risk analysis and mitigation for LOBs (e.g. GTS, Cisco SONA xApps, etc.). These play a critical role in addressing risks in operational systems. The SAP GRC Repository is the master data hub for GRC – it connects risks, controls, policies and regulations to ensure one version of the truth for GRC data and can help companies rationalize their risks and controls across the enterprise. Finally, SAP GRC Risk Management provides the complete enterprise view of risks within the context of the business processes. Automated process support for risk planning, identification, analysis, response and monitoring are provided by the application. <Technical information below> The current version of the application can be installed as an add-on to an SAP NetWeaver (NW2004s) system. It requires a Web Application Server (WebAS) 700. All end-user screens are delivered via the web – a SAP GUI installation is only required for the initial customizing. A standard 3-system landscape is recommended (development, quality/test, production). To run the dashboard, an SAP Enterprise Portal is required, which is also part of SAP NetWeaver (SAP EP 6 SPS14 + Runtime Patch see Note ) or SAP NW 04s Portal.

44 Risks Management Steps Process automation for the virtuous cycle
Establish risk appetite and thresholds Collaborate and aggregate across the enterprise Actionable, role-based dashboards and alerts Balance cost of risk avoidance and opportunity So let’s talk about the GRC Risk Management solution. I’ll use this general 4 step risk management process to discuss the functionality of our solution.

45 Drive Consistency Agreement on top risks, thresholds, and appetite
Create Risk and Activity Catalogs GRC Repository What types of risks do we want to track? Proposed risks based on business process Align risks to corporate goals Customizable, pre-delivered content Risk Catalog KRI 2 Supplier on-time delivery Supply chain continuity risk Document Risk Appetite <95% 5% KRI 1 Scrap Rates Identify KRI Thresholds The risk management process begins with Planning. This typically starts with: 1 – Setting up the risk and activity catalogs for the enterprise. What are the top risks that could effect your business that you need to track? Which of your business processes or activities are “worth” tracking from a risk management perspective? What are your company‘s goals and how do risks align to those? How do they differ by line of business? So in the end, you have customized risk content specific to your enterprise. Our GRC audit and risks partners, Deloitte, Protiviti, and PWC, can assist in this process if needed and have risk content tailored to your industry. 2 – The next step is then identifying the key risk indicators (KRI) for each of the top risks. KRI thresholds can be set using configurable business rules. Some typical examples are when a KRI crosses a particular level (e.g. safety injuries >3/month), on an % increase/decrease basis (5% increase in the number of unplanned manufacturing downtime), or % of volume (e.g. >0.5% customer complaints per product shipped). Additionally, multiple KRIs could be defined for monitoring a risk if needed (e.g., high scrap rates at the same time as your supplier on-time delivery rate is particularly low could result in a supply chain continuity risk.) 3 – Finally, the risk-bearing appetite for each line of business and the enterprise at-large need to be documented. How much loss can the business absorb based on current capitalization? This can be calculated by Line of Business, geography, and the overall enterprise at large, as there may be some parts of your business where you may want to take more risks – in an product line, for example, while other lines of businesses (“cash cows”) will be managed more conservatively.

46 Avoid Surprises Identify and assess all key risks across the enterprise
Automatically Identify Risks Embedded into key business processes Workflow delivers assessments to experts User receives alert – data updated in SAP GRC Risk Management Collaborative Assessments for Manual Risk Activities Prioritization using Risk Heat Map After the planning phase is complete, the next step is RISK IDENTIFICATION and ANALYSIS. The goal is to identify all key risks, regardless of where they exist – internally or externally - and analyze based on qualitative or quantitative methods. 1 – For as many risks as possible, it is preferred to automatically identify the risks based upon the KRIs set in your business operational systems. As we discussed on the previous slide, when a KRI that has been set in the source application has been reached, the SAP GRC Risk Management workflow kicks off either an alert or a riisk re-assessment, where the risk owner would updated the risk details to reflect the new conditions. By using this approach, risk identification is embedded into existing business processes rather than creating separate processes for risk identification. 2- Of course, not all risks cannot be automatically identified. SAP GRC Risk Management has user-friendly self-assessments as well as collaborative survey capabilities that can be used to gather information on risk type, impact, probability, timeframe, and mitigation strategy/costs. Easy-to-follow guided activities make it easy for risk assessments to be completed by non-risk professionals, and workflow support is provided to ease the burden on the risk management team and take care of progress tracking. Besides a portal, this information can be collected in Adobe Interactive Forms, Excel, or Word via to increase response and LOB “adoption”. 3 – After identifying the risks, they are prioritized using the standard risk “heat map” approach. The heat map may be customized to match your specific company definitions and categories. And by comparing the risk heat map based on different points in time, any changing or shifts in risk conditions are easily identified. Qualitative & quantitative point and scenario analyses Survey functionality and guided activities Workflow reminders for updates Prioritization for response investment Identifying shifting in risk profile

47 Respond Intelligently Create resolution strategies for critical risks
Spot Risk Interdependencies Pre-emptive marketing campaign Correlation Supplier Bankruptcy Marketing Sales IT Supply ... Enabling Lines of Business to Mitigate Risks Best Practice Response Playbooks Top Industry Risks Solution Employee health and safety Non-compliance-Title V emissions Production/reliability disruptions Commodity/Market risk Credit risk Inadequate staffing/skill sets Non-compliance financial regulations EH&S xEM EAM/ERP TriplePoint (partner in process) HCM Access/Process Controls The third step is RISK RESPONSE. Once you’ve identified critical risks, you need to have a response strategy (watch, research, transfer, delegate, mitigate). The particular response strategies are used in your organization are of course customizable. A single risk in SAP GRC Risk Management can have multiple responses. Every response documented has a cost, owner, status, and workflow reminder set at a certain frequency for updates on progress. How do you decide which risks to respond to, and which to accept? 1 – Addressing single risks may not always resolve the highest-priority problems. Instead, crucial issues are often the result of not being able to correctly identify what happens when multiple risks occur simultaneously and interact, combining to become a severe risk. For example, a large consumer product manufacturer shared the following experience: The marketing group had worked overtime to develop a new advertising campaign to offset a competitive product launch. However, marketing wasn’t aware that a key backup supplier had gone out of business and that purchasing was working to find a replacement. The purchasing department, not concerned that its search might take several weeks since the primary supplier could handle the historical demand, was oblivious to the new marketing campaign. The result? The new marketing campaign was a huge success and demand for the product soared, right at the time that the competitive product launched. Unfortunately, the main supplier could not meet the additional demand and store shelves quickly emptied, driving customers to purchase the competitor’s product instead. The strategy backfired and was a costly lesson. Clearly, these risks have a correlations and should be resolved together versus separately. But in a siloed approach, no one would have the cross-company visibility needed to make the connection. 2- Next, the Lines of Business need the tools to effectively mitigate risks. <NOTE: this box can be customized per industry – additional examples at end of presentation> Often, they already have the tools in place to operationally mitigate the risks – SAP and SAP partner applications such as EH&S, xEM, ERP, etc. play a key role in risk mitigation at the operational level and providing KRI monitoring. 3 – With the response tracking capability, you can monitor the status of responses (such as draft, committed, on track, completed), track the costs of the response, and even have multiple responses for a single risk. This is obviously critical to ensure that the risk owners are getting the support and capital needed to effectively mitigate the risks they own. <you can replace this slide with industry-specific slides at the end> Response status monitoring Response cost tracking Analysis done before and after responses

48 Stay Informed Build proactive monitoring into existing business processes
Latest Risk Management Status in Your Business Context Role-based Risk Management Dashboards SAP CPM Dashboards Set Control Limits Based Upon Associated Risk Capture Incidents and Losses The final step is RISK MONITORING. Clearly businesses need to have proactive monitoring around their risk management processes, and we support this is several ways. 1- One aspect of monitoring is dashboarding - dashboards provide insight for more informed business management by answering questions like: What and where are our top risks? How have risk levels changed for key activities/opportunities? Have incidents / losses occurred? Are we assessing our risks in accordance with company policy? These dashboards also provide a single point of entry for reporting-only (e.g. Board) users to all relevant risk management information, and can be tailored to role or business unit. In addition, the SAP CPM product plans to incorporate risk data from GRC Risk Management to enable risk adjusting strategy management and planning. As is the case with all planned functionality, SAP reserves the right to change plans. 2- Incorporating a risk view into control limit setting With SOX and other regulations taking up management mindshare, the current “checklist” approach most people take have led to some processes being controlled too much while others are controlled too little. A risk-based approach results in a more efficient use of resources and a better match of the level of control with the true risk value . 3 – Incidents and loss database Document “occurred risks“ or “external events“ (even if they weren’t being tracked as risks in the system yet), along with causes, related costs, and owners. Over time, the database will become a wealth of information, and you can add lessons learned back into 1) estimation of risk probability of occurrence, as well as 2) risk response playbooks. Additionally, this loss/event database can be fed or linked to other SAP applications where events are taking place (e.g. in EH&S for injury information, in GTS for number of customs violations, etc). Regulatory checklist approach has lead to over-controlling and under-controlling many processes Set controls based upon the level or risk associated with each business process Learn from previous experiences Incorporate into response playbook

49 AGENDA Partie I Quelques constats sur les pratiques actuelles
Partie II Quelques points d'attention à surveiller lors de la construction Partie III Les apports de l'approche Partie IV Les apports de SAP - GRC Partie V Questions / Réponses