L'Audit Informatique

ni exhaustif ni figé. Il n’apporte pas tout à tout le monde et doit être adapté à des environnements particuliers.

Quatre choses toutefois que le Guide n’est pas :

1. Le Guide d’Audit n’est pas conçu pour élaborer un plan d’audit ou de couverture générale qui prend en compte un ensemble de facteurs intégrant les anciennes faiblesses, les risques de l’entreprise, les incidents répertoriés, les nouveaux développements et les choix stratégiques. Si le Cadre de Référence et les Objectifs de Contrôle fournissent une orientation, le modèle correspondant parfaitement à l’activité est en dehors du périmètre du Guide d’Audit.

2. Le Guide d’Audit n’est pas conçu comme un outil d’apprentissage des bases de l’audit quand bien même il intègre les bases généralement reconnues de l’audit et de l’audit informatique. Le Guide d’Audit n’essaye pas d’expliquer de façon détaillée comment des outils de planification, d’évaluation, d’analyse et de documentation informatiques (qui incluent sans aller au-delà les Techniques d’Audit Assisté par Ordinateur) peuvent être employés pour aider et automatiser l’audit des processus informatiques. L’informatique offre un énorme potentiel pour accroître l’efficacité et l’efficience des audits mais ce type de guide ne fait pas non plus partie du périmètre du Guide d’Audit.

3. Le Guide d’Audit n’est ni exhaustif ni figé mais évoluera avec les Objectifs de Contrôle de COBIT.

4. Le Guide d’Audit de COBIT permet à l’auditeur de rapprocher la revue de processus informatiques spécifiques de celle recommandée dans les Objectifs de Contrôle pour rassurer le management lorsque les contrôles sont suffisants ou pour le conseiller lorsque les processus doivent être améliorés.

D’un point de vue management, les propriétaires de processus peuvent se poser les questions : « Ce que je fais est-il parfait ? Et si non, comment l’améliorer ? » Le Cadre de Référence et les Objectifs de Contrôle de COBIT aideront à apporter une réponse à ces questions. L’approche fournit un point de vue « réactif » mais les auditeurs doivent également aider le management de façon « proactive ».

Le Cadre de Référence et le Guide d’Audit sont aussi utilisables de manière proactive lors des premières étapes des processus et projets de développement - pour répondre à la question : « De quoi ai-je besoin pour que cela fonctionne ? ».

STRUCTURE GÉNÉRALE DU GUIDE D’AUDIT

Le modèle le plus répandu d’évaluation du contrôle est le modèle d’audit. Le modèle d’analyse des risques est une autre approche qui se développe et sur lequel on reviendra à la fin de cette introduction. Ceux qui sont en charge de l’évaluation du contrôle peuvent utiliser l’un ou l’autre modèle.

Les objectifs de l’audit sont de :

• donner au management une assurance raisonnable que les objectifs de contrôle sont atteints,

• évaluer les risques résultant des faiblesses de contrôle,

• et de conseiller le management sur les actions correctives.

La structure d’audit d’un processus généralement admise est :

• identification et documentation,

• évaluation,

• tests de conformité,

• tests détaillés.

Un processus informatique est donc audité ainsi :

• Acquérir une bonne compréhension des exigences de gestion en termes de risques et de dispositifs de contrôle

• Évaluer si les contrôles sont appropriés

• Évaluer la conformité des contrôles en place par des tests pour déterminer s’ils fonctionnent comme prévu, de façon cohérente et continue

• Évaluer le risque de ne pas atteindre les objectifs de contrôle à l’aide de techniques d’analyse et/ou en consultant d’autres sources.

Dans le but de fournir une aide au management sous la forme de conseils d'assurance, nous avons constitué un cadre de référence d'audit construit à partir des exigences de COBIT :

• présenté par niveaux

• orienté objectifs de gestion

• orienté processus

• centré sur les ressources à gérer

• les critères d'information requis.

Au premier niveau cette approche générale de l'audit s'appuie sur :

• le Cadre de Référence COBIT, particulièrement le tableau récapitulatif qui contient la classification des processus informatiques, les critères d'information applicables, et les ressources des TI (voir page 30)

• les besoins du processus d'audit lui-même (voir section Besoins du Processus d'Audit page 24)

• les besoins génériques pour l'audit des processus informatiques (voir la section Guide Générique d'Audit Informatique, page 24)

• principes généraux de contrôle (voir la section Observations sur le Processus de Contrôle, pages 24-25)

Le second niveau est constitué des principes détaillés d'audit pour chaque processus informatiques décrit dans le corps principal de ce fascicule.

Les principes ont été présentées selon un modèle standard qui adopte la structure commune suivante : Obtenir, Évaluer, Vérifier et Confirmer. Ce modèle a été appliqué au Guide d'Audit générique aussi bien qu'au Guide d'Audit détaillé.

Au niveau le plus détaillé, le troisième, l'auditeur peut enrichir le Guide d'Audit pour l'adapter aux circonstances spécifiques, conduisant ainsi la phase de planification de l'audit à prendre en compte des points d'audits particuliers et influençant les objectifs de contrôle détaillés au moyen de :

• critères spécifiques au secteur

• standards de la branche professionnelle

• éléments spécifiques à la plate-forme informatique

• techniques de contrôle détaillés employée.

Il est important à ce niveau de comprendre que les objectifs de contrôle ne s'appliquent pas nécessairement partout et tout le temps. Nous suggérons donc qu'une évaluation générale du risque soit conduite de façon à déterminer sur quels objectifs il faut se concentrer, et quels sont ceux qui peuvent être laissés de côté.

Tous ces éléments sont proposés pour assister la planification et la performance des audits des TI, et pour permettre une application mieux intégrée du guide d’audit détaillé.

Ce guide n'est ni exhaustif ni universellement applicable. L'information de premier niveau (guide générique, les besoins du processus d'audit, et les observations des contrôles) aideront les auditeurs à constituer le programme d'audit dont ils ont besoin.

STRUCTURE DÉTAILLÉE DE MISE EN PRATIQUE DU GUIDE D'AUDIT

[pic]

BESOINS DU PROCESSUS D'AUDIT

Ayant défini ce que nous allons auditer et ce à quoi nous allons donner une assurance, nous devons déterminer l'approche la plus appropriée, ou notre stratégie pour mener à bien notre travail d'audit. Nous devons d'abord déterminer le bon périmètre de l'audit. Dans ce but nous devons investiguer, analyser et définir :

• les processus de gestion concernés

• les plates-formes et les systèmes d'information sur lesquels s'appuient les processus de gestion, ainsi que leur interconnexion avec les autres plates-formes et les autres systèmes

• les rôles et les responsabilités au sein des TI, en distinguant les ressources internes et externes

• les risques liés aux choix stratégiques de l'entreprise.

L'étape suivante consiste à identifier les besoins en information qui concernent particulièrement les processus de gestion. Puis il faudra identifier les risques inhérents aux TI de même que les niveaux généraux de contrôle qui peuvent être associés aux processus de gestion. Dans ce but nous identifions :

• les changements récents dans l'environnement professionnel qui ont un impact sur les TI

• les changements récents dans l'environnement informatique, les nouveaux développements, etc

• les incidents récents en rapport avec les contrôles et l'environnement professionnel

• les contrôles de surveillance des TI