les contrôles et le risque des systèmes d’information 1 - les... · comme étant les contrôles...

Les contrôles et le risque

des systèmes d’information

2ème édition

Contenu

3

Résumé ............................................................................................................................................................. 4

1. Introduction ................................................................................................................................................ 5

2. Fondamentaux concernant les risques et les contrôles des SI ................................................................ 8 2.1 Concepts clés ....................................................................................................................................... 82.2 Gouvernance des SI ............................................................................................................................ 9

3. Parties prenantes internes et responsabilités des SI .............................................................................. 12

4. L’analyse des risques ................................................................................................................................ 144.1 Prise en compte du risque dans l’évaluation de l’adéquation des contrôles des SI .................... 14

4.1.1 L’environnement des SI ............................................................................................................ 154.1.2 Les risques informatiques rencontrés par l’organisation ...................................................... 154.1.3 L’appétence pour le risque et la tolérance au risque .............................................................. 154.1.4 L’analyse des risques ................................................................................................................ 16

4.2 Stratégies de traitement des risques ................................................................................................ 16

5. Évaluation des SI — une vue d’ensemble .............................................................................................. 18

6. Comprendre l’importance des contrôles des SI ..................................................................................... 226.1 Les contrôles généraux et applicatifs des SI ................................................................................... 22

6.1.1 Les contrôles généraux ............................................................................................................. 226.1.2 Les contrôles applicatifs ........................................................................................................... 23

6.2 Les contrôles de la gouvernance, du management et techniques des SI ..................................... 236.2.1 Les contrôles de la gouvernance des SI .................................................................................. 246.2.2 Les contrôles du management ................................................................................................ 246.2.3 Les contrôles techniques .......................................................................................................... 246.2.4 Les contrôles applicatifs ........................................................................................................... 24

6.3 Quels contrôles des SI ? ................................................................................................................... 246.3.1 Règles et procédures ................................................................................................................. 256.3.2 Normes ...................................................................................................................................... 256.3.3 Organisation et management .................................................................................................. 266.3.4 Contrôles physiques et environnementaux ............................................................................ 276.3.5 Contrôles des logiciels systèmes ............................................................................................. 286.3.6 Contrôles de l’acquisition et de développement des systèmes ............................................. 286.3.7 Contrôles applicatifs ................................................................................................................. 29

6.4 Sécurité informatique ....................................................................................................................... 306.5 Cadre de contrôle des SI .................................................................................................................. 30

7. Compétences et savoir-faire dans le domaine de l’audit des SI ........................................................... 31

8. Utilisation du cadre de contrôle .............................................................................................................. 328.1 Techniques d’audit assisté par ordinateur et analyse des données ............................................... 328.2 Recours à l’évaluation automatisée des risques ............................................................................. 338.3 Reporting des contrôles des SI ........................................................................................................ 33

9. Conclusion ................................................................................................................................................ 35

Auteurs et réviseurs ...................................................................................................................................... 36

Annexe : Liste de vérification du Cadre de contrôles des SI ..................................................................... 37

A propos du CRIPP ...................................................................................................................................... 39

Résumé

4

Ce guide pratique d’audit des technologies(GTAG) aide les responsables de l’audit interne(RAI) et les auditeurs internes à rester en phaseavec l’univers en constante évolution et parfoiscomplexe des systèmes d’information (SI), en pro-posant un document destiné aux dirigeants d’en-treprise - et non aux responsables des SI. Ladirection générale et le Conseil attendent de l’au-dit interne qu’il donne une assurance concernantles risques majeurs, notamment ceux introduits ouinduits par la mise en œuvre des SI. La série desGTAG aide les RAI et les auditeurs internes àmieux comprendre les risques liés aux SI ainsi queles problématiques de contrôle et de gouvernancey afférents.

Ce GTAG a pour objectif d’aider les auditeursinternes à mieux appréhender les contrôles géné-raux des SI de façon à pouvoir échanger avec leurConseil et partager des idées sur les risques et lescontrôles avec le directeur des systèmes d’infor-mation. Ce GTAG décrit la façon dont la directiongénérale, le management, les spécialistes des sys-tèmes d’information et les auditeurs internesgèrent les problématiques importantes relativesaux risques et aux contrôles, et présente des cadrespertinents pour évaluer les risques et les contrôlesdes SI. En outre, il pose les bases des GTAG sui-vants, qui sont consacrés à des sujets plus préciset présentent avec plus de détails les fonctions etresponsabilités correspondantes dans l’entreprise.

Ce guide est la deuxième édition du premier voletde la série des GTAG - GTAG 1 : « Les contrôlesdes systèmes d’information » - publié en mars2005.

GTAG – Introduction

5

1. Introduction

Ce GTAG a pour objectif d’expliquer les risques etles contrôles des SI afin de permettre aux RAI etaux auditeurs internes de comprendre et de com-muniquer sur la nécessité de disposer de solidescontrôles des SI. Ce GTAG présente les compo-santes clés de l’évaluation des contrôles des SI, enmettant l’accent sur les fonctions et les responsa-bilités des principaux acteurs de l’organisation quipeuvent dicter la gouvernance des SI. Certains lec-teurs reconnaîtront peut-être des éléments de ceGTAG, toutefois certaines parties offrent de nou-velles perspectives sur la façon d’aborder lesrisques et les contrôles des SI. L’un des objectifs dela série des GTAG est d’utiliser différentes com-posantes de l’évaluation des contrôles des SIcomme moyens de sensibilisation aux risques etaux contrôles des SI ainsi qu’aux raisons pour les-quelles la direction générale et les auditeursinternes devraient veiller à ce qu’un environne-ment de contrôle efficace et pérenne soit mis enplace pour maîtriser les risques liés aux SI.

Bien que la technologie offre des opportunités decroissance et de développement, elle s’accom-pagne également de menaces telles que des dys-fonctionnements, des manœuvres répréhensibles,des vols et des fraudes. Les recherches montrentque les organisations sont menacées par desattaques externes, néanmoins les personnes deconfiance, bien informées, représentent unemenace bien plus importante. Heureusement, latechnologie peut également protéger desmenaces, comme le montre ce guide. Les diri-geants devraient être en mesure de poser lesquestions appropriées et d’appréhender lesréponses apportées. Par exemple : • Pourquoi devrais-je comprendre les risques etles contrôles des SI ? La réponse tient en deuxmots : assurance et fiabilité. Les dirigeantsjouent un rôle clé dans l’assurance de la fiabi-lité des informations. L’assurance repose surun ensemble de contrôles métier interdépen-dants, ainsi que sur des preuves que lescontrôles sont continus et suffisants. Le mana-gement doit examiner les preuves résultant de

ces contrôles et des missions d’audit etconclure qu’ils donnent une assurance raison-nable.

• Que signifie être protégé ? La confiance repré-sente le fondement de l’organisation et de sonefficacité. Ainsi, la fiabilité des informations etdes processus financiers – obligatoires pour denombreuses organisations – repose sur laconfiance. Cette confiance s’appuie sur descontrôles qui passent souvent inaperçus car ilssont intégrés dans le SI.

• Dans quels domaines les contrôles des SI s’ap-pliquent-ils ? Dans tous les domaines. Les SIenglobent les composantes, les processus, lesressources humaines, l’organisation et l’archi-tecture technologiques, ainsi que les informa-tions. Bon nombre de contrôles des SI sont denature technique, et les SI fournissent les outilspour un grand nombre de contrôles métiers.

• Qui est responsable ? Chacun est responsable.Toutefois, l’affectation du contrôle et des res-ponsabilités doit être définie et communiquéepar le management, faute de quoi personne nesera effectivement responsable, ce qui peutentraîner de graves conséquences.

• Quand les risques et les contrôles des SIdevraient-ils être évalués ? Toujours. L’environ-nement des SI, qui favorise l’évolution desprocessus et de l’organisation, connaît deschangements rapides. De nouveaux risquesémergent rapidement. Les contrôles doiventapporter continuellement la preuve de leurefficacité, preuve qui doit être appréciée et éva-luée constamment.

• Quel est le niveau de contrôle suffisant ? Ilappartient au management d’en décider, enfonction l’appétence pour le risque, de la tolé-rance au risque et des réglementations envigueur. Les contrôles ne représentent pas unobjectif ; ils visent à contribuer à la réalisationdes objectifs de l’organisation. Les contrôlesconstituent un coût intrinsèque à l’activité, qui


6

peut être élevé, mais sans commune mesureavec les éventuelles conséquences de contrôlesinadéquats.

Les contrôles des SI sont essentiels pour protégerles actifs, les clients, les partenaires et les donnéessensibles, pour faire preuve d’un comportementsûr, efficace et éthique, et pour préserver lamarque, la réputation et la confiance. Dans l’envi-ronnement actuel de mondialisation et de régle-mentation, il est facile de perdre ces actifs. Un RAIpeut s’appuyer sur ce guide pour évaluer le cadreet les pratiques d’audit interne de l’organisationdans le domaine des risques et des contrôles desSI, de la conformité et de l’assurance. Ce guidepeut également être utilisé pour relever les défisinhérents à des menaces qui changent constam-ment, sont de plus en plus complexes et évoluentrapidement, ainsi qu’à la nécessité d’accroître l’ef-ficacité.

Les contrôles des SI n’existent pas isolément. Ilsforment un dispositif continu de protection dontles éléments sont interdépendants, et dont l'inté-grité peut être compromise si les liens entre euxsont peu solides. Potentiellement sujets à deserreurs et des contournements, les contrôles desSI vont du plus simple au plus complexe, et s’in-tègrent dans un environnement dynamique. Lescontrôles des SI comportent principalement deuxvolets : l’automatisation des contrôles métiers (enappui du management de l’organisation et de lagouvernance) et le contrôle de l’environnementdes SI et des activités (en appui des applicationset de l’infrastructure des SI). Le RAI doit prendreen compte et évaluer ces deux éléments. Il peutconsidérer les contrôles métiers automatiséscomme étant les contrôles nécessitant le regrou-pement de compétences d’audit opérationnel etd’audit informatique associées sous la forme d’au-dit intégré. Le RAI peut également souhaiter sépa-rer les contrôles généraux des SI ou les contrôlesinformatiques généraux sur la base des compé-tences techniques nécessaires pour évaluer desapplications, infrastructures et activités plus tech-niques. Ainsi, un Progiciel de Gestion Intégré (PGIaussi appelé ERP - enterprise resource planning)

fait davantage appel à des connaissances tech-niques et opérationnelles pour comprendre et éva-luer les contrôles des structures de la base dedonnées, des accès utilisateurs, de la configurationdu système et du reporting financier. Le RAIconstatera que l’évaluation des infrastructurestelles que les réseaux, les routeurs, les pare-feux etles appareils sans fil et mobiles exige des compé-tences et une expérience spécifiques. Pour lescontrôles des SI, l’auditeur interne doit toutd’abord disposer d’une bonne compréhension desconcepts avant de pouvoir tirer les conclusionsd’une évaluation des risques et des contrôles. L’au-dit interne suppose une interaction forte avec lespersonnes ayant des responsabilités de contrôles,et requiert un maintien à jour des connaissances,et des évaluations continues en fonction del’émergence de nouvelles technologies, et del’évolution des opportunités, usages, dépen-dances, stratégies, risques et besoins de l’organi-sation.

Les contrôles des SI apportent une assurancequant à la fiabilité de l’information et des servicesrendus. Ils permettent d’atténuer les risques inhé-rents à l’usage des SI. Il peut s’agir des politiquesde l’organisation aussi bien que de leur mise enœuvre dans des programmes informatiques, de laprotection des accès physiques à la capacité detracer les actions et les transactions des utilisa-teurs, de validations automatiques ou encore desanalyses de cohérence pour de grands volumes dedonnées.

Les exemples suivants illustrent des conceptsessentiels de ces contrôles : • Les contrôles des SI présents dans le systèmede contrôle interne fournissent une assurancequant au niveau de maîtrise des risques. Cescontrôles doivent être continus et s’appuyersur des éléments de preuve traçables et fiables.

• L’assurance de l’auditeur interne est une éva-luation indépendante et objective du bon fonc-tionnement des contrôles des SI. Cetteassurance repose sur la compréhension, l’exa-men et l’évaluation des contrôles clés liés auxrisques qu’ils doivent traiter, et sur la réalisa-


7

tion de tests suffisants pour s’assurer de laconception adéquate des contrôles et de leurfonctionnement efficace et continu.

De nombreux cadres de référence permettent decatégoriser les contrôles des SI et leurs objectifs.Ce guide recommande que chaque organisationemploie les composantes applicables des cadresde référence existants pour catégoriser et évaluerles risques et les contrôles des SI.

GTAG – Fondamentaux concernant les risqueset les contrôloes des SI

8

2. Fondamentauxconcernant les risques etles contrôles des SI

2.1 Concepts clés

Les organisations continuent d’exploiter l’évolu-tion constante de la technologie pour développerleur offre et leurs services, nécessitant ainsi uneadaptation de la profession d’audit interne. LesNormes internationales pour la pratique profession-nelle de l’audit interne de l’IIA (les Normes) préci-sent que les auditeurs internes doivent évaluer lesrisques et les contrôles pour les systèmes d’infor-mation de l’organisation. Avec les GTAG, l’IIAdonne une autre perspective sur l’évaluation desrisques et des contrôles des SI. Le GTAG 4« Management de l’audit des systèmes d’informa-tion » aborde l’analyse les risques liés aux SI etl’univers de risque des SI qui en découle. LeGTAG 11 « Élaboration d’un plan d’audit des SI »aide l’audit interne à évaluer les processus métierssoutenus par la technologie et les éventuels com-posants de l’univers d’audit des SI. En outre, leGTAG 8 « Audit des contrôles applicatifs » couvreles aspects propres à l’audit des contrôles applica-tifs et l’approche pouvant être adoptée par l’auditinterne lors de l’évaluation de ces contrôles.

Dans ce GTAG, le terme « Conseil » est utilisé ausens du glossaire des Normes. Le Conseil est « leniveau le plus élevé des organes de gouvernance,responsable du pilotage, et/ou de la surveillancedes activités et de la gestion de l'organisation.Habituellement, le Conseil (par exemple, unconseil d’administration, un conseil de surveil-lance ou un organe délibérant) comprend desadministrateurs indépendants. Si une telle ins-tance n’existe pas, le terme « Conseil », utilisé dansles Normes, peut désigner le dirigeant de l’orga-nisation. Le terme « Conseil » peut renvoyer aucomité d’audit auquel l’organe de gouvernance adélégué certaines fonctions ».

Comme plus amplement analysé dans ce GTAG,l’évaluation des risques et des contrôles des SI mis

en place pour les gérer doit être associée à l’envi-ronnement des processus métiers et aux objectifsspécifiques de l’organisation devant être atteints,conformément aux attentes des dirigeants et duConseil. Les risques liés aux SI, qui ne représen-tent qu’une partie de l’interconnexion complexedes personnes, des processus, de l’infrastructure etde l’environnement de risque existant, devraientêtre gérés de façon globale par l’organisation.

Les auditeurs internes doivent comprendre l’éven-tail des contrôles dont ils disposent pour limiterles risques liés aux SI. Les contrôles peuvent êtreenvisagés selon une séquence qui tient compte deleur interconnexion et du fait que l’échec d’unensemble de contrôles peut entraîner une dépen-dance accrue et la nécessité d’un examen desautres groupes de contrôle. Les contrôles SI traitésdans ce document sont de différents ordres selonla personne qui les met en œuvre et les gère ausein de l’organisation. Il peut s’agir de contrôlesau niveau de la gouvernance, du management ; decontrôles techniques ou applicatifs (cf. §6.2).

On peut aussi considérer les contrôles des SI sousl’angle des contrôles généraux des SI et descontrôles applicatifs. Les contrôles généraux desSI sont, par nature, fondamentaux et sont revus autravers de différentes méthodes d’audit. Citons parexemple l’exploitation des SI, le développement etla maintenance d’applications, la gestion des uti-lisateurs, la gestion des changements, ainsi que lasauvegarde et la restauration de données. Lescontrôles applicatifs représentent une autre caté-gorie de contrôles et englobent les contrôles desdonnées en entrée, des traitements, et des don-nées en sortie.

Ce GTAG analyse également l’utilisation descontrôles dans le cadre de la gestion et du pilotagede l’infrastructure, des processus et du personnelsoutenant l’organisation au travers de la techno-logie. La gouvernance des SI continue d’évoluerau sein des organisations en raison de l’utilisationcontinue des SI, et de la supervision accrue par ladirection générale et le Conseil.


9

2.2 Gouvernance des SI

Un aspect important de la question des contrôlesdes SI est celle de la gouvernance des SI, qui offreun cadre garantissant que les SI peuvent répondreaux besoins opérationnels de l’organisation. Pourle management des SI, il est important d’acquérirune solide compréhension des processus métiersde l’organisation utilisés pour atteindre ses objec-tifs et atteindre les buts fixés par la direction géné-rale et le Conseil. La gouvernance des SI ne selimite pas aux contrôles nécessaires à la gestiondes risques identifiés, mais représente égalementune structure intégrant des pratiques et le person-nel informatique. Elle doit être étroitement alignéesur les stratégies et objectifs de l’organisation, pouren permettre leur réalisation.

Un RAI doit pouvoir évaluer la structure de gou-vernance des SI et sa capacité à produire des résul-tats pour l’organisation, et accroître l’efficience desactivités informatiques. Les recherches montrentque la gouvernance des SI se traduit par une amé-lioration de la performance opérationnelle, et parun meilleur alignement des SI avec l’entreprisedans la réalisation de ses objectifs stratégiques.

La gouvernance des SI englobe le leadership, lesstructures organisationnelles et les processus assu-rant que les SI de l’organisation maintiennent etsoutiennent les stratégies et objectifs de l’organi-sation.

La Norme 2110.A2 de l’IIA précise que l’auditinterne doit évaluer si la gouvernance des SI del’organisation soutient la stratégie et les objectifsde l’organisation ; les RAI doivent donc être prêtsà évaluer cet aspect clé de l’environnement globaldes SI.

Une bonne application des principes de gouver-nance des SI peut influencer et affecter l’ensemblede l’organisation et son interaction avec les SI.

• Identifier et gérer les risques liés aux SI etpermettre une amélioration des SI : la gou-vernance des SI contribue à assurer l’existence

d’un lien étroit avec les activités de gestion desrisques d’une organisation, notamment lemanagement des risques de l’entreprise(ERM). La gouvernance des SI doit faire partieintégrante de la gestion globale des risques del’organisation, de sorte que les techniquesappropriées puissent être intégrées aux activi-tés des SI, notamment la communication surl’état des risques (aux principales parties pre-nantes) dans l’ensemble de l’organisation. LeRAI devrait revoir les activités de gestion desrisques mises en œuvre dans l’ensemble del’organisation et veiller à ce qu’il existe desliens entre efforts de gestion des risques des SIet activités à risque de l’organisation, et à ceque le profil de risque des SI reçoive l’attentionappropriée.

• Renforcer la relation entre les directionsmétiers et la direction des SI : la gouver-nance des SI établit un mécanisme reliant l’uti-lisation des SI aux stratégies et objectifs del’organisation. La relation entre les directionsmétiers et la direction des SI (DSI) permettrade veiller à ce que les ressources informatiquesfassent ce qu’il faut au moment opportun. Lacommunication entre la DSI et les directionsmétiers devrait être fluide et informative, don-nant des éclairages sur les apports des SI, ainsique sur l’état d’avancement de ses efforts. LeRAI devrait revoir cet alignement, et s’assurerde l’existence de solides processus de gestiondu portefeuille applicatif qui permettent auxdirections métiers et à la DSI de collaborer surles initiatives et sur les décisions d’investisse-ment globales.

• Obtenir une visibilité sur la capacité dumanagement des SI à réaliser ses objectifs :la DSI définira sa stratégie en appui de l’orga-nisation, ce qui consiste pour partie à veiller àl’exploitation efficiente et sans compromis desSI au quotidien. Les indicateurs et les objectifssont définis non seulement pour aider la DSIà délivrer et opérer les SI, mais également pourguider les activités des informaticiens vers uneamélioration de la maturité de ses pratiques.


10

Les résultats permettront à la DSI d’exécutersa stratégie et d’atteindre les objectifs approu-vés par le management de l’organisation. LeRAI devrait évaluer si le lien entre indicateurset objectifs des SI est aligné sur ceux de l’orga-nisation et mesure la progression des initia-tives approuvées. En outre, le RAI peut aider àvalider que les indicateurs sont correctementmesurés et qu’ils donnent une image réalistede l’exploitation et de la gouvernance des SIsur les plans tactique et stratégique.

• Gérer les risques et identifier les opportu-nités d’amélioration continue pour l’orga-nisation et les conséquences pour les SI : lagestion des risques est une composante cléd’une structure de gouvernance des SI efficaceau sein d’une organisation. L’identification etla gestion des risques liés aux SI permettront àla DSI de fonctionner plus efficacement, touten identifiant des opportunités potentiellesd’amélioration de ses pratiques. Les risquesliés aux SI devraient être rattachés à des pro-priétaires, qui communiquent méthodique-ment sur l’état d’avancement des efforts degestion des risques à tous les niveaux de l’or-ganisation. Le RAI joue un rôle importantlorsqu’il valide la cohérence de l’univers desrisques liés aux SI. Il utilisera les informationspour aider à définir l’univers de l’audit interneen vue d’une évaluation des risques indépen-dante et de l’élaboration du plan d’audit. LeRisk IT Practitioner Guide élaboré par l’ITGovernance Institute (ITGI) et l’ISACA offreun cadre de référence pour l’identification etl’évaluation des risques liés aux SI, tout en éta-blissant un lien direct avec le cadre de réfé-rence COBIT (Control Objectives for Informationand Related Technology).

• Améliorer, grâce à la gouvernance des SI,la flexibilité des SI en réponse aux évolu-tions de l’organisation et de l’environne-ment des SI : la gouvernance des SI offre desbases permettant à la DSI de mieux gérer sesresponsabilités et d’apporter un meilleur sou-tien à l’organisation grâce à des processus ainsi

que des rôles et responsabilités de son person-nel informatique clairement définis. Ce type deformalisation permet aux SI de mieux identifierles anomalies potentielles au quotidien et leurévolution tendancielle, et donc d’identifier lacause à l’origine des constats et des dysfonc-tionnements. En outre, la DSI a la capacité des’adapter plus facilement aux demandes ponc-tuelles de capacités opérationnelles nouvellesou accrues. Aujourd’hui, le RAI peut utiliser cessources de données (par exemple le supporttechnique et les tickets de gestion de pro-blèmes) pour évaluer comment les SI gèrentles problèmes inconnus. Le RAI peut égale-ment examiner les processus de gestion deportefeuille des SI pour comprendre la façondont les besoins sont hiérarchisés, et s’il existeune flexibilité pour définir une nouvelle prio-rité des besoins en fonction des évolutions despriorités de l’organisation.

Lorsqu’il évalue la structure et les pratiques degouvernance des SI d’une organisation, l’auditinterne peut examiner plusieurs composantes clésqui conduisent à une gouvernance efficace des SI,notamment :

• Le leadership. Évaluer la relation entre lesobjectifs des SI et les besoins actuels et straté-giques de l’organisation. Évaluer l’implicationdes responsables informatiques dans le déve-loppement et la concrétisation des objectifsstratégiques de l’organisation. Examiner lesmodalités d’affectation des rôles et des respon-sabilités au sein de l’activité des SI, et si le per-sonnel les exécute comme prévu. Examinerégalement la contribution de la direction géné-rale et du Conseil pour instaurer et maintenirune solide gouvernance des SI.

• Les structures organisationnelles. Examinercomment le personnel informatique et lesdirections métiers interagissent et commu-nique les besoins actuels et futurs dans le cadrede la structure organisationnelle existante. Cetexercice devrait couvrir l’existence des fonc-tions nécessaires et des rattachements hiérar-


11

chiques permettant à la DSI de répondreconvenablement aux besoins opérationnelstout en permettant aux demandes du métierd’être gérées via une évaluation et une hiérar-chisation formelles.

• Les processus des SI. Évaluer les activités etles contrôles des SI existants pour gérer lesbesoins opérationnels, tout en donnant l’assu-rance nécessaire sur les processus métiers etles systèmes sous-jacents. L’activité des SI uti-lise les processus pour soutenir l’environne-ment des SI et contribuer à l’homogénéité desservices fournis. Déterminer comment la DSIsera évaluée sur sa faculté à aider l’organisa-tion à atteindre ses objectifs.

• La gestion des risques. Examiner les proces-sus de l’activité des SI pour identifier, évalueret suivre / atténuer les risques dans l’environ-nement des SI. En outre, identifier les respon-sabilités confiées au personnel au sein duprocessus de gestion des risques, et déterminers’il s’acquitte de ces responsabilités conformé-ment aux attentes. Comprendre les événe-ments qui se sont produits et ont affectél’activité des SI pour déterminer si des pra-tiques de gestion des risques appropriées sontmises en œuvre, et si les données sur lesrisques (par exemple leur fréquence, leurimpact, les techniques d’atténuation) sontconvenablement documentées et, le caséchéant, mises à jour après l’événement.

• Les activités de contrôle. Évaluer les princi-paux contrôles définis par la DSI pour gérerl’activité et soutenir l’ensemble de l’organisa-tion. L’audit interne devrait revoir les aspectsliés à la propriété, la documentation et l’auto-validation. En outre, l’ensemble des contrôlesdevrait être suffisamment solide pour maîtriserles risques identifiés.

GTAG – Parties prenantes interneset responsabilités des SI

12

3. Parties prenantes internes et responsabilités des SI

Une organisation doit comprendre et gérer son environnement des SI. Elle doit en outre comprendre etreconnaître la dépendance des processus métiers envers les SI et la nécessité de respecter les exigencesréglementaires. Une bonne ou une mauvaise gestion ou utilisation des SI peut permettre de tirer parti ou de manquerdes opportunités commerciales. Une gouvernance efficace des SI accroît la probabilité que les SI facilitentla réalisation des objectifs de l’organisation, et que les ressources soient gérées avec prudence. Le tableauci-après1 expose un ensemble de responsabilités de surveillance pouvant être exercées par le Conseil, ladirection générale, la DSI et les auditeurs internes du point de vue de la gouvernance des SI.

Rôle Responsabilité

Le Conseil Le Conseil devrait :• Comprendre la valeur stratégique de la fonction informatique. • S’informer du rôle et de l’impact des SI sur l’organisation.• Fixer une direction stratégique et anticiper un retour.• Examiner la façon dont le management attribue les responsabilités. • Superviser la transformation.• Comprendre les contraintes dans lesquelles opère la direction générale.• Superviser l’alignement de l’organisation par rapport à la stratégie.• Demander à la direction générale de dégager une valeur mesurable au travers

des SI.• Superviser les risques de l’organisation.• Favoriser l’apprentissage, le développement et la gestion des ressources. • Superviser l’évaluation des performances.• Obtenir une assurance.

La directiongénérale

La direction générale devrait :• S’informer du rôle et de l’impact des SI sur l’organisation.• Diffuser la stratégie, les politiques et les objectifs à tous les niveaux de l’organi-

sation et aligner la structure des SI avec les objectifs de l’organisation.• Déterminer les capacités et les investissements nécessaires.• Affecter les responsabilités.• Soutenir les activités en cours.• Fournir les structures et les ressources organisationnelles nécessaires.• Intégrer des responsabilités claires pour la gestion des risques et le contrôle

des SI.• Évaluer la performance.• Privilégier les compétences stratégiques que les SI doivent soutenir.• Privilégier les processus majeurs des SI qui créent de la valeur.• Créer une organisation flexible et adaptable qui exploite informations et

connaissances.• Renforcer la valeur de l’offre de services.• Élaborer des stratégies pour optimiser les coûts des SI.• Disposer de stratégies d’acquisition des compétences claires.

1 Le tableau contient des parties du Board Briefing on IT Governance de l’ITGI, 2e édition, utilisées avec l’aimable autorisation de l’ITGI et l’ISACA.©2003 ITGI. Tous droits réservés.

13

Outre les parties prenantes internes, les parties extérieures telles que les auditeurs externes, les autoritésnationales, les attentes du public et les organisations internationales de normalisation doivent être prisesen compte.

GTAG – Parties prenantes interneset responsabilités des SI

La DSI La DSI devrait :• Gérer les attentes de la direction générale en matière de SI. • Piloter le développement de la stratégie des SI et sa mise en œuvre.• Relier les budgets des SI aux buts et objectifs stratégiques.• S’assurer qu’une valeur mesurable est dégagée dans les délais et le budget

impartis.• Établir des normes, des politiques et un cadre de contrôle des SI, selon les

besoins.• Informer et former le management sur les problématiques des SI. • Rechercher des manières d’accroître la contribution des SI à la création de

valeur. • Veiller à la bonne gestion des projets informatiques.• Fournir des infrastructures informatiques qui facilitent une création et un par-

tage rentables de l’informatique décisionnelle.• Veiller à la disponibilité de ressources, de compétences et d’infrastructures des

SI nécessaires à la réalisation des objectifs et à la création de valeur. • Évaluer les risques, les atténuer efficacement, et les rendre transparents pour

les parties prenantes.• S’assurer que les rôles essentiels à la gestion des risques des SI sont convena-

blement définis et dotés en ressources. • Veiller à la gestion et à la vérification au quotidien des processus et des

contrôles des SI. • Mettre en place des indicateurs de performance liés directement et manifeste-

ment à la stratégie.• Privilégier les compétences clés dans le domaine informatique.

L’audit interne L’audit interne devrait :• Veiller à posséder un niveau minimal d’expertise en SI suffisant.• Inclure l’évaluation des SI dans son processus de planification.• Évaluer si la gouvernance des SI dans l’organisation soutient et conforte les

stratégies et les objectifs. • Identifier et évaluer les expositions de l’organisation aux risques liés aux SI.• Évaluer les contrôles mis en place en réponse aux risques au sein des SI de l’or-

ganisation.• Veiller à posséder l’expertise nécessaire en matière de SI pour s’acquitter de ses

responsabilités. • Envisager, le cas échéant, d’utiliser des techniques d’audit informatisées.

GTAG – L’analyse des risques

14

4. L’analyse des risques

Les contrôles des SI sont choisis et mis en œuvreen fonction des risques qu’ils sont censés traiter.Une fois les risques identifiés, la stratégie de trai-tement des risques à adopter peut aller de : ne rienfaire et accepter le risque comme un coût intrin-sèque à l’activité, ou appliquer divers contrôlesspécifiques, notamment souscrire une police d’as-surance.

Il serait relativement simple d’établir une liste decontrôles des SI à mettre en œuvre impérative-ment dans chaque organisation. Cependant,chaque contrôle induit un coût spécifique qui peutne pas se justifier du point de vue de la rentabilité,suivant le type d’activités réalisées par l’organisa-tion. En outre, aucune liste de contrôles n’estapplicable à toutes les catégories d’organisations.Même si l’on peut formuler de multiples conseilssur le choix des contrôles adéquats, il faut fairepreuve de discernement et de jugement. Lescontrôles doivent être adaptés au niveau de risqueauquel doit faire face l’organisation. Le RAI doitpouvoir conseiller le comité d’audit sur la fiabilitédu cadre de contrôle interne et fournir un niveaud’assurance approprié selon l’appétence pour lerisque affiché par l’organisation. Le COSO1 définitl’appétence, pour le risque de l’organisationcomme :« Le niveau de risque global qu’une organisationaccepte de prendre pour répondre à son objectifde création de valeur. […] L’appétence pour lerisque est prise en compte dans la définition de lastratégie dans la mesure où les résultats de la stra-tégie doivent être en ligne avec l’appétence pourle risque. [...] La direction tient compte de l’appé-tence pour le risque lorsqu’elle […] élabore sondispositif pour traiter les risques et les gérer effi-cacement. »En plus de l’appétence au risque, le responsablede l’audit interne doit prendre en considération latolérance au risque, que le COSO définit comme :

« Le niveau de variation que l’entité accepte quantà l’atteinte d’un objectif spécifique. […]Lorsqu’elle définit le seuil de tolérance au risque,la direction considère l’importance relative desobjectifs et aligne la tolérance au risque avec l’ap-pétence pour le risque. »Ainsi, le responsable de l’audit interne doit évaluersi oui ou non :• L’environnement informatique de l’organisa-tion est cohérent avec l’appétence pour lerisque de l’organisation.

• Le cadre de contrôle interne est adéquat pourque les opérations de l’organisation restentdans les limites des tolérances au risque énon-cées.

4.1 Prise en compte du risque dansl’évaluation de l’adéquation descontrôles des SI

La gestion du risque s’applique à l’ensemble desactivités de l’organisation, et pas seulement à l’uti-lisation des SI. On ne peut pas considérer les SIisolément : ils font partie intégrante de tous lesprocessus. Le choix des contrôles des SI ne serésume pas à appliquer les bonnes pratiquesrecommandées. Ces contrôles doivent apporterune valeur ajoutée à l’organisation en réduisantefficacement les risques et en améliorant l’effica-cité.

Lorsque le RAI cherche à savoir si les contrôles desSI sont adéquats au sein du cadre de contrôleinterne de l’organisation, il doit étudier les proces-sus établis par la direction générale afin de déter-miner :• L’utilisation, la valeur et le caractère critiquedes données.

• L’appétence pour le risque et la tolérance aurisque de l’organisation pour chaque fonctionet processus.

• Les risques informatiques auxquels estconfrontée l’organisation, et la qualité du ser-vice offert à ses utilisateurs.

• La complexité de l’infrastructure SI. • Le caractère adéquat des contrôles des SI etleur utilité.

1 The Committee of Sponsoring Organizations of the Treadway Com-mission, “Committee of Sponsoring Organizations for the Commissionon Fraudulent Financial Reporting.” www.coso.org.


15

La fréquence de l’analyse de risques est un élé-ment important, fortement influencé par les chan-gements internes et externes. La rapidité desévolutions technologiques impactera chaque orga-nisation différemment. Certaines organisationsauront besoin de répondre très rapidement auxrisques associés à ces évolutions alors que d’autresdécideront d’être plus attentistes.

4.1.1 L’environnement des SI

L’analyse et l’évaluation des risques informatiquespeuvent se révéler complexes. L’infrastructure SIse compose de matériels, de logiciels, de commu-nications, d’applications, de protocoles (règles) etde données. Ces composantes doivent êtredéployées dans un espace physique, au sein del’organisation et entre l’organisation et son envi-ronnement externe. L’infrastructure inclut égale-ment les personnes qui interagissent avec leséléments physiques et logiques des systèmes.

Les autres zones de risque à prendre en considé-ration incluent celles qui sont associées aux projetsainsi qu’aux relations avec les fournisseurs. Un desrisques associés aux projets est par exemple, lasous-évaluation du budget, des ressources, descompétences techniques. Pour les risques liés auxrelations avec les prestataires de service ou lesfournisseurs, l’auditeur informatique devra notam-ment se poser la question de la pérennité, de lasolvabilité du prestataire, de la revue des contrôlesinformatiques et des clauses d’audit.

L’inventaire des composantes de l’infrastructure SImet en lumière des informations de base sur lesvulnérabilités de l’environnement. Ainsi, les sys-tèmes et réseaux connectés à Internet sont exposésà des menaces que ne connaissent pas les sys-tèmes et réseaux autonomes. Parce que la connec-tivité à Internet est essentielle pour la plupart dessystèmes et réseaux, les organisations doivent veil-ler à ce que ceux-ci intègrent les contrôles fonda-mentaux qui assurent une sécurité de base.

L’évaluation des vulnérabilités au sein des infra-structures informatiques commence par un inven-

taire complet du matériel, des logiciels, réseaux etdonnées de l’organisation. Les schémas d’archi-tecture des systèmes font apparaître l’agencementdes composants de l’infrastructure et la manièredont ils interagissent avec d’autres composants, àl’intérieur et en dehors de l’organisation. Pour lesexperts en sécurité informatique, l’inventaire etl’architecture des composants (y compris le posi-tionnement des technologies et contrôles de sécu-rité) permettent de révéler les éventuellesvulnérabilités. Malheureusement, les informationsconcernant un système ou un réseau peuventaussi rendre les vulnérabilités apparentes aux yeuxd’un pirate potentiel, si bien que l’accès à cesinformations doit être limité aux seules personnesqui en ont besoin. Un environnement de systèmeset de réseau correctement configuré permet deminimiser la quantité d’informations mises à dis-position des éventuels pirates, et un environne-ment qui paraît sécurisé représente une cible bienmoins attrayante pour la plupart des pirates.

4.1.2 Les risques informatiques rencontrés parl’organisation

Le RAI s’entretient des risques informatiques avecle directeur des SI et les propriétaires des proces-sus afin de s’assurer que toutes les parties concer-nées ont une compréhension et une consciencesuffisantes des risques techniques auxquels doitfaire face l’organisation du fait de son utilisationdes SI, et du rôle qui est le leur dans la mise enplace et la maintenance de contrôles efficaces.

4.1.3 L’appétence pour le risque et la toléranceau risque

Fort de sa connaissance des risques informatiques,l’auditeur peut valider l’existence de contrôles effi-caces, correspondant à l’appétence pour le risquedéfini par l’organisation et sa tolérance aux risquesinformatiques. Pour procéder à cette évaluation,l’auditeur devra discuter avec de nombreux mana-gers et dirigeants, et éventuellement avec leConseil. Le niveau de détails de ces discussionssera déterminé en sollicitant l’avis du directeur desSI, du RSSI, et des propriétaires de processus.


16

Les organisations qui mettent en œuvre l’ERM,devront prendre en considération les risques desSI. L’ERM comprend des méthodes et des proces-sus pour gérer les risques et saisir toutes les oppor-tunités pour réaliser les objectifs de l'organisation.Il faut généralement commencer par l'identifica-tion d’événements ou de circonstances pertinentspar rapport aux objectifs de l'organisation (parexemple, les risques de fuite d'information), puisles évaluer en termes de probabilité et d'impact(par exemple, le risque inhérent d'une fuite d’in-formation est fort, et l'impact est également élevé),pour déterminer une réponse (par exemple, denouvelles règles pour mieux sécuriser les donnéesde l'organisation) et suivre les progrès accomplisdans la mise en œuvre de réponses (par exemple,la mise en place de nouvelles mesures de sécuritédans les SI pour éviter des fuites d’information).En identifiant et en anticipant les risques et lesopportunités, les organisations seront plus àmême de se protéger et de créer de la valeur pourles parties prenantes. Ainsi, l’ERM aide le respon-sable de l’audit interne dans la compréhension desrisques majeurs de l'organisation. Ensuite, le RAIpeut l’utiliser pour fixer les priorités de l’auditinterne, déterminer les missions d’audit et la tolé-rance et l’appétence au risque.

4.1.4 L’analyse des risques

Une analyse des risques doit impliquer différentesfonctions et directions telles que le responsable dela gestion des risques, le RAI, la direction des SI etdes responsables métiers.

Les questions fondamentales de l’évaluation desrisques sont : • Quels actifs informatiques (actifs tangibles ouintangibles, comme l’information ou la répu-tation) sont exposés à un risque ? Quel est leniveau de confidentialité, d’intégrité et de dis-ponibilité nécessaire pour chacun de cesactifs ?

• Quel événement (menace) pourrait influernégativement la valeur de ces actifs informa-tionnels ? Cette question sous-entend l’ana-lyse de la vulnérabilité et la cartographie des

vulnérabilités face aux menaces ainsi que lesdonnées susceptibles d’être affectées.

• Si une menace venait à se réaliser, quelle seraitla gravité de ses répercussions ?

• À quelle fréquence peut-on s’attendre à voirces événements se réaliser ?

• Quel est le degré de certitude des réponses auxquatre premières questions (analyse d’incerti-tude) ?

• Que peut-on faire pour réduire le risque ?• Quel en sera le coût ?• Est-ce rentable ?

Déterminer la valeur des données traitées etstockées n’est pas chose facile, en raison des mul-tiples dimensions de cette valeur. Le RAI pourratirer parti d’une coordination avec le responsablede la gestion des risques et s’aligner sur les risquesliés au SI. En fonction de la taille de l’organisationet de ses risques, le RAI et le responsable de la ges-tion des risques peuvent partager leurs méthodesde hiérarchisation des risques, de couverture desrisques et utiliser leurs ressources de manière plusefficiente.

4.2 Stratégies de traitement desrisques

Une fois les risques identifiés et analysés, il n’estpas toujours judicieux de mettre en œuvre desmesures visant à les contrer. Certains risques peu-vent avoir un impact mineur ou être extrêmementpeu probables, et il peut s’avérer peu rentabled’adopter des procédures de contrôle onéreusespour y remédier.

De manière générale, il existe plusieurs manièresde traiter les risques :• Accepter le risque. L’une des principalesfonctions du management consiste à gérer lerisque. Certains risques sont mineurs parceque leurs répercussions et leur probabilité sontfaibles. Dans ce cas, on recommande d’accep-ter sciemment le risque comme constituant uncoût inhérent à l’activité, et de réévaluer pério-diquement ce risque pour s’assurer que sesrépercussions restent faibles.


17

• Eviter le risque. Il est possible qu’un risquedécoule du recours à une technologie, à unfournisseur ou à un éditeur en particulier. Onpeut alors l’éviter en remplaçant ladite tech-nologie par des produits plus robustes, ou enrecherchant des fournisseurs ou des distribu-teurs plus performants.

• Partager le risque. L’atténuation du risquepeut être partagée avec les partenaires com-merciaux et les fournisseurs. Un bon exempleréside dans l’externalisation de la gestion del’infrastructure. Dans ce cas, les risques décou-lant de la gestion de l’infrastructure SI sontatténués par le fournisseur qui dispose decapacités accrues et a accès à du personnelmieux qualifié que son client. Le risque peutégalement être réduit par le transfert des coûtsde la réalisation du risque à une compagnied’assurance.

• Réduire le risque. En lieu et place ou en asso-ciation avec d’autres options, il convient deconcevoir des contrôles idoines et de les mettreen œuvre pour empêcher que le risque ne seréalise, pour réduire la probabilité d’occurrenceou en minimiser les effets.

GTAG – Évaluation des SI – une vue d’ensemble

18

5. Évaluation des SI – unevue d’ensemble

Les contrôles des SI mis en œuvre lors du contrôleou de la maîtrise des risques se révèlent être lameilleure option. S’il convient d’appliquer lescontrôles des SI en tenant dûment compte desrisques concernés ; il existe un ensemble decontrôles élémentaires qui devraient être mis enplace pour assurer un niveau minimum decontrôle des SI.

Les contrôles des SI devraient faire partie des prin-cipaux processus SI relatifs à la planification, l’or-ganisation, les acquisitions, les changements, laprestation de services des SI, ainsi que le supportet la surveillance des SI. Les contrôles des SI quiviennent en appui d’une large part de ces proces-sus SI sont généralement des contrôles de l’infra-structure des SI couvrant des domaines tels queles contrôles réseau, les contrôles des bases dedonnées, des systèmes opérationnels et du maté-riel. Les contrôles des SI couvrant des applicationset, souvent, d’importants domaines opérationnels,peuvent inclure des contrôles de validation dessaisies, des contrôles de réalisation de processusou de rapprochements, et des contrôles des rap-ports d’anomalies. Pour comprendre les risques etles contrôles des SI, le RAI devrait en premier lieuacquérir une vue d’ensemble des contrôles impor-tants et des processus métiers qu’ils soutiennent.Les descriptions des processus et les organi-grammes comptent parmi les outils utiles pouracquérir une vue d’ensemble. En outre, le RAIdevrait comprendre les principales initiatives tech-nologiques pour appréhender l’évolution éven-tuelle des infrastructures et des applications des SIsur un intervalle de temps donné. Grâce à cesinformations, le RAI pourra effectuer une évalua-tion initiale des risques qui permettra une analyseplus approfondie.

Certaines questions peuvent être prises en comptelors de l’évaluation de l’environnement decontrôle et de la sélection d’un ensemble appro-prié de contrôles.

• Existe-t-il une politique des SI, et notammentdes contrôles des SI ?

• Les responsabilités en matière de SI et decontrôles des SI ont-elles été définies, affectéeset acceptées ?

• La conception du contrôle est-elle efficace ?• Le fonctionnement du contrôle est-il efficace ?• Le contrôle aboutit-il au résultat souhaité ?• La combinaison de contrôles préventifs, détec-tifs et correctifs est-elle efficace ?

• Les contrôles génèrent-ils des éléments depreuve lorsque les limites sont franchies ouque les contrôles échouent ? Comment lemanagement est-il averti des dysfonctionne-ments, et quelles mesures sont attendues enconséquence ?

• Des traces sont-elles conservées (par exempleau travers d’une piste d’audit) ?

• Les équipements et outils d’infrastructure desSI bénéficient-ils d’une protection logique etphysique ?

• Des mécanismes de contrôle d’accès et d’au-thentification sont-ils utilisés ?

• Existe-t-il des contrôles protégeant l’environ-nement opérationnel et les données des viruset autres logiciels malveillants ?

• Existe-t-il des contrôles relatifs aux pare-feux ?• Existe-t-il des politiques relatives aux pare-feux ?

• Des évaluations des vulnérabilités externes etinternes sont-elles effectuées et les risquesont-ils été identifiés et résolus de manièresatisfaisante ?

• Existe-t-il des procédures d’assurance-qualitéet de gestion des changements et de la confi-guration ?

• Existe-t-il des procédures structurées de sur-veillance et de mesures des services ?

• Les risques inhérents aux services externalisésont-ils été pris en compte ? (Pour de plusamples informations sur ce point, voir leGTAG 7 : L’infogérance.)

Le secteur des cartes de paiement (PCI) publie desnormes de sécurité des données parmi les pluscouramment utilisées - PCI Data Security Stan-dards (PCI DSS). Lancé en 2006, le Conseil des


19

normes de sécurité PCI est un forum internationalouvert, en charge du développement, de la ges-tion, de l’éducation et de la sensibilisation auxnormes de sécurité PCI, dont : la norme de sécu-rité des données (DSS), la norme de sécurité desdonnées d’application de paiement (PA-DSS), etles besoins liés au service de saisie du PIN (PED).

Le RAI peut s’appuyer de façon importante sur lanorme PCI DSS pour déterminer si certaines acti-vités liées à la sécurité devraient être prises encompte pour l’organisation (voir la norme PCIDSS – Présentation).


20

Introduction et présentation de la norme PCI DSS

La norme PCI (Payment Card Industry) DSS (Data Security Standard) a été développée dans le but derenforcer la sécurité des données des titulaires de cartes et de faciliter l'adoption de mesures de sécuritéuniformes à l’échelle mondiale. La norme PCI DSS sert de référence aux conditions techniques et opéra-tionnelles conçues pour protéger les données des titulaires de cartes. La norme PCI DSS s'applique àtoutes les entités impliquées dans le traitement des cartes de paiement, notamment les commerçants, lesentreprises de traitement, acheteurs, émetteurs et prestataires de service, ainsi que toutes les autres entitésqui stockent, traitent ou transmettent des données de titulaires de cartes. La norme PCI DSS consiste enun ensemble de conditions minimales pour la protection des données de titulaires de cartes et peut êtrerenforcée par des contrôles et des pratiques supplémentaires afin de réduire davantage les risques. Les12 conditions de la norme PCI DSS sont résumées ci-dessous.

PCI DSS – Présentation synthétique

Création et gestiond’un réseau sécurisé

1. Installer et gérer une configuration de pare-feu pour protéger les don-nées des titulaires de cartes.

2. Ne pas utiliser les mots de passe système et autres paramètres de sécu-rité par défaut, définis par le fournisseur.

Protection des don-nées des titulaires decartes de crédit

3. Protéger les données de titulaires de cartes stockées.4. Crypter la transmission des données des titulaires de cartes sur les

réseaux publics ouverts.

Gestion d’un pro-gramme de gestiondes vulnérabilités

5. Utiliser des logiciels antivirus et les mettre à jour régulièrement. 6. Développer et gérer des systèmes et des applications sécurisés.

Mise en œuvre demesures de contrôled’accès strictes

7. Restreindre l’accès aux données des titulaires de cartes aux seuls individusqui doivent les connaître.

8. Affecter un identifiant unique à chaque utilisateur d’ordinateur. 9. Restreindre l’accès physique aux données des titulaires de cartes.

Surveillance et testsréguliers des réseaux

10. Effectuer le suivi et surveiller tous les accès aux ressources réseau et auxdonnées des titulaires de cartes.

11. Tester régulièrement les processus et les systèmes de sécurité.

Gestion d’une poli-tique de sécurité desinformations

12. Gérer une politique de sécurité des informations pour l’ensemble du per-sonnel.


21

L’évaluation des contrôles des SI est un processuscontinu. Les procédures métiers changentconstamment au fil de l’évolution de la technolo-gie et des menaces émergent, à mesure que denouvelles vulnérabilités sont découvertes. Lesméthodes d’audit s’améliorent, lorsque les audi-teurs internes adoptent une approche où les pro-blématiques de contrôles des SI, à l’appui desobjectifs de l’organisation sont une priorité abso-lue. Le management fournit les indicateurs de

contrôle des SI et le reporting et les auditeursinternes se portent garants de leur validité et deleur qualité.

Le processus d’audit interne offre une démarcheformelle pour traiter les contrôles des SI au seindu système global de contrôle interne. La figure 1– La structure de l’audit des SI, scinde l’évaluationen une suite logique d’étapes.

Éval

uer l

es c

ontr

ôles

des

SI

Compréhension descontrôles des SI

Contrôles – Gestion - Technique

Généraux / Applicatifs

Prévention, détection, correction

Information - Sécurité

Importance descontrôles des SI

Fiabilité et efficacité

Avantage concurrentiel

Législation et réglementation

Rôles etresponsabilités

Gouvernance

Management

Audit

Approchepar les risques

Analyse du risque

Réponse au risque

Contrôles élémentaires

Surveillance ettechniques

Cadre de contrôle

Fréquence

ÉvaluationMéthodologies

Interface avec le comité d’audit

Figure 1 – La structure de l’audit des SI

Pour les contrôles des SI, l’auditeur interne doit tout d’abord disposer d’une bonne compréhension desconcepts avant de pouvoir tirer les conclusions d’une évaluation des risques et des contrôles. Le RAIdevrait surveiller les activités de formation et de réévaluation continues en fonction de l’émergence denouvelles technologies, et de l’évolution des opportunités, usages, dépendances, stratégies, risques etbesoins de l’entreprise.

GTAG – Comprendre l’importance des contrôles des SI

22

6. Comprendrel’importance descontrôles des SI

Bien que ce GTAG traite exclusivement des risqueset des contrôles liés aux SI, l’environnement decontrôle des SI (par exemple l’exemplarité dudirecteur des SI, le climat éthique, la philosophiedu management et le style de management) estcritique et devrait donc être évalué. Compte tenudu sujet de ce chapitre, le guide pratique de l’IIA,« Auditer l’environnement de contrôle », devraitêtre utilisé en complément.

Le COSO définit le contrôle interne comme « unprocessus mis en œuvre par la direction générale,le management, et autre personnel d’une organi-sation, destiné à fournir une assurance raisonnablequant à la réalisation des objectifs entrant dans lescatégories suivantes :• Efficacité et optimisation des opérations,• Fiabilité des informations financières,• Conformité aux lois et réglementations envigueur. »

Les contrôles des SI englobent les processus quiprocurent une assurance sur les données et les ser-vices informatiques et qui contribuent à contrôleret atténuer les risques découlant de l’usage des SIpar une organisation. Il peut s’agir de politiquesd’entreprise formalisées ou de leur mise en œuvredans des programmes informatiques, de la protec-tion des accès physiques à la capacité d’imputerdes actions et des transactions aux utilisateurs, desvalidations automatiques ou encore des analysesde cohérence pour un grand volume de données.

Il n’est pas indispensable pour le RAI de « toutsavoir » sur les contrôles des SI, incluant toute lagamme des contrôles ou toutes les subtilités tech-niques. Plusieurs contrôles relèvent de spécialistesqui gèrent des risques spécifiques associés aux dif-férentes composantes des systèmes et de l’infra-structure de réseau.

6.1 Les contrôles généraux etapplicatifs des SI

On peut classifier les contrôles de manière à encomprendre les objectifs et à savoir où ils s’insè-rent au sein du système de contrôle interne (figure2). La compréhension de ces classifications permetà celui qui analyse les contrôles et à l’auditeur demieux connaître leur position au sein du systèmede contrôle et de répondre aux questions cruciales,telles : les contrôles détectifs sont-ils adéquatspour identifier les erreurs qui pourraient échapperaux contrôles préventifs ? Les contrôles correctifssont-ils suffisants pour corriger les erreurs une foiscelles-ci détectées ? Une classification courantedes contrôles des SI, est de séparer les contrôlesgénéraux des contrôles applicatifs. Pour avoir unedéfinition plus complète sur les contrôles applica-tifs, vous pouvez vous référer au GTAG 8 « L’auditdes contrôles applicatifs ».

Figure 2 – Quelques classifications descontrôles

6.1.1 Les contrôles généraux

Les contrôles généraux s’appliquent à l’ensembledes composantes, processus et données d’uneorganisation ou d’un environnement système.Sans se limiter à ces domaines, les contrôles géné-

Cont

rôle

s pr

éven

tifs

Cont

rôle

s dé

tect

ifs

Cont

rôle

s co

rrec

tifs

Contrôles degouvernance

Contrôles de gestion

Contrôles techniques

Contrôles

G

énéraux

Contrôles

Applic

atifs


23

raux incluent la gouvernance des SI, la gestion desrisques, la gestion des ressources, l’exploitation, ledéveloppement et la maintenance des applica-tions, la gestion des utilisateurs, la sécurité logique,la sécurité physique, la gestion des changementsdes systèmes, la sauvegarde et la restauration dedonnées, ou la continuité d’activité.Certains contrôles généraux sont liés aux métiers(par exemple la séparation des fonctions ou l’or-ganisation de la gouvernance), alors que d’autressont plus techniques (tels que les contrôles dessystèmes de logiciels, et les contrôles réseaux) etsont liés à l’infrastructure sous-jacente. Lescontrôles généraux sont revus par l’audit internecar ils sont la base de l’environnement de contrôledes SI. Si les contrôles généraux sont peu fiables(par exemple le contrôle des accès et des change-ments), l’auditeur devra modifier son approchedes tests pour les zones impactées.

6.1.2 Les contrôles applicatifs

Les contrôles applicatifs portent sur l’étendue desprocessus de l’organisation ou ses applications etincluent les contrôles au niveau des entrées, destraitements et des sorties des applications. Il s’agit,notamment, de la validation de données, de laséparation des tâches (par exemple : saisie et auto-risation d’une transaction), balance des totaux decontrôle, journalisation des transactions et desrapports d’erreurs. Le rôle d’un contrôle est primordial pour en éva-luer la conception et l’efficacité. On peut généra-lement différencier les contrôles préventifs,détectifs et correctifs. Les contrôles préventifs per-mettent d’éviter la survenue d’erreurs, d’omissionsou d’incidents de sécurité. Il s’agit, par exemple,de simples règles de validation des données dèsleur saisie, qui empêchent d’entrer des caractèresalphabétiques dans des champs numériques, decontrôles d’accès grâce auxquels les données sen-sibles ou les ressources système deviennent inac-cessibles aux individus non autorisés, ou encore decontrôles techniques dynamiques et complexestels que les logiciels antivirus, les pare-feux et lessystèmes anti-intrusion. Les contrôles détectifs visent à repérer les erreurs

ou les incidents qui échappent aux contrôles pré-ventifs. Ainsi, un contrôle détectif peut identifierle nombre de comptes inactifs ou les comptes quiont été signalés comme devant faire l’objet d’unesurveillance pour déceler des activités suspectes.Les contrôles détectifs peuvent aussi prendre laforme d’une surveillance ou d’analyses visant àmettre au jour des activités ou des événementshors des limites autorisées ou des schémas connuspour certaines données, pouvant être sujet à unemanipulation inadéquate. Pour les échanges dedonnées sensibles, des contrôles détectifs peuventindiquer si un message est corrompu ou si l’iden-tité de l’expéditeur ne peut être authentifiée. Les contrôles correctifs ont pour but de corriger leserreurs, omissions ou incidents une fois ceux-cidétectés. Il peut s’agir de la simple correction d’er-reurs de saisie, de l’identification et la suppressiond’utilisateurs ou de logiciels non autorisés, dansun système ou un réseau, ou encore de la repriseaprès un incident, une panne ou un sinistre.Généralement, il est plus efficient de prévenir leserreurs ou de les détecter à un niveau aussi procheque possible de la source pour en simplifier la cor-rection.De nombreuses autres classifications des contrôlesdécrites dans ce guide peuvent être utiles pour enévaluer l’efficacité. Par exemple, les contrôles auto-matisés tendent à être plus fiables que lescontrôles manuels, et les contrôles non discrétion-naires seront plus vraisemblablement appliqués demanière plus homogène que les contrôles discré-tionnaires. Parmi les autres catégories possibles,citons les contrôles obligatoires, volontaires, com-plémentaires, compensatoires, redondants, conti-nus, sur demande et déclenchés par desévénements.

6.2 Les contrôles de la gouvernance,du management et techniquesdes SI

Une autre classification habituelle regroupe lescontrôles en fonction du groupe chargé de veillerà leur mise en œuvre et de leur correcte actualisa-


24

tion. Afin d’évaluer les rôles et responsabilités, ceguide classe essentiellement les contrôles des SIen contrôles au niveau de la gouvernance, dumanagement, du personnel technique ou auniveau des applications

Ce guide s’adresse en priorité aux deux premiersniveaux (gouvernance et management), bien qu’ilpuisse également être utile à un technicien decomprendre comment les contrôles sont mis enœuvre au niveau des infrastructures SI. Lescontrôles techniques et applicatifs sont traités dansle cadre du GTAG 8 « Audit des contrôles applica-tifs ».

6.2.1 Les contrôles de la gouvernance des SI

La responsabilité première de la surveillance ducontrôle interne revient au Conseil, puisque c’estle dépositaire du cadre de gouvernance. Lecontrôle des SI au niveau de la gouvernanceimplique de veiller à l’efficience de la gestion del’information, à l’application des principes, poli-tiques et processus de sécurité, et à vérifier que cecadre fait en permanence l’objet de mesures deperformance et de conformité. Ces contrôles sontassociés aux concepts de gouvernance, lesquelssont guidés par les buts et objectifs de l’organisa-tion et par les attentes des instances externes telsque les superviseurs.

6.2.2 Les contrôles du management

S’agissant du contrôle interne, la responsabilité dumanagement consiste généralement à porter danstous les domaines de l’organisation une attentionparticulière aux actifs critiques, aux données sen-sibles et aux fonctions opérationnelles. Le mana-gement doit s’assurer que les contrôles des SInécessaires pour atteindre les objectifs que l’orga-nisation s’est fixés sont mis en place et garantis-sent un processus de gouvernance fiable etcontinu. Le déploiement de ces contrôles résulted’actions délibérées du management en réponseaux risques susceptibles d’affecter l’organisation,ses processus et ses actifs.

6.2.3 Les contrôles techniques

Les contrôles techniques sont souvent le socle desréférentiels de contrôle du management. C’estpourquoi, si les contrôles techniques sont faibles,c’est le référentiel de contrôles dans sa globalitéqui sera impacté. Par exemple, en assurant uneprotection contre les accès non autorisés et lesintrusions, les contrôles techniques sont à la basede la fiabilité de l’intégrité des données, en appor-tant notamment des preuves de tous les change-ments et de leur authenticité. Ces contrôles sontdifférents selon les technologies en usage au seinde l’infrastructure SI de l’organisation. Ce sont, parexemple, des contrôles opérationnels de systèmes,les contrôles de bases de données, le cryptage etle contrôle des accès.

6.2.4 Les contrôles applicatifs

Comme déjà établi, les contrôles applicatifs por-tent sur l’ensemble des processus de l’organisationou ses applications. Par nature techniques, lescontrôles applicatifs peuvent également être nontechniques en fonction de la zone de contrôle. Ilscomprennent les contrôles des entrées, des traite-ments et des sorties. Le chapitre 6.3.7 de ce guiderevient plus en détail sur le sujet.

6.3 Quels contrôles des SI ?

Les différents contrôles au sein d’une organisationpeuvent être définis dans le cadre de la hiérarchiedes contrôles des SI, allant des déclarations deprincipes généraux formulées par le managementet avalisées par le Conseil, jusqu’aux mécanismesde contrôle spécifiques intégrés aux applicationsLa hiérarchie représentée à la figure 3 (page sui-vante) propose une approche logique descen-dante, à la fois lorsque l’on considère les contrôlesà mettre en œuvre et aussi lorsque l’on définit surquels aspects concentrer les ressources d’auditdurant l’examen de l’environnement d’exploita-tion des SI. Les différents éléments de contrôleplacés dans cette hiérarchie ne sont pas mutuelle-ment exclusifs ; ils sont tous reliés les uns aux


25

autres, se chevauchent et se confondent souvent.Nous décrivons ci-dessous un certain nombre decontrôles.

Figure 3 – Les contrôles des SI

6.3.1 Règles et procédures

Toutes les organisations doivent définir leurs butset objectifs à travers des plans stratégiques et despolitiques. En l’absence de politiques et de règlesformalisées pour le management, les organisa-tions, manquant d’orientations à suivre, peuventdevenir inefficientes. Les SI étant essentiels pour la plupart des organi-sations, il faut que les principes qui régissent tousles aspects des SI soient clairement définis, etapprouvés par la direction générale, que le Conseilles avalise et qu’ils soient communiqués au per-sonnel. En fonction de la taille de l’organisation etde son niveau d’informatisation, il peut être parfoisnécessaire de formuler de nombreuses politiquesdifférentes. Pour les organisations plus petites, uneseule politique peut suffire, tant qu’elle couvre tousles aspects concernés. Les organisations plusgrandes auront souvent besoin de politiques plusdétaillées et plus spécifiques.Les politiques SI peuvent par exemple inclure : • Une politique générale sur le niveau de sécu-rité et le respect de la vie privée pour l’ensem-ble de l’organisation. Cette politique doit êtrecohérente avec l’ensemble des législations

nationales et internationales en vigueur et doitspécifier le niveau de contrôle et de sécuritérequis en fonction du niveau de sensibilité dusystème et des données traitées.

• Une politique sur la classification des donnéeset les droits d’accès applicables selon celle-ci.Elle doit également définir les limitationsquant à l’utilisation de ces données par les per-sonnes habilitées.

• Une définition des concepts de propriété dessystèmes et des données, ainsi que de l’habili-tation nécessaire pour créer, modifier ou sup-primer les données. Il peut s’agir d’unepolitique générale qui définit dans quellesmesures les utilisateurs peuvent créer leurspropres applications.

• Des politiques de ressources humaines quidéfinissent les conditions de travail dans lesdomaines sensibles et en vérifient la bonneapplication. Il peut s’agir d’examiner en détailles informations concernant des candidats àl’embauche avant de les accueillir dans l’orga-nisation, et de faire signer aux employés desaccords par lesquels ils acceptent la responsa-bilité pour le niveau de contrôle, de sécurité etde confidentialité requis. Typiquement, cettepolitique peut également détailler les procé-dures disciplinaires correspondantes.

• La définition des exigences en matière deplans de continuité d’activité, en veillant à ceque tous les aspects de l’activité, soient pris encompte dans l’éventualité d’une panne oud’un sinistre.

Cette liste n’est bien sûr pas exhaustive.

6.3.2 Normes

L’organisation devrait avoir un projet SI qui sup-porte toute sa stratégie et fixe les règles desnormes et politiques SI1.

Gouvernance

ManagementTe

chni

que

Politiques

Standards

Organisationet gestion

Contrôles physiqueset environnementaux

Contrôles des logiciels système

Contrôles du développement de systèmes

Contrôles applicatifs

1 Le Cadre de Référence International des pratiques professionnelles del’audit interne de l’IIA s’assure que l’audit interne évalue la stratégieSI. Selon la norme 2110.A2 « L’audit interne doit évaluer si la gouver-nance des systèmes d’information de l’organisation soutient la straté-gie et les objectifs de l’organisation. »


26

Les normes visent à définir des méthodes de tra-vail qui permettent la réalisation des objectifs del’organisation. De surcroît, l’adoption et l’utilisa-tion de normes promeuvent l’efficience, et assu-rent la cohérence de l’ensemble del’environnement d’exploitation SI.Les grandes organisations qui disposent de res-sources importantes peuvent tout à fait concevoirleurs propres normes. Mais, les petites organisa-tions ont rarement les ressources suffisantes pourle faire. Il existe de nombreuses sources d’infor-mations sur les normes et les bonnes pratiques.Par exemple, la DSI devrait prendre en compte : • Les procédures de développement des sys-

tèmes. Lorsque des organisations développentleurs propres applications, des normes définis-sent les procédures de conception, développe-ment, test, mise en œuvre et maintenance dessystèmes et programmes. Si elles externalisentle développement d’applications ou acquièrentdes systèmes auprès d’éditeurs, le RAI doits’assurer que des accords exigent du fournis-seur qu’il applique des normes qui sontconformes à celles de l’organisation ou quisoient acceptables par cette dernière.

• La configuration de logiciels. Parce que leslogiciels procurent une part importante ducontrôle de l’environnement SI, les normesrelatives à la configuration sécurisée de sys-tèmes sont de plus en plus largement accep-tées par les organisations et fournisseurs detechnologies leaders. La configuration des pro-duits tels que les systèmes d’exploitation, leslogiciels de réseau et les systèmes de gestionde bases de données peut soit renforcer leursécurité, soit créer des vulnérabilités qui ris-quent d’être exploitées à mauvais escient.

• Les contrôles applicatifs. Toutes les applica-tions qui supportent les activités métiers doi-vent être contrôlées. Pour toutes lesapplications que l’organisation développe ouacquiert, des normes doivent définir les typesde contrôle à mettre impérativement en placetout le long des processus métiers, ainsi que lescontrôles spécifiques aux processus et donnéessensibles.

• La structure des données. Si l’on dispose de

définitions de données homogènes dans latotalité des applications, des systèmes distri-bués peuvent accéder sans difficulté aux don-nées, et des contrôles de sécurité peuvent êtremis en place uniformément sur toutes les don-nées à caractère personnel et autres donnéessensibles.

• La documentation. Des normes doivent spé-cifier le niveau de détail minimal de documen-tation requis pour chaque application ouimplémentation informatique, ainsi que pourles différentes catégories d’applications, deprocédures et de centres de traitement.

Comme les politiques, les normes formalisées doi-vent être approuvées par le management, et acces-sibles à tous ceux qui ont à les appliquer.

6.3.3 Organisation et management

L’organisation et le management jouent un rôle clédans l’ensemble du système de contrôle des SI,comme dans tous les aspects de la vie d’une orga-nisation. Une structure adéquate permet la défini-tion de rattachements hiérarchiques et deresponsabilité ainsi que la mise en place de sys-tèmes de contrôle efficaces. Les principauxcontrôles clés qui sont habituellement mis enplace sont la séparation des tâches incompatibles,les contrôles financiers et la gestion du change-ment.

6.3.3.1 Séparation des tâchesLa séparation des tâches est un élément crucial denombreux contrôles. Une organisation doit êtrestructurée de sorte que tous les aspects du traite-ment des données ne reposent jamais sur uneseule personne. Les fonctions d’émission, d’auto-risation, de saisie, de traitement et de vérificationdes données doivent être séparées afin qu’aucunindividu ne puisse être à l’origine d’une erreur oud’une omission ou de toute autre irrégularité etl’autoriser et/ou en masquer les preuves. Lescontrôles de séparation des tâches concernant lesapplications sont mis en place par l’octroi d’accèsprivilégiés en fonction des exigences du poste en


27

termes de traitement et d’accès aux données.La séparation traditionnelle des tâches dans ledomaine informatique répond à la distinctionentre développement de système et exploitationdes SI. L’exploitation des SI doit assurer le fonc-tionnement des systèmes de production, sauf pource qui est du déploiement du changement, et avoirpeu voire aucune responsabilité, dans le processusde développement. Ce contrôle prévoit des restric-tions qui empêchent les exploitants d’accéder auxprogrammes, systèmes ou données de productionou de les modifier. De même, les développeursdoivent avoir peu de contacts avec les systèmes deproduction. On obtiendra une séparation destâches adéquate en assignant des rôles différentslors des processus de mise en production et dechangement. Dans les grandes organisations, ilfaut procéder de la même manière pour de nom-breuses fonctions si l’on veut que la séparation destâches soit adéquate.

6.3.3.2 Contrôles financiersÉtant donné que les organisations réalisent desinvestissements considérables dans les SI, descontrôles d’ordre budgétaire et financier sontnécessaires pour s’assurer qu’ils aboutissent auretour sur investissement ou aux économiesannoncés. Il convient de mettre en place des pro-cédures de gestion permettant de recueillir, d’ana-lyser et de rendre compte de ces aspects.Malheureusement, les évolutions des SI induisentsouvent des dépassements de coût massifs et nese traduisent pas par les économies ou les revenusattendus, en raison d’estimations erronées oud’une planification insuffisante.

6.3.3.3 Gestion du changementLes procédures de gestion du changement1 s’as-surent que les modifications apportées à l’environ-nement de SI, aux logiciels, aux applications et auxdonnées doivent permettre de respecter unebonne séparation des tâches, d’assurer le bonfonctionnement des changements, d’empêcherl’exploitation de ces changements à des fins frau-duleuses. Une faiblesse dans la gestion du chan-gement pourrait sérieusement impacter le systèmeet le service disponibles.

6.3.4 Contrôles physiques etenvironnementaux

Les équipements informatiques représentent uninvestissement considérable pour de nombreusesorganisations. Il faut donc les protéger des pertesou dégradations accidentelles ou délibérées. Lescontrôles physiques et environnementaux, initia-lement mis au point pour les grands centres detraitement informatique qui hébergent des main-frames, sont tout aussi importants dans le mondedes architectures client-serveur et les systèmesWeb. Bien que les équipements communémentutilisés de nos jours soient conçus pour être sim-ples d’utilisation dans un environnement debureau normal, leur valeur pour l’organisation, lecoût et la vulnérabilité des applications qui fontfonctionner les processus de l’organisation peu-vent être significatifs. Tous les équipements doivent être protégés, ycompris les serveurs et les postes de travail quipermettent au personnel d’accéder aux applica-tions. Parmi les contrôles physiques et environne-mentaux, citons :• L’installation des serveurs dans des locaux ver-rouillés et à accès restreint.

• La limitation de l’accès aux serveurs à des per-sonnes autorisés.

• La mise en place de dispositifs de détectionincendie et d’extincteurs.

• L’installation des équipements, applications etdonnées sensibles à distance des risques envi-ronnementaux, par exemple loin de zonesinondables, des couloirs aériens ou de lieux destockage de liquides inflammables.

Lorsque l’on s’intéresse à la sécurité physique etenvironnementale, il convient également d’envi-sager le plan de reprise après un sinistre2.Que faire en cas d’incendie ou d’inondation, ou sid’autres menaces se présentent ? Comment l’or-ganisation doit-elle procéder pour redémarrerl’activité et les installations et services informa-

1 GTAG 2 : Contrôles de la gestion du changement et des patchs : unfacteur clé de la réussite pour toute organisation (2ème éd.).

1 GTAG 10 « Gestion de la continuité d’activité ».


28

tiques rattachés, afin que le fonctionnementnormal se poursuive avec des incidences aussi fai-bles que possible sur les activités habituelles ? Cetype de planification ne se contente pas de propo-ser des capacités de traitement informatique desecours ou une sauvegarde régulière des donnéesde production. Il doit envisager la logistique et lacoordination nécessaires pour couvrir tout lechamp de l’activité. Enfin, l’expérience montre, àchaque fois, qu’un plan de secours, qui n’a pas ététesté avec succès, ne sera pas fiable en situationréelle.

6.3.5 Contrôles des logiciels systèmes

Les logiciels système permettent aux applicationset aux utilisateurs d’exploiter l’équipement infor-matique. Il s’agit de systèmes d’exploitationcomme Windows, UNIX ou Linux, de logiciels degestion de réseau et de transmission, de pare-feux,d’antivirus ou encore de système de gestion debases de données (SGBD) tels qu’Oracle et DB2.Les spécialistes de l’audit des SI doivent évaluerces contrôles. Il est peu vraisemblable que lespetites organisations aient des ressources suffi-santes pour employer ce type de spécialistes, ainsielles doivent envisager d’externaliser ce travail. Lesauditeurs informatiques, soit employés directe-ment ou intervenant en sous-traitance, doiventdisposer de connaissances très spécifiques. Ilsacquièrent l’essentiel de ce savoir par l’expérience,mais il leur faut constamment mettre à jour leursconnaissances afin qu’elles restent actualisées etutiles.Les systèmes de logiciels peuvent s’avérer extrê-mement complexes et s’appliquer à différents élé-ments et à des appareils au sein des systèmes etde l’environnement réseau. Le logiciel peut êtreconfiguré pour répondre à des besoins très spéci-fiques et donc avoir besoin d’un niveau élevé despécialisation pour une maintenance sécurisée.Bien que les systèmes de certaines applicationspossèdent leur propre système de contrôle desaccès et pourraient alors fournir un accès à des uti-lisateurs non autorisés pour rentrer dans le sys-tème, les paramétrages techniques permettent uncontrôle des accès logiques aux applications. Ils

permettent également de renforcer la séparationdes tâches, de générer des pistes d’audit et s’ap-pliquer aux contrôles d’intégrité des données à tra-vers les listes de contrôles d’accès, des filtres et desconnexions. Voici quelques-uns des contrôles techniques clésque l’on doit s’attendre à trouver dans un environ-nement de SI bien géré :• Les droits d’accès sont attribués et contrôlésconformément à la politique énoncée par l’or-ganisation.

• Les principes de séparation des tâches sontrespectés grâce à des contrôles logiciels etd’autres contrôles de configuration.

• Des évaluations et des actions de préventionet de détection des intrusions et des vulnéra-bilités1 sont en place et suivies en continu.

• Des tests d’intrusion sont régulièrement réali-sés.

• Des services de chiffrement sont mis en œuvrelorsque la confidentialité est explicitementrequise.

• Des procédures de gestion des changements,y compris la gestion des patchs, sont en place,si bien que les changements et les patchs sontappliqués aux logiciels, systèmes, composantsréseau et données selon une procédure étroi-tement encadrée2.

6.3.6 Contrôles de l’acquisition et dedéveloppement des systèmes

Les organisations adoptent rarement une métho-dologie unique pour tous les projets de dévelop-pement de systèmes. La méthodologie retenuedoit correspondre au contexte particulier à chaqueprojet. Les auditeurs informatiques doivent déter-miner si oui ou non l’organisation développe ouacquiert des applications selon une méthode enca-drée, qui prévoit ensuite des contrôles efficaces suret au sein des applications et données traitées. Parl’examen des procédures de développement des

1 GTAG 6 « Gérer et auditer les vulnérabilités des technologies de l’in-formation ».

1 GTAG 2 « Contrôles de la gestion du changement et des patchs : unfacteur clé de la réussite pour toute organisation (2ème éd.) ».


29

applications, l’auditeur peut obtenir l’assuranceque les contrôles applicatifs sont adéquats. Cer-tains points de contrôle de base doivent être traitésdans toutes les activités d’acquisition et de déve-loppement de systèmes. Par exemple :• Les besoins des utilisateurs doivent être for-malisés, et leur satisfaction mesurée.

• La conception des systèmes doit suivre uneprocédure formelle qui permet de s’assurerque les besoins des utilisateurs et les contrôlessont bien intégrés dans le système.

• Le développement des systèmes doit êtremené de manière structurée, afin que lesbesoins et les spécifications requis soient bienpris en compte dans le produit final.

• Les tests doivent vérifier que les différentescomposantes du système opèrent de la façonrequise, que les interfaces fonctionnentcomme prévu, que les utilisateurs participentau processus de test et que les fonctionnalitésattendues sont bien présentes.

• Les procédures de maintenance des applica-tions doivent permettre de s’assurer que tousles changements apportés aux applicationsrépondent à un schéma de contrôle homo-gène. La gestion des changements doit fairel’objet de procédures structurées de validationde l’assurance.

Si le développement est externalisé, les presta-taires doivent se voir imposer, par contrat, descontrôles similaires. Les techniques et contrôles degestion de projet devraient faire partie intégrantedu processus de développement, que celui-ci soitréalisé en interne ou externalisé. La directiongénérale doit savoir si les projets respectent lesdélais, ne dépassent pas le budget et si les res-sources sont utilisées avec efficience. Des remon-tées d’information sur les projets doiventpermettre à la direction générale d’avoir une com-préhension de l’état d’avancement des projets dedéveloppement et d’éviter d’avoir de mauvaisessurprises lors de la mise en service du produitfinal1. Le GTAG 12 « Auditer les projets informa-tiques » évoque également l’évaluation des projetsd’acquisition ou de développement.

6.3.7 Contrôles applicatifs2

Les points de contrôle interne portant sur lesapplications veillent à ce que :• Toutes les données saisies soient exactes, com-plètes, autorisées et correctes.

• Toutes les données soient traitées commeprévu.

• Toutes les données stockées soient exactes etcomplètes.

• Tous les résultats soient exacts et complets.• Le traitement des données fasse l’objet detraces (logs) depuis la saisie jusqu’au stockageet à la production de données de sortie.

L’examen des contrôles d’application a toujoursconstitué le domaine des auditeurs informatiques.Cependant, ce type de contrôles représentant dés-ormais une composante essentielle de la maîtrisedes activités, tous les auditeurs internes devraienten faire une priorité. Différents types de contrôles courants devraientexister dans chaque application :• Les contrôles des données d’entrée : ils ser-vent essentiellement à vérifier l’intégrité desdonnées saisies dans une application, qu’ellessoient saisies directement par les utilisateurs,à distance par un partenaire ou à travers uneapplication Web. Une vérification des entréespermet de s’assurer qu’elles respectent lesparamètres spécifiés.

• Les contrôles du traitement : ils procurent unmoyen automatisé de s’assurer que le traite-ment est complet, exact et autorisé.

• Les contrôles des données de sortie : ils por-tent sur ce qui est fait des données. Ils doiventcomparer les résultats obtenus aux résultatsattendus, et les vérifier par rapport à ce qui aété saisi.

• Les contrôles d’intégrité : ils peuvent s’ap-pliquer de façon permanente sur les donnéesen cours de traitement et/ou stockées, afin des’assurer qu’elles restent cohérentes et exactes.

1 GTAG 14 « L’audit des applications développées par les utilisateurs ».1 GTAG 8 « Audit des contrôles applicatifs ».


30

• La traçabilité : le fait de traiter l’historique descontrôles, ce qu’on appelle souvent une pisted’audit, permet au management de suivre lestransactions depuis la source jusqu’au résultatfinal ou de remonter à partir des résultatsjusqu’aux transactions et les événements enre-gistrés qui les ont générés. Ces contrôles doi-vent permettre de surveiller l’efficacité del’ensemble des contrôles et de déceler leserreurs le plus en amont possible.

6.4 Sécurité informatique

La sécurité informatique1 fait partie intégrante descontrôles des SI. Elle s’applique à la fois à l’infra-structure et aux données, et c’est sur elle querepose la fiabilité des autres contrôles des SI, àl’exception de ceux ayant trait aux aspects finan-ciers des SI (par exemple le retour sur investisse-ment, les contrôles budgétaires) et de quelquescontrôles de gestion de projet. Les composantesgénéralement acceptées de la sécurité informa-tique sont :• La confidentialité : les données confiden-tielles ne doivent être divulguées que lorsquec’est nécessaire, et doivent être protégéescontre toute interception ou communicationnon autorisée. La confidentialité a égalementtrait au respect de la vie privée et des donnéespersonnelles.

• L’intégrité : l’intégrité des données désignedes données correctes et complètes. Elle estparticulièrement importante pour la fiabilitédu traitement de données financières et lescommunications financières.

• La disponibilité : les données doivent êtreaccessibles à l’organisation, à ses clients et par-tenaires au moment, à l’endroit et de lamanière requise. La disponibilité porte égale-ment sur la capacité de redémarrage des SIaprès une perte, une panne ou la corruption dedonnées et de services des SI, ou encore aprèsun sinistre majeur à l’emplacement où les don-nées étaient situées.

6.5 Cadre de contrôle des SI

Les organisations utilisent les SI depuis plus de 50ans et, sur cette période, les contrôles n’ont pastoujours constitué une caractéristique par défautdes nouveaux matériels ou logiciels. L’élaborationet la mise en place de contrôles arrivent générale-ment après que l’on ait décelé une vulnérabilitédans le système ou des menaces qui exploitent cesvulnérabilités. En outre, les contrôles des SI nesont pas définis dans des normes universellementreconnues applicables à tous les systèmes ou àtoutes les organisations qui les utilisent.Un cadre de contrôle permet de structurer la typo-logie et l’identification des contrôles pour sécuriserl’environnement SI. Ce cadre peut être formel ouinformel. Une approche formelle sera plus satis-faisante pour répondre aux différents régulateursou aux exigences légales auxquels sont soumisesles organisations. Toutes les parties concernées,notamment les propriétaires des processus métierset les fonctions qui mettent en œuvre les contrôles,doivent être impliquées dans la définition ou l’éla-boration du cadre de contrôle. Ce cadre decontrôle devrait être appliqué et utilisé par l’en-semble de l’organisation.

1 GTAG 15 « La gouvernance de la sécurité de l’information ».

GTAG – Compétences et savoir-fairedans le domaine de l’audit des SI

31

7. Compétences et savoir-faire dans le domaine de l’auditdes SI

Selon le CRIPP, les auditeurs internes doivent appliquer et veiller au respect de quatre principes : intégrité,objectivité, confidentialité et compétence. Le principe de compétence impose aux auditeurs internes des’engager uniquement dans des travaux pour lesquels ils ont les connaissances, le savoir-faire et l’expé-rience nécessaires. En outre, la norme de qualification « 1210 : Compétence » de l’IIA, précise que « Lesauditeurs internes doivent posséder les connaissances, le savoir-faire et les autres compétences nécessairesà l’exercice de leurs responsabilités individuelles. L’équipe d’audit interne doit collectivement posséderou acquérir les connaissances, le savoir-faire et les autres compétences nécessaires à l’exercice de ses res-ponsabilités. » Le RAI doit obtenir l’avis et l’assistance de personnes qualifiées si les auditeurs internes ne possèdentpas les connaissances, le savoir-faire ou les autres compétences nécessaires pour s’acquitter de tout oupartie de la mission. L’IIA fournit un cadre de référence intitulé Integrated Competency Framework qui aideà identifier les compétences nécessaires à l’activité d’audit interne. Cette approche relie les risques opé-rationnels identifiés aux processus des SI auxquels ils se rapportent. Le RAI devrait donc savoir quel typeet quel niveau de compétences et de savoir-faire en matière de SI sont requis pour auditer l’efficacité descontrôles sur les risques opérationnels identifiés. Le tableau ci-après donne quelques exemples de liensentre risques opérationnels et contrôles des SI, et de savoir-faire / compétences requis pour exécuter l’au-dit.

1 Voir la Modalité pratique d’application « 1210.A1-1: Recoursà des prestataires externes » de l’IIA.

Risque métiers Contrôles des SISavoir-faire et compétences

en matière de SI

Gestion de la sécurité informa-tique

Contrôle de la sécurité logiqueefficace

Administration de la sécurité ;contrôles d’accès au niveau duréseau, du système opération-nel, des bases de données et desapplications

Interruption critique de l’activité Garantir la disponibilité desapplications métiers critiques

Plans de continuité d’activité etplan de secours pour les installa-tions informatiques (notam-ment l’infrastructure réseau, lessystèmes opérationnels, lesbases de données et les applica-tions)

Informations financières et opé-rationnelles inexactes et incom-plètes

Sécuriser la confidentialité et ladisponibilité des données

Contrôles applicatifs, contrôlesdes changements et des cyclesde vie du développement logi-ciel (SDLC)

Si l’audit interne ne possède pas les compétences et le savoir-faire requis dans le domaine des SI, le RAIpeut faire appel à un prestataire externe pour soutenir ou compléter l’équipe interne (externalisation ouressources externes partagées).1

GTAG – Utilisation du cadre de contrôle

32

8. Utilisation du cadre decontrôle

Chaque organisation devrait examiner les cadresde contrôle existants et déterminer lesquels (ouquelles parties) répondent le mieux à ses besoins.Le choix ou l’élaboration d’un cadre de contrôledoit associer tout le personnel de l’organisationayant une responsabilité directe vis-à-vis descontrôles. L’audit interne évaluera l’adéquation ducadre et l’utilisera pour la planification et l’exécu-tion des travaux d’audit interne.

Le RAI doit avoir une connaissance globale desrisques liés aux SI pour juger de l’efficacité et del’adéquation des contrôles des SI. Il élabore le pland’audit interne et affecte les ressources dans lesdomaines et aux problématiques qui appellent uneattention particulière en raison de leur niveau derisque intrinsèque. L’analyse et l’évaluation desrisques ne peuvent pas être réalisées une fois pourtoutes, surtout si elles s’appliquent aux SI. La tech-nologie évolue constamment et rapidement, demême que les risques et menaces qui y sont asso-ciés. La classification des contrôles des SI d’aprèsleur positionnement, objectif et fonction au seinde l’organisation peut se révéler utile pour en éva-luer leur pertinence et leur adéquation, et pourjuger si le système de contrôle interne est appro-prié. La connaissance de la gamme des contrôlesdes SI disponibles, des raisons d’être de cescontrôles ainsi que des rôles et responsabilités ausein de l’organisation permet des analyses et desévaluations complètes de risques. Lorsque l’onjuge de l’efficacité des contrôles, il est égalementutile de savoir si ces derniers sont obligatoires oufacultatifs, discrétionnaires ou non, manuels ouautomatisés, clés ou secondaires, et si le manage-ment peut avoir la possibilité de les outrepasser.

Enfin, l’évaluation des contrôles des SI suppose desélectionner des contrôles clés qui seront testés,d’en évaluer les résultats, et de déterminer si leséléments de preuves permettent de déceler desfaiblesses significatives. La liste de vérification pré-sentée en annexe peut aider à s’assurer que toutes

les problématiques pertinentes ont été prises enconsidération lors de la planification et du choixde l’orientation donnée aux évaluations d’auditinterne sur les contrôles des SI. Plusieurs référen-tiels et approches peuvent aider le RAI et d’autresmanagers à définir les besoins de contrôles des SI.Cependant, les organisations doivent étudier suf-fisamment de cadres de référence pour savoirlequel correspond le mieux à leurs besoins et à leurculture.

8.1 Techniques d’audit assisté parordinateur et analyse desdonnées

Les RAI devraient envisager d’utiliser des tech-niques d’audit assisté par ordinateur - notammentdes outils d’analyse des données - pour obtenirune vision réaliste de l’environnement des risquesliés aux SI et pour identifier les anomalies poten-tielles. Dans un contexte où les organisations et lesactivités d’audit interne doivent en faire plus avecdes moyens réduits, l’analyse des données permetaux RAI d’exploiter les informations disponiblesdans l’ensemble de l’organisation et d’identifierdes domaines nécessitant potentiellement uneévaluation des risques ou un audit. L’analyse desdonnées peut également représenter pour le RAIune approche pour évaluer en continu l’efficacitéopérationnelle des contrôles et pour analyser lesindicateurs des risques émergents. Les outils exis-tants d’analyse des données accroissent les possi-bilités de l’audit des informations et l’efficience dutraitement de volumes de données plus impor-tants. Toutefois, les RAI sont confrontés à des dif-ficultés importantes : ils doivent obtenir lesavoir-faire technique, accéder aux outils d’analysedes données, exploiter les outils de reporting / d’ex-traction des données, accéder aux sources de don-nées et élaborer une stratégie axée sur les risquesorganisationnels les plus élevés.L’audit continu est semblable à la surveillancecontinue, les données étant analysées ou évaluéesen continu par l’audit interne. La surveillancecontinue relève de la responsabilité et de la fonc-tion du management. L’audit interne peut tester,revoir ou exploiter l’utilisation de la surveillance


33

continue. Pour de plus amples informations, voirle GTAG 3 de l’IIA « Audit continu : répercussionssur l’assurance, le pilotage et l’évaluation desrisques ».

8.2 Recours à l’évaluationautomatisée des risques

Le RAI peut estimer que pour renforcer son éva-luation des risques, il doit procéder à une cotationou à une évaluation détaillée des risques. Certainsoutils permettent également l’automatisation duprocessus d’analyse des risques. Ces outils per-mettent d’établir une cotation des risques, de pré-ciser leur impact et d’en estimer la probabilité,entre autres facteurs. Grâce à l’automatisation del’évaluation des risques, il est possible de compareret de hiérarchiser les risques. Le recensement desfacteurs de risque inhérents et résiduels permet auRAI de fournir des informations résumées tellesque des cartographies des risques ou des profils derisques correspondant au profil de risque de l’or-ganisation. L’automatisation de la gestion de l’au-dit interne est un sujet important en soi.L’automatisation du processus d’évaluation desrisques (par exemple le recours à des outils pourpermettre au management d’enregistrer les cota-tions du risque) représente une opportunité.

8.3 Reporting des contrôles des SI

Les RAI doivent communiquer aux principalesparties prenantes - par exemple le Comité d’audit,le comité exécutif, les instances de réglementation,les auditeurs externes ou le directeur des SI - lesrésultats des missions d’assurance. Les RAI peu-vent utiliser différents formats de rapport, et lesapproches peuvent aller des mises à jour auxtableaux de bord, en passant par des présentationsà huis-clos à la direction générale.

Une approche consiste à commencer par actualiserl’évaluation. Le RAI devrait tout d’abord détermi-ner le niveau de risque inhérent à certains proces-sus clés des SI. Par exemple, le RAI peut indiqueret vérifier avec le directeur des SI ou les principalesparties prenantes des SI le risque inhérent audéveloppement, à l’exploitation, au plan de conti-nuité des activités, au réseau, à la sécurité infor-matique et à la gestion du changement. Le risqueinhérent dépend souvent de la stratégie et de l’or-ganisation des SI. Certaines organisations des SIpeuvent être externalisées, centralisées ou décen-tralisées. Les actualisations peuvent prendre laforme de projets d’audit dans différents domainesfonctionnels des SI, et peuvent englober desconstats ou des problématiques importants. L’état

Contribution de l’audit aux contrôles des SI

Au cours des dernières décennies, on s’est, à plusieurs reprises, interrogé, en particulier lorsque ladirection générale et les auditeurs s’accordaient à dire que ces derniers pouvaient être source devaleur ajoutée pour l’organisation en apportant aux processus de développement leur expertise enmatière de contrôles ; cette démarche permettait de veiller à ce que des contrôles adéquats soientintégrés aux nouveaux systèmes, au lieu de n’y ajouter des contrôles qu’après que l’audit ait détectédes failles. Ces activités ont coïncidé avec les avancées dans l’autoévaluation des contrôles et desrisques dans le monde de l’audit. Les missions de conseil et l’approche d’audit fondée sur les risquesse sont généralisées. A partir des années 1990 et après, on a prêté davantage attention à la gestionde la sécurité informatique, à mesure que des cyber-attaques de plus en plus graves se multipliaient.Ces événements ont contribué à façonner le rôle de l’auditeur informatique et la prise de consciencedes organisations de l’importance d’une gestion efficace de la sécurité informatique.


34

d’avancement des recommandations d’auditpourrait également faire partie de l’actualisationsur les SI.

Une autre approche consiste à utiliser un tableaude bord aligné avec le tableau de bord (BalancedScorecard) utilisé par le directeur des SI pour lereporting de la stratégie et des activités informa-tiques. Le Balanced Scorecard Institute donne unmodèle qui considère l’activité informatique selonquatre axes : financier, client, processus métiersinternes, apprentissage organisationnel et déve-loppement. Lorsque le RAI rend compte des SIdans le cadre du reporting régulier au Conseil, auComité d’audit ou à la direction générale, le rap-port devrait couvrir généralement des probléma-tiques liées aux incidents affectant la sécuritéinformatique, les anomalies en matière de gestiondu changement, l’état d’avancement de projets, lereporting des incidents d’exploitation, les dépensesd’investissement, et d’autres indicateurs mesurantles principaux risques et l’évaluation des contrôlesdes SI. Ce type d’approche permet une appréhen-sion intégrée et exhaustive de tous les risques etcontrôles – métier et SI – dans un seul format.

Il arrive que le RAI ait besoin d’organiser des réu-nions en comité restreint. Ce type de reportingconcerne généralement les problématiques impor-tantes. Il peut s’agir par exemple de l’incapacité del’équipe d’audit interne à obtenir des donnéesdemandées malgré des tentatives répétées, de col-laborateurs clés de la DSI ne fournissant pas desinformations complètes, ou des responsablesinformatiques qui excluent l’auditeur interne desdiscussions importantes, de comités de pilotage(qui ne le convie pas). L’absence de soutien dudirecteur des SI peut également constituer une dif-ficulté nécessitant une réunion. Cette « exempla-rité » peut instaurer une culture inadéquate, voirebloquer les mesures correctrices ou permettre auxprincipaux contrôles des SI de fonctionner sanssurveillance.

GTAG – Conclusion

35

9. Conclusion

L’évaluation des risques et des contrôles des SIreprésente – pour les nouveaux RAI comme pourles plus expérimentés – l’une des premières étapesvers la compréhension de l’environnement des SIet de son importance dans la gestion des risquesde l’organisation. La lecture et l’application desrecommandations de ce GTAG permettront auxRAI et aux auditeurs internes de mieux compren-dre les risques des SI et les contrôles applicables.Le RAI pourra ensuite animer des discussions surles risques et les contrôles des SI avec les princi-pales parties prenantes.

L’étape suivante, l’évaluation et la compréhensionde la gouvernance des SI, permet au RAI d’identi-fier les responsabilités au sein des SI et de déter-miner comment la DSI, en coopération avec ladirection générale, déploie la stratégie des SI. Dansce contexte, les RAI devraient garder à l’esprit lesdispositions de la Norme 2110.A2 de l’IIA concer-nant « l’évaluation de la gouvernance des SI ». LaSection 3 (Parties prenantes internes et responsa-bilités des SI) de ce document résume de façonutile les principaux rôles et responsabilités.

Une fois que le RAI évalue la gouvernance des SI,l’étape suivante logique du processus est celle del’analyse des risques liés aux SI. Malheureuse-ment, il n’existe pas de liste de vérification univer-selle pour analyser les risques liés aux SI. Chaqueorganisation - selon les spécificités de ses métiersou de sa taille - fonctionne avec des infrastruc-tures, des applications et des interfaces technolo-giques différentes, et utilise des politiquesdifférentes pour mener à bien sa stratégie des SI.Le RAI devrait effectuer une analyse des risquesen utilisant une méthodologie structurée, telle quecelle exposée dans la norme ISO 31000 « Mana-gement du risque » ou COSO II, et exploiter lesconnaissances des principaux responsables des SI(par exemple le directeur des SI et autres direc-teurs) dans le contexte des risques globaux inhé-rents à l’organisation. Le développement derelations de confiance solides favorisera la trans-

parence lors de l’analyse des risques inhérents etrésiduels.

Il existe de nombreux modèles et approches pouranalyser les risques liés aux SI, et le RAI devraitsélectionner ceux qui correspondent le mieux àson organisation. Plusieurs rôles et fonctions clésdes SI sont détaillés à la Section 6 (Comprendrel’importance des contrôles des SI) de ce document.Le RAI note les niveaux de risque liés aux SI etdétermine les éléments devant être intégrés auplan d’audit général. À partir du plan d’audit général, le RAI doit iden-tifier et évaluer le savoir-faire et les compétencestechniques nécessaires. Il peut s’inspirer de laGAIT Methodology de l’IIA lorsqu’il utilise uneapproche descendante basée sur les risques. Cer-taines spécialisations peuvent toutefois être coû-teuses à déployer à titre permanent. Les RAIpeuvent exploiter des savoir-faire acquis en interneou recrutés, ou faire appel à des prestatairesexternes. S’appuyer sur des ressources externespermet aux organisations de toutes tailles debénéficier d’une expertise ainsi que d’une visibilitésur les tendances les plus récentes et leur risque.

L’évaluation des risques et des contrôles des SIs’appuie sur un plan réfléchi et organisé. Les RAIdevraient prévoir suffisamment de temps et deressources qualifiées pour adopter une approcheprofessionnelle et établir un processus pérenned’analyse continue.

GTAG – Auteurs et réviseurs

36

Auteurs et réviseurs

AuteursSteve Mar, CFSA, CISARune Johannessen, CIA, CCSA, CISAStephen Coates, CIA, CGAP, CISAKarine Wegrzynowicz, CIAThomas Andreesen, CISA, CRISC

RéviseursSteve Hunt, CIASteve Jameson, CIA, CCSA, CFSA, CRMA

Autres contributeursDragon Tai, CIA, CCSA

Réviseurs en françaisBéatrice Ki-Zerbo, CIAAlain Rogulski, CIA

GTAG – Annexe : Liste de vérificationdu Cadre de contrôles des SI

37

Annexe : Liste de vérification du Cadre de contrôles des SI

Les RAI peuvent utiliser cette liste de vérification pour examiner leur cadre de contrôle des SI afin devérifier que l’organisation a pris en compte tous les éléments de contrôle. Cette liste peut les aider à com-prendre les problèmes et à planifier une mission d’audit interne couvrant l’intégralité des champs de véri-fication.

Actions Questions

1. Déterminer l’environnement de contrôle desSI de l’organisation, notamment : a. Ses valeurs. b. Sa philosophie. c. Son style de management. d. Sa connaissance des SI. e. Son organisation. f. Ses politiques. g. Ses normes.

• Existe-t-il des politiques et des normes d’entre-prise expliquant la nécessité des contrôles desSI ?

2. Identifier la législation et la réglementationqui ont des conséquences sur les contrôlesdes SI : a. La gouvernance. b. La communication financière. c. La protection des données. d. Le respect des règles.

• Quelles sont les lois en vigueur ayant desconséquences sur les besoins de contrôle desSI ?

• La direction générale a-t-elle pris des mesuresen vue de respecter cette législation ?

3. Identifier les rôles et les responsabilités rela-tifs au contrôle des SI pour : a. Le conseil d’administration.

i. Le comité d’audit. ii. Le comité de gestion des risques. iii. Le comité de gouvernance. iv. Le comité financier.

b. Le management. i. Le directeur général. ii. Le directeur financier et le contrôleur de

gestion. iii. Le directeur des SI. iv. Le directeur de la sécurité / sûreté.v. Le directeur de la sécurité informatique. vi. Le directeur des risques.

c. L’audit. i. L’audit interne. ii. L’audit externe.

• Toutes les responsabilités portant sur lecontrôle des SI ont-elles été attribuées ?

• L’allocation des responsabilités est-elle compa-tible avec les principes de séparation destâches ?

• Les responsabilités en matière de SI sont-ellesformalisées ?

• Les responsabilités concernant les contrôlesdes SI ont-elles été communiquées à l’ensem-ble de l’organisation ?

• Les personnes endossant les différents rôlescomprennent-elles clairement leurs responsa-bilités concernant les contrôles des SI ?

• Quelles preuves existe-t-il que les titulaires desdifférents rôles exercent leurs responsabilités ?

• L’audit interne emploie-t-il suffisamment despécialistes informatiques pour examiner lesproblèmes liés aux contrôles des SI ?

GTAG – Annexe : Liste de vérificationdu Cadre de contrôles des SI

38

Actions Questions

4. Identifier le processus d’évaluation desrisques. Couvre-t-il : a. L’appétence pour le risque ? b. La tolérance au risque ? c. L’analyse de risques ? d. L’adaptation des contrôles des SI aux

risques ?

• Comment sont déterminées l’appétence pourle risque et la tolérance au risque de l’organisa-tion ?

• L’appétence pour le risque et la tolérance aurisque de l’organisation ont-elles reçu l’aval duConseil ?

• Le niveau d’appétence pour le risque et de tolé-rance au risque sont-ils clairement compris partous ceux qui ont des responsabilités enmatière de contrôle des SI ?

• L’organisation recourt-elle à un processusformel pour l’analyse des risques ?

• Ce processus est-il compris par tous ceux quiont des responsabilités en matière de contrôledes SI ?

• Ce processus est-il uniformément utilisé danstoute l’organisation ?

5. Identifier tous les processus de surveillance :a. Imposés par la réglementation.b. Classiques, en interne.c. Autres que l’audit interne.

• Quels processus sont en place pour vérifier quetous les textes de loi, ainsi que les politiques etnormes internes, sont bien respectés ?

• La direction générale a-t-elle mis en place desprocessus autres que l’audit interne ?

6. Identifier les mécanismes d’information etde communication :a. Information de contrôle.b. Défaillances de contrôles.

• Quels indicateurs sont fournis au Conseil, à sescomités et à la direction générale concernant lasécurité informatique ?

• Quels rapports supplémentaires sont régulière-ment fournis au conseil et à la direction géné-rale ?

• La direction générale reçoit-elle systématique-ment un rapport en cas de défaillance descontrôles des SI ?

• Le Conseil et ses comités reçoivent-ils des rap-ports analogues en cas de défaillance descontrôles des SI ?

GTAG – A propos du CRIPP

39

Eléments Définition

Les dispositions obligatoires. Le respect de ces éléments est exigé et la ligne directrice est élaborée selon le processus requis quiinclut une consultation publique. La conformité aux principes mis en exergue dans les lignes direc-trices obligatoires est indispensable pour la pratique professionnelle de l'audit interne. Les trois com-posantes des dispositions obligatoires sont la définition de l’audit interne, le Code de Déontologie etles Normes internationales pour la pratique professionnelle de l’audit interne (Normes).

Définition La Définition de l’Audit Interne établit l’objectif fondamental, la natureet le champ d'application de l’audit interne.

Code de déontologie Le Code de déontologie établit les principes et attentes régissant lecomportement des individus et des organisations dans la conduite del’audit interne. Il décrit les règles minimales de conduite ainsi que descomportements attendus plutôt que des activités spécifiques.

Normes internationalespour la pratique profession-nelle de l’audit interne(Normes)

Les Normes sont des principes qui fournissent un cadre pour la réali-sation des missions et la promotion de l’audit interne. Elles se compo-sent de Normes de qualification, de Normes de fonctionnement et deNormes de mises en œuvre. Les Normes sont des exigences obliga-toires constituées :

· de déclarations sur les exigences fondamentales pour la pratiqueprofessionnelle de l’audit interne et pour l’évaluation de sa per-formance. Elles sont internationales et applicables au niveau duservice et au niveau individuel.

· d’interprétations clarifiant les termes ou les concepts utilisésdans les déclarations.

Il est nécessaire de considérer le texte dans sa totalité (c’est-à-dire lesdéclarations et les interprétations) afin de comprendre et d’appliquercorrectement les Normes. Les termes spécifiques utilisés dans lesNormes sont explicités dans le Glossaire.

A propos du CRIPP

GTAG – A propos du CRIPP

40

Ce GTAG est un guide pratique du CRIPP.

Eléments Définition

Les dispositions fortement recommandées. La conformité à ces lignes directrices, approuvées par l’IIA, est fortement recommandée. Elles propo-sent des pratiques pour la mise en œuvre effective de la définition de l’audit interne, du Code de Déon-tologie de l’IIA et des Normes internationales pour la pratique professionnelle de l’audit interne(Normes). Les trois composantes des dispositions fortement recommandées sont les prises de position,les modalités pratiques d’application (MPA) et les guides pratiques.

Prises de position Les Prises de Position aident l’ensemble des parties prenantes, y com-pris celles qui ne sont pas des professionnels de l’audit interne, à com-prendre les principaux enjeux en matière de gouvernance, de risqueou de contrôle. Elles précisent également le rôle et les responsabilitésde l’audit interne.

Modalités pratiques d’appli-cation (MPA)

Les Modalités Pratiques d’Application fournissent une approche etune méthodologie mais ne précisent pas les processus et les procé-dures détaillées. Ce sont des lignes directrices qui aident les auditeurs internes dansl'application du Code de déontologie et des Normes ainsi que la pro-motion des meilleures pratiques.Ces pratiques concernent notamment :

• des problématiques internationales, nationales ou spécifiques àcertains secteurs d'activité ;

• des missions d'audit spécifiques ;• des questions légales ou réglementaires.

Guides pratiques Les guides pratiques sont des lignes directrices détaillées pour laconduite des activités d’audit interne. Ce sont des processus et des procédures détaillés tels que des outils,des techniques, des programmes, des approches séquentielles (parexemple, des modèles de livrables).

les contrôles et le risque des systèmes d’information 1 - les... · comme étant les contrôles...

Documents