PROGIFORUM Gouvernance, risque & conformité PROGIFORUM 12 Juin 2008 Construire un contrôle interne...

Gouvernance, risque & conformitéPROGIFORUMPROGIFORUM

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 ComptableAnimateur de la ligne de service Processus, Risques et Conformité

Alain NAULEAU BMA : Directeur de mission AssociéLigne de service Processus, Risques et Conformité

AGENDA

Partie I

Quelques points d'attention à surveiller lors de la construction

Quelques constats sur les pratiques actuelles

Partie II

Partie III

Partie IV

Les apports de l'approche

Les apports de SAP - GRC

Partie V Questions / Réponses

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éduresProcédures

Réf. sécuritéRéf. sécurité

SOX/LSFSOX/LSF

COSO 1COSO 1

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.

Conformité

Maitrisedes risques opérationnels

Améliorationde la

performance

Effort Croissant

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 descontrôles automatisés

– A certains processus informatiques(Accès auxdonnées, Gestion deschangements, Gestion desopérations, Gestion desprojets 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 p31du guide d’application décrivent les attentes en termed’IT)

ConformitéRéglementaire

Contrôle interne IT

Sécurité

Certains processusCertaines applicationsCertaines entités

Sur les ressources ITSur les applicationsToutes les entités

Autres processusAutres applications

Autres entités

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 »


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)1

2

4

5

6

"Aucune défaillance ou insuffisance grave de contrôle interne n'a été indentifié"

"Le groupe estime disposer d'un système de Contrôle Interne cohérent et adapté à ses activités"

3

7

"La présentation des résultats de la cartographie des risques a identifiée quatre risques majeurs et un plan d'action a été mis en place pour les suivre" (3 risques opérationneles et un risque liée au traitement de l'information comptable et financière)

"La mise en œuvre des procédures de Contrôle interne, testée au travers d'audits et de questionnaires d'auto-évaluation s'avère cependant inégale (sur les 93 entités). Le Groupe a donc engagé une démarche de détermination d'un référentiel des contrôles clés des entités permettant d'intentifier les contrôles incontournables sur les processus considérés comme critiques par la Direction du Groupe"

"L'un des risques majeurs identifiés - la sécurité des systèmes d'information - a donné lieu à des travaux importants de la la part de la DSI pour "Aucune déficience majeure signalée au président Directeur Générals par les Commissaires aux Comptes"

"Il n'est pas apparu de risques importants dont le niveau de maitrise n'est pas satisfaisant""Ces travaux (d'audit interne) n'ont pas révélé de défaillances ou d'insuffisances significatives de Contrôle interne"

En compléments de ces autoévaluations, tous les Directeurs de filiales et leurs Directeurs Financiers ont signé un lettre confirmant que les contrôles internes en place sont adéquats et fonctionnnent de manière à diriger les opérations. Dans cette lettre, ils attestent aussi la fiabilité des informations financières


Constat 2 : Très peu d’entreprises expriment un avis sur leur dispositif de contrôle interne

GlobalCompartiment

ACompartiment B

et C

Aucun avis ou commentaires 86%

Avis ou commentaires 14%Nombre de commentaires positifs 3 1Nombre de commentaires négatifs 1 2

Appréciation du contrôle interne

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

GlobalCompartiment

ACompartiment B

et C

Identification des risques 87% 96% 70%

en utilisant des cartographies 65% 60% 50%

Mention globale des risques 60%

Mention détaillée des principaux risques 40% 50% 25%

Lien entre les principaux risques mentionnés et les actions de maitrise

40% 50% 25%

Description des risques

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

GlobalCompartiment

ACompartiment

B et C

Description précise 6%Description très succinte 32%Pas de description 62%

Dispositif de Contrôle Interne des Systèmes d'information

Répartition pas significativement différente entre les compartiments

94 %

Quelle perception les entreprises ont-elles de leurs risques IT ?

Votre organisme/entreprise vous semble-t-elle exposée à des risques informatiques ? *

L’activité de votre entreprise dépend-elle des systèmes d’information ? *

* « Risques technologiques et risk management » - AFAI

• Plus de 80 % se perçoiventcomme étant exposéesà des risques informatiques.

•La grande majorité del’activité desentreprises dépend de leur système d’informations.

Où en est la réflexion portant sur les risques IT ?

* « Risques technologiques et risk management » - AFAI

Existe-t-il au sein de votre entreprise une 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 ellesn’ont pas de référentiels des risquestechnologiques.

•Près de 70% d’entre ellesn’ont pas de définitiondes risquestechnologiques.

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

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

AGENDA

Partie I



Partie II

Partie III

Partie IV




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

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 »

Situation actuelleAdéquation du dispositifde 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 interneIT aux risques IT

Situation cible


Description desprocessus IT

Identification des « zonesde risques »

Évaluation desrisques

Définition du dispositif

de contrôle

Une approche en quatre étapes


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.





de contrôle

11


Illustration d’un processus IT Cas simplifié du processus« Gestion des changements » de l’application de consolidation

Enregistrement d’une

demande de changement

Approbation

Recette fonctionnelle

Réalisation du

changement

Validation technique

(unitaire, intégration, …)

Mise en

production

Approbation pour

Mise en production


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.





de contrôle

22


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





de contrôle


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.





de contrôle

33


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

Approbation

Recette fonctionnelle

Réalisation du

changement

Validation technique

(unitaire, intégration, …)

Mise en

production

Approbation pour

Mise en production

FR01-Demande de changement non enregistrée

FR02- Etude d’impact du changement non réalisée

FR03-Demande de changement lancée sans approbation

FR06-Accès à l’environnement de production non contrôlé

FR05-Absence de

validation fonctionnelle

d’une règle de consolidation

Groupe

FR04-Absence de validation fonctionnelle d’une

modification portant sur la saisie des liasses

de consolidation

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

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

C1 : «Indisponibilité majeure des informations »C1 : «Indisponibilité majeure des informations »




C2 : «Fraude »C2 : «Fraude »

C3 : «Résultats financiers non-conformes à la réalité »C3 : «Résultats financiers non-conformes à la réalité »

C3 : «Résultats financiers non-conformes à la

réalité »

C3 : «Résultats financiers non-conformes à la

réalité »



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é

C1 : «Indisponibilité majeure des informations » C3 : «Résultats financiers non-conformes à la réalité »


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





de contrôle

44

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 2Rare Less than once a year 1


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.

Nature of risk Consequence Impact MetricIT System outage 0 Stoppage less than 5 minutesIT System outage 1 Stoppage less than 1 hourIT System outage 2 Stoppage less than 4 hoursIT System outage 3 Stoppage less than 12 hoursIT System outage 4 Stoppage less than 48 hours

Nature of risk Conséquence Impact MetricIT System outage 0 Stoppage with no impact on the businessIT System outage 1 Stoppage with limited impact on the businessIT System outage 2 Stoppage with an impact on the business but workarounds possibleIT System outage 3 Stoppage that prevents continuation of business operations

Fort

Faible

Faible

Faible

Fort

Faible

Fréquence

1

Vol d’informations / Diffusion non

maîtrisée

3

0

3

3

Diffusion d’information fausse

ou incomplète

Indisponibilité majeure des informations

2FR06-Accès à l’environnement de production non contrôlé

3FR05-Absence de

validation fonctionnelle d’une règle de

consolidation Groupe

3FR04-Absence de

validation fonctionnelle d’une modification

portant sur la saisie des liasses de consolidation


3FR02- Etude d’impact du changement non réalisée

3FR01-Demande de changement non enregistrée

Fort

Faible

Faible

Faible

Fort

Faible

Fréquence

1


maîtrisée

3

0

3

3


ou incomplète



3FR05-Absence de



3FR04-Absence de






Le résultat : une matrice de criticité partagée entre l’IT et les métiers

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

Fort

Faible

Faible

Faible

Fort

Faible

Fréquence

1


maîtrisée

3

0

3

2


ou incomplète



3FR05-Absence de



1FR04-Absence de






Fort

Faible

Faible

Faible

Fort

Faible

Fréquence

1


maîtrisée

3

0

3

2


ou incomplète



3FR05-Absence de



1FR04-Absence de






Fort

Faible

Faible

Faible

Fort

Faible

Fréquence

1


maîtrisée

3

0

3

3

Diffusion d’information

fausse ou incomplète

Indisponibilitémajeure des informations


2FR05-Absence de



1FR04-Absence de

validation fonctionnelle d’une

modification portant sur la saisie des

liasses de consolidation




Fort

Faible

Faible

Faible

Fort

Faible

Fréquence

1


maîtrisée

3

0

3

3

Diffusion d’information

fausse ou incomplète

Indisponibilitémajeure des informations


2FR05-Absence de



1FR04-Absence de

validation fonctionnelle d’une

modification portant sur la saisie des

liasses de consolidation




L’évaluation est réalisée par processus et par application.

Criticité = Probabilité x GravitéG=3 G=4 G=4 G=4

G=2 G=3 G=3 G=3

G=1 G=2 G=2 G=3

G=0 G=0 G=1 G=1

I=4

I=3

I=2

I=1

P=4P=3P=2P=1

Impact

Probabilité

AGENDA

Partie I



Partie II

Partie III

Partie IV




Zone de risque à couvrir

1 - Obtenir une vision unifiée de la couverture des risques métier et IT

Dispositif de contrôlemétier

Dispositif decontrôle IT

2/ Identifier et couvrir les zones de risques résiduelles

3/ Transferer la couverture du risque

4/ Alléger le dispositif

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

2 - Adapter le niveau de protection au niveau de risque métier et IT.

Sur Protection

Sous Protection

Inapproprié

Trop systématique

Trop lourd

Trop éclaté

Trop fréquent Réduction de la fréquence de contrôle

Suppression du contrôle

Ajuster les attributs des contrôles existants :Préventif vs Détectif

Automatisation du contrôleFréquence de contrôle

Changement du niveau de contrôle (Environnement de contrôle vs contrôle applicatif)

Changement du mode de test

Regroupement de contrôles et ou de tests

Réduction du périmètre des populations ou activités à contrôler

Mettre en place un ou des contrôles complémentaires

Changement de point de vue en fonction des acteurs concernés :Transfert de la couverture du risque

Les contrôles n’existent pas

Les contrôles existent

Corrections possiblesNiveau de protection État du dispositif

Changement du mode de test

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

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

Nombre de contrôles avant optimisation

19 16 32 29 28 29 42 27 51 21 294

Nombre de contrôles supprimés 2 1 6 9 4 5 16 9 7 0 59

Nombre de contrôles regroupés 1 1 7 3 2 1 4 2 0 0 21

Nombre de contrôles/tests modifiés 7 2 3 10 4 8 9 7 9 0 59

Nombre de contrôles/tests avec modifications mineures

6 8 12 7 15 10 1 8 1 0 68

Nombre de contrôles inchangés 3 4 4 0 3 5 14 1 34 0 68

Nombre de contrôles final 16 14 19 17 22 23 22 16 44 21 214

en % 16% 13% 41% 41% 21% 21% 48% 41% 14% 0% 27%

Nombre de contrôles dont le niveau de test a été diminué

3 2 2 7

Nombre de contrôles dont le niveau de test a été augmenté

2 2

Nombre de contrôles/tests dont la fréquence a été diminuée

6 7 1 14

Nombre de contrôles/tests dont la fréquence a été augmentéeNombre de contrôles/tests dont le périmimètre/la période a été diminué(e)

2 2

Nombre de contrôles/tests dont le périmimètre/la période a été augmenté(e)

2 2

Nombre de suppressions à valider 0 1 2 0 0 0 0 1 0 0 4

Appli1 Appli2 Appli3 Appli4 Appli5 Appli6 Appli7 Appli8 …

Contrôlesavant

Contrôlesavant

Contrôlesaprès

Contrôlesaprès

Impactssur les

tests

Impactssur les

tests

AGENDA

Partie I



Partie II

Partie III

Partie IV


Les apports de SAP-GRC


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.

© SAP 2007 /

Illustration d’un processus de gestion de sinistre:

Ouverture

Règlement

Recours

Identification du

contrat

Vérification de

Couverture

Données généralesdu sinistre

Garantiestouchées

Evaluationdu

sinistre

Missionexpert

Mission réparateur

Saisie tiers et

témoins

Saisie des

bénéficiaires

Demande de

règlement

Vérificationdes

plafonds

Modification

Annulation Décaissement

Création d’intervenant

Evaluation Saisie

dubénéficiaire

Saisie du

bénéficiaire

Saisie du

règlement

Décaissement / encaissement

Back office de gestion

Centre d’appels

Instruction du dossier

Saisie du règlement

Saisie des honoraires

Recherche d’intervenant

Création

- Impossibilité de créer, régler et décaisser un sinistre….

- Impossibilité de créer un expert puis de régler ses honoraires ….

Pour une même personne:

Multiple Controls

Des contrôles automatiques IT pour prévenir des risques métiers

Any Form, Tab or Field

...

Apply percentage threshold

Apply absolute value threshold

Monitor change frequency

Monitor changes to control

Check that control value exists

Is the Duplicate Voucher flag turned ON?

Have any duplicate vouchers been

processed over the past 30, 60, 90 days?

Hide / Disable / Query Only

Has the duplicate Voucher control

changed? How often?

Configuration, Master Data and Transaction Data

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

Perform Assessments

Test Automated Controls

Test Manual Controls

Doc

ume

ntT

est

Mon

itor

Cer

tify

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

11

34

5

6

910

1112

1516

1718

19

78

1314

2223

2425

26

2021

2930

2728

2

SAP GRC Process Control - Convergence of Controls Process Management and Continuous Controls Monitoring

Perform Assessments

Test Automated Controls

Test Manual Controls

Doc

ume

ntT

est

Mon

itor

Cer

tify

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

11

34

5

6

910

1112

1516

1718

19

78

1314

2223

2425

26

2021

2930

2728

2

SAP GRC Process Control: Centralized Control Management

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

Three Ways to Monitor Automated Controls Across Critical Business Processes

Construct

Ad-hoc Test

Re-use Custom

Test

Select

Pre-delivered Test

Pre-delivered tests with flexible rule criteria for SAP and Oracle

Plug-and-play your existing test scripts

Create control tests on-the-fly with custom query builder

Order to Cash Order Capture Order Fulfillment Billing &Returns

Procure to Pay DemandPlanning

Operational Procurement

Reconcile to Report Budgeting Planning Subledger Transactions

FinancialClose

IT Basis Application Security

Change Control

RevenueRecognition

Inventory Management

PayablesManagement

Consolidation& Reporting

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

SAP GRC Access ControlSustainable prevention of segregation of duties violations

Cross-enterprise library of best practice segregation of duties rules

Compliant User Provisioning

Prevent SoD violations at

run time

Compliant User Provisioning

Prevent SoD violations at

run time

Superuser Privilege Management

Close #1 audit issue with temporary

emergency access

Superuser Privilege Management

Close #1 audit issue with temporary

emergency access

Periodic Access Review and Audit

Focus on remaining challenges during recurring audits

Periodic Access Review and Audit

Focus on remaining challenges during recurring audits

(Stay in Control)(Stay Clean)

Risk analysis, remediation and prevention services

Enterprise Role Management

Enforce SoD compliance at

design time

Enterprise Role Management

Enforce SoD compliance at

design time

Risk Identification and Remediation

Rapid, cost-effective and comprehensive

initial clean-up

Risk Identification and Remediation

Rapid, cost-effective and comprehensive

initial clean-up

(Get Clean)

Minimal Time To Compliance

Minimal Time To Compliance

Continuous Access Management

Continuous Access Management

Effective Management Oversight

and Audit

Effective Management Oversight

and Audit

SAP GRC Risk ManagementProviding the framework for an integrated approach to ERM

Business Process Platform

SAP GRC Risk Management

GRC Repository

Global Trade Environment / Safety Supply Risk xApp Others…Access / Process

External Provider

KRIs / ContentSources

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

Risks Management Steps Process automation for the virtuous cycle

Actionable, role-based dashboards

and alerts

Establish risk appetite

and thresholds

Collaborate and aggregate across the

enterprise

Balance cost of risk avoidance and opportunity

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 2Supplier on-time

delivery

Supply chain continuity risk

Document Risk Appetite

<95%

5%

KRI 1Scrap Rates

Identify KRI Thresholds

Avoid SurprisesIdentify and assess all key risks across the enterprise

Collaborative Assessments for Manual Risk Activities

Qualitative & quantitative point and scenario analyses

Survey functionality and guided activities

Workflow reminders for updates

Prioritization using Risk Heat Map

Prioritization for response investment

Identifying shifting in risk profile

Automatically Identify Risks

User receives email alert – data updated in SAP GRC Risk Management

Embedded into key business processes

Workflow delivers assessments to experts

Respond IntelligentlyCreate resolution strategies for critical risks

Best Practice Response Playbooks

Spot Risk Interdependencies

Ma

rketing

Sale

s

IT

Sup

ply

...

Correlation

Enabling Lines of Business toMitigate Risks

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

Top Industry Risks Solution

Response status monitoring

Response cost tracking

Analysis done before and after responses

Supplier Bankruptcy

Pre-emptive marketing campaign

Stay InformedBuild proactive monitoring into existing business processes

Capture Incidents and LossesSet Control Limits Based Upon

Associated Risk

Learn from previous experiences

Incorporate into response playbook

Latest Risk Management Status in Your Business Context

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

Role-based Risk Management Dashboards SAP CPM Dashboards

AGENDA

Partie I



Partie II

Partie III

Partie IV




PROGIFORUM Gouvernance, risque & conformité PROGIFORUM 12 Juin 2008 Construire un contrôle interne...

Documents

Transcript of PROGIFORUM Gouvernance, risque & conformité PROGIFORUM 12 Juin 2008 Construire un contrôle interne...