Management de laudit

des systmes dinformation

2me dition

Janvier 2013
Copyright 2013 par lInstitute of Internal Auditors, 247 Maitland Ave., Altamonte Springs, Floride, 32701-4201,
tats-Unis. Tous droits rservs. Imprim aux tats-Unis. Aucune partie de cette publication ne peut tre reproduite,
stocke dans un systme de consultation ou transmise sous quelque forme que ce soit, ni par aucun moyen (lectronique, mcanique, reprographie, enregistrement ou autre) sans autorisation crite pralable de lditeur.
LIIA publie ce document titre informatif et pdagogique. Cette publication entend donner des informations, mais
ne se substitue en aucun cas un conseil juridique ou comptable. LIIA ne fournit pas ce type de service et ne garantit,
par la publication de ce document, aucun rsultat juridique ou comptable. En cas de problmes juridiques ou comptables, il convient de recourir lassistance de professionnels.

Contenu

Rsum ............................................................................................................................................................. 4
1.

Introduction ........................................................................................................................................... 5

2.

Stratgie mtier , processus et projets ............................................................................................ 7

3.

Infrastructure et processus SI ............................................................................................................... 8

4.

Approche fonde sur les risques ........................................................................................................ 12

5.

Univers d'audit .................................................................................................................................... 13

6.

Savoir-faire et comptences ............................................................................................................... 14

7.

Raliser des missions d'audit des SI .................................................................................................. 15

8.

Rapports ............................................................................................................................................... 17

9.

Outils d'audit ....................................................................................................................................... 18

10.

Conclusion ........................................................................................................................................... 20

Annexe A : Normes de rfrence ................................................................................................................. 21

Annexe B : Modles d'architecture des SI ................................................................................................... 22
Auteurs et relecteurs ..................................................................................................................................... 23

Rsum
les ressources de laudit des SI pourront se
recentrer sur les domaines qui prsentent le
plus de valeur ajoute pour lorganisation.

Rsum
Les systmes dinformation (SI) ont une influence
omniprsente sur l'audit interne. Lmergence de
nouveaux risques implique de repenser les procdures pour grer ces risques de faon adquate. Le
processus d'audit des SI nest globalement pas diffrent de celui dautres travaux d'audit : lauditeur
planifie la mission, identifie et documente les
contrles pertinents, vrifie lefficacit de la
conception et du fonctionnement de ces contrles,
en tire les conclusions et rdige son rapport. Les
responsables de l'audit interne (RAI) rendent
rgulirement compte des conclusions des missions d'audit des SI aux principales parties prenantes telles que le Conseil, la direction gnrale,
le directeur des systmes d'information, les rgulateurs et les auditeurs externes. Ce guide a pour
objectif d'aider les RAI planifier et grer les travaux d'audit avec une efficacit et une efficience
accrues en analysant comment :

Raliser des travaux d'audit des SI. Du fait

de la prolifration et de la complexit des SI, il
devient indispensable de disposer de procdures d'audit des SI appropries, qui peuvent
tre intgres aux audits de routine des oprations et des processus afin de grer les risques
spcifiques identifis durant la phase de planification. Laudit effectu daprs des listes de
vrification ou sur la base dune enqute est
insuffisant.
En outre, le guide donne au RAI des indications
sur l'ventail de comptences que les auditeurs
des SI devraient possder pour apporter des
connaissances et une expertise suffisantes la
fonction d'audit, ainsi que des outils pour aider
l'auditeur effectuer les tests lis aux SI et pour
rpondre des attentes spcifiques concernant les
rapports. Ce guide a pour objectif de donner des
informations pragmatiques et claires, ainsi que des
recommandations spcifiques qu'un RAI peut
mettre en uvre immdiatement. Ce guide veille
fournir des critres quun RAI peut utiliser pour
valuer la maturit des capacits en audit des SI et
s'assurer que les travaux de l'quipe d'audit
interne correspondent un haut niveau dexigence.

Dterminer les domaines ncessitant des

ressources en audit des SI. Quelles sont les
missions qui ncessiteront l'intervention de
spcialistes en audit des SI ? A la lumire des
lignes directrices exposes dans ce document,
le RAI devrait tre mme de planifier le
recours des auditeurs des SI pour une couverture adquate de primtre auditer. Les
ressources en audit des SI sont gnralement
rares, alors que la demande est forte. Dfinir
les besoins en audit des SI permet au RAI dassurer la ralisation des missions planifies
dans ce domaine. Quelle que soit la taille des
quipes d'audit interne, il reste primordial de
disposer des comptences adquates pour les
travaux d'audit spcifiques. Celles-ci peuvent
exister en interne ou tre recherches en
externe, selon les capacits de l'organisation.
valuer les risques lis aux SI. Les risques
lis aux SI voluent continuellement de
concert avec la technologie. Certains sont lis
la technologie elle-mme et d'autres la
manire dont elle est utilise. Ce guide aide le
RAI comprendre comment identifier et valuer au mieux les risques relatifs aux SI. Ainsi,
4

GTAG Introduction
comme facilitateur pour les mtiers modifiera
les risques stratgiques d'une organisation.
Celle-ci doit comprendre ce changement et
prendre les mesures appropries pour grer
ces risques.

1. Introduction
Les risques auxquels est confronte lorganisation,
les types daudits effectuer, les modalits de priorisation dans lunivers daudit et la manire de formuler des constats pertinents sont autant de
proccupations des RAI. Ce guide pratique daudit
des technologies de linformation (GTAG) est destin aux RAI et aux personnes charges de la
supervision des missions daudit des SI et des tests
des SI intgrs dans d'autres missions.

Le dveloppement des contrles gnraux des

SI et des contrles applicatifs devrait grer
convenablement les risques relatifs aux SI. Les
contrles des SI doivent protger efficacement
les activits d'une organisation et garantir que
sa comptitivit n'est pas affecte ; les systmes dfectueux risquent de nuire fortement
la rputation. Par exemple : considrons le
processus automatis dcrit ci-dessus, dans
lequel le bon de commande arriverait via un
site Internet et serait transmis directement
lentrept par le progiciel ERP. Si un client
commande par erreur 100 palettes au lieu de
100 units et que lorganisation a entirement
intgr ses processus dans lERP ; il est possible que le systme vrifie le stock, constate
quil ny a pas 100 palettes disponibles, rvise
le plan de production afin de produire 100
palettes et envoie automatiquement des bons
de commande pour des matires premires via
lchange de donnes informatises (Electronic
Data Interchange, EDI). Sans les contrles prventifs ad hoc, cette erreur risquerait de ne pas
tre dtecte avant la rception des biens par
le client.

Il a pour vocation de les aider rpondre aux

questions stratgiques concernant la planification,
lexcution et les rapports sur les travaux daudit
des SI. Il tudie les aspects fondamentaux ainsi
que les nouveaux enjeux. Une valuation annuelle
des risques ralise dans le cadre de l'laboration
du plan d'audit qui ne couvre pas les risques informatiques serait considre comme dficiente (voir
les Normes 1210.A3, 1220.A2 et 2110.A2). L'audit
interne devrait tenir compte de trois aspects :
Un taux important de dispositifs de contrle
interne cl pour lorganisation sont susceptibles de reposer sur un systme informatis. Par
exemple : la politique dune organisation prcise quavant de rgler la facture dun fournisseur, il convient de procder une triple
vrification de cohrence (three way watch),
entre un bon de commande, un bon de livraison et une facture. Dans le pass, un employ
rapprochait physiquement les documents, les
agrafait et les classait. Aujourdhui, le progiciel
de gestion intgr (ERP) procde automatiquement ces rapprochements sur la base de
rgles prconfigures, et de niveaux de tolrance. Les carts sont automatiquement enregistrs dans des comptes prvus cet effet.
Pour auditer efficacement ce contrle, l'auditeur peut avoir besoin daccder aux paramtres de configuration des systmes ERP, ce qui
fait appel des comptences techniques que
ne possdent pas tous les auditeurs.

Une des difficults les plus frquentes est de comprendre les liens entre contrles des SI, reporting
financier, fraudes, activits, conformit et autres
domaines cls. Cest relativement facile lorsque
vous valuez des contrles dans le cadre dun systme applicatif (par exemple, les paramtres de la
triple vrification de cohrence voque cidessus). a l'est nettement moins lorsque vous
valuez des technologies connexes qui peuvent
avoir un impact bien plus important sur l'organisation que les contrles propres une seule application ou un seul processus.

Les organisations doivent comprendre les

risques stratgiques induits par les environnements complexes des SI. L'adoption des SI

Supposons par exemple quune organisation

mette des paiements lectroniques quelle envoie
ses fournisseurs. Ces paiements sont achemins

GTAG Introduction
par voie lectronique vers des comptes bancaires
sur la base des numros de routage SWIFT (Society
for Worldwide Interbank Financial Telecommunication) pour chaque compte fournisseur. Tous les
numros de lAutomated Clearing House (ACH)
sont stocks quelque part dans une table du systme de base de donnes de lorganisation. Un
administrateur de base de donnes, quiconque
ayant un droit d'accs la base de donnes, ou des
individus sans droit d'accs mais possdant les
comptences techniques leur permettant d'accder la base de donnes peuvent modifier chaque
entre de cette table pour y faire figurer le numro
ACH de leur propre compte bancaire. Ds qu'un
paiement lectronique est trait, les fonds sont
crdits sur le compte bancaire du contrevenant.
Une telle manipulation contournerait tous les
mcanismes de scurit, de contrle et de piste
daudit en place au sein du processus et de lapplication.
Dans le scnario ci-dessus, il est facile de comprendre comment la dfaillance dun contrle au
niveau de la base de donnes peut produire
davantage de dgts quune dfaillance au niveau
des paramtres de la triple vrification de cohrence. La probabilit et l'impact potentiel des
risques inhrents l'environnement des SI
devraient donc tre soigneusement pris en compte
dans le cadre de l'valuation annuelle des risques.

GTAG Stratgie mtier , processus et projets

2. Stratgie mtier ,
processus et projets
La stratgie mtier , facteur dterminant pour
identifier l'univers d'audit, est prendre en
compte imprativement lors de l'valuation des
risques. La stratgie mtier articule les objectifs
de l'organisation et les moyens mettre en uvre
pour les atteindre. Il est important que le RAI et le
management de l'audit interne comprennent cette
stratgie et le rle de la technologie dans l'organisation, ainsi que les interactions entre les deux.
L'un des outils pouvant tre utilis par le RAI pour
valuer la stratgie mtier d'une organisation
et son influence sur les travaux d'audit des SI est
le GTAG 11 : laboration d'un plan daudit des SI.
Ce guide donne aux RAI des informations sur la
comprhension de l'environnement des SI de l'organisation dans un contexte oprationnel.
Les composantes des SI figurant la section 3 facilitent lexplication des relations entre les activits
oprationnelles et l'infrastructure des SI, et lidentification du volet informatique dautres domaines
identifis dans l'univers d'audit lors de lvaluation
des risques.
Une cartographie tendue peut permettre didentifier les domaines critiques tels que l'infrastructure, les applications, les processus et les liens (tant
internes qu'externes) pouvant tre soumis des
risques qui n'avaient pas encore t identifis. Ce
processus de cartographie aidera le RAI valuer
les risques relatifs aux SI et les seuils de tolrance
au sein de l'organisation, et donne une perspective
pertinente sur les risques non identifis, qui
devrait tre communique la direction gnrale
et au management des SI.
Gnralement, les ressources spcialises de l'audit interne peuvent tre sollicites pour donner
une assurance quant la ralisation dtapes de
projets informatiques. Le RAI devrait valuer le
niveau de comptences et de connaissances requis
pour raliser ces travaux et affecter les ressources
appropries. Dans certains cas, une expertise
externe est ncessaire. Pour plus de dtails, se rfrer au GTAG 12 : Audit des projets SI.
7

GTAG Infrastructure et processus SI

sont intgres des procdures et des processus
manuels et certaines peuvent tre envisages isolment. Il existe des risques informatiques dans
chaque domaine de l'organisation, et ils varient
considrablement. Pirater le site Internet d'une
organisation et dtourner un paiement lectronique sont, par exemple, des risques trs diffrents
pour l'organisation.

3. Infrastructure et
processus SI
1. Dfinition des SI
L'une des difficults auxquelles un RAI est
confront lorsqu'il dtermine l'implication des ressources d'audit informatiques est dapprhender
les usages du SI dans lorganisation. Le tlphone
et les messageries vocales en font-ils partie ? Les
systmes d'accs et d'identification, ainsi que les
systmes de scurit physique devraient-ils tre
inclus ? Et que faire si ces derniers sont externaliss ? Voici quelques-unes des questions auxquelles
il faut rpondre lorsquil sagit de dterminer comment allouer ses ressources daudit des SI.

2. Tenir compte de chaque niveau du

SI
Pour un audit des SI efficace, il est ncessaire
dtudier et de classer par ordre de priorit les
risques inhrents chaque niveau du SI et dy
allouer les ressources daudit en fonction de ces
risques. Si le volet SI du plan daudit ne prvoit
pas une valuation de chacun des niveaux, il est
probable que le plan daudit dans son ensemble
ne traite pas correctement les risques lis aux SI.

Les SI sont spcifiques chaque organisation.

Deux organisations oprant dans le mme secteur
peuvent avoir des environnements de SI trs diffrents. Mme au sein d'une mme organisation,
les contrles peuvent tre centraliss, dcentraliss
ou les deux la fois. Les ordinateurs portables, les
rseaux sociaux et le cloud repoussent les frontires d'un contrle centralis et introduisent des
risques et des facteurs spcifiques.

Dans certains cas, il peut se rvler utile de traiter

tous les niveaux sur plusieurs annes, en faisant
un focus particulier chaque anne, au lieu de couvrir tous les niveaux sur une seule anne. Les plans
par roulement allant au-del de trois ans peuvent
tre inadquats en raison de la rapidit des changements qui soprent dans lenvironnement des
SI.

Cette section aidera les RAI envisager les SI au

sein d'une organisation. Certaines composantes

Management des SI
Clients

Infrastructure technique
Systmes
dexploitation

Internet
Base de
donnes
Fournisseurs
Rseaux

Applications
Dveloppement
interne dune
solution
transactionnelle

Solution
Solution
transactionnelle
transactionnelle
gnrique
correspondant
customise par un
loffre dun
prestataire externe
prestataire externe

Logiciel de
support /
assistance

Centre de donnes

Processus des SI
Figure 1

GTAG Infrastructure et processus SI

Quelles ressources allouer chaque niveau? A
quelles fins ? La rponse ces questions dlicates
devrait naturellement dcouler des processus
dvaluation des risques, du jugement professionnel et dune analyse stratgique. Au-del de lallocation prcise des ressources, il sagit de
sassurer que tous les niveaux du SI sont pris en
compte.

Objectifs oprationnels
Risque oprationnel / stratgique
Processus mtier

Risques inhrents
au processus

Application
TIC

Informations
oprationnelles

Procdure

Risques inhrents
au processus

Procdure

Le SI dune organisation peut-tre illustr selon la

figure 1.

Objectifs

Application
TIC

3. Quels sont les niveaux

considrer ?

Objectifs

Informations
oprationnelles
Infrastructure

Chaque organisation est diffrente, mais cette

reprsentation aidera identifier les processus cls
des SI dans la plupart des organisations. D'autres
modles d'architecture des SI peuvent tre envisags et sont rfrencs l'Annexe A.

Assurance

Figure 2

Attention : ce graphique ne dfinit pas des catgories

du plan daudit des SI. La planification des missions
d'audit des SI peut tre organise en fonction des processus de l'organisation, ou conformment un cadre
standard. Ce graphique a pour objectif d'aider
expliciter les liens entre les SI et l'organisation et
sassurer que des ressources d'audit sont alloues
chaque niveau. Lorganisation d'audits spcifiques est
laisse lapprciation du responsable de laudit
interne.

Les Technologies de l'information et de la communication (TIC) peuvent tre apprhendes travers

les principaux niveaux suivants :
le management des systmes dinformation,
linfrastructure technique,
les applications,
les connexions externes.
(Cf. figure 2)

4. Management des systmes

dinformation
Le management des SI concerne les personnes, les
rgles, les procdures et les processus qui grent
les services et les installations des SI. L'intgrit
du traitement et des donnes repose sur les tches
spcifiques rgulirement ralises par le personnel administratif. En consquence, cette composante englobe la surveillance, la programmation,
la planification, la gestion des fournisseurs, la gestion des problmes et des incidents, la gestion des
changements, la gestion des projets informatiques,
le plan de continuit d'activit, la gestion de la
scurit, la gouvernance des SI, etc.

Ces fonctions relvent de processus mtier. L'approche d'audit sera donc similaire une mission
classique. Lauditeur considrera les acteurs et
leurs tches, plutt que la configuration dun systme technique. Nanmoins, dans certains cas, la
gestion des processus porte sur les installations
techniques que l'audit devra prendre en considration. De mme, certains contrles peuvent
ncessiter des comptences spcialises. En principe, les comptences d'un auditeur interne expriment seront suffisantes.

GTAG Infrastructure et processus SI

enregistre dans le Grand Livre en passant par
le rseau o elle est traite. Mais que se produit-il si elle ne passe pas par le rseau ? Que
se passe-t-il si elle est modifie en cours de
route, ou disparat compltement ? Comment
lorganisation le saurait-elle ?
Centres de donnes L'quipement informatique est situ dans des centres de donnes
et des salles des serveurs, qui constituent l'infrastructure physique et assurent, la scurit
physique et environnementale permettant de
protger l'infrastructure technique et les applications.

5. Infrastructure technique
Linfrastructure technique sous-tend, soutient les
principales applications mtier et facilite leur mise
en uvre. En rgle gnrale, ce niveau comprend :
Les systmes d'exploitation L'ensemble
des programmes qui assurent le fonctionnement des ordinateurs. Citons par exemple
Z/OS, UNIX, Windows, et OS/400. Tous les
programmes et les fichiers sont grs par le
systme d'exploitation. Les actions engages
au niveau du systme dexploitation parviennent en gnral contourner la plupart des
dispositifs de scurit et des contrles existant
au niveau du processus.
Les fichiers et les bases de donnes Toutes
les donnes lectroniques de lorganisation,
critiques ou autres, sont contenues dans des
fichiers qui peuvent faire partie d'une base de
donnes. Les bases de donnes (qui peuvent
tre un seul fichier ou un groupe de fichiers)
comprennent des tables contenant des donnes, des relations entre des donnes lmentaires et des index de donnes lmentaires. La
flexibilit des structures d'une base de donnes
explique qu'elles soient utilises pour la plupart des traitements oprationnels et des
applications de remonte d'informations. Ces
bases sont par exemple Oracle, MS SQL
Server et DB2. Les actions engages au niveau
des bases de donnes tendent galement
contourner la plupart des contrles qui existent au niveau du processus.
Rseaux Pour que les donnes circulent
dans une organisation, il faut quelles disposent dun vecteur, qui peut tre un cble, une
fibre optique ou un systme sans fil. Le rseau
se compose d'lments physiques tels que des
cbles, des appareils qui grent le trafic sur le
rseau, comme les commutateurs, les routeurs
ou les pare-feux, et des programmes qui commandent la circulation des donnes. Lintgrit
du rseau joue un rle important dans
lexhaustivit et lexactitude des donnes dune
organisation. Par exemple, lorsque l'agent dun
entrept prpare lexpdition dun produit en
scannant un code-barres, la transaction est

Les audits de l'infrastructure technique sont axs

sur la revue des paramtres de configuration technique en association avec les processus de gestion
y affrents.

6. Applications
Les applications mtier sont des programmes qui
excutent des tches spcifiques lies aux activits
de lorganisation. Elles font partie intgrante du
processus mtier et ne peuvent tre considres
sparment des processus qu'elles soutiennent.
Les applications appartiennent gnralement
deux catgories :
Les solutions transactionnelles sont principalement des logiciels qui traitent et enregistrent
les transactions, par exemple des logiciels de
traitement des bons de commande, de saisie
dans le Grand Livre et de gestion des entrepts.
Les logiciels support sont des logiciels spcialiss qui facilitent les activits mtier mais ne
traitent gnralement pas les transactions. Ils
servent par exemple au stockage des donnes,
la messagerie lectronique, la tlcopie,
la veille stratgique (business intelligence), la
gestion lectronique des documents (GED) et
la conception.
Alors que les solutions transactionnelles constituent gnralement lessentiel de leffort daudit,
certains logiciels support tels que ceux qui viennent en appui du reporting externe ou les appli-

10

GTAG Infrastructure et processus SI

pour l'organisation. Il peut tre difficile de dfinir
des procdures d'audit des SI pour grer ce risque
car l'organisation ne peut auditer que ce qu'elle
contrle. Il est donc primordial d'auditer au minimum les points d'entre et de sortie.

cations qui contrlent des machines peuvent galement tre soumis des risques importants.
L'audit interne doit valuer continuellement les
risques mergents pour l'organisation et identifier
la rponse d'audit requise. Les connaissances spcialises requises pour certains aspects des SI peuvent rendre ce processus complexe.

7. Connexions externes
Le rseau de lorganisation ne fonctionne pas isolment. Il est quasiment toujours connect de
nombreux autres rseaux externes. Internet est
celui qui vient le premier lesprit, mais trop souvent, les auditeurs commettent lerreur de ne pas
aller au-del.
En ralit, il est fort probable que le rseau de l'entreprise soit connect de nombreux autres
rseaux (dont le cloud et les logiciels des prestataires de services). Par exemple : lorganisation
opre-t-elle via un change de donnes informatises (EDI) ? Si tel est le cas, son rseau est certainement connect celui dun prestataire dEDI,
ou peut-tre directement au rseau dun partenaire commercial. Lorganisation externalise-t-elle
sa fonction de stockage ? Si oui, les deux rseaux
sont aussi probablement relis. Les risques associs aux rseaux d'autres organisations et les
contrles y affrents sont diffrents de ceux applicables aux connexions Internet.
Dans la mesure o les organisations continuent
dautomatiser leurs processus cls, les tiers ont de
plus en plus accs leur rseau, souvent via Internet. Prenons par exemple la possibilit de vrifier
le solde dun compte bancaire ou ltat davancement dune expdition. Les clients qui utilisent ces
fonctions entrent probablement dans le rseau
interne de ces entreprises via Internet.
Du fait que lorganisation ne matrise pas les
rseaux extrieurs, les communications provenant
(ou transmises vers) des rseaux externes
devraient tre rigoureusement contrles et surveilles en fonction du risque qu'elles reprsentent

11

GTAG Approche fonde sur les risques

criticit oprationnelle au nombre d'entits fonctionnant l'aide de l'application. Le nombre d'incidents recenss ou les projets mens bien par
l'organisation peuvent mesurer la probabilit d'occurrence.

4. Approche fonde sur les

risques
Toutes les dimensions de la gestion dun service
daudit interne reposent sur une approche fonde
sur les risques, notamment l'laboration et le
maintien des programmes d'audit, la gestion des
ressources humaines et la conduite des missions.
Cette section se concentre sur la partie de l'valuation des risques inhrents aux SI.

Outre la collecte de donnes, la conduite d'entretiens avec les principales parties prenantes telles
que le management des SI, le management oprationnel et les experts constitue galement une
source importante pour l'valuation des risques
relatifs aux SI. Les interviews peuvent aider
quantifier les risques difficiles mesurer directement.

L'valuation des risques relatifs aux SI ralise par

laudit interne permet didentifier des missions
d'audit spcifiques plus forte valeur ajoute
potentielle pour la priode considre. Les risques
relatifs aux SI ne ncessitent pas de mthodologie
distincte. Il est important d'utiliser la mme
mthodologie pour tous les types de risques afin
de veiller l'homognit du processus d'valuation pour l'ensemble de la fonction d'audit
interne.

Il est primordial de tenir compte de l'volution

rapide de la technologie et de son utilisation par
lorganisation. Aussi l'valuation des risques doitelle tre frquemment mise jour. Ceci est parfaitement illustr par l'importance croissante des
problmatiques de protection de la vie prive
dcoulant de l'existence et de l'utilisation des
rseaux sociaux. Pour une description plus dtaille de cette problmatique, vous pouvez consulter
le Guide pratique de l'IIA, Laudit des risques datteinte la vie prive.

Les risques sont gnralement exprims en termes

de combinaison dimpact et de probabilit doccurrence dun vnement. Il est souvent difficile
dvaluer exactement les risques, notamment pour
les sries d'vnements peu probables. Les journaux d'erreurs et les statistiques donnent des lments utiles pour ces valuations. Dans certains
cas, l'examen des impacts est suffisant (par exemple la perte d'un centre de donnes) et il n'est
pas ncessaire de connatre le cheminement des
vnements qui en seraient l'origine, ni la probabilit d'occurrence pour savoir qu'il faut tre
attentif au risque.

Enfin, pour une description plus dtaille de l'valuation des risques relatifs aux SI, vous pouvez
consulter le GTAG 11 : laboration d'un plan daudit
des SI.

Il est souvent possible de dfinir des critres qui

s'appliquent tous les types de risques lis aux SI,
mais se manifestent diffremment. Par exemple,
l'exposition potentielle peut tre apprhende par
des indicateurs denvergure ou de criticit oprationnelle. Par exemple, le nombre d'applications
sous-tendues par un centre de donnes pourrait
tre indicatif de son niveau de criticit (ventuellement pondr en fonction de son importance),
et le nombre de serveurs qu'il hberge peut ventuellement caractriser sa taille. La taille d'un
projet, en revanche, se mesure son budget, et sa
12

GTAG Univers d'audit

vent ne pas tre vidents (par exemple les activits externalises telles que les prestataires de
services l'tranger, des lments oprationnels trs importants sur le plan des SI et les
processus mtier automatiss).
Lors du processus de mise jour, mettre l'accent sur les thmes nouveaux et mergents.
Citons par exemple le cloud computing, les
mdias sociaux ou l'utilisation d'appareils
mobiles.
L'univers d'audit ne devrait pas tre tenu
secret, mais doit tre partag avec les parties
prenantes concernes (par exemple le management des SI et d'autres fonctions) afin de
favoriser la communication de donnes et de
suggestions d'amlioration.

5. Univers d'audit
Pour constituer les bases de l'allocation et de la
prvision des ressources en audit des SI et pour
assurer la couverture ncessaire la fourniture
dune assurance raisonnable concernant les
risques relatifs aux SI, les domaines impliquant des
SI et ncessitant des comptences spcialises en
audit des SI devraient tre identifis dans l'univers
d'audit.
Il ne devrait pas y avoir d'univers d'audit des SI
distinct. Les travaux d'audit des SI devraient tre
intgrs l'univers d'audit global car les SI et les
processus mtier qu'ils sous-tendent sont fortement interdpendants. Par exemple, les applications informatiques mtier feront gnralement
partie de l'univers d'audit global l'intrieur d'un
processus mtier. La structuration de l'univers
d'audit devrait permettre un regroupement par
type d'audit et donc une identification des missions ncessitant des comptences spcialises
(par exemple, l'audit des applications et des processus des SI).

Pour de plus amples informations, voir le GTAG

11 : laboration d'un plan daudit des SI.

Pour les processus de regroupement/structuration,

on s'appuie gnralement sur la structure utilise
par le management des SI, qui figure habituellement dans la stratgie des SI. Idalement, cette
structure est base sur des rfrentiels tels que
COBIT, ITIL, COSO (pour de plus amples dtails,
voir la section 7), etc.
Dans une organisation complexe, un univers d'audit trs dtaill peut facilement comporter des milliers d'lments relatifs aux SI. Cet univers d'audit
sera alors difficile grer car sa production, sa mise
jour, et l'valuation des risques pour tous les lments ncessiteront des efforts importants. En
revanche, si les lments relatifs aux SI sont trop
gnraux, ils ne pourront sans doute pas servir de
base l'laboration du plan d'audit.
Voici quelques principes importants qui devraient
tre suivis lors du dveloppement des composants
SI de l'univers d'audit :
Veiller l'exhaustivit en intgrant les lments pertinents, notamment ceux qui peu13

GTAG Savoir-faire et comptences

diteur adquat. Le RAI doit savoir qu'aucun auditeur ne peut effectuer tous les travaux d'audit des
SI et que souvent, certaines missions ncessitent
plutt des comptences concernant des applications et d'autres missions ncessiteront des auditeurs plus comptents en matire d'infrastructure.

6. Savoir-faire et
comptences
Une thmatique rcurrente dans de nombreuses
organisations, concerne lcart entre dune part
l'utilisation des systmes informatiques et la
dpendance des organisations leur gard, et
dautre part, les ressources utilises pour identifier
et grer les risques dcoulant de ces technologies.
Il est donc primordial que la fonction d'audit
interne tienne compte des systmes d'information
lorsqu'elle value les processus de gouvernance,
de management des risques et de contrle.

Par consquent, un RAI qui a une bonne apprhension de lunivers daudit, des risques gnrs
par l'utilisation des SI, ainsi que des comptences
en audit des SI dont il dispose, devrait tre mme
de cibler les efforts de recrutement et de formation
en consquence. En l'absence du savoir-faire et
des comptences informatiques ncessaires, ou s'il
est dcid de ne pas former ou embaucher de collaborateurs possdant ces comptences, le RAI
peut faire appel un prestataire de services externe
pour toffer ou complter l'quipe d'audit interne
(sous-traitance ou co-sourcing)1.

Pour grer ces risques, un RAI doit veiller ce que

son quipe possde les comptences requises. Ceci
est prconis par le Code de dontologie du Cadre de
Rfrence International des Pratiques Professionnelles
de l'audit interne (CRIPP) de l'IIA, qui exige que les
auditeurs internes effectuent uniquement des services pour lesquels ils possdent les connaissances, les comptences et l'exprience requises,
ainsi que par la Norme 1210 : Les auditeurs internes
doivent possder les connaissances, le savoir-faire et
les autres comptences ncessaires l'exercice de leurs
responsabilits individuelles. La fonction d'audit
interne devrait possder ou obtenir, collectivement, les connaissances, le savoir-faire et autres
comptences ncessaires. L'IIA propose un rfrentiel des comptences qui aide identifier les
comptences ncessaires l'excution des activits
d'audit interne.

Pour s'acquitter des responsabilits relatives laudit des SI, le RAI devrait se poser des questions
cls concernant la gestion des comptences et du
savoir-faire des auditeurs :
Toutes les composantes des SI de l'organisation sont-ils inclus dans le processus de planification et tous les domaines haut risque
ont-ils t identifis ?
Existe-t-il une vue d'ensemble de l'ventail
des comptences ncessaires pour auditer
l'usage des SI de l'organisation et les comptences dj disponibles ?
Le service d'audit dispose-t-il d'une politique
sur la gestion des connaissances manquantes
(par exemple recrutement, sous-traitance ou
co-sourcing) ?
Les auditeurs des SI possdent-ils la formation, les certifications et l'exprience requises ?
Si ce n'est pas le cas, le service d'audit interne
a-t-il mis en place un plan pour pallier ce
manque ?
Le service d'audit interne dispense-t-il la formation adquate aux auditeurs pour apprhender lusage du SI, les risques y affrents et
les modalits daudit appropris ?

Le RAI devrait obtenir l'avis et l'assistance de personnes qualifies si le service d'audit interne ne
possde pas les connaissances, le savoir-faire et les
autres comptences ncessaires pour s'acquitter
de tout ou partie d'un audit des SI. Les ressources
affectes la ralisation des missions planifies
ont un rle critique. Par exemple, les comptences
requises pour auditer la configuration dun parefeu sont trs diffrentes de celles ncessaires pour
auditer les tables dans une base de donnes. Pour
une mission donne requrant telles ou telles
comptences, il est donc essentiel de trouver lau-

Pour de plus amples dtails, voir la MPA 1210.A1-1 : Recours des prestataires externes.

14

GTAG Raliser des missions d'audit des SI

2. Cadres de rfrence et normes

7. Raliser des missions

d'audit des SI

Lune des difficults que rencontrent les auditeurs

lorsquils effectuent un audit des SI est la dtermination dun rfrentiel. La plupart des organisations nont pas labor de rfrences de contrle
des SI pour toutes les applications et technologies.
Lvolution rapide de la technologie pourrait
rendre ces rfrences rapidement obsoltes et
donc inutiles.

Le droulement de missions d'audit des SI nest

gnralement pas diffrent de celui dautres missions. Lauditeur planifie, identifie et documente
les contrles pertinents, vrifie lefficacit de la
conception et du fonctionnement de ces contrles,
en tire des conclusions et rdige son rapport.
Puisque la plupart des responsables de laudit
interne connaissent bien ce processus gnral, il
nest pas rappel ici. Toutefois, le RAI doit connatre et grer certaines problmatiques relatives aux
missions d'audit des SI.

Un RAI devrait avoir une srie dobjectifs de

contrle des SI, et devrait pouvoir trouver un cadre
de rfrence appropri mme sil nest pas 100%
adapt son environnement.

1. Collaboration entre auditeurs des

SI et autres auditeurs

3. COSO et COBIT
O un RAI peut-il trouver une srie cohrente
dobjectifs de contrle des SI ? Les cadres de rfrence Contrle interne et management des risques de
lentreprise du Committee of Sponsoring Organizations of the Treadway Commission (COSO) constituent des sources d'information frquemment
consultes, mais ils ne sont pas spcifiquement
axs sur les SI. Lenvironnement de contrle reposant sur le COSO devrait tre complt par des
objectifs de contrle des SI plus dtaills, qui permettront dvaluer plus efficacement lenvironnement de contrle des SI. Il existe un certain
nombre de possibilits cet gard.

Lorsqu'il effectue une mission, l'audit interne

devrait s'efforcer d'avoir une perspective globale.
Certains domaines des SI seront probablement
audits exclusivement par des spcialistes des SI
(principalement ceux qui sont axs sur l'infrastructure tels que les centres de donnes, les rseaux,
ou les processus des SI comme les services d'assistance) ; en revanche, pour les revues des applications, l'audit de l'ensemble de la chane de
valeur, incluant les mtiers et les SI, apportera le
plus grand bnfice. Ces types de missions
devraient se concentrer sur les objectifs oprationnels et tous les risques (dont ceux relatifs aux SI)
doivent tre valus selon cette perspective. Cet
exercice peut tre difficile, mais galement trs
positif car il permet de cerner les liens de dpendance du mtier vis--vis des SI. Par exemple, si
les missions d'audit des SI rvlent qu'il n'existe
pas de plan de continuit d'activit, les auditeurs
des SI et les auditeurs oprationnels peuvent collaborer pour dcrire l'impact de la dure de l'interruption anticip dans le scnario de crise pour
le mtier (par exemple, en termes de baisse de la
production, retards dans le paiement des salaires,
impossibilit de vendre des produits). Peu importe
qui est responsable des audits spcifiques, l'attention de laudit interne devrait tre centre sur la
collaboration pour obtenir des rsultats optimaux.

Le CobiT (Control Objectives for Information and

related Technology), initialement publi en 1994 par
lISACA (Information Systems Audit and Control
Association), est lun des rfrentiels de contrle et
de gouvernance des SI couramment utilis. La version 5.0 du CobiT a t publie en 2012. Le CobiT
n'a pas pour vocation de concurrencer le COSO
ou d'autres rfrentiels, mais peut tre utilis pour
les complter en les enrichissant avec des objectifs
de contrle des SI plus cibls.

15

GTAG Raliser des missions d'audit des SI

4. Rgles, normes et procdures
Un rfrentiel comme le CobiT propose une srie
dobjectifs de contrle des SI communment
admis, qui aide le management concevoir une
politique dvaluation et de gestion des risques lis
aux SI. Le management se sert gnralement dun
tel rfrentiel pour le dveloppement dun systme cohrent de rgles, normes et procdures
relatives aux SI. L'Annexe A donne une vue d'ensemble des sources pertinentes pour les rgles, les
normes et les procdures.

16

GTAG Rapports
qus au management que les risques relatifs aux
SI. Les risques relatifs aux SI dbouchent in fine
sur des risques oprationnels, mais le lien entre les
deux n'est pas toujours clair.

8. Rapports
Comme pour tous les autres travaux d'audit
interne, les RAI rendent compte rgulirement des
rsultats des missions d'audit des SI aux principales parties prenantes telles que le Conseil1, la
direction gnrale, le directeur des systmes d'information, les rgulateurs et les auditeurs externes.
Pour des lignes directrices plus dtailles sur la
faon de communiquer avec les principales parties
prenantes, voir le guide pratique de l'IIA, Interaction with the board.

Un certain nombre de questions concernant la

communication se posent : Convient-il de procder un audit des rseaux sans fil, un audit de
larchitecture et de la conception des rseaux ou
bien une revue de la conception dune application lectronique ? Si les missions sont ainsi dissocies, il y a fort parier que les constats
porteront sur des dtails pour chaque technologie.
Pour certains publics, cette approche pourrait tre
approprie, mais le Conseil ou la direction gnrale pourraient ne pas s'intresser ou comprendre
les dtails des questions techniques. Ils veulent
gnralement que les constats d'audit soient relis
aux problmatiques oprationnelles. En consquence, les travaux d'audit des SI doivent s'intgrer aux travaux des auditeurs de processus /
oprationnels / financiers et aux procdures qu'ils
mettent en uvre. Ceci est particulirement vrai
dans les environnements comportant des applications ERP importantes, dont les systmes comportent un grand nombre de contrles cls de
processus. N'oublions pas que dans certains cas,
l'audit de composants centraux de l'infrastructure
tels que les centres de donnes ou les rseaux sans
fil sera difficile ; il sera donc pertinent d'auditer
individuellement ces domaines. Toutefois, les
risques identifis durant la mission doivent tre
traduits en langage oprationnel et en risques
mtier.

Les destinataires des rapports d'audit peuvent

appartenir des niveaux hirarchiques plus levs
que ceux qui sont interviews ou qui excutent les
contrles. Il est donc ncessaire de communiquer
prcisment et clairement les informations les plus
importantes, de faon ce que les constats ou les
enjeux soient compris et que le management
puisse ragir. Il est inutile d'effectuer un audit de
qualit si le management ne met pas en uvre des
plans d'action efficaces pour grer les problmatiques et les risques identifis. Le management ne
s'intresse gnralement pas aux dtails du processus d'audit. Il souhaite connatre les dfaillances, leurs consquences potentielles et les
mesures prendre pour y remdier.
Lorsqu'il effectue une mission, l'auditeur interne
devrait s'efforcer d'avoir une perspective globale.
La plupart des organisations tant dpendantes
des SI, les rapports sur les risques et les contrles
relatifs aux SI devraient faire partie des activits
d'assurance du RAI. Si des processus SI et l'infrastructure SI peuvent (et peut-tre devraient pour
des raisons d'efficacit) tre audits sparment,
en rgle gnrale, l'audit de l'ensemble de la
chane de valeur (dont les mtiers et les SI) apportera le plus grand bnfice. Ces types d'audit peuvent tre nettement plus axs sur les risques
oprationnels, qui sont plus facilement communi-

Les rapports devraient tre rdigs pour des lecteurs avertis, mais qui ne possdent peut-tre pas
d'exprience spcifique dans le domaine audit, et
le message ne doit tre ni dlay ni noy dans un
langage technique. L'objectif du RAI est de prsenter un message clair, comprhensible et quilibr.

Le terme Conseil est utilis au sens donn dans le glossaire des Normes, savoir : Le niveau le plus lev des organes de gouvernance, responsable
du pilotage, et/ou de la surveillance des activits et de la gestion de l'organisation. Habituellement, le Conseil (par exemple, un conseil dadministration,
un conseil de surveillance ou un organe dlibrant) comprend des administrateurs indpendants. Si une telle instance nexiste pas, le terme Conseil ,
utilis dans les Normes, peut dsigner le dirigeant de lorganisation. Le terme Conseil peut renvoyer au comit daudit auquel lorgane de gouvernance a dlgu certaines fonctions.

17

GTAG Outils daudit

d'analyse de la scurit, les principaux tant les
outils d'analyse de rseau :

9. Outils d'audit
Les RAI devraient chercher utiliser des outils
et/ou des techniques pour accrotre l'efficience et
l'efficacit de l'audit. En rgle gnrale, les outils
d'audit requirent un investissement, si bien que
le RAI devrait soigneusement valuer le rapport
cot/avantages de toute solution avant de sy
engager. Les outils daudit peuvent tre rpartis en
deux catgories : les facilitateurs daudit (qui ne
sont pas abords ici), qui viennent en support du
processus global daudit (par exemple un outil de
gestion des documents de travail lectroniques), et
les outils de tests : outils qui automatisent la ralisation des tests daudit (comme les outils danalyse des donnes et les techniques daudit assist
par ordinateur).

Outils danalyse de rseau Ces outils sont des

programmes logiciels qui peuvent tre lancs sur
un rseau pour y recueillir des informations. Classiquement, les pirates informatiques utilisent ce
type doutils au dbut dune attaque afin de dterminer la structure du rseau. Les auditeurs des SI
peuvent y recourir pour diverses procdures daudit, notamment :
La vrification de lexactitude des diagrammes
de rseau par une cartographie du rseau,
Lidentification des dispositifs cls du rseau
qui appellent une attention supplmentaire de
la part des auditeurs,
La collecte des informations concernant le
trafic autoris sur un rseau (tayant directement le processus dvaluation des risques lis
aux SI).

1. Outils de tests des SI

Outils d'valuation de la vulnrabilit

Les outils de tests permettent dautomatiser des

tches daudit chronophages, comme lexamen de
vastes bases de donnes. En outre, le recours un
outil pour excuter des procdures daudit confre
une certaine cohrence. Par exemple, si un outil est
utilis pour valuer la configuration de la scurit
dun serveur, tous les serveurs tests au moyen de
cet outil seront valus par rapport aux mmes critres. Excuter ces procdures manuellement
laisse du champ une interprtation de la part de
lauditeur. Enfin, lutilisation de ces outils permet
aux auditeurs de tester la totalit dune base de
donnes, et non un simple chantillon de transactions, do un niveau dassurance bien suprieur.

La plupart des technologies, lorsquelles ne sont

pas personnalises, souffrent dun certain nombre
de vulnrabilits standard, comme lexistence
didentifiants, de mots de passe ou de paramtres
par dfaut. Ces outils d'valuation offrent une
solution automatise pour vrifier ces vulnrabilits.
Ces outils peuvent tre utiliss pour les pare-feux,
les serveurs, les rseaux et les systmes dexploitation. Nombre de ces outils sont prts utiliser ( plug and go ) : lauditeur les branche sur
tout ce quil souhaite analyser, et l'outil produit un
rapport des vulnrabilits identifies.

Les RAI devraient savoir que les mmes considrations s'appliquent tant l'acquisition d'outils
d'audit des SI quau choix de n'importe quel autre
outil oprationnel (par exemple fonctionnalit,
support).

Il est important que lauditeur exploite ce type

doutils pour plusieurs raisons, notamment parce
que ce sont les outils quun pirate informatique
utiliserait pour monter une attaque contre lorganisation. Nanmoins, il convient de les utiliser
avec vigilance car certains de ces outils sont potentiellement dangereux et peuvent compromettre
lintgrit des systmes quils scannent. Lauditeur
devrait examiner avec le responsable de la scurit
lutilisation quil prvoit de faire de ces outils et

Outils danalyse de la scurit

Un vaste ensemble doutils permettent dexaminer
diffrentes catgories de dispositifs et/ou dutilisateurs, et de dceler les expositions des risques
lis la scurit. Il existe de nombreux types
18

GTAG Outils daudit

coordonner les tests avec le management des SI
afin de veiller ce que le calendrier des tests naffecte pas la production. Dans certains cas, le responsable de la scurit ou les administrateurs
systmes emploient dj rgulirement certains de
ces outils dans le cadre des processus de gestion
des systmes. Si tel est le cas, il peut tre envisag
dexploiter ces rsultats dans les travaux d'audit
des SI, sils sont correctement conus et excuts.
Outils danalyse des applicatifs de scurit
Bon nombre d'applications intgres comportent
des outils d'analyse de la scurit en fonction de
rgles prconfigures. Ces outils peuvent galement valuer la sparation des fonctions au sein
dune application. Le RAI devrait tre conscient du
fait que la plupart de ces outils sont assortis dun
ensemble de rgles prconfigures ou proposes
par le fournisseur comme relevant des meilleures
pratiques .

19

GTAG Conclusion
outre, les RAI devraient chercher utiliser des
outils et/ou des techniques pour accrotre l'efficience et l'efficacit de l'audit. Comme pour n'importe quel outil, les outils d'audit requirent un
investissement en temps et en ressources, si bien
que le RAI devrait soigneusement valuer le rapport cot/avantages de toute solution avant de sy
engager.

10. Conclusion
Lapparition de nouveaux risques lis la technologie impose de repenser les procdures pour bien
grer ces risques. Il ne fait aucun doute qu'au cours
des 15 dernires annes, la technologie a modifi
la nature de la fonction daudit interne.
Aujourdhui, les RAI devraient sinterroger sur les
risques auxquels est confronte lorganisation, les
types daudits effectuer, les modalits de priorisation dans lunivers daudit et sur la manire de
communiquer des constats pertinents au Conseil
et la direction gnrale.

Enfin, le processus pour raliser une mission relative aux risques SI nest gnralement pas diffrent
de celui dautres travaux d'audit : lauditeur planifie la mission, identifie et documente les contrles
pertinents, vrifie lefficacit de la conception et du
fonctionnement de ces contrles, en tire des
conclusions et rdige son rapport. De mme, les
RAI rendent compte rgulirement des rsultats
des travaux d'audit des SI aux principales parties
prenantes telles que le Conseil, la direction gnrale, le directeur des systmes d'information, les
rgulateurs et les auditeurs externes.

La stratgie mtier guide la dfinition de l'univers

d'audit et l'valuation des risques. Elle dtermine
les lments importants pour le Conseil et le
management, et les domaines dans lesquels les
activits sont susceptibles de changer. Il est donc
important que le RAI comprenne tant la stratgie
mtier que le rle des SI dans l'organisation et
l'impact qu'ils ont l'un sur l'autre.
Lorsque le RAI cartographie les activits de l'organisation et son infrastructure, il peut observer de
faon privilgie l'impact des diffrentes relations
entre les SI et les mtiers. Les projets SI sont souvent des lments cls du changement, dans les
organisations, et le mcanisme utilis par le management pour mettre en uvre la stratgie oprationnelle.
Les difficults auxquelles un RAI est initialement
confront lorsqu'il dveloppe les composantes SI
du plan d'audit concernent l'identification des
activits SI au sein de l'organisation. Sachant que
les environnements des SI sont trs diversifis, un
RAI peut chercher dfinir les SI en termes de
composantes. Chaque composante est diffrente
et importante la fois. L'utilisation d'une
approche fonde sur les risques est un concept
gnral qui s'applique quasiment toutes les activits d'audit interne. L'univers d'audit devrait tenir
compte des SI car il existe des interdpendances
importantes entre les SI et les mtiers.
Pour grer ces risques, un RAI doit veiller ce que
son quipe possde les comptences requises. En
20

GTAG Annexe A : Normes de rfrence

SysAdmin, Audit, Network, Security (SANS)
Institute Source dinformation parmi les plus
fiables pour ce qui est de la formation et de la sensibilisation la scurit des SI, le SANS Institute
publie de nombreux documents traitant des diffrents aspects de la scurit pour diverses technologies. Les publications du SANS exposent un
certain nombre de critres incontournables au
regard desquels lauditeur des SI peut effectuer
son audit.

Annexe A : Normes de
rfrence
Les normes cites ci-aprs peuvent tre prises en
considration :
ISO 27001 ISO 27001/ISO 17799 LOrganisation internationale de normalisation (ISO) a dit
une norme gnrique sur la scurit des SI reconnue lchelle internationale. Il sagissait au
dpart dune norme britannique (BS 7799), qui a
t transforme en norme ISO et qui est dsormais connue sous lappellation ISO 27001. Elle
prsente les bonnes pratiques communment
admises concernant la gestion de la scurit des SI
et constitue un document de rfrence utile
partir duquel les auditeurs des SI peuvent mener
bien leurs missions.

http://www.sans.org

IT Infrastructure Library (ITIL) L'ITIL est l'approche la plus gnralement admise de la gestion
des services des SI dans le monde. L'ITIL donne
un ensemble homogne de meilleures pratiques
tires des secteurs public et priv l'chelle internationale.

http://www.iso.org

http://www.itil-officialsite.com
Capability Maturity Model Integration
(CMMI) Le Software Engineering Institute (SEI)
de luniversit Carnegie Mellon a labor le
concept de Capability Maturity Models (CMM,
modles de maturit des capacits) relatifs diffrents processus au sein dune organisation,
notamment en ce qui concerne le dploiement de
logiciels. L'approche la plus rcente est CMMI.

Normes propres aux fournisseurs De nombreux fournisseurs de solutions technologiques

publient des recommandations sur la scurit et le
contrle applicables la technologie quils produisent. SAP, par exemple, dite un guide sur la scurit qui nonce des recommandations dtailles
pour la scurit et les contrles de lapplication
SAP ERP. Souvent, ces normes fournisseurs ne
prennent pas en compte la scurit et le contrle
au mme niveau que, par exemple, une publication NIST, mais elles donnent une bonne base de
dpart. Les RAI devraient donc vrifier auprs des
fournisseurs de systmes critiques pour les missions si des normes spcifiques sont disponibles.
Dans bien des cas, les fournisseurs nont rien
publi, mais le groupe dutilisateurs associ cette
technologie a dit une ou des publication(s) (par
exemple les diffrents groupes dutilisateurs de
SAP aux tats-Unis).

http://www.sei.cmu.edu

United States Computer Security Resource

Center Le United States Computer Security
Resource Center est une division du National Institute of Standards and Technology (NIST) qui propose une srie complte de publications offrant
des informations dtailles sur le contrle de la
scurit des SI. Parmi ses publications, citons
Guidelines for Securing Wireless Local Area Networks (WLAN) et Guidelines on Security and
Privacy in Public Cloud Computing. Ces normes
noncent des bonnes pratiques qui peuvent tre
utilises dans tous les secteurs.
http://csrc.nist.gov
21

GTAG Annexe B : Modles d'architecture des SI

Annexe B : Modles
d'architecture des SI
Les modles d'architecture des SI et les rfrences
pouvant tre pris en compte sont :
The Abu Dhabi IT Architecture & Standards
Framework Bas sur un rfrentiel comportant
huit niveaux, il couvre tous les aspects d'un environnement des SI notamment : Mtiers, Accs et
prsentation, Application, Donnes, Intgration,
Infrastructure, Scurit et Exploitation.
http://adsic.abudhabi.ae

AndroMDA Des applications modernes sont

construites l'aide de plusieurs composants
connects les uns aux autres, chacun d'entre eux
ayant une fonctionnalit spcifique. Les composants qui effectuent des fonctions similaires sont
gnralement regroups en niveaux. Ces niveaux
sont organiss en pile dans laquelle les composants d'un niveau utilisent les services de composants d'un niveau infrieur. Un composant dans
un niveau donn utilisera gnralement la fonctionnalit d'autres composants de son propre
niveau ou de niveaux infrieurs.
http://www.andromda.org

TOGAF The Open Group Architecture Forum

a dvelopp et maintient le TOGAF, une norme
reconnue au niveau mondial en matire d'architecture d'entreprise.
http://www.opengroup.org

22

GTAG Auteurs et relecteurs

Auteurs et relecteurs
Auteurs
Stephen Coates, CIA, CGAP, CISA
Max Haege
Rune Johannessen, CIA , CCSA, CRMA , CISA
Jacques Lourens, CIA , CISA, CGEIT , CRISC
Cesar L. Martinez, CIA , CGAP
Relecteurs
Steve Hunt, CIA , CRMA , CISA, CGEIT
Steve Jameson, CIA , CCSA, CFSA, CRMA
Rviseurs
Marie-Elisabeth Albert, CIA
Batrice Ki-Zerbo, CIA
Gilles Trolez

23

A PROPOS DE LINSTITUTE OF INTERNAL AUDITORS

Fond en 1941, The Institute of Internal Auditors (IIA) est une organisation professionnelle internationale dont le
sige mondial se situe Altamonte Springs, en Floride, aux tats-Unis. LInstitute of Internal Auditors est la voix
mondiale, une autorit reconnue, un leader incontest et le principal dfenseur de la profession dauditeur interne.
Cest galement un acteur de premier plan pour la formation des auditeurs internes. Il est reprsent en France
par lIFACI.

A PROPOS DES GUIDES PRATIQUES

Les guides pratiques dtaillent la ralisation des activits daudit interne. Ils contiennent des processus et des procdures, tels que les outils et techniques, les programmes et les approches pas--pas, et donnent des exemples de
livrables. Les guides pratiques sinscrivent dans le Cadre de rfrence international des pratiques professionnelles
de l'audit interne de lInstitute of Internal Auditors. Ces guides pratiques relvent de la catgorie des dispositions
fortement recommandes. La conformit ces guides pratiques nest donc pas obligatoire, mais fortement recommande. Ces guides ont t officiellement rviss et approuvs par lIIA.
Le Global Technologies Audit Guide (GTAG) est un type de guide pratique qui aborde, dans un langage courant,
une question dactualit lie la gestion, au contrle ou la scurit des technologies de linformation.
Pour de plus amples informations sur les documents de rfrence proposs par lInstitute, vous pouvez consulter
notre site Web, www.theiia.org.guidance ou www.ifaci.com.

AVERTISSEMENT
LInstitute of Internal Auditors publie ce document titre informatif et pdagogique. Cette ligne directrice na pas
vocation apporter de rponses dfinitives des cas prcis, et doit uniquement servir de guide. LInstitute of
Internal Auditors vous recommande de toujours solliciter un expert indpendant pour avoir un avis dans chaque
situation. LInstitute dgage sa responsabilit pour les cas o des lecteurs se fieraient exclusivement ce guide.

COPYRIGHT
Le copyright de ce guide pratique est dtenu par lInstitute of Internal Auditors et par lIFACI pour sa version franaise. Pour lautorisation de reproduction, prire de contacter lInstitute of Internal Auditors ladresse
guidance@theiia.org ou lIFACI ladresse recherche@ifaci.com.

The Institute of Internal Auditors

247 Maitland Avenue, Altamonte Springs
Florida 32701, tats-Unis
Tlphone : +1 407 937 1100
Tlcopie : 1 407 937 1101
Site Web : www.theiia.org
Courrier lectronique : guidance@theiia.org

IFACI
98bis, Boulevard Haussmann
75008 PARIS, France
Tlphone : 01 40 08 48 00
Fax : 01 40 08 48 20
Site Web : www.ifaci.com
Courrier lectronique : recherche@ifaci.com