Guide d analyse des risques informatiques

Transcription

1 Guide d analyse des risques informatiques Support de travail pour les auditeurs de PME Processus métiers Applications IT Systèmes IT de base Infrastructure IT ITACS Training

2

3 «Guide d analyse des risques informatiques» Table des matières Table des matières 1 Vue d ensemble et délimitation 2 Introduction 4 Guide d analyse des risques informatiques 6 Phase 1: Evaluation globale des risques 8 Phase 2: Contrôle relatif à l utilisation de l informatique 15 L IT-Check comme «combinaison» des phases 1 et 2 19 Indications concernant les audits IT approfondis 21 Conclusion 24 Questionnaire Phase I (Annexe 1) 25 Questionnaire Phase II (Annexe 2) 27 Auteurs: Comité technique informatique de la Chambre fiduciaire Gestion de projet: Peter R. Bitterli et Peter Steuri Graphisme et mise en page: Felice Lutz, ITACS Training AG 1

4 1 Vue d ensemble et délimitation Délimitation de l approche Dans le cadre des procédures d audit orientées processus ou résultat et basées sur l utilisation d applications informatiques (IT), il est essentiel de prendre en compte tous les domaines importants, y compris les domaines IT spécifiques ayant une influence significative sur l objectif de l audit. Pour y parvenir, une approche d audit intégrée (auditeur et auditeur IT) est nécessaire. L absence de procédure concertée entre auditeurs et auditeurs IT constitue à cet égard un risque élevé. Afin de prévenir ce risque d audit, les membres du Comité technique informatique de la Chambre fiduciaire ont élaboré deux guides. Ceux-ci reposent sur un modèle à quatre couches qui présente les principales interactions de manière schématique et simplifiée. Dans la réalité, les interactions peuvent être beaucoup plus complexes. La schématisation permet de mieux appréhender les deux approches. couvert par la méthode non couvert par la méthode Contrôles IT généraux Environnement de contrôle IT (polices, directives) Développement de programmes Modifications IT Exploitation IT Gestion des accès Sécurité des systèmes Sécurité des données Processus métier / transactions Applications financières Middleware / base de données Systèmes d exploitation / réseau Contrôles d applications IT Intégralité Exactitude Validité Autorisation Séparation des fonctions Modèle à quatre couches La figure ci-dessus montre, sous forme simplifiée, le modèle en couches utilisé dans les deux approches élaborées par le Comité technique informatique. Chacune des quatre couches représente un type de processus et de ressource. La couche supérieure (bleue) contient les principaux processus (manuels) de l entreprise, présentés typiquement par domaines d activité et subdivisés en sous-processus et en activités individuelles. La deuxième couche (rouge) contient les éléments automatisés des processus de l entreprise, c est-à-dire les applications (IT) à proprement parler. A l exception peut-être des PME de petite taille, la majorité des opérations commerciales dans toutes les entreprises est traitée à l aide d applications IT. La troisième couche (jaune) contient les systèmes IT de base. Ce terme recouvre une grande diversité de plates-formes possibles supportant les applications de la deuxième couche. Exemples: systèmes de gestion de base de données (p. ex. SQL, Oracle), composants de base d applications intégrées (p. ex. SAP Basis) ou systèmes plus techniques (p. ex. Middleware). La couche inférieure (verte) contient les éléments d infrastructure informatique. Pour l essentiel, cette couche contient les éléments matériels (systèmes Midrange, serveurs) ainsi que les composants du réseau et les systèmes de surveillance technique y relatifs. 2

5 «Guide d analyse des risques informatiques» Guide d audit des applications informatiques Le «Guide d audit des applications informatiques» publié en 2008 est aujourd hui disponible en allemand ( en français ( et en anglais ( Il traite principalement des deux couches supérieures, c est-à-dire des contrôles basés sur l utilisation d applications informatiques au sein des processus métiers ainsi que des applications sous-jacentes. L approche présentée est destinée à aider l auditeur financier à développer une approche d audit intégrée et à recentrer la procédure d audit de manière plus efficace et plus ciblée sur les risques, en intégrant l audit des processus métiers pertinents et des applications correspondantes. L approche commence donc avec l analyse des états financiers de l entreprise et se termine par l appréciation de l impact des résultats d audit sur ces états financiers. Cette analyse des états financiers de l entreprise lie les principales positions comptables aux processus métiers pertinents ou, plus concrètement, détermine les flux de traitement des données à l origine des principales positions comptables et des applications de base qui supportent ces flux. Une fois les applications de base identifiées, l auditeur s intéresse à la qualité du système de contrôle. Il détermine d abord si la conception du système de contrôle est adaptée à la situation de risque actuelle des processus de l entreprise et enfin si les contrôles prévus sont implémentés et sont efficaces. L évaluation du système de contrôle des processus métiers pris en compte dans le cadre de l audit permet à l auditeur de savoir s il peut s appuyer sur les procédures et les applications de base à l origine des principales positions comptables et, le cas échéant, de définir l étendue des procédures d audit orientées résultat supplémentaires qu il doit effectuer. Guide d analyse des risques informatiques Le présent «Guide d analyse des risques informatiques» traite principalement des deux couches inférieures, c est-à-dire de l infrastructure IT et des processus IT sous-jacents, mais aussi des processus IT généraux relatifs à la maintenance et au développement des applications IT de l entreprise au sein de la deuxième couche. Le guide analyse en outre un certain nombre de problématiques liées aux deux couches supérieures afin de procéder à une évaluation globale de la situation en termes de risques. Le «Guide d analyse des risques informatiques» établit une approche standard pour: l identification des risques inhérents à l utilisation de l informatique dans l entreprise; le recensement et l'évaluation des «contrôles IT généraux» ainsi que l utilisation de l informatique au sein des petites et moyennes entreprises et organisations. Le «Guide d analyse des risques informatiques», qui constitue un support de travail facultatif, fournit ainsi à l auditeur les informations sur l utilisation de l informatique nécessaires à la planification stratégique de l audit. 3

6 2 Introduction Importance de l informatique pour le SCI Conformément à l art. 728a CO, l organe de révision doit vérifier et confirmer, à partir de l exercice 2008, s il existe un système de contrôle interne (SCI) dans les entreprises ayant une importance économique soumises à un contrôle ordinaire. Dans bon nombre de petites et moyennes entreprises, on observe que l étendue et le contenu, mais aussi l utilité concrète du SCI, sont encore sources d incertitudes et de questions. Ceci est valable tant pour le SCI au niveau de l entreprise et des processus que, dans une plus large mesure encore, pour les contrôles IT. La Norme d audit suisse «Vérification de l existence du système de contrôle interne» (NAS 890) définit comme suit l importance de l informatique pour le système de contrôle interne: «Plus le processus de tenue de la comptabilité et d établissement du rapport financier dépend de systèmes IT et plus le risque que des erreurs trouvent leur origine dans la mise en place et l utilisation des systèmes IT est élevé, plus les contrôles dans le domaine de l informatique sont importants.» Utilisation de l informatique dans les PME Les exigences des PME en matière d informatique ne sont pas très différentes de celles des grandes entreprises: il est souvent indispensable de recourir à des applications recouvrant un large éventail de fonctions et requérant une disponibilité et une sécurité importantes pour assurer l efficacité et la fiabilité des processus de l entreprise. Par rapport aux grandes entreprises, dont les services informatiques sont dotés d un savoir-faire et de capacités élevés, les PME bien que leurs systèmes et leur infrastructure IT soient généralement «clairs» et que les applications de base consistent de logiciels standard sont souvent exposées aux risques «typiques» suivants: absence de savoir-faire en matière d applications IT ainsi que de flux de données et de valeurs (interfaces), d où une utilisation des logiciels inefficace et sujette aux erreurs, des faiblesses dans les contrôles internes et une dépendance élevée vis-à-vis de partenaires externes (fournisseurs); concentration importante du savoir-faire au niveau de quelques personnes, ce qui s accompagne très souvent de processus IT peu structurés et peu documentés, d où une dépendance élevée vis-à-vis de ces personnes clés; pas de séparation des fonctions entre la comptabilité et l informatique, notamment parce que dans les petites entreprises la responsabilité et parfois aussi l exécution dans ces deux domaines relèvent de la même personne; protection appropriée des accès au niveau du réseau et du système d exploitation, cependant au sein des applications les droits d accès sont peu différenciés, des mots de passe peu sûrs sont utilisés et il n y a pas de changement périodique des mots de passe; présence d'applicatifs Excel ou Access et de solutions individuelles installées par certains utilisateurs sur leur PC et peu documentées; leur développement, leur évaluation, leur fonctionnement et, souvent, leur utilisation (en particulier concernant les chiffres clés et le MIS) dépendent entièrement de cette seule personne; faiblesses en termes de sécurité physique (accès, détection de la fumée et des incendies, climatisation et alimentation électrique) dans le centre de calcul ou la salle des serveurs; réalisation régulière de sauvegardes des données, mais faiblesses fréquentes au niveau de leur conservation (pas de coffre-fort pour supports de données), externalisation insuffisante et absence de tests de restauration (pour restaurer les données après un incident grave); absence de mesures de précaution et de préparation pour appréhender les incidents graves (p. ex. destruction du centre de calcul ou de la salle des serveurs), alors que les processus de l entreprise dépendent largement de la disponibilité des moyens informatiques. 4

7 «Guide d analyse des risques informatiques» Le SCI dans le domaine IT Dans le domaine IT, un SCI global comprend des objectifs de contrôle et des contrôles à différents niveaux: Entreprises: stratégie, organisation et personnel IT, gestion des risques et de la sécurité ainsi que pilotage et gestion de projets IT; Processus de l entreprise: organisation structurelle et opérationnelle et contrôles principalement au niveau des processus de l entreprise ayant une influence sur les flux de données et de valeurs ainsi que sur la présentation des comptes et le rapport financier; Applications IT: contrôles lors de la saisie, de l entrée, du traitement et du résultat des transactions et des données ainsi que contrôles au niveau des interfaces entre les applications IT; Exploitation IT: contrôles lors du développement et de la modification de programmes, de l exploitation et de la configuration des moyens IT, de la sécurité des systèmes et des données et de la surveillance de l informatique. 5

8 3 Guide d analyse des risques informatiques Considérations initiales Le «Guide d analyse des risques informatiques» a pour but d aider l auditeur à identifier et à évaluer, dans les petites et moyennes entreprises et organisations, les risques éventuels liés à l utilisation de l informatique. L auditeur peut ainsi tirer des conclusions qui lui serviront pour planifier et exécuter l audit, mais aussi pour décider s il doit faire appel ou non à un auditeur IT spécialisé. L approche couvre les «contrôles informatiques généraux (IT)» mentionnés dans la Norme d audit suisse NAS 890 «Vérification de l existence du système de contrôle interne». Elle se concentre sur les domaines ayant une importance directe et indirecte pour la tenue et la présentation des comptes et aborde aussi un certain nombre d autres domaines. L approche est indépendante du type de contrôle (ordinaire ou restreint); elle se fonde sur l importance que revêt l informatique pour l entreprise ainsi que sur la tenue et la présentation des comptes de celle-ci. Les prescriptions juridiques et réglementaires concernant l utilisation de l informatique et son contrôle ne sont pas prises en compte dans le «Guide d analyse des risques informatiques», mais elles peuvent parfaitement constituer une raison essentielle de faire évaluer l utilisation de l informatique par un auditeur IT spécialisé. Aperçu du contenu Phase 1: Evaluation sommaire des risques voir chapitre 4 La phase 1 correspond à une évaluation des risques et des interdépendances liés à l utilisation de l informatique. L évaluation ne doit pas impérativement être exhaustive et précise en tous points, mais elle doit mettre en lumière le besoin de réaliser un contrôle complémentaire et plus détaillé de l utilisation de l informatique. A l issue de la phase 1, l auditeur peut décider, sur la base de cette première évaluation des risques, si l exécution de la phase 2 est nécessaire. Phase 2: Contrôle relatif à l utilisation de l informatique voir chapitre 5 La phase 2 correspond à un contrôle vaste et détaillé des forces et des faiblesses liées à l utilisation de l informatique. Le traitement des questions/du questionnaire de la phase 2 peut s effectuer tant dans le cadre de la planification stratégique de l audit que dans celui de l audit (intermédiaire) proprement dit. A l issue de la phase 2, les conclusions tirées par l auditeur permettent à celui-ci de décider si un audit IT complet doit être effectué et dans quels domaines. Un questionnaire comme base de contrôle Un questionnaire a été élaboré pour chacune des deux phases. Son étendue et son contenu sont adaptés aux objectifs de chaque phase et permettent un traitement ciblé et efficace. Les «réponses» aux différentes questions se basent sur un modèle de maturité à quatre niveaux; elles permettent (et exigent) ainsi une évaluation claire d un fait ainsi qu une comparaison avec d autres entreprises. 6

9 «Guide d analyse des risques informatiques» L IT-Check comme «combinaison» des phases 1 et 2 voir chapitre 6 Le contenu des phases 1 et 2 peut, notamment quand le contrôle lors de chaque phase est effectué parallèlement par le même auditeur, être regroupé dans un IT-Check. Ce que le «Guide d analyse des risques informatiques» n est pas Le «Guide d analyse des risques informatiques» ne constitue pas une analyse complète des risques. Il s agit plutôt d un outil de travail destiné principalement à la planification stratégique de l audit qui peut être mis en œuvre efficacement. Il permet une identification et une évaluation raisonnables des risques liés à l utilisation de l informatique. Le «Guide d analyse des risques informatiques» n est pas un guide pour un audit informatique approfondi; selon les auteurs du guide, ce dernier doit être effectué par des auditeurs IT spécialisés. En outre, il existe des approches d audit globalement reconnues, comme par exemple l IT Audit Framework de l ISACA et l IT Governance Assurance Guide basé sur le CobiT. Les grands cabinets d audit utilisent par ailleurs des approches et des documents de travail spécifiques à l entreprise. 7

10 4 Phase 1: Evaluation globale des risques Positionnement Le traitement des questions/du questionnaire de la phase 1 doit s effectuer dans le cadre de la planification stratégique de l audit. Les risques liés à l utilisation de l informatique peuvent ainsi être identifiés à temps et les conclusions en découlant peuvent être intégrées dans la planification de l audit. La phase 1 correspond à une évaluation des risques et des interdépendances liés à l utilisation de l informatique. L évaluation ne doit pas impérativement être exhaustive et précise en tous points, mais elle doit mettre en lumière le besoin de réaliser un contrôle complémentaire et plus détaillé de l utilisation de l informatique. Procédure et parties prenantes Le contrôle lors de la phase 1 doit permettre de déterminer l importance que revêt l informatique dans l entreprise. Les réponses aux 16 questions permettent de conclure si l utilisation de l informatique engendre pour l entreprise des risques accrus qui sont à prendre en compte lors de la planification stratégique de l audit. Le questionnaire de la phase 1 est remis au client au préalable et rempli par les responsables de la comptabilité et de l informatique. La revue du questionnaire effectuée par l auditeur avec des représentants de l entreprise devrait prendre environ une heure. Il est ainsi possible d évaluer dans un laps de temps raisonnable, sur la base de faits clairs, si un contrôle approfondi portant sur les risques IT, c est-à-dire le déclenchement de la phase 2, s impose. Questionnaire / Critères Le questionnaire contient cinq domaines thématiques; chaque domaine thématique comporte entre une et cinq questions. Exploitation et IT Stratégie de l entreprise et utilisation de l informatique Degré d innovation dans l utilisation de l informatique Dépendance par rapport à la disponibilité des moyens informatiques Organisation interne et contrôle Gestion des risques Système de contrôle interne Sensibilisation à la sécurité informatique Séparation des fonctions Suppléance et savoir-faire en matière d applications au sein du service de comptabilité Applications IT Logiciels comptables Modifications dans les applications de base Intégration des flux de valeurs dans la comptabilité Erreurs de programme dans les applications de base Audit indépendant de l informatique Date du dernier audit indépendent de l informatique Exploitation IT Sécurité opérationnelle des moyens informatiques Suppléance au sein du service informatique Dépendance vis-à-vis de prestataires externes (y c. externalisation) Pour chaque question/critère, quatre «réponses» différentes (niveaux de maturité) sont proposées. 8

11 «Guide d analyse des risques informatiques» Exploitation et IT Ce domaine thématique permet de déterminer l importance que revêt l informatique pour l entreprise. Il s agit de savoir dans quelle mesure la stratégie de l entreprise repose sur l utilisation de moyens informatiques et dans quelle mesure les processus primaires de l entreprise dépendent de la disponibilité des moyens informatiques. Critère Niveau 1 Niveau 2 Niveau 3 Niveau 4 Stratégie de l entreprise et utilisation de l informatique Degré d innovation dans l utilisation de l informatique Dépendance par rapport à la disponibilité des moyens informatiques La stratégie de l entreprise La stratégie de l entreprise repose principalement sur repose en partie sur l utilisation d Internet et l utilisation d Internet et des des nouvelles technologies nouvelles technologies; les ainsi que sur l échange actif processus importants de d informations via des réseaux l entreprise se basent sur de données. l échange d informations via des réseaux de données. L entreprise utilise une L entreprise utilise une infrastructure IT moderne infrastructure IT complexe et complexe et s adapte et s adapte aux nouvelles clairement aux nouvelles technologies sans retard. technologies avant l ensemble du secteur. La disponibilité des moyens informatiques est un facteur critique pour l exploitation (activités de front-office et processus primaires); le temps de défaillance acceptable est inférieur à quatre heures. La disponibilité des moyens informatiques est importante pour l exploitation (activités de front-office et processus primaires); le temps de défaillance acceptable est compris entre quatre heures et deux jours. La stratégie de l entreprise dépend peu des nouvelles technologies, mais les processus importants de l entreprise utilisent déjà ces technologies. L entreprise utilise une infrastructure IT étendue, comprenant dans une large mesure des composants standard, et ne s adapte aux nouvelles technologies que lorsqu'elles sont matures. La disponibilité des moyens informatiques est parfois importante pour l exploitation (activités de front-office et processus primaires); le temps de défaillance acceptable est compris entre deux jours et une semaine. La stratégie de l entreprise ne dépend pas des nouvelles technologies (p. ex. Internet ou e-commerce). L entreprise utilise une infrastructure IT simple, comprenant dans une large mesure des composants standard; l infrastructure IT est plutôt en marge par rapport aux développements technologiques. La disponibilité des moyens informatiques n est pas critique pour l exploitation (activités de front-office) et les processus primaires internes; une défaillance supérieure à une semaine semble acceptable. 9

12 Organisation interne et contrôle Ce domaine thématique permet d évaluer la gestion des risques et le système de contrôle interne, la sensibilisation à la sécurité des données, la séparation des fonctions entre l informatique et les différents services spécialisés ainsi que le savoirfaire et la suppléance au sein du service de comptabilité. Critère Niveau 1 Niveau 2 Niveau 3 Niveau 4 Gestion des risques Il n y a pas de gestion des risques identifiable; des mesures ad hoc sont mises en œuvre pour réduire les risques. Système de contrôle interne Sensibilisation à la sécurité de l information Un système de contrôle interne (SCI) est difficilement identifiable ou inexistant. Il y a une gestion des risques ponctuelle, spécifique aux applications et partiellement documentée; les mesures de réduction des risques en découlant ne sont pas (facilement) identifiables. Il y a un SCI ponctuel, spécifique aux domaines d activité; le niveau de documentation et d actualisation est toutefois peu clair. Les collaborateurs ne Les collaborateurs sont sont pas informés de leur responsabilité quant au respect des exigences internes et externes en matière de sécurité de l information. informés de leur responsabilité quant au respect des exigences internes et externes en matière de sécurité de l information. Il y a une gestion des risques formalisée au niveau de toute l entreprise; elle est documentée et actualisée périodiquement et les mesures de réduction des risques en découlant sont clairement identifiables. Il y a un SCI formalisé au niveau de toute l entreprise; il est documenté et actualisé périodiquement. Les collaborateurs sont informés de manière répétée de leur responsabilité quant au respect des exigences internes et externes en matière de sécurité de l information et sont formés de manière appropriée. Il y a une gestion des risques formalisée au niveau de toute l entreprise; elle est documentée et actualisée chaque année et les risques sont clairement réduits. La gestion des risques est complétée par une autoévaluation des contrôles mis en place. Il y a un SCI formalisé au niveau de toute l entreprise; il est documenté et actualisé chaque année. Le SCI est complété par une autoévaluation des contrôles mis en place. Les collaborateurs sont formés systématiquement et le respect des exigences internes et externes en matière de sécurité de l information est contrôlé régulièrement. Séparation des fonctions Il y a uniquement une séparation des fonctions sommaire et informelle; il existe (également eu égard à l informatique) des fonctions couvrant plusieurs services. Il y a une séparation des fonctions entre l informatique et les domaines d activité; les fonctions au sein des services spécialisés ne sont parfois pas séparées. Au sein des domaines d activité, une séparation fonctionnelle des fonctions est assurée; celle-ci est documentée dans les descriptions des tâches, mais n est pas contrôlée. Au sein des domaines d activité, une séparation fonctionnelle des fonctions est systématiquement assurée; celle-ci est documentée dans les descriptions des tâches et contrôlée en continu. Suppléance et savoir-faire en matière d applications au sein du service de comptabilité Seule une suppléance sommaire est assurée au sein de l entreprise; l absence de certaines personnes engendre des problèmes déjà au niveau des activités quotidiennes habituelles. Des suppléances sont prévues pour les fonctions importantes, mais la formation est quasi inexistante; l absence de certaines personnes a une incidence sur les activités quotidiennes habituelles après quelques jours; la résolution des problèmes et des incidents n est pas possible en cas de défaillance. Des suppléances existent pour toutes les fonctions essentielles et donnent lieu à une formation; les activités quotidiennes habituelles sont assurées; la résolution des problèmes et des incidents est cependant difficile et engendre des retards. Des suppléances existent pour toutes les fonctions essentielles et donnent lieu à une formation; il y a une documentation correspondante; les activités quotidiennes habituelles et la résolution efficace des problèmes sont assurées. 10

13 «Guide d analyse des risques informatiques» Applications IT Ce domaine thématique permet d évaluer les logiciels comptables et les applications de base ainsi que leur degré d intégration et leur qualité. Critère Niveau 1 Niveau 2 Niveau 3 Niveau 4 Logiciels comptables L application comptable a été développée en interne. Pour la comptabilité, Pour la comptabilité, des des logiciels standard logiciels standard disposant paramétrables disposant de uniquement de possibilités possibilités de programmation de paramétrage et de individuelle sont utilisés. programmation individuelle limitées sont utilisés. Pour la comptabilité, des logiciels standard sans possibilités de paramétrage et de programmation individuelle sont utilisés. Modifications dans les applications de base Les applications de base ont été remplacées au cours de l exercice précédent ou actuel et les «anciennes» données ont été migrées. Des parties essentielles des applications de base ont été remplacées au cours de l exercice précédent ou actuel et les données ont été migrées. Des parties essentielles des applications de base ont été modifiées (p. ex. changement de version) ou étendues au cours de l exercice précédent ou actuel. Les applications de base n ont été que légèrement modifiées ou étendues au cours de l exercice précédent ou actuel. Intégration des flux de valeurs dans la comptabilité Erreurs de programme dans les applications de base Pour les applications de base, des solutions intégrées présentant un degré élevé d automatisation ont été mises en œuvre; la compréhension des flux de données et de valeurs exige des connaissances spécialisées. Pour les applications de base, des solutions intégrées dotées d interfaces automatisées sont utilisées; les flux de données et de valeurs sont compréhensibles. Les applications de base Les erreurs dans les connaissent fréquemment des applications de base sont problèmes dont la résolution rares, mais leur résolution exige beaucoup de temps. exige beaucoup de temps. Les erreurs et les défaillances Les pannes et les défaillances se répètent souvent. se répètent rarement. Pour les applications de base, différentes solutions individuelles dotées d interfaces (entre lots, «batch») sont utilisées; les flux de données et de valeurs sont facilement compréhensibles. Les erreurs dans les applications de base sont rares et peuvent être résolues rapidement. Les erreurs et les défauts sont documentés Plusieurs solutions individuelles spécifiques aux fonctions et dotées d interfaces (entre lots, «batch») sont utilisées; les flux de données et de valeurs dans les applications et au niveau des interfaces sont documentés de manière compréhensible au moyen d évaluations et de protocoles d interface. Les erreurs dans les applications de base sont très rares; les erreurs et les défauts sont résolus systématiquement, rapidement et durablement et ils sont documentés de manière compréhensible. 11

14 Exploitation IT Ce domaine thématique permet d évaluer la sécurité de l exploitation des moyens informatiques ainsi que la situation en termes de personnel (suppléance / dépendance vis-à-vis de prestataires externes) dans le domaine de l informatique. Critère Niveau 1 Niveau 2 Niveau 3 Niveau 4 Sécurité de l exploitation des moyens informatiques Suppléance au sein du service informatique Dépendance vis-àvis de prestataires externes (y c. partenaires d externalisation) Les moyens informatiques (serveur, clients, réseau et périphériques) connaissent très souvent des pannes et des défaillances; celles-ci ont une incidence sur l ensemble des activités de l entreprise. Les règles de suppléance au sein du service IT sont sommaires; l absence de certaines personnes engendre des problèmes déjà au niveau de l exploitation IT normale. Les moyens informatiques connaissent des pannes et des défaillances à répétition; celles-ci ont une incidence sur l ensemble des activités de l entreprise. Des suppléances sont prévues pour les principales fonctions au sein du service IT, mais elles donnent rarement lieu à une formation; l absence de certaines personnes a une incidence sur l exploitation IT après quelques jours et la résolution des problèmes IT n est pas possible. Pour l exploitation IT, L exploitation IT normale l entreprise dépend largement est largement possible du soutien extérieur; celui-ci sans soutien extérieur; en est notamment indispensable revanche, les erreurs ou en cas de problèmes. problèmes ne peuvent guère être résolus sans soutien extérieur. Les moyens informatiques connaissent peu de pannes et de défaillances; celles-ci ont parfois une incidence sur les activités de l entreprise. Les moyens informatiques ne connaissent que rarement des pannes et des défaillances; celles-ci n ont une incidence que sur certaines activités de l entreprise. Des suppléances existent Des suppléances existent pour les fonctions essentielles pour les fonctions essentielles au sein du service IT; elles au sein du service IT; elles donnent lieu à une formation, donnent lieu à une formation mais elles ne sont pas et il existe une documentation documentées; l exploitation IT correspondante; l exploitation est assurée, la résolution des IT et la résolution efficace des problèmes IT est cependant problèmes IT sont assurées. difficile sans ces personnes. L exploitation IT normale est assurée sans soutien extérieur; en cas d erreurs ou de problèmes, un soutien extérieur est parfois nécessaire. L exploitation normale et la résolution des problèmes sont assurées à tout moment sans soutien extérieur; celui-ci est uniquement nécessaire en cas de crise. Audit indépendant de l informatique (risque temporel) Ce critère montre à quelle date l utilisation de l informatique dans l entreprise a été évaluée pour la dernière fois par un expert indépendant. Critère Niveau 1 Niveau 2 Niveau 3 Niveau 4 Audit indépendant de l informatique Aucun audit IT n a encore été effectué. Un audit IT a été effectué pour la dernière fois il y a plus de cinq ans. Un audit IT a été effectué pour la dernière fois il y a quelques années. Un audit IT a été effectué au cours de l exercice écoulé. Comment remplir le questionnaire Pour chacun des 16 critères, il convient de choisir parmi les quatre «réponses» celle qui correspond le mieux à la situation actuelle de l entreprise. Il ne faut pas donner des évaluations «entre» les niveaux de maturité (1 2, 2 3 et 3 4), ceci ayant peu d utilité. En cas de doute, le niveau inférieur doit être sélectionné, car ceci réduit le risque d audit. 12

15 «Guide d analyse des risques informatiques» Interprétation des résultats / Evaluation L interprétation du questionnaire s effectue au moyen des niveaux de maturité. S agissant de l évaluation de la phase 1, un niveau de maturité ne correspond pas forcément à un degré de maturité technique ou organisationnel, mais à un facteur de risque potentiel. Par exemple, une entreprise dotée d un degré d innovation (question 2) de niveau 1 (c.-à-d. avec une adaptation très précoce aux nouvelles technologies IT) s expose certainement à un risque plus élevé qu avec un niveau 4 (qui correspond à une adaptation conservatrice et à des moyens IT standardisés et moins modernes). Sur la base de leurs connaissances et de leurs expériences, les auteurs du «Guide d analyse des risques informatiques» estiment qu une classification dans les niveaux de maturité 4 et 3 indique des risques minimes. En revanche, une classification dans les niveaux de maturité 2 et 1 indique des risques importants à élevés. Rapport Pour le rapport concernant la phase 1, une solution efficace et facilement visualisable consiste à documenter l évaluation (niveau) directement dans le questionnaire en attribuant la couleur voulue à la «réponse» sélectionnée (p. ex. 1 = rouge, 2 = jaune, 3 = vert clair et 4 = vert foncé). 13

16 Les résultats de la phase 1 peuvent ainsi être récapitulés sur une seule page. Etant donné que, avec ce type de représentation, les descriptions des quatre niveaux de maturité sont visibles, une comparaison rapide des conditions correspondant au niveau choisi avec celles des niveaux de maturité voisins (supérieurs/inférieurs) est également possible. A côté de la représentation des résultats en forme de tableau ci-dessus, un «graphique en toile d araignée» permet aussi de déterminer le degré de dépendance de l entreprise par rapport à l informatique. Un exemple d un tel graphique est donné ci-dessous pour une entreprise individuelle (à gauche) et pour quatre types d entreprise différents (à droite): Risque temporel de l audit IT Dépendance par rapport à l extérieur Suppléance IT Sécurité de l exploitation IT Stratégie et IT Innovation IT Dépendance IT SCI Gestion des risques Risque temporel Exploitation et IT Exploitation IT Erreurs de programme Séparation des fonctions Degré d intégration de la comptabilité Suppléance Applications de base Sensibilisation Logiciels comptables Organisation interne et contrôle Applications IT Banque Fiduciaire Hôpital Industrie Figure: Représentation des 16 critères Figure: Récapitulatif des 5 domaines thématiques Recommandations quant à la poursuite de la procédure Lorsqu un ou plusieurs critères sont classés dans les niveaux de maturité 2 et 1 ou dans les couleurs jaune et rouge, les auteurs considèrent qu il est opportun de déclencher la phase 2, c est-à-dire un contrôle approfondi de l utilisation de l informatique. Enfin, il appartient à l auditeur, et à son «professional judgement», d évaluer les résultats obtenus au cours de la phase 1 concernant les risques et les dépendances liés à l utilisation de l informatique du point de vue de leur importance pour l audit des comptes annuels. A cet égard, il peut être judicieux de discuter des résultats et de la nécessité d un contrôle approfondi de l utilisation de l informatique avec un auditeur IT expérimenté. 14

17 «Guide d analyse des risques informatiques» 5 Phase 2: Contrôle relatif à l utilisation de l informatique Positionnement La phase 2 correspond à un contrôle vaste et détaillé des forces et des faiblesses liées à l utilisation de l informatique. Le traitement des questions/du questionnaire de la phase 2 peut s effectuer tant dans le cadre de la planification stratégique de l audit que dans celui de l audit (intermédiaire) proprement dit. Les résultats de la phase 2 peuvent servir à une évaluation finale des «contrôles informatiques généraux (IT)» mentionnés dans la NAS 890, mais ils peuvent également justifier à l aide de faits le besoin de réaliser un contrôle complet et/ou approfondi de l utilisation de l informatique dans son ensemble ou au niveau de domaines spécifiques. Procédure et parties prenantes Les contrôles lors de la phase 2 doivent être réalisés par un auditeur familiarisé avec les audits IT ou par un auditeur IT. Ils comprennent, outre une inspection de l infrastructure IT et la consultation des documents disponibles, des entretiens approfondis avec les représentants IT de l entreprise. Pour les contrôles «sur place», notamment le traitement du questionnaire, nous estimons le temps nécessaire à un jour; à cet égard, l étendue de l utilisation de l informatique et le nombre d interlocuteurs concernés sont déterminants. A l issue de la phase 2, des affirmations fiables peuvent être énoncées quant aux risques IT et aux faiblesses concrètes. Ceci permet de déterminer si un audit IT complet est opportun et dans quels domaines. Questionnaire / Critères ( détails dans l annexe 2) Le questionnaire de la phase 2 comprend 20 domaines thématiques dotés de quatre points de contrôle en moyenne; selon les auteurs du guide, il couvre intégralement les «contrôles IT généraux» mentionnés dans la Norme d audit suisse NAS 890 «Vérification de l existence du système de contrôle interne» et, dans certains domaines, il va même volontairement au-delà afin de réduire le risque d audit. Le questionnaire contient environ 90 critères (points de contrôle) concernant les domaines thématiques suivants: Documentation IT Protection des accès Organisation IT Sécurité IT Gouvernance IT Sécurité physique Gestion des risques IT Exploitation IT Conformité Gestion des problèmes Gestion des projets IT Sauvegarde des données Développement et modification de logiciels Externalisation (le cas échéant) Evaluation d applications IT Comptabilité Directives d utilisation Contrôles d application directs Formation des utilisateurs Contrôles d application secondaires 15

18 Pour une grande partie des domaines thématiques cités, il s agit de contrôles IT généraux; certains domaines supplémentaires qui sont importants pour l auditeur et permettent d identifier plus précisément les faiblesses et les risques éventuels sont également contrôlés. Comment remplir le questionnaire Pour chacun des critères, il convient de choisir parmi les quatre «réponses» celle qui correspond le mieux à la situation actuelle de l entreprise. L évaluation (niveau) est donnée dans la colonne «Niveau» du questionnaire ou indiquée directement en cochant la «réponse» appropriée. Pour l évaluation et le rapport, il est utile de fournir des indications complémentaires dans la colonne «Constatation / Evaluation / Recommandation»; idéalement, celles-ci doivent être identifiées par un «C» pour constatation, un «E» pour évaluation et un «R» pour recommandation. Il ne faut pas donner des évaluations «entre» les niveaux de maturité (1 2, 2 3 et 3 4); en cas de doute, les auteurs du guide recommandent de choisir le niveau inférieur (p. ex. 1 au lieu de 1 2) pour réduire le risque d audit. Si un critère n est pas pertinent pour l entreprise (p. ex. questions concernant l externalisation), on peut indiquer «n.a.» (non applicable) dans la colonne «Niveau» du questionnaire. Interprétation des résultats / Evaluation L interprétation du questionnaire s effectue au moyen des niveaux de maturité. Contrairement à la phase 1, ceux-ci correspondent plutôt à un degré de maturité technique ou organisationnel et pas forcément à un facteur de risque potentiel. Cependant, il existe incontestablement un rapport entre la maturité du processus et le risque en question. Sur la base de leurs connaissances et de leurs expériences, les auteurs du «Guide d analyse des risques informatiques» estiment qu une classification dans les niveaux de maturité 4 et 3 indique un degré de maturité satisfaisant et des risques minimes. En revanche, une classification dans les niveaux de maturité 2 et 1 indique un degré de maturité insuffisant et des risques importants à élevés. 16

19 «Guide d analyse des risques informatiques» Rapport Au vu de l étendue du questionnaire, nous proposons diverses approches pour la visualisation des résultats relatifs à la phase 2. Deux des variantes que nous avons testées à plusieurs reprises sont décrites ci-après. Accent sur la représentation détaillée de la situation réelle Il est possible d établir un rapport détaillé en attribuant la couleur voulue à la réponse pour chaque critère ou à la colonne «Niveau» (1 = rouge, 2 = jaune, 3 = vert clair et 4 = vert foncé). Titre Niveau de maturité 1 Niveau de maturité 2 Niveau de maturité 3 Niveau de maturité 4 Constatation Evaluation Recommandation Documentation IT Aperçu de l'infrastructure IT Inventaire du matériel Inventaire des logiciels Contrats et contrats de prestation de services Il n'existe pas d'aperçu de l'infrastructure IT. Il n'existe pas d'inventaire du matériel. Il n'existe pas d'inventaire des logiciels. Il existe peu de contrats entre le domaine IT et des tiers, même si des prestations sont fournies. Il existe un aperçu ancien (remontant à plus d'une année) de l'infrastructure IT. Il existe un inventaire ancien (remontant à plus d'une année) du matériel. Il existe un inventaire ancien (remontant à plus d'une année) des logiciels. Il existe un aperçu/récapitulatif des contrats passés avec des tiers dans le domaine IT (fournisseurs, clients, partenaires); celui-ci est cependant incomplet et pas actuel. Il existe un aperçu actuel des principaux composants de l'infrastructure IT (systèmes et gestion de réseau). Les processus d'acquisition, d'installation et de gestion des changements n'entraînent pas obligatoirement une actualisation de cet aperçu. Un inventaire du matériel est en cours de réalisation; les processus d'acquisition ne garantissent cependant pas l'actualisation obligatoire de cet inventaire. Un inventaire des logiciels (également pour le contrôle des licences) est en cours de réalisation; les processus d'acquisition ne garantissent cependant pas l'actualisation obligatoire de cet inventaire. Il existe un aperçu/récapitulatif de tous les contrats passés avec des tiers dans le domaine IT (fournisseurs, clients, partenaires). Il existe un aperçu actuel de l'ensemble de l'infrastructure IT (systèmes et gestion de réseau). Les processus d'acquisition, d'installation et de gestion des changements comprennent l'actualisation obligatoire de cet aperçu. Un inventaire complet du matériel est en cours de réalisation. Les processus d'acquisition et d'installation comprennent l'actualisation obligatoire de cet inventaire ainsi que l'adaptation/la conclusion de contrats de maintenance éventuels. Un inventaire complet des logiciels (également pour le contrôle des licences) est en cours de réalisation. Les processus d'acquisition et d'installation comprennent l'actualisation obligatoire de cet inventaire ainsi que la clarification des éventuelles questions relatives à l'octroi de licences d'installations et de mises à jour. Il existe un aperçu/récapitulatif de tous les contrats passés avec des tiers dans le domaine IT (fournisseurs, clients, partenaires). Celui-ci est géré centralement, tenu à jour et contient tous les contrats et documents connexes tels que les SLA, etc. Les résultats de la phase 2 peuvent ainsi être visualisés dans leur globalité sur environ dix pages (format A4), avec les forces et les faiblesses pour chaque critère. Une évaluation du «contenu» est donnée au moyen des descriptions relatives aux différents niveaux et via la colonne «Constatation / Evaluation / Recommandation». Accent sur la représentation des mesures à prendre Lorsqu une opinion sur les «mesures à prendre» doit être émise, l étendue du rapport peut être réduite en «éliminant» tous les critères dotés d évaluations de niveaux 3 et 4 (contrôle satisfaisant / risque minime) et «n.a.» (non applicable). Selon la situation, les faiblesses existantes, et donc les mesures à prendre, peuvent ainsi être récapitulées sur quelques pages seulement (format A4). 17

20 Représentation graphique de la situation réelle Pour la pratique, les auteurs du guide considèrent qu il est utile de faire un résumé des évaluations par domaine thématique et, par exemple, de les représenter dans un diagramme circulaire. En indiquant les couleurs voulues, la situation réelle (ici en vert) et les mesures à prendre «potentielles» (ici en rouge) peuvent être très bien visualisées. Contrôle d application secondaire Contrôle d application direct Application comptable Externalisation Sauvegarde des données Documentation IT Organisation IT Gouvernance IT Conformité Gestion des risques IT Gestion de projet IT Gestion des problèmes Développement de logiciels Exploitation IT Evaluation d applications IT Sécurité physique Directives d utilisation Sécurité IT Protection des accès Formation des utilisateurs Rapport succinct complémentaire Les auteurs du guide considèrent qu il est utile de récapituler les principales forces et faiblesses ainsi que les principales recommandations d optimisation de la situation dans un rapport succinct destiné au management, au conseil d administration et à l auditeur. Le rapport succinct constitue un complément précieux à la représentation graphique de la situation réelle ci-dessus et permet de réaliser une évaluation globale de la situation actuelle et des mesures à prendre et, le cas échéant, de justifier le besoin d exécuter un audit IT approfondi. Recommandations quant à la poursuite de la procédure Lorsqu une grande partie des critères sont classés dans les niveaux de maturité 2 et 1, les auteurs du guide considèrent qu il est opportun d exécuter un audit IT complet ou un audit approfondi de l utilisation de l informatique dans son ensemble ou au niveau de domaines spécifiques. Enfin, il appartient à l auditeur, et à son «professional judgement», et de préférence en accord avec un auditeur IT expérimenté, d évaluer les résultats obtenus au cours des phases 1 et 2 concernant l utilisation de l informatique ainsi que les faiblesses et les risques correspondants du point de vue de leur importance pour l audit des comptes annuels. 18

21 «Guide d analyse des risques informatiques» 6 L IT-Check comme «combinaison» des phases 1 et 2 Considérations initiales Le contenu des phases 1 et 2 peut, notamment lorsque les contrôles des deux phases sont effectués simultanément et par le même auditeur, être récapitulé à peu de frais dans un IT-Check. En peu de temps (souvent un seul jour «sur place» suffit), il est possible: de déterminer l importance que revêt l informatique pour l entreprise et les risques liés à son utilisation; d identifier les forces et les faiblesses liées à l organisation et aux processus IT et d évaluer ensuite l «utilité» de l informatique en général ainsi que les «contrôles informatiques généraux (IT)» mentionnés dans la NAS 890; de documenter et d évaluer sommairement les applications de base, y c. les principaux flux de valeurs et de données (interfaces IT) ainsi que les interlocuteurs concernés par leur utilisation, leur maintenance et leur exploitation. Procédure Préparation Envoyer au préalable le questionnaire de la phase 1 au client et demander à celui-ci de procéder à une évaluation des risques (auto-évaluation) de son point de vue, laquelle sera ensuite discutée en commun lors des contrôles «sur place». Envoyer également au préalable le questionnaire de la phase 2 au client pour que celui-ci puisse préparer l'évaluation des contrôles «sur place» (p. ex. mise à disposition de documents ou implication d autres collaborateurs). Exécution 1. Réaliser un entretien d ouverture Déterminer les bases de l organisation IT et de l utilisation de l informatique 2. Effectuer un tour d inspection Se faire une idée de l infrastructure IT 3. Discuter du questionnaire de la phase 1 Déterminer l importance que revêt l informatique pour la comptabilité et l entreprise et examiner l évaluation des risques faite par le client 4. Etudier le questionnaire de la phase 2 Identifier les forces et les faiblesses liées à l organisation et aux processus IT; évaluer la «maturité» de l informatique 5. Contrôler les applications de base Se faire une idée des applications de base ainsi que des principaux flux de valeurs et de données (interfaces); catégoriser les applications financières (logiciels standard, logiciels standard adaptés ou logiciels individuels); identifier les interlocuteurs concernés par leur utilisation, leur maintenance et leur exploitation 6. Bref feed-back (oral) Remarque: le contrôle portant sur les applications de base (étape 5) est une étape de travail à part entière qui n est pas traitée de manière approfondie dans le présent guide. Elle est décrite en détail dans le «Guide d audit des applications informatiques». 19

22 Rapport / Rapport succinct Management Summary avec principales constatations et mesures à prendre Aperçu de l organisation IT, de l utilisation de l informatique et des applications de base Résultats (constatation, évaluation et éventuellement recommandation) sur l organisation et les processus IT Résultats (constatation, évaluation et éventuellement recommandation) sur les applications de base Résultats de l auto-évaluation (questionnaire de la phase 1) Dans la pratique, il s avère utile d établir une représentation distincte des résultats par domaine thématique, comme le montre l exemple ci-après. Une représentation détaillée de ce type ne peut cependant pas être le fruit d une évaluation réalisée sur une journée: pour un rapport succinct, il faut généralement plus de temps pour contrôler les informations et beaucoup plus encore pour le rapport lui-même. L auditeur obtient toutefois une base plus précise pour la planification stratégique de l audit, et le client bénéficie clairement d une importante valeur ajoutée Sauvegarde des données Constatations Il existe un concept de sauvegarde datant de janvier 200x; celui-ci n'a pas été approuvé formellement. Des sauvegardes complètes sont effectuées les jours ouvrables, 4 bandes étant disponibles le vendredi (semaine 1 4). Aucun test de restauration visant à vérifier la lisibilité n'est réalisé. Les bandes de sauvegarde ne sont pas conservées à l'extérieur de l'entreprise, mais dans un tiroir du responsable IT concerné. Il n'existe pas de plan d'urgence IT. Degré de maturité déterminé Concept de sauvegarde Processus de sauvegarde Test de restauration Plan d'urgence IT Transfert des données Un concept de sauvegarde est documenté et généralement utilisé; il n'a toutefois jamais été approuvé formellement. Des sauvegardes quotidiennes sont effectuées, mais leur intégralité n'est pas contrôlée. Aucun test systématique n'est réalisé pour récupérer et relire les sauvegardes. Peu de réflexions sont engagées quant à un plan d'urgence IT. Aucune sauvegarde suffisante des données n'est assurée à l'extérieur de l'entreprise. Mesures à prendre Approbation formelle du concept de sauvegarde Réalisation de tests de restauration réguliers Conservation des bandes en dehors de l'entreprise Définition d'un plan d'urgence IT Risques Restauration incomplète des données en cas d'incident Restauration des données en dehors des délais exigés Perte de données en cas de catastrophe Mise en danger de la poursuite de l'exploitation lt Figure: Présentation détaillée des résultats sous forme de texte (exemple) Avantages pour l auditeur S agissant des mandats/clients soumis à un contrôle ordinaire: l évaluation des risques IT fait partie de la planification stratégique de l audit; les «contrôles informatiques généraux (IT)» mentionnés dans la NAS 890 peuvent être évalués définitivement; un IT-Check fournit des informations fiables et vérifiables pour la détermination des domaines d audit à intégrer dans un audit IT complet ou tout du moins des arguments clairs justifiant leur suppression ou leur report. S agissant des mandats/clients soumis à un contrôle restreint: l évaluation des risques IT est certes facultative mais, au vu de la dépendance souvent considérable par rapport à l informatique, elle est néanmoins judicieuse et permet souvent d effectuer des contrôles approfondis (du point de vue de l audit); un IT-Check fournit des informations fiables et vérifiables pour la détermination des domaines à intégrer dans un audit IT complet. Un IT-Check est en outre toujours judicieux en cas de dépendance importante ou peu claire par rapport à l informatique et lorsque des secteurs importants de l informatique sont externalisés. 20

23 «Guide d analyse des risques informatiques» 7 Indications concernant les audits IT approfondis Situation initiale A l issue de la phase 2, des affirmations fiables peuvent être énoncées et justifiées quant au degré de maturité technique et organisationnel ainsi qu aux risques IT. Sur cette base, l auditeur peut, de préférence en accord avec un auditeur IT expérimenté, décider si et pour quels domaines un audit IT approfondi doit être effectué, mais également si des domaines connexes, et lesquels, doivent être vérifiés en détail dans le cadre de contrôles approfondis ou de l audit intermédiaire. Domaines d audit possibles Sur la base de leurs connaissances et de leurs expériences, les auteurs du guide voient principalement les deux domaines suivants pour un audit IT approfondi faisant suite à la phase 2: Domaine d audit 1: application informatique et SCI lors de leur utilisation Objectifs de l audit a) Evaluation de l application IT sous les aspects suivants: - présence des fonctions de traitement nécessaires - exactitude des règles de traitement programmées - possibilités de différenciation au moyen de droits d accès - étendue et efficacité du système de contrôle interne (SCI) basé sur des logiciels, c est-à-dire des contrôles programmés - documentation (intégralité/clarté et conformité avec les programmes) - adéquation et degré de développement des résultats des transactions du point de vue des dispositions légales en matière de comptabilité et de conservation - méthode d audit, c est-à-dire preuve des transactions importantes du point de vue de la comptabilité depuis leur origine jusqu à la présentation des comptes (progressif) et inversement (rétrograde) b) Evaluation du SCI lors de l utilisation de l application IT, de la documentation d utilisation, de l installation («customizing»), de la maintenance (modifications du programme) et, le cas échéant, évaluation des «contrôles IT généraux» lors de leur exploitation. Méthodes «Guide d audit des applications informatiques» de la Chambre fiduciaire et listes de contrôle d origines diverses pour le contrôle du système de contrôle interne. Le choix de l application IT se base sur l étape 5 d un IT-Check (voir le chapitre 6), c est-à-dire le contrôle de toutes les applications de base. Domaine d audit 2: organisation et processus IT Objectif de l audit Contrôle approfondi de l organisation, des processus et des contrôles IT. Ceci permet d approfondir et d élargir des domaines thématiques importants issus de la phase 2 et couvre intégralement les «contrôles IT généraux» conformément à la Norme d audit suisse «Vérification de l existence du système de contrôle interne» (NAS 890). 21

24 Base méthodologique / Dossiers de travail La norme CobiT (Control Objectives for Information and related Technologies) de l ISACA ( acceptée dans le monde entier et largement utilisée, constitue une base de travail éprouvée. Le référentiel CobiT classe les activités et les responsabilités IT au sein d un modèle de processus générique dans les quatre domaines suivants: «Planification et organisation», «Acquisition et mise en place», «Distribution et support» et «Surveillance et évaluation». CobiT contient une approche et un langage commun, valable pour toute l entreprise, pour l examen et la gestion des activités IT. L introduction d une approche opérationnelle et d un langage commun pour toutes les personnes concernées est l une des étapes les plus importantes visant à mettre en place une bonne gouvernance. Cette approche aide les propriétaires des processus fonctionnels et permet de définir les tâches et les responsabilités. CobiT contient en outre un référentiel pour mesurer et évaluer la performance IT, communiquer avec les prestataires de services et intégrer des meilleures pratiques. Planification de l audit Les expériences faites par les auteurs du guide montrent que les donneurs d ordre éventuels (auditeur / client) n ont souvent qu une idée imprécise des objectifs et des possibilités, mais aussi de la durée et de l utilité, d un «audit IT approfondi». Pour impliquer un auditeur IT spécialisé de manière efficace et ciblée, la formulation du mandat d audit est très importante. Selon les auteurs du guide, il est donc judicieux d impliquer l auditeur IT et le client. Le mandat d audit confié par l auditeur à l auditeur IT doit porter au minimum sur les points suivants: objectifs supérieurs / conditions cadres contenu et étendue détaillés de l audit / délimitation base méthodologique / dossiers de travail interlocuteurs et sources d information éventuels rapport, y c. structure, contenu, étendue et destinataires du rapport Audit Au vu des grandes différences d un audit IT approfondi en ce qui concerne le domaine d audit ainsi que le contenu et l étendue de l audit, nous renonçons à fournir des indications détaillées sur l audit. A titre indicatif, pour un audit IT approfondi réalisé dans une PME, il faut prévoir entre trois et dix jours pour les contrôles «sur place» et entre deux et cinq jours supplémentaires pour le rapport. 22

25 «Guide d analyse des risques informatiques» Rapport Le rapport se base en principe sur ce qui a été convenu lors de la planification de l audit (voir ci-dessus). Les principaux points sont entre autres: La structure, l étendue et le contenu dépendent des objectifs et du public cible. Le rapport doit être clairement structuré et axé sur les destinataires: - Management Summary avec principales constatations et recommandations; - détails (constatation, évaluation et recommandation) à l attention du management sous forme verbale; - détails avec constatation, évaluation et recommandation (y c. ordre de priorité du point de vue de l auditeur) à l attention des responsables techniques sous forme de tableau; - récapitulatif des recommandations (selon l ordre de priorité) et, le cas échéant, prise de position de l audité ainsi que délai et responsables de la mise en œuvre de la recommandation. Le rapport doit préciser clairement la situation actuelle et les mesures à prendre. D après notre expérience, il est fortement recommandé de discuter du projet de rapport avec la personne auditée et, le cas échéant, le management. Ceci permet de clarifier les incertitudes et les malentendus éventuels avant d établir et d envoyer le rapport définitif. Un tel rapport ressemble au rapport succinct établi pour un IT-Check (voir page 20), mais il est généralement beaucoup plus concret sur certains points. Sont notamment concernés l ordre de priorité des recommandations et la prise de position de l audité (y c. délai et responsabilités pour la mise en œuvre). 23

26 8 Conclusion Malgré l existence et l utilisation d un certain nombre de supports (approches, questionnaires, référentiel CobiT, listes de contrôle, etc.), le «professional judgement» de l auditeur est indispensable pour obtenir des résultats répondant aux exigences spécifiques à l entreprise, aux processus et aux risques. Une discussion approfondie entre l auditeur et l auditeur IT s impose pour évaluer les résultats des audits et, le cas échéant, déterminer d autres opérations d audit nécessaires. Le présent «Guide d analyse des risques informatiques pour les auditeurs de PME» doit contribuer à améliorer la compréhension des domaines IT spécifiques. 24

27 «Guide d analyse des risques informatiques» Annexes Annexe 1 Questionnaire Phase I Critère Niveau 1 Niveau 2 Niveau 3 Niveau 4 Maturité Exploitation et IT Organisation interne et contrôle Stratégie de l entreprise et utilisation de l informatique La stratégie de l entreprise repose principalement sur l utilisation d Internet et des nouvelles technologies ainsi que sur l échange actif d informations via des réseaux de données. Degré L entreprise utilise une d innovation dans infrastructure IT moderne l utilisation de et complexe et s adapte l informatique clairement aux nouvelles technologies avant l ensemble du secteur. Dépendance par rapport à la disponibilité des moyens informatiques Gestion des risques Système de contrôle interne Sensibilisation à la sécurité de l information Séparation des fonctions DiLa disponibilité des moyens informatiques est un facteur critique pour l exploitation (activités de front-office et processus primaires); le temps de défaillance acceptable est inférieur à quatre heures. Il n y a pas de gestion des risques identifiable; des mesures ad hoc sont mises en œuvre pour réduire les risques. Un système de contrôle interne (SCI) est difficilement identifiable ou inexistant. Les collaborateurs ne sont pas informés de leur responsabilité quant au respect des exigences internes et externes en matière de sécurité de l information. Il y a uniquement une séparation des fonctions sommaire et informelle; il existe (également eu égard à l informatique) des fonctions couvrant plusieurs services. Suppléance Seule une suppléance et savoir-faire en matière d applications au sein du service de comptabilité sommaire est assurée au sein de l entreprise; l absence de certaines personnes engendre des problèmes déjà au niveau des activités quotidiennes habituelles. La stratégie de l entreprise repose en partie sur l utilisation d Internet et des nouvelles technologies; les processus importants de l entreprise se basent sur l échange d informations via des réseaux de données. L entreprise utilise une infrastructure IT complexe et s adapte aux nouvelles technologies sans retard. La stratégie de l entreprise dépend peu des nouvelles technologies, mais les processus importants de l entreprise utilisent déjà ces technologies. L entreprise utilise une infrastructure IT étendue, comprenant dans une large mesure des composants standard, et s adapte aux nouvelles technologies avec du retard. La disponibilité des moyens La disponibilité des informatiques est importante pour l exploitation (activités de front-office et processus primaires); le temps de défaillance acceptable est compris entre quatre heures et deux jours. Il y a une gestion des risques ponctuelle, spécifique aux applications et partiellement documentée; les mesures de réduction des risques en découlant ne sont pas (facilement) identifiables. Il y a un SCI ponctuel, spécifique aux domaines d activité; le niveau de documentation et d actualisation est toutefois peu clair. Les collaborateurs sont informés de leur responsabilité quant au respect des exigences internes et externes en matière de sécurité de l information. Il y a une séparation des fonctions entre l informatique et les domaines d activité; les fonctions au sein des services spécialisés ne sont parfois pas séparées. Des suppléances sont prévues pour les fonctions importantes, mais la formation est quasi inexistante; l absence de certaines personnes a une incidence sur les activités quotidiennes habituelles après quelques jours; la résolution des problèmes et des incidents n est pas possible en cas de défaillance. moyens informatiques est parfois importante pour l exploitation (activités de front-office et processus primaires); le temps de défaillance acceptable est compris entre deux jours et une semaine. Il y a une gestion des risques ponctuelle, spécifique aux applications et partiellement documentée; les mesures de réduction des risques en découlant ne sont pas (facilement) identifiables. Il y a un SCI ponctuel, spécifique aux domaines d activité; le niveau de documentation et d actualisation est toutefois peu clair. Les collaborateurs sont informés de leur responsabilité quant au respect des exigences internes et externes en matière de sécurité de l information. Il y a une séparation des fonctions entre l informatique et les domaines d activité; les fonctions au sein des services spécialisés ne sont parfois pas séparées. Des suppléances sont prévues pour les fonctions importantes, mais la formation est quasi inexistante; l absence de certaines personnes a une incidence sur les activités quotidiennes habituelles après quelques jours; la résolution des problèmes et des incidents n est pas possible en cas de défaillance. La stratégie de l entreprise ne dépend pas des nouvelles technologies (p. ex. Internet ou e-commerce). L entreprise utilise une infrastructure IT simple, comprenant dans une large mesure des composants standard; l infrastructure IT est plutôt en retard par rapport aux développements technologiques. La disponibilité des moyens informatiques n est pas critique pour l exploitation (activités de front-office) et les processus primaires internes; une défaillance supérieure à une semaine semble acceptable. Il y a une gestion des risques formalisée au niveau de toute l entreprise; elle est documentée et actualisée chaque année et les risques sont clairement réduits. La gestion des risques est complétée par une autoévaluation des contrôles mis en place. Il y a un SCI formalisé au niveau de toute l entreprise; il est documenté et actualisé chaque année. Le SCI est complété par une autoévaluation des contrôles mis en place. Les collaborateurs sont formés systématiquement et le respect des exigences internes et externes en matière de sécurité de l information est contrôlé régulièrement. Au sein des domaines d activité, une séparation fonctionnelle des fonctions est systématiquement assurée; celle-ci est documentée dans les descriptions des tâches et contrôlée en continu. Des suppléances existent pour toutes les fonctions essentielles et donnent lieu à une formation; il y a une documentation correspondante; les activités quotidiennes habituelles et la résolution efficace des problèmes sont assurées. 25

28 Critère Niveau 1 Niveau 2 Niveau 3 Niveau 4 Maturité Applications IT Exploitation IT Logiciel comptable Modifications dans les applications de base Intégration des flux de valeurs dans la comptabilité Erreurs de programme dans les applications de base Sécurité de l exploitation des moyens informatiques Suppléance au sein du service informatique Dépendance vis-à-vis de prestataires externes (y c. partenaires d externalisation) L application comptable a été développée en interne. Les applications de base ont été remplacées au cours de l exercice précédent ou actuel et les «anciennes» données ont été migrées. Pour les applications de base, des solutions intégrées présentant un degré élevé d automatisation ont été mises en œuvre; la compréhension des flux de données et de valeurs exige des connaissances spécialisées. Les applications de base connaissent fréquemment des problèmes dont la résolution exige beaucoup de temps. Les erreurs et les défaillances se répètent souvent. Les moyens informatiques (serveur, clients, réseau et périphériques) connaissent très souvent des pannes et des défaillances; celles-ci ont une incidence sur l ensemble des activités de l entreprise. Pour la comptabilité, des logiciels standard paramétrables disposant de possibilités de programmation individuelle sont utilisés. Des parties essentielles des applications de base ont été remplacées au cours de l exercice précédent ou actuel et les données ont été migrées. Pour les applications de base, des solutions intégrées dotées d interfaces automatisées sont utilisées; les flux de données et de valeurs sont compréhensibles. Pour la comptabilité, des logiciels standard disposant uniquement de possibilités de paramétrage et de programmation individuelle limitées sont utilisés. Des parties essentielles des applications de base ont été modifiées (p. ex. changement de version) ou étendues au cours de l exercice précédent ou actuel. Pour les applications de base, différentes solutions individuelles dotées d interfaces (entre lots, «batch») sont utilisées; les flux de données et de valeurs sont facilement compréhensibles. Pour la comptabilité, des logiciels standard sans possibilités de paramétrage et de programmation individuelle sont utilisés. Les applications de base n ont été que légèrement modifiées ou étendues au cours de l exercice précédent ou actuel. Plusieurs solutions individuelles spécifiques aux fonctions et dotées d interfaces (entre lots, «batch») sont utilisées; les flux de données et de valeurs dans les applications et au niveau des interfaces sont documentés de manière compréhensible au moyen d évaluations et de protocoles d interface. Les erreurs dans les applications de base sont Les erreurs dans les applications de base sont Les erreurs dans les applications de base sont rares, mais leur résolution exige beaucoup de temps. rares et peuvent être résolues très rares; les erreurs et rapidement. Les erreurs et les les défauts sont résolus Les pannes et les défaillances défauts sont documentés. se répètent rarement. systématiquement, rapidement et durablement et ils sont documentés de manière compréhensible. Les moyens informatiques connaissent des pannes et des défaillances à répétition; celles-ci ont une incidence sur l ensemble des activités de l entreprise. Les règles de suppléance Des suppléances sont au sein du service IT sont prévues pour les principales sommaires; l absence fonctions au sein du service de certaines personnes IT, mais elles donnent engendre des problèmes déjà rarement lieu à une au niveau de l exploitation IT formation; l absence de normale. certaines personnes a une incidence sur l exploitation IT après quelques jours et la résolution des problèmes IT n est pas possible. Pour l exploitation IT, l entreprise dépend largement du soutien extérieur; celui-ci est notamment indispensable en cas de problèmes. L exploitation IT normale est largement possible sans soutien extérieur; en revanche, les erreurs ou problèmes ne peuvent guère être résolus sans soutien extérieur. Les moyens informatiques connaissent peu de pannes et de défaillances; celles-ci ont parfois une incidence sur les activités de l entreprise. Des suppléances existent pour les fonctions essentielles au sein du service IT; elles donnent lieu à une formation, mais elles ne sont pas documentées; l exploitation IT est assurée, la résolution des problèmes IT est cependant difficile sans ces personnes. L exploitation IT normale est assurée sans soutien extérieur; en cas d erreurs ou de problèmes, un soutien extérieur est parfois nécessaire. Les moyens informatiques ne connaissent que rarement des pannes et des défaillances; celles-ci n ont une incidence que sur certaines activités de l entreprise. Des suppléances existent pour les fonctions essentielles au sein du service IT; elles donnent lieu à une formation et il existe une documentation correspondante; l exploitation IT et la résolution efficace des problèmes IT sont assurées. L exploitation normale et la résolution des problèmes sont assurées à tout moment sans soutien extérieur; celuici est uniquement nécessaire en cas de crise. Risque temporel Dernier contrôle IT Aucun contrôle IT n a encore été effectué. Un contrôle IT a été effectué pour la dernière fois il y a plus de cinq ans. Un contrôle IT a été effectué pour la dernière fois il y a quelques années. Un contrôle IT a été effectué au cours de l exercice écoulé. 26

29 «Guide d analyse des risques informatiques» Annexe 2 Questionnaire Phase II Titre Niveau de maturité 1 Niveau de maturité 2 Niveau de maturité 3 Niveau de maturité 4 Constatation Evaluation Recommandation Documentation IT Organisation IT Aperçu de Il n'existe pas d'aperçu de l'infrastructure IT l'infrastructure IT. Inventaire du matériel Inventaire des logiciels Contrats et contrats de prestation de services Responsabilités Architecture / Technologie Séparation des fonctions Il n'existe pas d'inventaire du matériel. Il n'existe pas d'inventaire des logiciels. Il existe peu de contrats entre le domaine IT et des tiers, en dépit de la fourniture de prestations. Les responsabilités pour l'introduction, l'exploitation, la maintenance et la protection des ressources IT ne sont pas définies. Les nouvelles technologies sont introduites immédiatement, sans que leur utilité économique ou stratégique et leur bon fonctionnement dans l'environnement existant soient démontrés. Il n'y a pas de séparation des fonctions au sein du service IT; les fonctions critiques (p. ex. développeur/opérateur) ne sont pas séparées. Il existe un aperçu ancien (remontant à plus d'une année) de l'infrastructure IT Il existe un inventaire ancien (remontant à plus d'une année) du matériel. Il existe un inventaire ancien (remontant à plus d'une année) des logiciels. Il existe un aperçu actuel Il existe un aperçu actuel de des principaux composants l'ensemble de l'infrastructure de l'infrastructure IT (systèmes et gestion de réseau). gestion de réseau). Les pro- informatique (systèmes et Les processus d'acquisition, cessus d'acquisition, d'installation et de gestion des d'installation et de gestion des changements n'entraînent pas obligatoirement la mise à jour obligatoire de changements comprennent une mise à jour de cet aperçu. cet aperçu. Un inventaire du matériel est en cours de réalisation; les processus d'acquisition ne garantissent cependant pas la mise à jour obligatoire de cet inventaire. Un inventaire des logiciels (également pour le contrôle des licences) est en cours de réalisation; les processus d'acquisition ne garantissent cependant pas la mise à jour obligatoire de cet inventaire. Il existe un aperçu/récapitulatif des contrats passés avec tulatif de tous les contrats Il existe un aperçu/récapi- des tiers dans le domaine passés avec des tiers dans IT (fournisseurs, clients, le domaine IT (fournisseurs, partenaires); celui-ci est clients, partenaires). cependant incomplet et pas actuel. Les responsabilités pour l'introduction, l'exploitation, la maintenance et la protection des ressources IT sont généralement définies de manière informelle. Les nouvelles technologies sont introduites immédiatement lorsqu'elles promettent un avantage économique ou stratégique. Des clarifications techniques sont parfois effectuées avant la première utilisation. Il y a uniquement une séparation des fonctions sommaire et informelle au sein du service IT; les fonctions critiques (p. ex. développeur/opérateur) ne sont pas séparées. La plupart des responsabilités pour l'introduction, l'exploitation, la maintenance et la protection des ressources IT sont documentées. La documentation n'est cependant pas gérée centralement et est parfois ancienne. Les nouvelles technologies sont introduites uniquement lorsqu'elles se sont établies sur le marché et que des références existent. Les tests habituels sont effectués avant la première utilisation. Il y a une séparation fonctionnelle des fonctions pour les fonctions IT critiques; celle-ci n'est cependant pas documentée et n'est pas surveillée. Un inventaire complet du matériel est en cours de réalisation. Les processus d'acquisition et d'installation comportent la mise à jour obligatoire de cet inventaire ainsi que l'adaptation/la conclusion de contrats de maintenance éventuels. Un inventaire complet des logiciels (également pour le contrôle des licences) est en cours de réalisation. Les processus d'acquisition et de projet comprennent la mise à jour obligatoire de cet inventaire ainsi que la clarification des éventuelles questions relatives à l'octroi de licences d'installations et de mises à jour. Il existe un aperçu/récapitulatif de tous les contrats passés avec des tiers dans le domaine IT (fournisseurs, clients, partenaires). Celui-ci est géré centralement, tenu à jour et contient tous les contrats et documents connexes tels que les SLA, etc. Les responsabilités pour l'introduction, l'exploitation, la maintenance et la protection des ressources IT sont documentées dans les descriptions de postes ou de processus. Ces documentations sont contrôlées et adaptées en cas de besoin mais au moins une fois par an. Les nouvelles technologies sont systématiquement évaluées et leur importance pour la stratégie de l'entreprise est analysée. Avant la première utilisation, le fonctionnement, la fiabilité et la compatibilité des nouveaux produits sont testés de manière approfondie en dehors de l'environnement de production. Une séparation fonctionnelle des fonctions est systématiquement assurée au sein du service IT; celle-ci est documentée dans les descriptions des tâches et son respect est surveillé en continu. 27

30 Titre Niveau de maturité 1 Niveau de maturité 2 Niveau de maturité 3 Niveau de maturité 4 Constatation Evaluation Recommandation Organisation IT Gouvernance IT Suppléance Procédure d'autorisation pour les modifications de l'infrastructure IT Il n'y a pas de règles de suppléance au sein du service IT. de suppléance sommaires au prévues pour les fonctions Il y a uniquement des règles Des suppléances sont sein du service IT. les plus importantes au sein du service IT, mais elles donnent rarement lieu à une formation; une documentation correspondante est parfois disponible et facilite l'exécution des tâches par le ou les suppléants. Il n'y a pas de procédure d'autorisation pour les modifications de l'infrastructure IT. Clarté des Les autorisations relatives autorisations aux modifications de relatives aux l'infrastructure IT ne sont modifications de pas définies par écrit. l'infrastructure IT Contrôle des coûts Infrastructure IT convenue Prescriptions IT (SLA) Gouvernance IT Les coûts IT ne sont pas traités de manière homogène selon des normes précises dans la comptabilité. L'attribution de coûts et de temps aux activités IT n'est pas possible. L'acquisition, l'exploitation et la maintenance de l'infrastructure IT suivent une stratégie indépendante des activités opérationnelles. Il n'existe pas de contrats de prestation de services entre le service IT et les services spécialisés (utilisateurs) concernant les temps de service, la disponibilité et l'efficacité des services IT. Aucun pilotage de l'organisation et des processus IT n'est effectué. Il y a des procédures d'autorisation informelles pour les modifications de l'infrastructure IT. Des procédures d'autorisation formelles sont définies pour les modifications dans toute l'infrastructure IT; celles-ci peuvent néanmoins être contournées ou ignorées. Les autorisations relatives La plupart des processus aux modifications de l'infrastructure IT sont rarement consignées. Les coûts IT sont budgétisés et comptabilisés en continu. Une répartition entre les différentes activités IT n'est cependant pas effectuée. S'agissant des projets, il n'y a pas de calcul rétrospectif. L'acquisition, l'exploitation et la maintenance de l'infrastructure IT ne suivent pas une stratégie globale découlant des objectifs opérationnels. L'approche se base néanmoins sur les activités opérationnelles. Il n'existe pas d'objectifs de performance au sein du service IT pour la fourniture de ses prestations. Ceux-ci ne sont ni communiqués ni convenus avec les services spécialisés. La structure et le pilotage de l'organisation et des processus IT ne se basent pas sur des normes, mais sont développés en interne. d'autorisation des modifications de l'infrastructure IT ainsi que les modifications elles-mêmes sont consignés; en revanche, seule une surveillance ponctuelle est assurée. Les coûts IT sont budgétisés globalement et comptabilisés en continu. Une répartition entre les différentes activités IT n'est cependant pas effectuée. S'agissant des projets importants, un calcul rétrospectif est réalisé, les principaux dépassements étant alors justifiés. Des suppléances existent pour les fonctions essentielles au sein du service IT et donnent lieu à une formation; la documentation actuelle correspondante permet de facto l'exécution des tâches par le ou les suppléants. Des procédures d'autorisation formelles sont définies pour les modifications dans toute l'infrastructure IT. Leur respect est assuré et régulièrement contrôlé. Les demandes de modification ne donnant pas lieu aux autorisations requises sont systématiquement rejetées. Tous les processus d'autorisation des modifications de l'infrastructure IT ainsi que les modifications ellesmêmes sont consignés systématiquement. Le respect des processus d'autorisation est surveillé en continu et contrôlé régulièrement. Il existe un processus complet pour le contrôle financier de toutes les activités et de tous les projets IT, y c. la planification, la budgétisation, la comptabilisation des coûts et du temps ainsi que le contrôle des résultats. Les écarts font l'objet d'une analyse systématique. L'entreprise veille à la conformité de l'acquisition, de Il existe un processus l'exploitation et de la maintenance de l'infrastructure IT aux objectifs opérationnels; il n'existe cependant pas de processus formalisé à cet égard. formalisé garantissant la conformité de l'acquisition, de l'exploitation et de la maintenance de l'infrastructure IT aux objectifs opérationnels de l'entreprise. Des contrats de prestation de services informels de services formels existent Des contrats de prestation existent entre le service IT entre le service IT et les et les services spécialisés services spécialisés (utilisateurs) concernant les temps (utilisateurs) concernant les temps de service, la disponibilité et l'efficacité des et l'efficacité des services de service, la disponibilité services IT; ceux-ci ne sont IT sous la forme de SLA cependant pas documentés écrits. Le respect de ceux-ci intégralement et leur respect fait l'objet d'un contrôle ne fait pas l'objet d'un périodique. contrôle périodique. La structure et le pilotage de l'organisation et des processus IT se basent sur des normes telles que COBIT (gouvernance), ITIL (gestion des services) et ISO & (gestion de la sécurité). La structure et le pilotage de l'organisation et des processus IT sont systématiquement mis en œuvre conformément à des normes telles que COBIT (gouvernance), ITIL (gestion des services) et ISO & (gestion de la sécurité). 28

31 «Guide d analyse des risques informatiques» Titre Niveau de maturité 1 Niveau de maturité 2 Niveau de maturité 3 Niveau de maturité 4 Constatation Evaluation Recommandation Gouvernance IT Gestion des risques IT Documentation des processus IT Concept de protection de l'accès aux données Concept de protection de l'accès aux applications Gestion des risques Politique de sécurité Assurances Les processus IT et les responsabilités correspondantes ne sont pas communiqués. Chacun est libre dans son activité. Il n'y a ni surveillance ni contrôle. Il n'existe pas de concept de protection des accès réglant la classification des données et les droits d'accès des utilisateurs. Il n'existe pas de concept de protection des accès réglant les droits d'accès des utilisateurs aux applications et aux fonctions disponibles dans celles-ci. Les processus IT et les responsabilités correspondantes sont communiqués de manière informelle et chacun dispose d'une grande liberté dans son activité. Il n'y a ni surveillance ni contrôle. Seuls les processus IT les plus importants et les responsabilités correspondantes sont fixés par écrit; cette documentation n'est pas forcément actuelle et correcte. Le respect de ces processus est surveillé de manière sporadique uniquement; des contrôles ne sont effectués qu'en cas d'incident exceptionnel. Il existe un concept informel Il existe un concept de de protection des accès réglant la classification des données et les droits d'accès des utilisateurs; il n'a cependant pas toujours été communiqué aux utilisateurs. Il existe un concept informel de protection des accès réglant les droits d'accès des utilisateurs aux applications et aux fonctions disponibles dans celles-ci; il n'a cependant pas toujours été communiqué aux utilisateurs. Les risques IT et les exigences de sécurité ne sont ni gences de sécurité ne sont Les risques IT et les exi- identifiés ni vérifiés. vérifiés qu'en cas d'incident ayant un impact sur la sécurité. La mise en œuvre des mesures d'amélioration prévues n'est pas surveillée. La politique de sécurité IT et le concept de sécurité ne sont présents que sous une forme sommaire ou sont totalement inexistants. La politique de sécurité IT et le concept de sécurité sont parfois présents, mais ils remontent déjà à plus d'une année. Il n'existe pas d'assurances Il existe parfois des assurances pour les infrastruc- pour les infrastructures et les équipements IT (matériel). tures et les équipements IT (matériel); il n'est cependant pas clair s'il existe une couverture d'assurance appropriée pour tous les incidents possibles. protection des accès réglant la classification des données et les droits d'accès des utilisateurs; son respect n'est cependant pas vérifié régulièrement et il n'est pas mis à jour régulièrement. Il existe un concept de protection des accès réglant les droits d'accès des utilisateurs aux applications et aux fonctions disponibles dans celles-ci; son respect n'est cependant pas vérifié périodiquement et il n'est pas mis à jour régulièrement. Les nouvelles applications ne sont pas prises en compte ou le sont uniquement avec un retard considérable. Les risques IT et les exigences de sécurité sont examinés à intervalles irréguliers ou de manière non systématique. Les mesures d'amélioration prévues ne sont que partiellement surveillées. La politique de sécurité IT et le concept de sécurité sont examinés et adaptés à intervalles irréguliers. Il existe une assurance de choses pour les infrastructures et les équipements IT (matériel); le besoin d'assurances supplémentaires (p. ex. supports de données/ coûts supplémentaires, interruption de l'exploitation) est précisé de manière informelle. Tous les processus IT pertinents et les responsabilités correspondantes sont documentés par écrit, tenus à jour et conformes à la réalité; leur respect est surveillé en continu et contrôlé régulièrement. Il existe un concept de protection des accès réglant la classification des données et les droits d'accès des utilisateurs. Son respect et son efficacité sont vérifiés régulièrement et il est mis à jour en cas de besoin. Il existe un concept de protection des accès réglant les droits d'accès des utilisateurs aux applications et aux fonctions disponibles dans celles-ci. Son respect et son efficacité sont vérifiés périodiquement et il est mis à jour en cas de besoin. Les risques IT et les exigences de sécurité sont examinés périodiquement et systématiquement et activement traités via une auto-évaluation régulière des contrôles mis en place. La mise en œuvre complète des mesures d'amélioration prévues est surveillée de manière continue. La politique de sécurité IT le concept de sécurité sont examinés périodiquement et adaptés à la menace concrète et à la stratégie/ aux objectifs actuels de l'entreprise. Il existe une assurance de choses pour les infrastructures et les équipements IT (matériel); le besoin d'assurances supplémentaires (p. ex. supports de données/ coûts supplémentaires, interruption de l'exploitation) est précisé de manière formelle. Les processus d'acquisition et de projet comprennent l'examen obligatoire d'une couverture d'assurance supplémentaire; il existe un aperçu central et actuel de toutes les prestations d'assurance conclues. 29

32 Titre Niveau de maturité 1 Niveau de maturité 2 Niveau de maturité 3 Niveau de maturité 4 Constatation Evaluation Recommandation Conformité Gestion des projets IT Non-respect des lois / normes / prescriptions Audit IT indépendant Gestion des projets IT Répartition des projets en différentes phases Equipe de projet Degré de participation de la direction dans les projets La reconnaissance de l'applicabilité des lois, normes et prescriptions et de leur respect n'est pas réglée. Aucun audit indépendant des applications, de l'infrastructure et de l'exploitation IT n'est réalisé. Il n'existe pas d'aperçu des projets IT. Les projets sont rarement répartis en phases; la majeure partie des produits livrables ou des étapes importantes manquent. Les équipes ne sont pas nommées, les collaborateurs sont impliqués de manière dynamique et non coordonnée. La direction n'utilise pas son pouvoir de décision et n'a pas non plus délégué celui-ci formellement à un comité de pilotage ou au responsable IT. Il n'existe pas de dispositions concernant le recensement systématique et le respect des lois, normes et prescriptions pertinentes pour l'entreprise. Un audit indépendant des applications, de l'infrastructure et de l'exploitation IT est rarement réalisé. Aucune mesure visant à remédier aux faiblesses ou lacunes identifiées n'est mise en œuvre. Il existe un aperçu partiel des projets IT en cours; il n'existe cependant pas de documentation complémentaire. Les projets sont répartis dans des phases individuelles longues sans produits livrables et étapes importantes clairement définis. Les responsables et les équipes de projet sont nommés de manière informelle; il n'existe cependant pas de descriptions claires des tâches. Les équipes de projet sont rarement formées à la méthode de gestion de projet appliquée. La direction délègue son pouvoir de décision, p. ex. à un comité de pilotage ou au responsable IT. La direction participe aux projets uniquement à la demande des représentants des utilisateurs ou du responsable IT. Les principales lois, normes et prescriptions applicables sont connues des divers services spécialisés. Leur respect est réglé par domaine. Des audits indépendants des applications, de l'infrastructure et de l'exploitation IT sont réalisés, mais uniquement en cas d'incidents ou d'exigences spécifiques. Les mesures visant à remédier aux faiblesses ou lacunes ne sont pas mises en œuvre de manière systématique. Il existe un aperçu actuel de tous les projets IT; il n'existe cependant pas d'harmonisation obligatoire avec un portefeuille de l'ensemble des projets au niveau de l'entreprise. Les projets sont structurés en phases courtes avec des livrables clairs; les phases de planification initiales (cachier des charges / spécifications) sont habituellement réduites au profit de la phase d'exécution. Un contrôle de l'avancement des projets est parfois réalisé. Des responsables et des équipes de projet sont nommés, mais leurs tâches concrètes et le temps correspondant n'ont pas été planifiés de manière systématique. Une formation à la méthode de gestion de projet appliquée a parfois été assurée. La direction est informée sur l'avancement des projets via des protocoles réguliers, mais elle participe rarement aux réunions (de pilotage) concernant les projets ou aux rencontres avec les responsables de projet. Il existe un processus défini pour le recensement de toutes les lois, normes et prescriptions applicables ainsi que des contrôles internes clairs concernant leur respect. Des audits indépendants des applications, de l'infrastructure et de l'exploitation IT sont réalisés régulièrement. Des mesures appropriées sont mises en œuvre de manière systématique et rapidement; les travaux nécessaires à cet effet sont contrôlés. Un portefeuille de projets comprenant tous les projets IT est géré au niveau de l'entreprise. Le processus de projet comprend l'harmonisation obligatoire avec ce portefeuille et sa mise à jour. Les projets sont répartis clairement dans des étapes importantes et des activités principales et secondaires avec des produits livrables clairement définis (p. ex. cahier des charges / spécifications / exécution / test / validation / application); des réunions régulières ont lieu concernant l'avancement des projets. Des responsables et des équipes de projet sont nommés; leurs tâches et le pourcentage de temps de travail correspondant sont clairement indiqués. Les responsables de projet et tous les collaborateurs participant aux projets ont reçu une formation suffisante à la méthode de gestion de projet appliquée. La direction est informée régulièrement sur l'avancement des projets et des problèmes survenus et prend part aux décisions importantes relatives aux projets; à cet effet, elle rencontre les responsables de projet ou participe activement aux réunions sur l'avancement des projets. 30

33 «Guide d analyse des risques informatiques» Titre Niveau de maturité 1 Niveau de maturité 2 Niveau de maturité 3 Niveau de maturité 4 Constatation Evaluation Recommandation Gestion des projets IT Développement de logiciels Analyse des besoins / Participation des utilisateurs Analyse coûts/ utilité Processus de développement/ configuration Cahier des charges manquant/ incomplet Dépendance vis-à-vis de développeurs/ fournisseurs externes Les nouveaux systèmes IT sont conçus sans la participation de tous les groupes d'utilisateurs concernés principalement sur la base des souhaits et des idées de certains groupes. Des projets ont été lancés sans que des analyses coûts/ utilité aient été réalisées. Il n'existe pas de processus spécifique pour le développement, l'évaluation et la configuration des applications. Il existe rarement un cahier des charges pour les nouvelles applications. Les unités d'organisation importantes concernées ne sont pas intégrées. Les dépendances et les suppléances vis-à-vis de développeurs/fournisseurs externes ne sont ni réglées, ni surveillées ni contrôlées. Les nouveaux systèmes IT Le développement/ sont conçus principalement par le service IT sur la base des souhaits et des idées des services spécialisés. Certains groupes d'utilisateurs sont sollicités pour clarifier des questions de détail. Des projets ad hoc ont été lancés sur la base des exigences actuelles des services spécialisés ou de la direction, les estimations relatives aux coûts/à l'utilité se basant sur des idées optimistes qui ne sont pas étayées par des chiffres. Les adaptations nécessaires dans le cadre d'autres projets sont rarement identifiées et démontrées. Les processus de développement, d'évaluation et de configuration des applications sont informels; l'accès aux environnements de développement et d'évaluation n'est pas spécialement protégé. Le cahier des charges pour les nouvelles applications est incomplet, d'autant plus que les unités d'organisation importantes concernées ne sont pas intégrées de manière systématique. Il n'y a pas de validation formelle du cahier des charges. Les suppléances vis-à-vis de développeurs/fournisseurs externes sont réglées de manière informelle et ad hoc. Il n'existe pas de contrats garantissant la disponibilité d'un savoir-faire critique. l'acquisition de nouveaux systèmes IT est parfois réglé formellement. Les nouveaux systèmes sont conçus principalement par le service IT, les différents groupes d'utilisateurs étant sollicités précocement pour clarifier et piloter les besoins. Les projets sont lancés sur la base des besoins démontrés. Les coûts donnent lieu à une évaluation quantitative, l'utilité à une évaluation plutôt qualitative. Les effets des projets sur les autres applications manifestement concernées sont analysés et les coûts subséquents sont examinés. Il existe un processus de développement/d'acquisition formel et complet pour les systèmes IT. Les représentants de tous les groupes d'utilisateurs sont impliqués dès le départ dans le processus et responsables de l'exhaustivité de la spécification. Les changements de besoins/spécifications sont pilotés de manière proactive par les représentants des utilisateurs. Les projets résultent de la planification IT stratégique de l'entreprise et d'une analyse complète des coûts/ de l'utilité (business case). La réalisation des objectifs est systématiquement mesurée et évaluée à la fin du projet. Le cahier des charges pour les nouvelles applications est complet, les exigences de la plupart des unités d'organisation concernées étant prises en compte. La validation est informelle. Des changements/compléments sont apportés encore fréquemment au cahier des charges après la validation. Lorsque des développeurs/ fournisseurs externes sont impliqués, des suppléances formelles sont prévues pour les fonctions importantes auprès des prestataires de services, mais elles ne sont cependant ni surveillées ni contrôlées systématiquement. Le savoir-faire critique est transmis de manière informelle ou doit être constitué rapidement en cas d'urgence. Les processus de développement, d'évaluation fixés par écrit pour le Il existe des processus et de configuration des développement, l'évalua- applications et l'accès aux environnements de développement et d'évaluation sont documentés et largement connus; leur respect n'est cependant vérifié qu'au cas par cas. tion et la configuration des applications, y c. l'accès aux environnements de développement et d'évaluation et la mise à disposition des processus de l'environnement de production. Leur respect est surveillé en continu et contrôlé périodiquement. Il existe un cahier des charges formel et complet pour les nouvelles applications. Les exigences de toutes les unités d'organisation concernées sont systématiquement sondées et analysées. Avant le début du développement/de l'acquisition, le cahier des charges est formellement validé. Les changements apportés ultérieurement au cahier des charges sont strictement contrôlés. Lorsque des développeurs/ fournisseurs externes sont impliqués, des règles contractuelles garantissent la disponibilité de collaborateurs compétents. Le savoirfaire critique est largement et clairement soutenu auprès du prestataire de services par une formation ciblée, la suppléance et la rotation des tâches. 31

34 Titre Niveau de maturité 1 Niveau de maturité 2 Niveau de maturité 3 Niveau de maturité 4 Constatation Evaluation Recommandation Développement de logiciels Test des applications Disponibilité du code source Documentation relative aux applications Migration des données Procédure de modification Séparation développement/ production Le code source des programmes ou des versions de programme installés est peu documenté. Il n'existe pas de documentation écrite relative aux applications. Le code source des programmes ou des versions de programme installés et leurs configurations sont documentés de manière incomplète. L'accès au code source des logiciels acquis n'est souvent pas possible. Il n'existe qu'une documentation informelle relative aux applications; dans de nombreux cas, la documentation disponible est incomplète ou pas mise à jour. Lors de l'introduction de Lors de l'introduction de nouvelles applications, les nouvelles applications, les données nécessaires sont données sont migrées à migrées. Avant la mise en l'aide d'outils standard. service, des contrôles sont Avant la mise en service, on cependant rarement effectués pour vérifier l'exhaustillons si la structure des contrôle à l'aide d'échantivité, l'exactitude et la données a été reprise compatibilité de la migration correctement. des données. Il n'existe pas de procédure de contrôle des modifications. Les développeurs peuvent faire des modifications de manière illimitée; les modifications ne sont en outre pas claires. Il n'existe pas d'environnement de test. Les applications sont intégrées directement dans l'environnement de production et testées en direct. Il existe peu de procédures de modification formelles. Les développeurs peuvent faire des modifications non autorisées au niveau de l'environnement de production ou modifier les configurations. Les modifications notamment en cas d'urgence sont peu traçables. Il n'existe pas d'environnement suffisamment séparé de l'environnement de production pour développer et tester les applications. Le code source des programmes ou des versions de programmes et versions de Le code source de tous les programme installés et les programme installés et les configurations correspondantes sont documentés dantes sont documentés de configurations correspon- en majeure partie et à jour. manière exhaustive, à jour L'accès au code source et traçables. L'accès au code des logiciels acquis est source des logiciels acquis parfois garanti par des est incontestablement règles contractuelles (escrow garanti (escrow agreement). agreement). Il existe une documentation détaillée pour toutes les applications; sa mise à jour et son intégralité ne peuvent cependant pas être toujours garanties. Avant le début de la mise en production des nouvelles applications, les données devant être reprises sont partiellement migrées et l'application est testée avec les données migrées. Lors de la mise en service, toutes les données actuelles sont une nouvelle fois migrées. Les procédures de modification sont largement réglées pour la plupart des systèmes, toutes les modifications d'urgence étant couvertes. Les modifications sont claires et peuvent uniquement être effectuées par des personnes autorisées; elles sont testées dans leur majeure partie avant leur installation et explicitement autorisées; le respect des procédures n'est cependant contrôlé qu'au cas par cas. Pour certaines applications importantes, il existe des environnements de développement et de test séparés de la production. Il existe une procédure formelle et complète pour la documentation des applications, avec des descriptions de toutes les applications et de leurs principales spécifications, y c. la clarté des documents de projet centraux et des tests effectués. La documentation est obligatoirement mise à disposition et tenue à jour. Avant le début de la mise en production des nouvelles applications, les données devant être reprises sont intégralement migrées et l'intégralité, l'exactitude et la compatibilité de l'application avec les nouvelles fonctions sont testées en parallèle de manière exhaustive par un groupe d'utilisateurs des services spécialisés concernés. Lors de la mise en service, toutes les données actuelles sont une nouvelle fois migrées. Il existe des règles formelles strictes concernant les modifications des programmes et configurations, qui couvrent aussi les modifications d'urgence. Les modifications sont toujours claires, ne peuvent être effectuées que par des personnes autorisées et doivent être testées et explicitement autorisées avant l'installation. Toutes les modifications sont surveillées en continu et documentées précisément. A côté de l'environnement de développement, il existe un environnement de test qui est totalement séparé de l'environnement de production. Toutes les applications peuvent y être testées sans danger avant leur mise en production. 32

35 «Guide d analyse des risques informatiques» Titre Niveau de maturité 1 Niveau de maturité 2 Niveau de maturité 3 Niveau de maturité 4 Constatation Evaluation Recommandation Test des applications Identification des environnements de système Intégralité des tests Tests au début de la production de la nouvelle application ou de la nouvelle version Tests de compatibilité Les environnements de système disponibles ne sont séparés ni physiquement ni logiquement. Les environnements de système disponibles (développement/test/production) ne sont pas documentés et ne sont identifiables ni physiquement ni logiquement comme des environnements de système dédiés. La planification, l'exécution Les tests ne sont pas et la documentation des formalisés; la planification, tests sont rarement réalisées. l'exécution et la documentation des tests ne suivent pas de directives concrètes. Aucun test n'est réalisé dans cette phase de projet. Une mise en service définitive peut cependant avoir lieu même si les tests sont incomplets et les résultats ne sont pas satisfaisants. Des tests sont réalisés, mais ils ne sont ni formalisés ni standardisés. Il n'y a pas d'archivage des résultats des tests après leur mise en œuvre. Une autorisation définitive peut être donnée en vue de l'exploitation même si les tests ne sont pas exécutés correctement. Avant la mise en production Avant la mise en production d'applications nouvelles ou d'applications nouvelles ou modifiées, aucun test n'est modifiées, seuls des tests réalisé concernant la compatibilité avec l'environnement. concernant la compatibi- sommaires sont réalisés lité avec l'environnement existant. Les environnements de système disponibles (développement/test/production) sont documentés, mais ils ne sont identifiables ni physiquement ni logiquement comme des environnements de système dédiés. Les tests sont formalisés; la planification, l'exécution et la documentation des tests suivent des directives sommaires. Les tests sont généralement réalisés dans la plupart des phases (avancées) de projet; ceci n'est cependant pas obligatoirement mis en œuvre et surveillé. Des tests standardisés sont réalisés, mais ils ne sont pas formalisés. Il n'y a pas d'archivage des résultats des tests après leur mise en œuvre. L'autorisation définitive pour l'exploitation de l'application est généralement donnée après l'exécution correcte des tests; ceci n'est cependant pas obligatoirement effectué ni surveillé. Les principales interfaces des applications nouvelles et modifiées sont soumises à des tests concernant les systèmes secondaires. Les résultats de ces tests ne sont cependant pas toujours documentés ni archivés de manière systématique. Les environnements de système disponibles (développement/test/production) sont documentés. Ils sont clairement identifiables physiquement (p. ex. au moyen d'un marquage) et logiquement (p. ex. fond d'écran ou texte en couleur) comme étant associés à un certain type d'environnement de système. Les tests sont formalisés; la planification, l'exécution et la documentation des tests suivent dans toutes les phases de développement des directives claires concernant l'étendue et l'intégralité et intègrent tous les services spécialisés et domaines d'utilisation. Des tests individuels et en série suffisants sont réalisés intégralement et correctement, ce qui donne lieu à une surveillance continue et à des contrôles réguliers. Pendant et après l'installation (mise en service), de nombreux tests sont réalisés au moyen de questionnaires utilisateurs ou via la mise à disposition de l'application en vue d'un test représentatif. L'autorisation définitive pour l'exploitation est donnée uniquement si tous les critères sont remplis. L'exécution du test (y c. les résultats du test) est établie clairement, ce qui est surveillé en continu et contrôlé régulièrement. Il existe des processus formalisés pour la réalisation de tests de compatibilité des applications nouvelles ou modifiées avec les environnements existants (notamment interfaces). Les résultats, les erreurs survenues et les solutions/mesures de correction correspondantes sont systématiquement documentés et archivés, ce qui est surveillé en continu et contrôlé régulièrement. 33

36 Titre Niveau de maturité 1 Niveau de maturité 2 Niveau de maturité 3 Niveau de maturité 4 Constatation Evaluation Recommandation Directives d'utilisation Formation des utilisateurs Directives d'utilisation sur la protection anti-virus Utilisation d'internet / de l' Archivage Manuel d'utilisation et documentation Formations informatiques Il n'existe pas de directives d'utilisation relatives à la protection anti-virus. Il n'existe pas de formation spécifique pour les utilisateurs, p. ex. concernant le traitement des supports de données externes, les pièces jointes par , l'accès Internet et les téléchargements inconnus. Il n'existe pas de directives d'utilisation relatives à Internet et à l' . Les collaborateurs ne sont pas sensibilisés aux risques liés à l'utilisation d'internet et de l' . Les activités liées à Internet et à l' ne sont ni consignées ni surveilllées. Il n'existe pas de directives d'utilisation concernant la conservation, l'archivage et la destruction des documents. Les utilisateurs ne disposent pas d'un manuel d'utilisation pour les applications utilisées. Les utilisateurs ne reçoivent pas de formation. Il existe des directives d'utilisation informelles relatives à la protection anti-virus. Les utilisateurs sont informés, p. ex. du fait que les supports de données externes, les pièces jointes par , les accès à des sites Internet douteux et les téléchargements inconnus représentent un danger, mais il n'est pas possible de prouver que les collaborateurs respectent vraiment les directives. Il existe des indications concernant l'utilisation d'internet et de l' , et les collaborateurs sont sensibilisés aux risques liés à l'utilisation d'internet et de l' . Les activités liées à Internet et à l' ne sont ni consignées ni autrement surveillées et analysées. Il existe des directives et des procédures d'utilisation informelles concernant la conservation, l'archivage et la destruction des documents. Il n'est cependant pas possible de prouver que les collaborateurs respectent vraiment les directives. Il existe uniquement des manuels d'utilisation informels pour certaines applications. Dans bien des cas, la documentation disponible est cependant incomplète ou pas à jour. Les utilisateurs sont formés selon le principe "learning by doing". Des formations existent pour certaines applications. Il existe des directives d'utilisation formelles relatives à la protection anti-virus. Les utilisateurs sont informés, p. ex. du fait que les supports de données externes, les pièces jointes par , les accès à des sites Internet douteux et les téléchargements inconnus représentent un danger, mais il n'y a pas eu de véritable formation au cours des trois dernières années. Le respect des directives n'est cependant surveillé qu'au cas par cas. Il existe des directives d'utilisation concernant l'utilisation d'internet et de l' . Les collaborateurs sont sensibilisés durablement aux risques liés à l'utilisation d'internet et de l' . Les activités liées à Internet et à l' sont consignées, mais ne sont ni surveillées ni analysées. Il existe des directives et des procédures d'utilisation concernant la conservation, l'archivage et la destruction des documents. Le respect des directives n'est cependant surveillé qu'au cas par cas. Il existe des manuels d'utilisation détaillés pour les applications importantes. Leur mise à jour et leur exhaustivité ne peuvent cependant pas toujours être garanties. Il existe des directives d'utilisation formelles relatives à la protection anti-virus. Les utilisateurs sont informés dans le cadre de formations, comme p. ex. sur le traitement des supports de données, des pièces jointes par et des téléchargements inconnus. Le respect des directives est surveillé en continu et contrôlé périodiquement. Il existe des directives d'utilisation formelles concernant l'utilisation d'internet et de l' ainsi que des procédures formelle pour la sensibilisation régulière de tous les collaborateurs à l'accès aux ordinateurs en ce qui concerne les risques liés à l'utilisation d'internet et de l' . Le comportement relatif à l' et Internet est enregistré en continu et les activités suspectes ou risquées (tout comme le respect de la protection de la personnalité) sont analysées. Il existe des directives d'utilisation et des procédures formelles concernant la conservation, l'archivage et la destruction des documents. Leur respect est surveillé et contrôlé périodiquement. Il existe une procédure formelle complète pour les manuels d'utilisation et la documentation de toutes les applications. La documentation est obligatoirement tenue à disposition et mise à jour. Il existe un programme Un programme de formation de formation destiné à formel et des procédures former les collaborateurs à correspondantes garantissent que tous les utilisa- l'utilisation correcte et sûre d'une application. Cette teurs sont systématiquement formation n'a cependant formés, conformément à pas obligatoirement lieu leurs besoins spécifiques, à avant la première utilisation leur niveau de connaissances de cette application et n'est et aux exigences de sécurité pas adaptée aux besoins de l'entreprise, à l'utilisation correcte et sûre des spécifiques des utilisateurs ni aux exigences de sécurité de applications avant qu'ils ne l'entreprise. travaillent avec celles-ci de manière autonome. 34

37 «Guide d analyse des risques informatiques» Titre Niveau de maturité 1 Niveau de maturité 2 Niveau de maturité 3 Niveau de maturité 4 Constatation Evaluation Recommandation Formation des utilisateurs Protection des accès Formation en cas de modification et de développement Profils utilisateurs Gestion des droits d'accès Comptes utilisateurs impersonnels En cas de modification En cas de modification majeure des applications, les utilisateurs ne reçoivent ni information ni formation. Il n'existe pas de profils de sécurité basés sur les rôles. Il n'existe pas de procédures spécifiques garantissant que les autorisations sont saisies et mises à jour correctement et en particulier que les droits d'accès des collaborateurs qui quittent l'entreprise sont supprimés à temps. majeure des applications, aucune formation n'est proposée. Les utilisateurs sont formés selon le principe "learning by doing". Il existe des applications individuelles avec des profils de sécurité basés sur les rôles. Les procédures de gestion des droits d'accès sont informelles; les identifications utilisateurs et les droits d'accès sont commandés de manière ad hoc auprès de l'administrateur système. Des comptes utilisateurs Des comptes utilisateurs impersonnels sont utilisés impersonnels sont parfois pour les opérations et les utilisés sans que leur nécessité soit systématiquement activités IT quotidiennes sans qu'une surveillance spéciale contrôlée. ne soit assurée. Les collaborateurs sont informés des modifications majeures des applications. Des formations sont proposées, mais elles ne sont cependant pas obligatoirement suivies par tous les utilisateurs. Il existe un concept d'autorisation avec des rôles clairs et des profils de sécurité basés sur les rôles; il est cependant mis en œuvre uniquement pour certaines applications et fonctions. Les procédures de gestion des droits d'accès sont documentées et largement connues, de sorte que les droits d'accès d'un collaborateur sont mis en place à son arrivée conformément à sa fonction et supprimés lors de son départ. La gestion des droits d'accès est limitée à quelques personnes. Il n'existe cependant pas d'autres contrôles garantissant que les comptes non utilisés et les droits d'accès devenus inutiles sont supprimés. Les cas dans lesquels des comptes utilisateurs impersonnels peuvent être utilisés sont documentés. L'accès à ces comptes est limité à quelques personnes; il n'est cependant pas possible d'identifier la personne en question. Il n'y a pas de contrôle périodique de leur nécessité. Une procédure formelle garantit que, en cas de modifications et de développements majeurs, les collaborateurs sont informés du besoin de formation (complémentaire) et qu'ils suivent ces formations dans le délai requis. Un service spécifique a été mis sur pied pour répondre aux questions typiques des utilisateurs. Le respect est surveillé et contrôlé périodiquement. Il existe un concept d'autorisation général avec des rôles clairs et des profils de sécurité basés sur les rôles. Des profils 1-n sont attribués aux collaborateurs selon leur fonction et/ou leur description de poste. L'octroi d'autorisations individuelles est nécessaire uniquement dans des cas exceptionnels. Il existe des procédures fixées par écrit pour la gestion des droits d'accès, qui garantissent que les droits d'accès d'un collaborateur sont mis en place à son arrivée conformément à sa fonction, mis à jour périodiquement et supprimés lors de son départ. La gestion des autorisations est strictement limitée à certaines personnes du point de vue tant organisationnel que technique. Le respect des procédures est surveillé en continu et contrôlé périodiquement; les droits d'accès eux-mêmes sont contrôlés régulièrement afin de garantir que les comptes non utilisés ne sont plus actifs et que les droits d'accès devenus inutiles sont supprimés. Une procédure formelle garantit que des comptes utilisateurs impersonnels sont utilisés uniquement dans des cas exceptionnels et avec l'accord préalable du service responsable. Les comptes utilisateurs impersonnels peuvent être utilisés par les collaborateurs uniquement via une authentification personnelle préalable, de sorte que la clarté est garantie. La nécessité des comptes utilisateurs impersonnels est contrôlée périodiquement. 35

38 Titre Niveau de maturité 1 Niveau de maturité 2 Niveau de maturité 3 Niveau de maturité 4 Constatation Evaluation Recommandation Protection des accès Sécurité IT Authentification (avec mots de passe) Sensibilisation à l'utilisation des mots de passe Violation de la confidentialité en cas d'accès non autorisé Sensibilisation des utilisateurs Programmes de protection anti-virus Il n'existe pas de spécifications (techniques/conceptuelles) concernant l'utilisation de mots de passe. Les systèmes importants ou particulièrement exposés ne sont pas protégés avec des authentifications à deux facteurs. L'accès aux systèmes et applications est en principe protégé avec des mots de passe; pour certains systèmes particulièrement exposés, il existe des authentifications à deux facteurs. Le changement périodique de mot de passe est imposé au minimum une fois par an, mais les utilisateurs peuvent choisir les mots de passe qu'ils souhaitent. Il n'y a pas de sensibilisation des collaborateurs Les collaborateurs ont été concernant l'utilisation sûre des mots de passe. Les mots de passe sont rarement modifiés et ils sont fréquemment transmis à d'autres personnes. sensibilisés au moins une fois (p. ex. lors de leur engagement) à l'utilisation sûre des mots de passe. Des mots de passe faciles à deviner sont utilisés, les mots de passe ne sont pas modifiés régulièrement ou sont communiqués à d'autres utilisateurs. Il n'existe pas de directives Il existe des directives concernant le traitement des d'utilisation informelles données confidentielles. Les serveurs et les données ne sont pas protégés. Les accès non autorisés ne peuvent pas être détectés. Les utilisateurs ne sont ni sensibilisés ni formés à la sécurité de l'information et IT. Les serveurs et les places de travail (clients) ne disposent pas de programmes de protection anti-virus. concernant le traitement des données confidentielles; il n'est cependant pas possible de prouver que les collaborateurs respectent ces directives. Les serveurs et les données ne sont pas spécialement protégés. Les accès non autorisés ne peuvent pas être détectés. Il existe des instructions informelles quant à l'utilisation correcte des systèmes d'information et à la sécurité de l'information et IT; elles ne sont cependant pas communiquées systématiquement. Il n'y a pas de formation systématique des utilisateurs. Les serveurs et les places de travail (clients) disposent parfois d'un programme de protection anti-virus; celui-ci n'est cependant pas mis à jour régulièrement. Les procédures d'authentification des identifications utilisateurs sont documentées et en principe mises en place de manière sûre. Pour les systèmes importants ou particulièrement exposés, il existe des authentifications à deux facteurs. Le changement périodique de mot de passe (au minimum deux fois par an) et une syntaxe de mot de passe minimale sont imposés. Les collaborateurs sont parfois sensibilisés au choix de mots de passe forts et à l'utilisation sûre de ceux-ci, mais leur niveau de formation n'est ni déterminé ni fixé. Les violations des instructions ne sont pas obligatoirement poursuivies sur le plan disciplinaire. Il existe des directives d'utilisation concernant le traitement des données confidentielles. Le respect des directives n'est cependant surveillé qu'au cas par cas. Il existe des procédures de cryptage pour les données confidentielles et les serveurs spécialement protégés, mais elles ne sont pas mises en œuvre systématiquement. Les accès non autorisés à des données confidentielles peuvent parfois être détectés et tracés. Il existe des instructions claires et contraignantes quant à l'utilisation correcte des systèmes d'information et à la sécurité de l'information et IT, lesquelles sont communiquées aux collaborateurs lors de leur arrivée dans l'entreprise. Une formation est généralement dispensée aux nouveaux collaborateurs; les autres collaborateurs ne sont pas systématiquement formés. Les serveurs et les places de travail (clients) disposent d'un programme de protection anti-virus; celui-ci n'est cependant pas mis à jour quotidiennement. Une procédure fixée par écrit garantit que, pour l'authentification des identifications utilisateurs, il existe des procédures suffisamment sûres; les systèmes importants ou particulièrement exposés sont protégés par des authentifications à deux facteurs. Lors de l'utilisation de mots de passe, une syntaxe de mot de passe complexe et le changement périodique des mots de passe sont imposés. Une procédure fixée par écrit garantit que tous les collaborateurs sont sensibilisés régulièrement au choix de mots de passe forts et à l'utilisation sûre de ceux-ci. Tous les utilisateurs connaissent leur responsabilité quant à l'utilisation des mots de passe; leur niveau de formation et le respect sont contrôlés; les violations sont poursuivies sur le plan disciplinaire. Il existe des directives d'utilisation formelles concernant le traitement des données confidentielles et les utilisateurs sont formés en conséquence. Les données confidentielles sont cryptées ou se trouvent sur des serveurs spécialement protégés. Les accès aux données confidentielles sont entièrement consignés et contrôlés périodiquement. Il existe des instructions formelles quant à l'utilisation correcte des systèmes d'information et à la sécurité de l'information et IT; elles sont communiquées activement à tous les utilisateurs. Des formations systématiques ont lieu à intervalles réguliers selon les groupes cibles et les fonctions et sont suivies par la plupart des collaborateurs. Des mesures de sensibilisation complémentaires sont mises en œuvre de manière planifiée. L'entreprise dispose d'un programme de protection anti-virus qui est mis à jour en ligne quotidiennement, est installé sur tous les serveurs et places de travail et ne peut pas être désactivé par les utilisateurs. 36

39 «Guide d analyse des risques informatiques» Titre Niveau de maturité 1 Niveau de maturité 2 Niveau de maturité 3 Niveau de maturité 4 Constatation Evaluation Recommandation Sécurité IT Sécurité physique Droits d'administration sur les ordinateurs personnels Protection du réseau Accès à distance (remote access) Protection incendie Protection de l'alimentation électrique Il n'existe pas de concept réglant l'octroi d'autorisations administrateur; certains utilisateurs dans les services spécialisés disposent d'autorisations administrateur à leurs places de travail, ce qui permet d'installer des logiciels sans l'autorisation d'un responsable. Il n'existe pas de concept réglant la protection du périmètre; le réseau ne dispose pas de mesures de protection identifiables; les flux de données entrants et sortants ne sont ni enregistrés ni surveillés. Il n'existe pas de concept réglant l'octroi des accès à distance; il existe des comptes d'accès à distance dont personne ne connaissait jusqu'ici l'existence. L'infrastructure IT n'est pas protégée contre les incendies et il n'y a pas d'équipement d'extinction. Il existe une quantité importante de matériel inflammable dans les locaux de l'infrastructure IT ou dans les environs immédiats. L'entreprise ne dispose pas de mesures de protection contre les coupures d'électricité et les fluctuations de la tension. Il existe un concept informel réglant l'octroi d'autorisations administrateur. Certains utilisateurs enregistrés disposent d'autorisations administrateur à leurs places de travail, ce qui permet des installations de logiciels, des logiciels pouvant ainsi être installés sans l'autorisation d'un responsable. Il existe des mesures de sécurité fondamentales pour protéger les connexions entre le réseau interne et l'extérieur. Les flux de données entrants et sortants ne sont ni enregistrés ni surveillés. Il existe un concept informel réglant l'octroi des accès à distance; il n'est cependant pas systématiquement mis en œuvre. Les accès à distance à partir de réseaux extérieurs à l'infrastructure IT (p. ex. maintenance à distance, service de piquet) ne sont pas contrôlés en ce qui concerne leur fréquence, leur origine et leur nécessité. L'infrastructure IT n'est pas spécialement protégée contre les incendies et les équipements d'extinction sont sommaires. Il existe parfois une quantité importante de matériel inflammable dans les locaux de l'infrastructure IT ou dans les environs immédiats. L'entreprise dispose d'une protection contre les fluctuations de la tension pour les principales installations IT (p. ex. serveurs, centre de calcul), mais uniquement exceptionnellement d'une alimentation électrique sans coupure. Il existe un concept formel réglant l'octroi d'autorisations administrateur. Certains utilisateurs enregistrés disposent d'autorisations administrateur à leurs places de travail, ce qui permet des installations de logiciels sans l'autorisation d'un responsable. Les utilisateurs sont toutefois tenus d'obtenir une autorisation et de faire contrôler les logiciels avant leur installation. Toutes les connexions réseau entre le réseau interne et l'extérieur sont systématiquement protégées; les flux de données entrants et sortants sont enregistrés et surveillés en continu. Il existe un concept formel réglant l'octroi des accès à distance. Les accès à distance à partir de réseaux extérieurs à l'infrastructure IT (p. ex. maintenance à distance, service de piquet) sont parfois consignés, mais ils ne sont pas contrôlés systématiquement en ce qui concerne leur fréquence, leur origine et leur nécessité. L'infrastructure IT est protégée de manière insuffisante, malgré le respect des prescriptions anti-incendie en vigueur; les exigences IT spécifiques comme les équipements d'extinction spéciaux ou l'absence de matériel inflammable dans les environs immédiats ne sont que partiellement remplies. L'entreprise dispose d'une alimentation électrique sans coupure et d'une protection contre les fluctuations de la tension pour les principaux serveurs et installations. Pour les places de travail elles-mêmes, il n'y a pas d'alimentation électrique sans coupure. Il existe un concept formel réglant l'octroi des autorisations administrateur. Aucun utilisateur ne dispose d'autorisations administrateur à sa place de travail. Une installation de logiciel doit être autorisée par une demande formelle du service responsable. Le logiciel est installé aux places de travail concernées après un contrôle préalable par les spécialistes compétents et autorisés. Toutes les connexions réseau entre le réseau interne et l'extérieur sont protégées, et les connexions utilisateur sont surveillées. Les connexions réseau sont périodiquement contrôlées par des experts indépendants afin de détecter les faiblesses et les vulnérabilités. Il existe un concept formel réglant l'octroi des accès à distance. Les accès sont systématiquement consignés et évalués périodiquement. Les accès à distance sont régulièrement contrôlés, au moins une fois par an, par le service indépendant en ce qui concerne leur fréquence, leur origine et leur nécessité. L'infrastructure IT est protégée contre les incendies grâce à la mise en place de zones anti-feu, de sytèmes de détection d'incendies et d'installations d'extinction appropriées. Le matériel inflammable n'est conservé ni dans les locaux informatiques ni dans les environs immédiats. L'entreprise dispose pour toute l'infrastructure IT (y c. des principales places de travail) d'une alimentation électrique sans coupure pour éviter les dommages dus aux pannes d'électricité ou aux fluctuations de la tension. 37

40 Titre Niveau de maturité 1 Niveau de maturité 2 Niveau de maturité 3 Niveau de maturité 4 Constatation Evaluation Recommandation Sécurité physique Exploitation IT Possibilités d'accès aux locaux Tâches relatives aux applications Exploitation Gestion de la configuration Surveillance système Il est possible d'entrer dans les locaux et de s'y déplacer librement sans devoir s'annoncer à la réception. Les locaux informatiques ne sont ni fermés ni surveillés. En dehors des heures de travail, les locaux ne sont pas sécurisés par des dispositifs antivol. Les responsabilités liées à l'utilisation, à la maintenance et à l'exploitation des applications ne sont pas fixées par écrit. Il n'y a aucune séparation des pouvoirs aux niveaux technique et organisationnel Personne n'assume la fonction d'administrateur: le réseau et les systèmes ne sont ni surveillés ni entretenus. L'accès aux données de configuration des systèmes est de facto ni réglé par des procédures ni limité à des personnes autorisées. Il est possible d'entrer dans les locaux et de s'y déplacer librement sans devoir s'annoncer à la réception. Les locaux informatiques sont fermés, mais ils ne sont pas surveillés. En dehors des heures de travail, les locaux ne sont pas sécurisés par des dispositifs antivol. Les responsabilités liées à l'utilisation, à la maintenance et à l'exploitation des applications sont en principe connues des collaborateurs, mais pas documentées. La séparation des pouvoirs aux niveaux technique et organisationnel peut être contournée par les collaborateurs. Un administrateur a été désigné, mais il n'a pas d'autres fonctions liées à l'exploitation et ne peut ainsi pas toujours assurer la maintenance des systèmes ni les tâches de surveillance. Les procédures de modification de la configuration des systèmes sont informelles; les modifications de la configuration des systèmes ne sont pas enregistrées. Les composants système Il existe des procédures sont rarement surveillés et ils informelles pour la surveillance des systèmes; sont remplacés uniquement en cas de panne importante. une surveillance technique est parfois assurée et les composants système sont remplacés si besoin est (de manière réactive). L'entreprise dispose d'une réception, mais ni de sas ni de barrières d'accès pour le contrôle des accès à l'intérieur. Les visiteurs ne sont pas systématiquement accompagnés dans les zones internes, mais les locaux informatiques sont sécurisés par une protection des accès et les tentatives d'accès ou les accès effectifs sont clairement identifiables. Les responsabilités liées à l'utilisation, à la maintenance et à l'exploitation des applications sont fixées et documentées; la séparation technique des pouvoirs peut cependant être contournée par les collaborateurs. Un administrateur et/ou une équipe d'exploitation* responsable de la maintenance du réseau et des systèmes a été désigné(e). Une surveillance sporadique, mais pas quotidienne, est assurée. *en fonction de la taille de l'entreprise Tous les locaux sont surveillés, les accès sont consignés. Les visiteurs doivent s'annoncer à la réception et sont accompagnés pendant toute la durée de leur présence dans les locaux de l'entreprise. Les locaux informatiques sont sécurisés, l'accès aux personnes étrangères à l'entreprise (visiteurs, techniciens de maintenance, etc.) doit être demandé explicitement. Les personnes étrangères à l'entreprise sont surveillées en continu dans les zones de sécurité. Les responsabilités liées à l'utilisation, à la maintenance et à l'exploitation des applications sont fixées et documentées formellement. La séparation technique des pouvoirs fait l'objet de contrôles réguliers concernant le respect des exigences. Un administrateur et/ou une équipe d'exploitation a été désigné(e). Il/elle est responsable des tâches de maintenance et de surveillance quotidiennes et systématiques du réseau et des systèmes. *en fonction de la taille de l'entreprise Les procédures de modification de la configuration des formelle pour les modifi- Il existe une procédure systèmes sont documentées et largement connues des systèmes; toutes les cations de la configuration et l'accès est limité aux modifications sont vérifiées personnes autorisées. Le avant leur mise en œuvre respect des procédures n'est et documentées durablement. Les modifications de cependant contrôlé qu'au cas par cas. la configuration effectuées sont automatiquement reconnues, rapportées et leur conformité avec une demande de modification correspondante est contrôlée. Il existe des procédures Il existe des procédures formelles pour la surveillance formelles pour la surveillance des systèmes; une surveillance technique est assurée en œuvre de manière sys- des systèmes qui sont mises et les composants système tématique. La performance sont remplacés selon un des principaux composants plan prédéfini. Les données système est enregistrée en pertinentes sont en partie permanence et contrôlée consignées et évaluées; des régulièrement par les sondages sont parfois réalisés auprès des utilisateurs. la surveillance des systèmes responsables IT chargés de (pannes, défaillances, temps de réaction, etc.). Des sondages sont réalisés auprès des utilisateurs en cas de besoin. 38

41 «Guide d analyse des risques informatiques» Titre Niveau de maturité 1 Niveau de maturité 2 Niveau de maturité 3 Niveau de maturité 4 Constatation Evaluation Recommandation Exploitation IT Gestion des problèmes Utilisation d'outils Surveillance réseau Contrôle de fonctionnement du système Traitement des erreurs Helpdesk Disponibilité système Des outils sont rarement Certains outils sont utilisés utilisés pour l'exploitation IT. pour l'exploitation IT. Leur utilisation est cependant essentiellement réactive et isolée. Le réseau est peu surveillé et il n'existe pas de responsabilité claire concernant la surveillance du réseau. Il n'y a pas de contrôle de la performance système au sein de l'entreprise. Il n'existe pas de procédure concernant le traitement des pannes et erreurs. Il n'y a pas de helpdesk. Les utilisateurs s'adressent directement aux collaborateurs IT et annoncent leurs problèmes de manière informelle. Les pannes système ne sont ni surveillées ni documentées. Des outils sont utilisés pour l'exploitation IT; leur utilisation est cependant rarement coordonnée et est essentiellement réactive. Il existe des procédures informelles pour le contrôle de la performance système effective. Les observations ne sont pas consignées. Il existe peu de procédures formelles concernant le traitement des pannes et erreurs. Les erreurs ne sont pas systématiquement enregistrées et sont peu traçables. Des rapports sont établis sur les problèmes. Il y a un helpdesk, mais pour différentes raisons (ressources, savoir-faire, etc.), celui-ci n'est pas en mesure de répondre à toutes les demandes des collaborateurs. Des contacts informels entre les utilisateurs et IT servent d'alternative au helpdesk. Certaines statistiques Les statistiques concer- concernant les connexions et les erreurs liées au réseau et aux composants réseau sont disponibles, mais elles ne sont pas systématiquement analysées. nant les connexions et les erreurs liées au réseau et aux composants réseau sont consignées systématiquement, mais elles sont plutôt analysées selon la situation (p. ex. après un incident). Des outils reposant sur un concept clair sont utilisés pour l'exploitation IT. Les différents outils sont clairement coordonnés; leur utilisation est planifiée selon des directives claires. Les statistiques concernant les connexions et les erreurs liées au réseau et aux composants réseau sont consignées systématiquement et de manière exhaustive selon un concept clair; elles sont contrôlées régulièrement et les incidents survenus font l'objet d'un examen systématique. Il existe des procédures Il existe des procédures formelles pour le contrôle formelles pour le contrôle de la performance système de la performance système effective; l'enregistrement effective; les pannes, défaillances et temps de réaction est automatique. Une évaluation n'est effectuée qu'au des applications sont cas par cas. automatiquement reconnus et clarifiés en conséquence. Un résumé des erreurs et des mesures de résolution mises en œuvre est disponible. Les procédures concernant les pannes et erreurs sont largement réglées pour la plupart des systèmes; le respect des procédures n'est cependant contrôlé qu'au cas par cas. Les pannes sont enregistrées, mais évaluées au cas par cas uniquement. Un helpdesk spécial pour les utilisateurs est disponible pendant les heures de travail et est en mesure de répondre aux demandes des collaborateurs. Les contacts informels entre les utilisateurs et IT sont transmis au helpdesk. Il existe des procédures formelles pour le traitement des pannes et erreurs. Les incidents sont entièrement compréhensibles et systématiquement clarifiés. Les rapports d'erreur sont systématiquement archivés. Un helpdesk spécial pour les utilisateurs est disponible pendant les heures de travail et est en mesure, au plan tant quantitatif que qualitatif, de répondre aux demandes des collaborateurs. Les demandes, les problèmes identifiés et les solutions mises en œuvre sont systématiquement enregistrés dans un système en vue d'une amélioration proactive. Les exigences en termes de disponibilité sont uniquement contrôlées en cas d'incident affectant la Il existe un concept de maintien de la disponibilité; il n'est cependant pas entièrement mis en œuvre. Il existe des procédures formelles de maintien de la disponibilité qui sont entièrement mises en œuvre. La sécurité. Les pannes système La disponibilité des systèmes disponibilité des systèmes sont en partie documentées. importants est automatiquement enregistrée. Les pannes système sont systématiquement documentées est automatiquement enregistrée et périodiquement analysée. Les causes des pannes sont systématique- et leurs causes sont ment clarifiées, des mesures généralement analysées. correctives sont mises en œuvre de manière proactive. 39

42 Titre Niveau de maturité 1 Niveau de maturité 2 Niveau de maturité 3 Niveau de maturité 4 Constatation Evaluation Recommandation Sauvegarde des données Concept de sauvegarde Processus de sauvegarde Test de restauration Il n'existe pas de concept de sauvegarde des données. Aucune sauvegarde des données n'est effectuée. Aucun test de restauration des sauvegardes n'est effectué. Plan d'urgence IT Aucune réflexion n'a été engagée concernant un plan d'urgence IT. Transfert de données Les sauvegardes de données ne sont pas conservées en dehors de l'entreprise. Il existe un concept informel de sauvegarde des données, mais il n'est cependant pas fixé par écrit. Aucune sauvegarde régulière des données n'est effectuée et les sauvegardes ne sont pas contrôlées. Des tests informels, mais pas systématiques, de restauration des sauvegardes sont effectués (p. ex. à l'initiative des services spécialisés). Des réflexions ont été engagées concernant la détermination des principales données et des éléments du système d'information sans lesquels l'entreprise ne peut pas poursuivre son activité. Un plan de reprise de l'activité en cas de dommage n'a pas été établi. Les sauvegardes de données sont mises en lieu sûr, mais le processus n'est ni réglé ni documenté. L'accès aux données de sauvegarde n'est pas assuré à tout moment pour l'entreprise (p. ex. en cas de mise en lieu sûr dans les armoires d'un collaborateur). Il existe un concept de sauvegarde des données fixé par écrit qui règle clairement quelles données sont enregistrées à quel moment et dans quelle mesure, ainsi que le nombre de générations; le lieu et la durée de conservation sont en partie spécifiés. Le respect du concept n'est pas contrôlé régulièrement. Des sauvegardes quotidiennes (ou plus fréquentes) sont effectuées conformément au concept de sauvegarde des données. Les sauvegardes sont consignées, mais les journaux ne sont contrôlés qu'au cas par cas. Des tests de restauration des données sont effectués périodiquement; leurs résultats sont contrôlés au cas par cas. Des réflexions ont été engagées concernant la détermination des principales données et des éléments du système d'information sans lesquels l'entreprise ne peut pas poursuivre son activité. Un plan de reprise de l'activité en cas de dommage a été établi, mais aucune mesure concrète n'a encore été prise aux niveaux technique et du personnel. Il existe un concept fixé par écrit pour la mise en lieu sûr des sauvegardes de données qui est entièrement mis en œuvre. La mise en lieu sûr est consignée, mais le journal n'est contrôlé qu'au cas par cas. L'accès aux données de sauvegarde dans le laps de temps défini n'est cependant pas toujours assuré au sein du laps de temps défini (p. ex. en cas de mise en lieu sûr dans les armoires d'un collaborateur). Il existe un concept de sauvegarde des données fixé par écrit qui règle clairement quelles données sont enregistrées à quel moment et dans quelle mesure, ainsi que le nombre de générations. Le respect du concept est contrôlé régulièrement. Des sauvegardes quotidiennes (ou plus fréquentes) sont effectuées conformément au concept de sauvegarde des données. Les sauvegardes sont consignées et les journaux sont contrôlés pour chacune d'elle. Des tests systématiques de restauration des sauvegardes de toutes les applications clés sont effectués régulièrement (au moins une fois par mois); les résultats sont consignés et systématiquement contrôlés. Des mesures ont été prises pour la mise en œuvre du plan d'urgence (p. ex. mise à disposition d'un lieu de remplacement pour les cas d'urgence et le stockage du matériel de remplacement en cas de panne). Un plan précisant les rôles des personnes concernées et les systèmes à restaurer en priorité a été formalisé pour la reprise de l'activité. Le plan est testé régulièrement et prêt à être mis en œuvre. Il existe un concept fixé par écrit pour la mise en lieu sûr des sauvegardes de données qui est entièrement mis en œuvre. La mise en lieu sûr est consignée, et le journal est contrôlé systématiquement. L'accès aux données de sauvegarde dans le laps de temps défini est assuré et documenté à tout moment pour l'entreprise grâce à des processus spécifiques. 40

43 «Guide d analyse des risques informatiques» Titre Niveau de maturité 1 Niveau de maturité 2 Niveau de maturité 3 Niveau de maturité 4 Constatation Evaluation Recommandation Externalisation Contrats d'externalisation Procédure de sélection des partenaires d'externalisation Dépendance / perte de savoir-faire Possibilité de contrôle auprès du partenaire d'externalisation Il n'existe pas de contrats d'externalisation avec les prestataires externes. L'entreprise ne dispose pas de procédure de sélection des partenaires d'externalisation qui garantit la prise en compte de critères de sélection essentiels. Aucune spécification ne précise quelles activités de l'entreprise (non critiques, critiques, stratégiques) peuvent ou ne peuvent pas être confiées à un prestataire externe. Il n'y a pas de responsable de la coordination avec le prestataire. Les prestations des prestataires externes se basent sur les contrats standard des prestataires et ne contiennent que des indications vagues ou insuffisantes sur la qualité, la sécurité et la disponibilité de la prestation. Les modalités de résiliation du contrat sont inexistantes. L'entreprise dispose de procédures de sélection informelles. Les critères de sélection sont toutefois incomplets, des exigences spécifiques au projet font défaut. Des appels d'offre ne sont pas systématiquement lancés pour tous les projets d'externalisation. Des réflexions informelles sont engagées quant aux activités de l'entreprise (non critiques, critiques, stratégiques) qui peuvent ou ne peuvent pas être confiées à un prestataire externe. Les activités externalisées sont en partie documentées par écrit. Il n'existe aucune possibilité de contrôle auprès du mesures de sécurité sont Les prestations et les prestataire d'externalisation. décrites uniquement dans Les mesures de sécurité au niveau du partenaire d'externalisation ne sont pas connues. la documentation du prestataire externe. Les mesures de contrôle des prestations et de respect des exigences de sécurité ne sont pas définies formellement dans les contrats. Les prestations des prestataires externes se basent sur des contrats écrits décrivant les prestations convenues. La qualité, la sécurité et la disponibilité ne sont cependant pas réglées de manière exhaustive. Il existe des procédures informelles concernant la surveillance de la prestation et son amélioration en cas de non-respect des contrats. Les modalités de résiliation du contrat sont décrites sommairement. L'entreprise dispose d'une procédure de sélection formalisée pour les partenaires d'externalisation qui est largement appliquée. Les critères de sélection essentiels (y c. solvabilité et efficacité) sont présents, mais ils ne sont pas obligatoirement évalués systématiquement. Il existe des prescriptions formelles quant aux activités de l'entreprise pouvant ou ne pouvant pas être externalisées. Concernant les activités ayant une importance stratégique, les prestations externalisées sont systématiquement documentées; seule une surveillance au cas par cas est assurée. La documentation favorise un changement de fournisseur potentiel en cas de problèmes. Les prestations des prestataires externes se basent sur des Service Level Agreements et des contrats clairs qui garantissent la qualité des prestations, la disponibilité et la sécurité. Le respect du contrat est surveillé en continu. En cas d'écart, des mesures ciblées sont prises; les modalités de résiliation du contrat sont clairement fixées. L'entreprise dispose d'une procédure de sélection formalisée pour les partenaires d'externalisation. La procédure de sélection tient compte de tous les critères de sélection essentiels (p. ex. références, taille de l'entreprise, connaissances spéciales, exigences spécifiques au projet, solvabilité) et est soumise à un processus d'autorisation formalisé qui intègre tous les services concernés de l'entreprise. En principe, des appels d'offre sont toujours lancés. Il existe des prescriptions formelles garantissant que seules les activités définies précisément, formalisées et documentées sont confiées à des partenaires externes. Concernant les activités ayant une importance stratégique, les prestations externalisées sont systématiquement documentées et surveillées périodiquement. Les fournisseurs de remplacement ou secondaires potentiels sont régulièrement évalués; la documentation permet un changement de fournisseur en cas de problèmes. Les prestations et les Les prestations et les exigences de sécurité devant exigences de sécurité être remplies par le prestataire sont fixées par écrit. Les mesures de contrôle des prestations et le respect des exigences de sécurité sont formellement définies dans les contrats; leur respect n'est cependant pas contrôlé concrètement. Le prestataire externe est contrôlé régulièrement par une instance indépendante; le rapport de contrôle est remis au client. devant être remplies par les prestataires sont fixées par écrit de manière détaillée; les mesures de contrôle des prestations et de respect des exigences de sécurité sont définies formellement dans les contrats et mises en œuvre. Le prestataire externe est contrôlé régulièrement par une instance indépendante en ce qui concerne les objectifs fixés dans les contrats; le rapport de contrôle est remis au client. Il a le droit d'effectuer des contrôles supplémentaires auprès du prestataire (Right to Audit). 41

44 Titre Niveau de maturité 1 Niveau de maturité 2 Niveau de maturité 3 Niveau de maturité 4 Constatation Evaluation Recommandation Externalisation Comptabilité Contrôles d application directs Surveillance des activités de support Archivage Comptes annuels (préparation) Comptes annuels (exécution) Saisie des données (documentation) Saisie des données (clarté) Les interventions des prestataires externes en matière de prestataires externes en Les interventions des maintenance et de support ne sont pas surveillées; le résultat de leurs interventions n'est pas comparé avec le résultat attendu. Il n'existe pas d'archivage à proprement parler. Les travaux de préparation, les étapes du traitement et les contrôles devant être effectués avant la clôture de l'exercice ne sont pas documentés. Les étapes et les contrôles du traitement de la clôture de l'exercice ne sont pas documentés. L'origine (origination) et la saisie ad hoc des données ne sont pas documentées. Les opérations/transactions ne sont pas consignées dans des journaux. matière de maintenance et de support sont consignées sporadiquement; le résultat de leurs interventions n'est cependant pas comparé avec le résultat attendu. Il n'existe pas de concept d'archivage. Les supports (également électroniques) et les locaux utilisés pour l'archivage ainsi que l'archivage proprement dit ne correspondent pas aux exigences légales (p. ex. Olico, OeIDI). Certains travaux de préparation, certaines étapes du traitement et certains contrôles devant être effectués avant la clôture de l'exercice ne sont documentés que de manière sommaire. Les étapes et les contrôles du traitement de la clôture de l'exercice sont insuffisamment documentés. Les processus liés à l'origine (origination) et à la saisie des données ne sont pas documentés ou le sont de manière insuffisante. Les opérations et transactions saisies manuellement et générées par le système ne sont que partiellement consignées dans des journaux. Les interventions des prestataires externes en matière de maintenance et de support sont consignées systématiquement, le résultat de leurs interventions est comparé au cas par cas avec le résultat attendu. Les prestataires externes sont en contact régulier avec le responsable IT. Les interventions des prestataires externes en matière de maintenance et de support sont consignées systématiquement; le résultat de leurs interventions et les progrès réalisés sont comparés régulièrement avec le résultat attendu concernant les applications essentielles en termes de sécurité, les activités des prestataires externes sont surveillées très étroitement. Il existe un concept Le concept d'archivage est d'archivage, mais il n'est pas fixé par écrit. Le concept, entièrement fixé par écrit. Il les supports (également n'est pas clair si le concept, électroniques) et les locaux les supports (également utilisé pour l'archivage électroniques) et les locaux et l'archivage lui-même utilisés pour l'archivage tout répondent aux exigences comme l'archivage lui-même légales (p. ex. Olico, OeIDI). répondent aux exigences L'intégralité et l'exactitude légales (p. ex. Olico, OeIDI). de l'archivage sont régulièrement contrôlées. Il n'y a pas de contrôle régulier de l'archivage. Tous les travaux de préparation, les étapes du traitement et les contrôles devant être effectués avant la clôture de l'exercice sont documentés; il n'y a pas de surveillance étroite. Les étapes et les contrôles du traitement de la clôture de l'exercice sont documentés. Ils ne sont cependant pas totalement fixés clairement et il n'y a pas de surveillance étroite. Tous les travaux de préparation, les étapes du traitement et les contrôles devant être effectués avant la clôture de l'exercice sont documentés. Leur respect est strictement surveillé et contrôlé. Les étapes et les contrôles du traitement de la clôture de l'exercice sont documentés entièrement et clairement; leur respect est strictement surveillé et contrôlé. Les processus liés à l'origine Tous les processus liés à (origination) et à la saisie des l'origine (origination) et à données sont entièrement la saisie des données sont documentés. Il n'y a pas de entièrement documentés; les contrôle régulier de la mise processus de modification à jour de cette documentation. obligatoirement la mise et de projet comprennent à jour de cette documentation. L'exactitude de la documentation est vérifiée régulièrement. Les opérations/transactions saisies manuellement et générées par le système sont consignées entièrement et clairement dans des journaux; il n'y a pas de contrôle régulier des enregistrements. Les opérations/transactions saisies manuellement et générées par le système sont consignées entièrement dans des journaux; leur intégralité, leur exactitude et leur mise à jour sont périodiquement contrôlées. 42

45 «Guide d analyse des risques informatiques» Titre Niveau de maturité 1 Niveau de maturité 2 Niveau de maturité 3 Niveau de maturité 4 Constatation Evaluation Recommandation Contrôles d application directs Traitement des données (intégralité) Données produites (transparence) Les opérations saisies ou traitées ne sont pas enregistrées. Les évaluations ne donnent pas d'indications quant aux données et aux critères de sélection utilisés. Toutes les opérations saisies ou traitées ne sont pas enregistrées chronologiquement. Les évaluations donnent parfois des indications sur les données. Toutes les opérations saisies ou traitées (journal) sont enregistrées chronologiquement. Les évaluations donnent des indications claires sur les données sous-jacentes, mais pas sur les critères de sélection utilisés. Toutes les opérations saisies ou traitées (journal) sont enregistrées chronologiquement. Les journaux sont clairement identifiables et numérotés; leur intégralité et leur exactitude sont régulièrement contrôlées. Les évaluations donnent des indications claires sur les données sous-jacentes et sur les critères de sélection utilisés. Contrôles d'application secondaires Documentation des systèmes Surveillance des interfaces Mise à jour des données de base Accès directs aux bases de données Les principales fonctions des applications financières, les flux de données et de valeurs ainsi que les interfaces avec les applications en amont et en aval ne sont pas documentés. Il n'y a pas de surveillance ni pour les interfaces automatisées ni pour les interfaces manuelles. L'accès aux fonctions de mise à jour des données de base n'est de facto ni réglé par des procédures ni limité à des personnes autorisées. Il n'existe pas de procédure pour l'accès direct aux bases de données. L'installation et l'utilisation de supports permettant un accès direct et la manipulation du contenu des bases de données est possible de manière quasiment illimitée. Les principales fonctions des applications financières, les flux de données et de valeurs ainsi que les interfaces avec les applications en amont et en aval sont insuffisamment documentés. Les rapports d'erreur des applications financières générés par la surveillance des interfaces manuelles et automatisées ne sont pas examinés en détail et ne sont pas conservés. Les procédures de mise à jour des données de base sont informelles; l'accès aux données de base n'est pas spécialement limité aux personnes autorisées. Les procédures pour l'accès direct aux bases de données ainsi que l'installation et l'utilisation des supports permettant un accès direct et la manipulation du contenu des bases de données (outils, SQL, etc.) sont informelles. L'utilisation de ces outils n'est pas spécialement limitée. Pour la plupart des applications financières, les principales fonctions, les flux de données et de valeurs ainsi que les interfaces avec les applications en amont et en aval sont documentés; leur intégralité et leur mise à jour ne peuvent cependant pas être toujours garanties. Pour la plupart des applications financières, les rapports d'erreur générés par la surveillance des interfaces manuelles et automatisées ne sont pas examinés en détail, mais uniquement conservés Pour toutes les applications financières, les principales fonctions, les flux de données et de valeurs ainsi que les interfaces avec les applications en amont et en aval sont intégralement documentés et à jour; les processus de modification et de projet comprennent la mise à jour obligatoire de la documentation. Pour toutes les applications financières, les rapports d'erreur générés par la surveillance des interfaces manuelles et automatisées sont analysés rapidement. Le processus de correction des erreurs est documenté, les erreurs sont corrigées rapidement et clairement. Les procédures de mise à Il existe des procédures jour des données de base fixées par écrit pour la mise sont documentées et largement connues et l'accès aux L'accès aux données de à jour des données de base. données de base est limité base est strictement limité aux personnes autorisées. Le à quelques personnes d'un respect des procédures n'est point de vue tant organisationnel que technique. cependant contrôlé qu'au cas par cas. Le respect des procédures est surveillé en continu et contrôlé périodiquement. Les procédures pour l'accès direct aux bases de données, p. ex. via l'utilisation de supports spécifiques sont suffisamment documentées. L'installation et l'utilisation de programmes permettant un accès direct et la manipulation du contenu des bases de données sont limitées à quelques personnes autorisées. Les propriétaires des données ne sont impliqués qu'au cas par cas dans les accès directs; il existe rarement une surveillance étroite. Il existe une procédure formelle et documentée pour les accès directs aux bases de données, p. ex. via l'utilisation de programmes d'aide spécifiques. Les accès directs sont consignés sans faille et des procèsverbaux sont conservés. Le propriétaire des données doit approuver et surveiller étroitement chaque utilisation de ce type. 43

46 Titre Niveau de maturité 1 Niveau de maturité 2 Niveau de maturité 3 Niveau de maturité 4 Constatation Evaluation Recommandation Contrôles d'application secondaires Données de pilotage (paramètres) L'accès aux données de pilotage et de configuration n'est de facto ni réglé par des procédures ni limité à des personnes autorisées. Les procédures relatives à la mise à jour des données de pilotage et de configuration sont informelles; l'accès n'est pas spécialement limité aux personnes autorisées. Les procédures relatives à la mise à jour des données de pilotage et de configuration sont documentées et largement connues et l'accès à ces données est limité aux personnes autorisées. Le respect des procédures n'est cependant contrôlé qu'au cas par cas. Il existe une procédure formelle de demande, d'autorisation et de validation pour toutes les modifications des données de pilotage et de configuration. La mise à jour de ces données s'effectue uniquement par les personnes autorisées disposant des connaissances voulues et est documentée de manière compréhensible par des enregistrements. Le respect des procédures est surveillé en continu et contrôlé périodiquement. 44

47

48