Boîte À Outils ISO27k

Abonnez-vous à DeepL Pro pour modifier ce document.
Visitez www.DeepL.com/Pro pour en savoir plus.
Boîte à outils ISO27k
Ligne directrice sur l'audit

du SGSI
Version 2, 2017
Conseils génériques et pragmatiques pour

l'audit de la sécurité de l'information ISO27k
d'une organisation
Système de gestion, couvrant à la fois
le système de gestion et
les contrôles de sécurité de
l'information.
Un modèle à l'usage des auditeurs
informatiques, rédigé par et pour les
praticiens.
Complète la norme ISO27k (série ISO/IEC 27000)

les normes internationales en matière de
sécurité de l'information.
Boîte à outils ISO27k Ligne directrice sur l'audit
du SGSI v2
Système de gestion de la sécurité de

l'information
Ligne directrice en matière d'audit
Préparé par des praticiens du Forum ISO27k
Version 2 Août 2017
Contenu
1
. Introduction 5
2. Portée et objectif de la présente ligne directrice 5
3. Références 5
4. Termes et définitions 6
5. Principes de l'audit 7
6. Gestion de l'audit 8
6.1 Gestion du programme d'audit du SGSI 8
6.2 Gestion d'un audit du SGSI 8
7. Le processus d'audit 9
7.1 Enquête de cadrage et de pré-audit 9
7.2 Planification et préparation de l'audit 10
7.3 Travail d'audit sur le terrain 10
7.4 Analyse de l'audit 11
7.5 Rapports d'audit 11
7.6 Clôture de l'audit 13
8. Compétence et évaluation des auditeurs 13
8.1 Compétence des auditeurs 13
8.2 Démonstration de la compétence de l'auditeur 14
9. Contrôle des documents 15
9.1 Auteurs 15
9.2 Histoire 15
9.3 Retour d'information 15
9.4 Copyright 15
Copyright © ISO27k Forum, 2017 1|Page
Ligne directrice sur l'audit du SGSI
Boîte à outils ISO27k v2
Annexe A - Liste de contrôle générique pour l'audit de sécurité des

informations 16
Introduction 16
A.5. Politiques de sécurité de l'information 17
A.6. Organisation de la sécurité de l'information 17
A.6.1 Organisation interne 17
A.6.2 Appareils mobiles et télétravail 19
A.7. Sécurité des ressources humaines 19
A.7.1 Avant l'emploi 19
A.7.2 Pendant l'emploi 19
A.7.3 Licenciement et changement d'emploi 20
A.8. Gestion des actifs 20
A.8.1 Responsabilité des actifs 20
A.8.2 Classification des informations 22
A.8.3 Traitement des médias 22
A.9 Contrôle d'accès 23
A.9.1 Exigences commerciales du contrôle d'accès 23
A.9.2 Gestion de l'accès des utilisateurs 23
A.9.3 Responsabilités des utilisateurs 24
A.9.4 Contrôle de l'accès aux systèmes et applications 25
A.10. Cryptographie 25
10.1 Contrôles cryptographiques 25
A.11. Sécurité physique et environnementale 26
A.11.1 Zones sécurisées 26
A.11.2 Équipement 27
A.12. Sécurité des opérations 29
A.12.1 Procédures opérationnelles et responsabilités 29
A.12.2 Protection contre les logiciels malveillants 30
A.12.3 Sauvegarde 31
A.12.4 Enregistrement et surveillance 31
A.12.5 Contrôle des logiciels opérationnels 32
A.12.6 Gestion des vulnérabilités techniques 32
A.12.7 Considérations relatives à l'audit des systèmes
d'information 32
A.13. Sécurité des communications 33
A.13.1 Gestion de la sécurité des réseaux 33
A.13.2 Transfert d'informations 33
A.14. Acquisition, développement et maintenance des systèmes 34

Ligne directrice sur l'audit du
Boîte à outils ISO27k SGSI v2
A.14.1 Exigences de sécurité des systèmes d'information 34
A.14.2 Sécurité dans les processus de développement et de
soutien 34
A.14.3 Données d'essai 36
A.15. Relations avec les fournisseurs 36
A.15.1 Sécurité de l'information dans les relations avec les
fournisseurs 36
A.15.2 Gestion de la prestation de services des fournisseurs 37
A.16. Gestion des incidents de sécurité de l'information 37
A.16.1 Gestion des incidents de sécurité de l'information et améliorations 37
A.17. Gestion de la continuité des activités (selon la norme ISO
22301) 39
A.17.1 Continuité des activités 39
A.17.2 Licenciements 39
A.18. Conformité 40
A.18.1 Respect des exigences légales et contractuelles 40
A.18.2 Examens de la sécurité de l'information 41
Annexe B - Liste de contrôle générique pour l'audit du système de gestion du SGSI 42

Introduction 42
B.4. Contexte de l'organisation 43
B.4.1 Comprendre l'organisation et son contexte 43
B.4.2 Comprendre les besoins et les attentes des parties intéressées 43
B.4.4 Système de gestion de la sécurité de l'information 43
B.5. Leadership 44
B.5.1 Leadership et engagement 44
B.5.2 Politique 44
B.5.3 Rôles, responsabilités et pouvoirs de l'organisation 45
B.6. Planification 45
B.6.1 Actions visant à traiter les risques et les opportunités 45
B.6.2 Objectifs de sécurité de l'information et planification pour les atteindre 46
B.7. Support 46
B.7.1 Ressources 46
B.7.2 Compétence 46
B.7.3 Sensibilisation 47
B.7.4 Communication 47
B.7.5 Informations documentées 47
B.8. Opération 48
B.8.1 Planification et contrôle opérationnels 48
Ligne directrice sur l'audit du
Boîte à outils ISO27k SGSI v2
B.8.2 Évaluation des risques en matière de sécurité de
l'information 48
B.8.3 Traitement des risques liés à la sécurité de l'information 48
B.9. Évaluation des performances 49
B.9.1 Suivi, mesure, analyse et évaluation 49
B.9.2 Audit interne 50
B.9.3 Révision de la gestion 50
B.10. Amélioration 50
B.10.1 Non-conformité et mesures correctives 50
B.10.2 Amélioration continue 51
du SGSI v2
1. Introduction
Ce guide d'audit des systèmes de gestion de la sécurité de l'information est tenu à jour par les membres du
Forum ISO27k sur ISO27001security.com, une communauté internationale de praticiens qui utilisent
activement les normes de la famille ISO/IEC 27000 connues sous le nom de "ISO27k".
Nous l'avons initialement rédigé en 2008 pour contribuer au développement de la norme ISO/CEI 27007 en
fournissant ce que nous, en tant qu'experts de la mise en œuvre des SGSI et auditeurs de TI/SIG, pensions
être un contenu utile. Un objectif secondaire était de fournir une ligne directrice pragmatique et utile pour
les personnes impliquées dans l'audit des SGSI.
Depuis lors, la norme ISO/IEC 27007 a été publiée. D'autres normes ISO27k ont également été révisées, de
sorte que la ligne directrice a été entièrement mise à jour en 2017.
Le corps principal de cette ligne directrice concerne l'objectif et le processus de l'audit. L'annexe A est une
liste de contrôle (un ensemble générique de tests d'audit) pour l'audit des contrôles de sécurité de
l'information gérés par le SGSI. L'annexe B est une liste de contrôle pour l'audit du système de gestion lui-
même.
2. Portée et objectif de la présente ligne directrice

Cette ligne directrice fournit des conseils généraux aux auditeurs informatiques qui examinent les SGSI par
rapport aux normes ISO27k, principalement ISO/IEC 27001:2013 (la norme de certification spécifiant le
système de gestion) et ISO/IEC 27002:2013 (le code de pratique recommandant une série de contrôles de
sécurité de l'information).
Cette ligne directrice s'adresse en particulier aux personnes qui effectuent des Des notes explicatives, des
audits internes et des revues de direction de SGSI - et non des audits de conseils et des
certification formels. La ligne directrice doit être interprétée ou adaptée à des avertissements sont
situations spécifiques. Les audits sont normalement basés sur les risques, ce éparpillés dans des
qui donne une priorité naturelle au travail d'audit du SGSI reflétant les besoins encadrés de texte tout au
des entreprises en matière de gestion des risques et de la sécurité de
long de la ligne directrice.
l'information.
3. Références
Veuillez vous référer à :
• ISO/IEC 27000:2016 Technologies de l'information - Techniques de sécurité - Systèmes de management
de la sécurité de l'information - Vue d'ensemble et vocabulaire. Cette norme gratuite donne un aperçu
de la norme ISO27k et définit formellement de nombreux termes spécialisés utilisés dans les normes.
• ISO/IEC 27001:2013 Technologies de l'information - Techniques de sécurité - Exigences relatives aux
systèmes de gestion de la sécurité de l'information. Il s'agit de la spécification officielle d'un SGSI par rapport
à laquelle les organisations peuvent être certifiées conformes. La section 6 introduit la nécessité d'effectuer
des "audits internes du SGSI" et définit brièvement les principales exigences des procédures d'audit. La
section 7 identifie également la nécessité de procéder à des examens périodiques (au moins annuels) de la
gestion du SGSI. Outre les contrôles énumérés à l'annexe A, il s'agit d'exigences obligatoires pour les
organisations certifiées. Même si l'organisme met en œuvre un ensemble de contrôles alternatifs, les
contrôles choisis doivent être vérifiés par rapport à ceux énumérés à l'annexe A pour en vérifier la
pertinence et l'exhaustivité.
• ISO/IEC 27002:2013 Technologies de l'information - Techniques de sécurité - Code de pratique pour les
contrôles de sécurité de l'information. Développe considérablement l'annexe A de la norme ISO/IEC
27001.
• ISO/IEC 27003:2017 Technologies de l'information - Techniques de sécurité - Système de management de la
sécurité de l'information - Guide. En outre, des conseils pratiques sur la conception et la mise en œuvre d'un
SGSI opérationnel.

du SGSI v2
• ISO/IEC 27004:2016 Technologies de l'information - Techniques de sécurité - Gestion de la sécurité de
l'information - Surveillance, mesure, analyse et évaluation. Conseils sur le choix/développement et
l'utilisation de mesures pour gérer les risques et la sécurité de l'information de manière rationnelle et
proportionnée.
• ISO/IEC 27006:2015 Technologies de l'information - Techniques de sécurité - Exigences pour les
organismes procédant à l'audit et à la certification des systèmes de gestion de la sécurité de
l'information. Critères d'accréditation officiels pour les organismes de certification effectuant des
audits de conformité stricte à la norme ISO/IEC 27001.
• ISO/IEC 27007:2011 Technologies de l'information - Techniques de sécurité - Lignes directrices pour
l'audit des systèmes de gestion de la sécurité de l'information. Lignes directrices pour les organismes
de certification accrédités, les auditeurs internes, les auditeurs externes/tiers et les autres personnes
effectuant des audits de conformité des parties du système de gestion des SMSI par rapport à la norme
ISO/CEI 27001.
• ISO/IEC TR 27008:2011 Technologies de l'information - Techniques de sécurité - Lignes directrices pour
les auditeurs concernant les contrôles de sécurité de l'information. Lignes directrices pour les auditeurs
internes et les autres personnes chargées d'auditer ou d'examiner les aspects de la sécurité de
l'information des SGSI.
• ISO/IEC 27017:2015 Technologies de l'information - Techniques de sécurité - Code de pratique pour les
contrôles de sécurité de l'information basé sur l'ISO/IEC 27002 pour les services en nuage. Couvre les
contrôles de sécurité de l'information pour l'informatique en nuage.
• Autres normes ISO27k et normes connexes. Cet ensemble croissant de normes liées aux SGSI fournit
une foule de conseils judicieux sur les risques et la sécurité de l'information, la cybersécurité, la
sécurité dans les nuages, la continuité des activités (par exemple, ISO 22301) et d'autres sujets.
• ISO/IEC 17021-1:2015 Évaluation de la conformité - Exigences pour les organismes procédant à l'audit
et à la certification de systèmes de management - Partie 1 : Exigences. Orientations sur les audits de
conformité par les organismes de certification (audits "tiers").
• ISO 19011:2011 Lignes directrices pour l'audit des systèmes de management. Lignes directrices sur les
audits internes ("première partie") et les audits de fournisseurs ("seconde partie").
• La FAQ sur l'audit informatique contient des conseils généraux sur la réalisation d'un audit
informatique, les qualifications et compétences des auditeurs, le processus d'audit, etc.
• L'ISACA offre des conseils et un soutien professionnels aux professionnels de l'audit informatique.
• L'Institut des auditeurs internes soutient les auditeurs internes de toutes sortes.
4. Termes et définitions
La plupart des termes relatifs au SMSI utilisés dans ce guide et dans les normes connexes sont définis dans
les normes ISO/IEC 27000 et ISO 19011. Les termes spécifiques liés à l'audit des TI et du SMSI sont définis
ici par souci de clarté, tels qu'ils sont interprétés et utilisés dans le présent guide :
• Audit - processus par lequel un sujet d'audit est examiné de manière indépendante et fait l'objet d'un
rapport par un ou plusieurs auditeurs compétents au nom des parties prenantes. L'audit est un
processus systématique, indépendant, formel, structuré et documenté permettant d'obtenir des
preuves d'audit et de les tester objectivement afin de déterminer dans quelle mesure les critères
d'audit sont remplis ;
• Liste de contrôle de l'audit - un questionnaire structuré ou un plan de travail pour guider les auditeurs
dans l'examen du sujet de l'audit ;
• Critères d'audit - utilisés comme référence pour l'audit. Ils peuvent inclure des exigences ou des
objectifs que le SGSI devrait remplir (par exemple, la conformité aux normes ISO27k pertinentes, aux
politiques et procédures de l'entreprise, aux lois et règlements, aux obligations contractuelles, etc. ), et
les problèmes ou les objectifs que le SGSI devrait éviter (par exemple, les inefficacités telles que les
coûts excessifs de l'entreprise et les activités inappropriées, inutiles ou inefficaces) ;

du SGSI v2
• Preuves d'audit - informations vérifiables et factuelles recueillies dans le domaine audité, telles que
des documents écrits (par exemple, politiques, imprimés informatiques, formulaires remplis, rapports),
des notes ou enregistrements d'entretiens et d'autres observations (par exemple, photographies de
problèmes de sécurité physique) ;
• Constatation d'audit - résumé/description et analyse par l'auditeur d'un risque d'information
insuffisamment atténué ;
• Observation d'audit (également appelée opportunité d'amélioration) - conseil ayant moins de poids
qu'une recommandation d'audit, comme une suggestion qui - si elle est ignorée - peut conduire à une
non-conformité ou à un autre impact commercial (par exemple, des processus ou des systèmes non
optimaux) ;
• Plan ou programme d'audit - un plan de projet pour un audit exposant les principales activités d'audit
et leur calendrier ;
• Recommandation d'audit - une action corrective proposée pour répondre à une ou plusieurs
constatations d'audit identifiées, qui doit être traitée avant la certification ou la recertification du SGSI ;
• Rapport d'audit - un rapport formel à la direction documentant les principales constatations et
conclusions de l'audit. Il s'agit généralement d'un document écrit, mais il peut également comporter
une présentation et une discussion ;
• Risque d'audit - la possibilité qu'un audit n'atteigne pas ses objectifs, par exemple en utilisant des
informations peu fiables, incomplètes ou inexactes, ou en ne traitant pas les questions importantes de
manière suffisamment approfondie ;
• Calendrier des audits - un journal des audits prévus ;
• Portée ou objet de l'audit - l'organisation ou les parties d'une organisation qui font l'objet de l'audit ;
• Test d'audit - vérification effectuée par l'auditeur pour s'assurer qu'un contrôle est efficace, efficient et
adéquat pour atténuer un ou plusieurs risques d'information ;
• Documents de travail de l'audit - informations rédigées et recueillies par l'auditeur, qui consignent son
examen, ses constatations et son analyse du SGSI, telles que les listes de contrôle de l'audit complétées
;
• Audit de conformité - un type d'audit spécifiquement conçu pour évaluer la mesure dans laquelle le
sujet de l'audit satisfait aux exigences énoncées ;
• Audit du SGSI - un audit centré sur un système de gestion de la sécurité de l'information ;
• Audit basé sur le risque - un audit planifié et réalisé sur la base d'une évaluation des risques - en
particulier les risques liés à l'information dans le contexte ISO27k, plus les risques d'audit et autres
risques tels que la santé et la sécurité ;
• Travailleurs - un terme délibérément vague comprend les employés à temps plein et à temps partiel de
l'organisation (personnel et dirigeants) ainsi que les contractants, consultants, conseillers, techniciens
de maintenance et d'assistance, intérimaires, stagiaires/étudiants et autres personnes travaillant
directement au sein, pour et/ou sous le contrôle de l'organisation.
5. Principes de l'audit
domaine ou de l'activité examiné
La section 4 de la norme ISO 19011 couvre les principes de l'audit en
pour permettre l'accomplissement
général, y compris d'importants principes d'audit génériques, par
objectif de la mission d'audit.
exemple l'évaluation indépendante par rapport à des critères
convenus, ainsi que des principes plus spécifiques visant les audits de
systèmes de gestion. Pour toutes les questions liées à l'audit,
l'auditeur doit être indépendant tant dans son attitude que dans son
apparence. La fonction ou l'équipe d'audit doit être indépendante du
permet à l'auditeur de remarquer
L'indépendance concerne autant l'état d'esprit de l'auditeur que les des choses que les autres
relations hiérarchiques : une pensée objective, rationnelle et critique manquent ou ignorent.

du SGSI v2
6. Gestion de l'audit
6.1 Gestion du programme d'audit du SGSI

La gestion d'un programme d'audits du SGSI implique la planification, le contrôle et le suivi/la supervision
de celui-ci, par le biais d'activités telles que
• hiérarchiser, planifier et définir la portée de chaque audit du SGSI dans le cadre du programme de
travail global de l'audit, en combinant éventuellement des audits superficiels de grande envergure du
SGSI avec des audits plus ciblés, approfondissant les domaines particulièrement préoccupants (par
exemple, les problèmes de longue date ou les risques importants)
• Affecter des ressources appropriées pour entreprendre les audits planifiés et approuvés (par exemple,
s'assurer que les auditeurs du SGSI sont formés, compétents et motivés pour effectuer le travail à un
niveau de qualité requis) ;
• Organiser ou coordonner les audits du SGSI dans les organisations multisites, y compris les
multinationales et les structures de "groupe", où les comparaisons entre les SGSI en fonctionnement
dans les différentes unités commerciales peuvent aider à partager et à promouvoir les bonnes
pratiques ;
• l'audit des SGSI de secondes parties telles que les fournisseurs et les partenaires commerciaux
(remarque : la certification ISO/IEC 27001 d'une seconde partie par un organisme de certification
accrédité peut ou non fournir une assurance suffisante dans tous les domaines de préoccupation, par
exemple il peut y avoir des risques importants en matière d'information ou des implications en matière
de conformité découlant des services d'information fournis, ou des incidents et des préoccupations
peuvent indiquer des problèmes qui méritent d'être explorés).
6.2 Gestion d'un audit du SGSI

Chaque audit du SGSI est géré tout au long du processus décrit à la section 7. Activités de gestion des audits
inclure :
• Obtenir l'appui de la direction pour mener l'audit du SGSI tel que proposé dans les grandes lignes, avec
son accord de principe et l'autorisation de procéder au cadrage et à la planification détaillés (qui
peuvent conduire à une nouvelle étape d'autorisation une fois finalisés) ;
• Superviser, guider, motiver et soutenir les auditeurs, veiller à ce qu'ils suivent les pratiques d'audit
acceptées, examiner les dossiers et relire les projets de rapport ;
• Examiner et contester les conclusions non fondées ou notables, par exemple en se faisant l'avocat du
diable pour explorer les preuves, la profondeur de l'analyse et la nature des problèmes ; proposer des
explications alternatives et des recommandations potentielles ; aider les auditeurs à évaluer les risques
dans le contexte commercial ;
• Traiter les questions qui compromettent la mission d'audit, telles que les problèmes interpersonnels, le
manque d'engagement, les retards, la réticence ou le refus de fournir des informations essentielles,
etc. (les problèmes peuvent être soulevés ou portés à l'attention de toute personne impliquée dans le
processus) ;
• Assurer la liaison avec la direction, éventuellement en fournissant des mises à jour intermédiaires et en
fixant des attentes pour la phase de rapport d'audit.
du SGSI v2
7. Le processus d'audit
Bien que les noms et les détails des phases varient, les missions d'audit suivent généralement une
séquence logique dans ce sens :
L'itération est courante, par exemple lorsque l'analyse ou le compte

rendu nécessite des preuves supplémentaires, un travail de
terrain plus important peut être effectué.
7.1 Enquête de cadrage et de pré-audit

Au cours de cette phase, les auditeurs du SGSI déterminent le ou les principaux domaines d'intérêt de
l'audit et tous les domaines qui sont explicitement hors de portée, en se fondant normalement sur une
évaluation initiale fondée sur les risques et sur une discussion avec ceux qui ont commandé l'audit du SGSI.
Les sources d'information comprennent : des recherches générales sur l'industrie et l'organisation, plus les
normes ISO27k et les bonnes pratiques de sécurité, les rapports d'audit et de revue de direction antérieurs
du SGSI (et d'autres le cas échéant), et les documents du SGSI tels que la déclaration d'applicabilité, le plan
de traitement des risques et les politiques du SGSI.
Les auditeurs du SGSI doivent s'assurer que la portée de l'audit a un "sens" pour l'organisation. Il devrait
normalement correspondre au champ d'application du SGSI. Par exemple, les grandes organisations ayant
plusieurs divisions ou unités commerciales peuvent avoir des SGSI distincts, un SGSI global à l'échelle de
l'entreprise ou une combinaison de SGSI locaux et centralisés. Si le SGSI couvre l'ensemble de
l'organisation, les auditeurs peuvent être amenés à examiner le SGSI en vigueur dans tous les sites d'activité
- ou au moins dans un échantillon représentatif de ceux-ci - tels que le siège social et une sélection d'unités
d'activité, de départements, de sites, etc. distincts de leur choix.
Les auditeurs doivent accorder une attention particulière aux risques
Cela devrait être plus facile
liés à l'information et aux contrôles de sécurité associés aux conduits
lorsque les entités hors du
d'information vers d'autres entités (organisations, unités
champ d'application ont elles-
commerciales, etc.) qui ne relèvent pas du champ d'application du
mêmes été certifiées conformes
SGSI, par exemple en vérifiant l'adéquation des clauses relatives à la
à la norme ISO/IEC 27001.
sécurité de l'information dans les accords de niveau de service ou les
contrats avec les fournisseurs de services informatiques.
Au cours de l'étude préalable à l'audit, les auditeurs du SGSI identifient et, idéalement, prennent contact
avec les principales parties prenantes du SGSI, telles que le RSSI, les responsables des risques et de la
sécurité de l'information et des personnalités influentes, telles que le DSI et le PDG, ainsi que d'autres
professionnels, tels que les architectes et les administrateurs de la sécurité, les professionnels de
l'informatique, des ressources humaines, des installations et de la sécurité physique, les concepteurs et les
responsables de la mise en œuvre du SGSI... en profitant éventuellement de l'occasion pour demander la
documentation pertinente, etc. qui sera examinée au cours de l'audit.

du SGSI v2
La direction nomme normalement un ou plusieurs "accompagnateurs" d'audit, c'est-à-dire des personnes
chargées de veiller à ce que les auditeurs puissent se déplacer librement dans l'organisation et trouver
rapidement les personnes, les informations, etc. nécessaires pour mener à bien leur travail, en faisant office
de guides, de facilitateurs et de points de liaison avec la direction.
Le principal résultat de cette phase est un champ d'audit du SGSI, une charte, une lettre de mission ou un
document similaire, convenu entre les auditeurs et la direction du client. Des listes de contacts et d'autres
documents préliminaires sont également obtenus et les dossiers d'audit sont ouverts pour contenir la
documentation (documents de travail de l'audit, preuves, notes, retour d'information, rapports provisoires
et finaux, etc.
7.2 Planification et préparation de l'audit

Le champ d'application convenu du SGSI est détaillé, généralement en générant une liste de contrôle de
l'audit du SGSI (voir les annexes pour deux exemples détaillés mais génériques).
Le calendrier et les ressources globales de l'audit sont négociés et convenus par la direction de
l'organisation auditée et les auditeurs du SGSI, sous la forme d'un plan ou d'un calendrier d'audit. Les
techniques conventionnelles de planification de projet (telles que les diagrammes de GANTT montrant les
phases, les durées, les jalons, etc.
Les plans d'audit définissent et délimitent les grandes lignes des
Les listes de contrôle figurant dans la
phases restantes de l'audit (par exemple, les délais). Il est courant à
présente ligne directrice ne sont pas
ce stade de faire des réservations préliminaires pour le rapport
destinées à être utilisées sans avoir
d'audit officiel/la réunion de discussion prévue à la fin de l'audit
été dûment prises en considération et
afin de permettre aux participants de haut niveau de programmer
modifiées. Il ne s'agit que
leur participation.
d'indications. Les auditeurs
Les plans d'audit comprennent souvent aussi des "points de établissent normalement des listes de
contrôle" - des possibilités spécifiques pour les auditeurs de fournir contrôle personnalisées reflétant la
des mises à jour intermédiaires informelles à leurs contacts de portée et l'échelle spécifiques du SGSI
gestion, y compris une notification préliminaire de toute particulier audité, en tenant compte
incohérence observée ou de toute non-conformité potentielle, etc. des exigences pertinentes qui sont
Il s'agit également d'occasions de faire part de toute préoccupation déjà évidentes à ce stade (telles que
concernant l'accès limité aux informations ou aux personnes, et les lois, règlements et normes liés à la
pour la direction de faire part de toute préoccupation concernant la sécurité de l'information qui sont
nature des travaux d'audit. Bien que les auditeurs soient communément connus dans le
nécessairement indépendants, ils doivent établir un niveau de secteur).
confiance et un environnement de travail coopératif afin de
s'engager suffisamment et d'obtenir les informations nécessaires à
l'audit du SGSI. L'approche professionnelle, la compétence et
l'intégrité sont essentielles.
Enfin, le calendrier des éléments importants des travaux d'audit peut être déterminé, notamment afin de
hiérarchiser les aspects qui sont censés représenter les plus grands risques pour l'organisation si le SGSI est
jugé inadéquat.
Le résultat de cette phase est la liste de contrôle (personnalisée) de l'audit et un plan d'audit convenu avec
la direction.
7.3 Travail d'audit sur le terrain

Il s'agit généralement de la phase la plus longue d'un audit, bien que les rapports puissent également être
longs.
Copyright © ISO27k Forum, 2017 10 | P a g e
du SGSI v2
Au cours du travail sur le terrain, les auditeurs recueillent des preuves
d'audit en utilisant méthodiquement la liste de contrôle de l'audit, par Les listes de contrôle peuvent
exemple en interrogeant le personnel, les gestionnaires et les autres être modifiées au cours des
parties prenantes associées au SGSI, en examinant les documents, les audits, par exemple si des
imprimés et les données du SGSI (y compris les enregistrements des domaines de préoccupation
activités du SGSI tels que les examens des journaux de sécurité), en précédemment sous-estimés
observant les processus du SGSI en action et en vérifiant les sont mis en évidence ou s'il
configurations de sécurité du système, etc. Des tests d'audit sont est approprié de modifier
effectués pour évaluer et valider les éléments de preuve au fur et à l'importance ou le niveau de
mesure qu'ils sont recueillis. Des tests d'audit sont effectués pour évaluer détail à la suite des
et valider les éléments probants au fur et à mesure qu'ils sont recueillis. informations obtenues.
Des documents de travail sont préparés, documentant les tests effectués, Même la portée de l'audit
les preuves recueillies et les premiers résultats. peut être modifiée, à
condition que le changement
La première partie du travail sur le terrain consiste généralement en un soit justifié et approuvé par la
examen de la documentation. L'auditeur lit et prend des notes sur la direction.
documentation relative au SGSI et découlant de celui-ci (telle que la
déclaration d'applicabilité, le plan de traitement des risques, la politique
du SGSI, etc. ). ). L'auditeur produit une documentation d'audit
comprenant des éléments probants et des notes sous la forme de listes
de contrôle et de documents de travail d'audit remplis.
Les conclusions de l'examen de la documentation indiquent souvent la nécessité de tests d'audit
spécifiques pour déterminer dans quelle mesure le SGSI tel qu'il est actuellement mis en œuvre suit la
documentation, ainsi que pour tester le niveau général de conformité et la pertinence de la documentation
par rapport à la norme ISO/CEI 27001. Les tests d'audit types sont présentés en annexe A et en annexe B.
Les résultats des tests d'audit sont normalement enregistrés par les auditeurs dans des listes de contrôle,
avec les preuves, notes et autres documents dans le dossier d'audit.
Des tests de conformité technique peuvent être nécessaires pour vérifier que les systèmes informatiques
sont configurés conformément aux politiques, normes et directives de l'organisation en matière de sécurité
de l'information. Les outils automatisés de vérification de la configuration et d'évaluation des vulnérabilités
peuvent accélérer le rythme auquel les contrôles de conformité technique sont effectués, mais ils
introduisent potentiellement leurs propres problèmes de sécurité qui doivent être pris en compte*.
Le résultat de cette phase est une accumulation de documents de travail et de preuves dans les dossiers
d'audit.
7.4 Analyse de l'audit

Les preuves d'audit accumulées sont triées et Parfois, l'analyse identifie des lacunes dans les
classées, examinées et analysées par rapport aux éléments probants ou indique la nécessité de tests
risques et aux objectifs ou exigences en matière d'audit supplémentaires, auquel cas un travail de
d'information, tels que ceux des normes ISO/IEC terrain supplémentaire peut être effectué, à moins
27001 et 27002 ou d'autres normes et références, que le temps et les ressources prévus n'aient été
ainsi que par rapport à la portée et aux objectifs de épuisés. Toutefois, la hiérarchisation des activités
l'audit. Des constatations, conclusions et d'audit en fonction du risque implique que les
recommandations préliminaires peuvent être domaines les plus importants devraient déjà avoir
rédigées à ce stade, concernant tout problème été couverts.
important identifié.
7.5 Rapports d'audit

Le rapport est une partie importante du processus d'audit, et un sous-processus impliqué à lui seul.
Un rapport d'audit typique du SGSI contient les éléments suivants, dont certains peuvent être divisés en
annexes ou en documents séparés :
• Titre et introduction désignant l'organisation et précisant le champ d'application, les objectifs, la
période de couverture et la nature, le calendrier et l'étendue des travaux d'audit réalisés.
• Un résumé indiquant les principales constatations de l'audit, une brève analyse et un commentaire, ainsi
qu'une conclusion générale, généralement du type "Nous estimons que le SGSI est conforme à la norme
ISO/CEI 27001 et mérite

•
du SGSI v2
certification" ou "Mis à part [des préoccupations importantes], nous sommes impressionnés par la
couverture et l'efficacité des contrôles de sécurité de l'information au sein du SGSI".
 Le rapport prévu énumère des destinataires spécifiques (puisque le contenu peut être confidentiel)
et contient une classification appropriée des documents ou des instructions sur la circulation.
- aperçu des qualifications, des méthodes d'audit, etc. des auditeurs individuels et des membres de
l'équipe ;
 Les résultats et l'analyse détaillés des audits, parfois accompagnés d'extraits des preuves à l'appui
•
•
Le rapport d'audit est peut-
être le seul domaine où
l'indépendance formelle de
l'audit est essentielle. Les
auditeurs sont censés "dire ce
qui doit être dit". Toutefois,
étant donné l'objectif
d'améliorer le SGSI et de faire
progresser l'organisation, il est
utile de formuler les choses
avec beaucoup de prudence...
ce qui demande de
l'expérience, du tact et du
temps.
dans les dossiers d'audit lorsque cela facilite la compréhension.
 Les conclusions et les recommandations de l'audit, peut-être présentées initialement comme des
propositions provisoires à discuter avec la direction et finalement intégrées comme plans d'action convenus
en fonction de la situation locale
pratiques.
 Une déclaration formelle des auditeurs concernant toute réserve,
qualification, limitation de la portée ou autre réserve concernant l'audit.
 Selon les pratiques d'audit habituelles, la direction peut être
invitée à fournir un bref commentaire ou une réponse officielle, en
acceptant les résultats de l'audit et en s'engageant à prendre les
mesures convenues.
Il est important qu'il y ait une base factuelle, c'est-à-dire des preuves d'audit
suffisantes et appropriées pour étayer les constatations rapportées. Les
processus d'assurance qualité de l'audit doivent garantir que "tout ce qui
doit être signalé est signalé et tout ce qui est signalé est à signaler",
normalement sur la base d'un examen du dossier d'audit par un auditeur
principal expérimenté. La formulation du projet de rapport d'audit est
vérifiée pour en assurer la lisibilité, en évitant toute ambiguïté et les
déclarations non étayées. Lorsqu'il est approuvé par la direction de l'audit
pour diffusion, le projet de rapport d'audit est généralement présenté et
discuté
avec la direction. D'autres cycles d'examen et de révision du rapport peuvent avoir lieu jusqu'à ce qu'il soit
finalisé. La finalisation implique généralement que la direction s'engage à respecter le plan d'action.
L'évaluation par l'auditeur de l'importance des problèmes ou des lacunes identifiés au cours de l'audit est
le principal facteur déterminant d'un résultat "satisfaisant" ou "non satisfaisant". Les résultats d'audit sont
généralement classés en fonction de leur importance ou de leur gravité et (au moins en ce qui concerne les
audits de certification) communiqués comme suit :
Major Non-conformité Rapport (NCR) : a non-conformité que Les grands RNC sont des
affecte substantiellement la capacité du SGSI à atteindre ses objectifs. obstacles : lors des audits de
Les non-conformités peuvent être classées comme majeures dans les certification, ils sont
circonstances suivantes : susceptibles d'entraîner un
• S'il existe un doute important quant à l'existence d'un contrôle efficace refus de délivrer ou de
du processus ou quant au fait que la confidentialité, l'intégrité et la renouveler un certificat de
disponibilité des informations répondent à des exigences précises ; ou conformité, à moins que les
• Un certain nombre de non-conformités mineures associées à la même problèmes identifiés ne
exigence ou au même problème sont des symptômes indiquant une soient résolus à la
défaillance plus profonde et plus substantielle du système de gestion (par satisfaction des auditeurs.
exemple, une mauvaise gouvernance).
NCR mineur : une non-conformité qui n'affecte pas de manière substantielle la capacité du SGSI à
atteindre ses objectifs. La "substantialité" est une question subjective que l'auditeur doit déterminer, en
tenant compte des facteurs suivants
tels que :
• Le degré d'écart par rapport aux recommandations des normes ISO27k, ou par rapport aux bonnes
pratiques généralement acceptées dans ce domaine ;
• Si la non-conformité est délibérée/intentionnelle, ou simplement un oubli ;

du SGSI v2
• La durée de la non-conformité - une question complexe car il est parfois utile de porter à l'attention de
la direction des problèmes de longue date, mais l'organisation peut avoir réussi à faire face à la non-
conformité pendant la période intermédiaire ;
• La quantité d'informations risque de nuire à l'organisation (de loin le facteur le plus important).
Observation ou opportunité d'amélioration : un exposé des faits basé sur et étayé par des preuves
objectives, identifiant une faiblesse ou une déficience potentielle du SGSI qui, si elle n'est pas résolue, peut,
selon l'auditeur, conduire à une non-conformité à l'avenir.
Selon les conventions et les circonstances, l'auditeur peut offrir des Même s'ils ne figurent pas dans les
recommandations, des orientations et des conseils formels ou rapports d'audit formels, les
informels (par exemple, la promotion de bonnes pratiques et recommandations, observations et
d'autres améliorations), mais aucune solution spécifique ne doit conseils doivent normalement être
nécessairement être fournie. Si une conclusion d'audit est exprimée consignés dans le dossier d'audit. Les
de manière efficace et que le problème est discret, la résolution constatations peuvent être gérées
sera souvent évidente. En fin de compte, grâce à l'indépendance de comme des risques identifiés, ce qui
l'audit, c'est à la direction - et non à l'audit - qu'il incombe de peut inciter à effectuer un travail de
résoudre les problèmes, en agissant au mieux des intérêts de suivi lors de futurs audits internes, de
l'organisation et en tenant compte des autres professionnels et surveillance ou de recertification et
objectifs de l'entreprise. La direction doit décider de ce qu'il faut de revues de direction.
faire et quand le faire, le cas échéant. En bref, les audits sont
simplement consultatifs.
Le résultat de cette phase est un rapport d'audit du SGSI achevé, signé, daté et distribué selon les termes
de la lettre de mission d'audit.
7.6 Clôture de l'audit

En plus de l'indexation, des références croisées et de la fermeture littérale des dossiers d'audit, la clôture
implique de régler les derniers détails, de préparer des notes pour les futurs audits du SGSI ou d'autres
audits, et peut-être d'assurer un suivi pour vérifier que les actions convenues sont effectivement menées à
bien plus ou moins dans les délais et selon les spécifications.
8. Compétence et évaluation des auditeurs

8.1 Compétence des auditeurs
Les exigences suivantes s'appliquent à l'équipe d'audit dans son ensemble, ou à l'auditeur s'il travaille seul.
Dans chacun des domaines de connaissance et d'expertise suivants, au moins un membre de l'équipe
d'audit doit assumer la responsabilité principale au sein de l'équipe :
• La gestion de l'équipe, la planification de l'audit et les processus d'assurance qualité de l'audit ;
• Principes, méthodes et processus d'audit ;
• Les systèmes de gestion en général et le SGSI en particulier ;
• Obligations législatives, réglementaires et contractuelles pertinentes applicables à l'organisme contrôlé ;
• Les menaces, vulnérabilités et incidents liés à l'information, notamment en ce qui concerne
l'organisation auditée et les organisations comparables, par exemple une appréciation de la probabilité
de divers types d'incidents de sécurité de l'information affectant différentes formes d'information, leur
gravité et leurs impacts potentiels, les contrôles généralement utilisés pour atténuer les risques ainsi
que d'autres options de traitement des risques telles que la cyberassurance ;
• les techniques de mesure du SGSI (mesures de sécurité de l'information) ;

du SGSI v2
• Normes ISMS pertinentes, meilleures pratiques de l'industrie, politiques et procédures de sécurité ;
• Gestion de la continuité des activités, y compris l'évaluation de l'impact sur les activités, la gestion des
incidents, la résilience, la reprise et les aspects liés aux imprévus ;
• l'application des technologies de l'information aux entreprises et, partant, la pertinence et la nécessité
de la cybersécurité ; et
• Principes, méthodes et processus de gestion des risques liés à l'information.
L'équipe d'audit doit être compétente pour remonter jusqu'aux éléments pertinents du SGSI, ce qui
implique que les auditeurs aient une expérience professionnelle et une expertise pratique appropriées dans
les domaines mentionnés ci-dessus. Cela ne signifie pas que chaque auditeur doit posséder une expérience
et des compétences complètes dans tous les aspects de la sécurité de l'information, mais l'équipe d'audit
dans son ensemble doit avoir une expérience suffisamment large et des compétences suffisamment
approfondies pour couvrir l'ensemble du champ d'application du SGSI audité.
En ce qui concerne les audits du SGSI, en particulier, les auditeurs doivent se tenir au courant :
• Le domaine : il s'agit d'un domaine dynamique qui connaît des changements fréquents en ce qui
concerne les risques liés à l'information (c'est-à-dire les menaces, les vulnérabilités et/ou les impacts),
les contrôles de sécurité et le cyberenvironnement en général. Il est donc important que les auditeurs
du SGSI maintiennent leurs connaissances des menaces émergentes et actuelles, des vulnérabilités
activement exploitées et de la nature changeante des incidents et des impacts dans le contexte de
l'activité de l'organisation.
• Changements apportés à la norme ISO27k et à d'autres normes, lignes directrices, etc. : outre les
nouvelles normes et les mises à jour de la série ISO/CEI 27000, il y a de fréquents changements dans
d'autres normes (par exemple la série NIST SP800), lignes directrices et conseils potentiellement
pertinents (par exemple de l'ISACA).
• Modifications juridiques et réglementaires : Le règlement général sur la protection des données de l'UE
(GDPR) est un exemple d'actualité d'un changement important à venir dans les lois et pratiques
relatives à la protection de la vie privée, avec des implications pour les entreprises à l'échelle mondiale.
• Changements commerciaux et organisationnels : par exemple, modification des activités commerciales,
des processus, des priorités et des relations.
• Les changements technologiques : par exemple, nouveaux matériels, logiciels et microprogrammes ;
nouveaux paradigmes tels que l'IdO (Internet des objets), le BYOD (Bring Your Own Device) et
l'informatique en nuage.
8.2 Démonstration de la compétence de l'auditeur

Les auditeurs doivent être en mesure de démontrer leurs connaissances et leur expérience, par exemple
par le biais
• Détenir des qualifications reconnues et pertinentes telles que la CISA ;
• Inscription en tant qu'auditeur auprès d'un organisme professionnel L'audit est une activité
reconnu tel que l'ISACA ; hautement privilégiée qui
• Avoir suivi des cours de formation reconnus en matière de SGSI, tels dépend de la confiance et du
que "chef de la mise en œuvre" et "auditeur principal" ; respect des personnes
• Des dossiers de formation professionnelle continue à jour ; contrôlées, qui doivent être
• les documents confirmant les audits auxquels ils ont participé (en gagnés par des normes
particulier les audits du SGSI et des TI), et leurs rôles ; et/ou élevées et constantes de
• Démonstration pratique à des auditeurs plus expérimentés au cours professionnalisme, de
compétence et d'intégrité
d'audits de SGSI ;
personnelle.
- la confiance et le respect des collègues.

du SGSI v2
9. Contrôle des documents
9.1 Auteurs
Les membres suivants du Forum ISO27k ont mis à jour cette ligne directrice en 2017 : Bhushan
Kaluvakolan ; Richard Regalado ; Gary Hinson et Pratibha Agrawal.
Les personnes suivantes ont contribué à la version originale de 2012 de la ligne directrice : Alchap ; Javier
Cao Avellaneda ; Anton Aylward ; Pritam Bankar ; Jesus Benitez ; Lee Evans ; Gary Hinson ; Khawaja Faisal
Javed ; Lakshminarayanan ; ; Rocky Lam ; Prasad Pendse ; Renato Aquilino Pujol ; Bala Ramanan ; Marappan
Ramiah ; Richard Regalado ; Mninikhaya Qwabaza (Khaya) ; Kim Sassaman ; Mooney Sherman ; John South ;
Jasmina Trajkovski ; Rob Whitcher et autres.
9.2 Historique
Mars 2008 - Première publication de la ligne directrice soumise au comité ISO/IEC JTC1/SC27 via Standards
New Zealand, et publiée dans le cadre du Toolkit ISO27k gratuit.
Juillet-août 2017 - Mise à jour de l'ensemble du document, d'abord par un travail d'équipe en utilisant
Google Docs, puis finalisation en MS Word, et nouvelle publication dans la boîte à outils ISO27k.
9.3 Réactions
Les commentaires, les questions et (surtout !) les suggestions d'amélioration sont les bienvenus, soit via le
forum ISO27k, soit directement à Gary Hinson (Gary@isect.com).
9.4 Droits d'auteur

Cette ligne directrice est protégée par copyright © 2017, ISO27k Forum, certains droits réservés. Il
est soumis à la licence Creative Commons Paternité-Pas d'Utilisation Commerciale-Partage des
Conditions Initiales à l'Identique 3.0. Vous pouvez reproduire, faire circuler, utiliser et créer des
œuvres dérivées à condition que (a) il ne soit pas vendu
ou incorporé dans un produit commercial, (b) il est correctement attribué au Forum ISO27k à l'adresse
www.ISO27001security.com, (c) s'il est partagé, les travaux dérivés sont partagés dans les mêmes
conditions que celui-ci.
Le Forum ISO27k est une communauté

mondiale amicale et généreuse de ~3 500
professionnels des SMSI et constitue une
excellente source de conseils, de soutien
et d'orientation. ISO27001security.com
propose des informations sur les normes
ISO27k, une FAQ et une boîte à outils.
Et surtout, c'est gratuit !

du SGSI v2
Annexe A - Liste de contrôle générique pour l'audit de sécurité

des informations
Introduction
La liste de contrôle suivante des tests d'audit est générique. Elle reflète et se réfère principalement aux
conseils de la norme ISO/IEC 27002 sur les contrôles de sécurité de l'information, sans tenir compte des
exigences de contrôle spécifiques qu'une organisation individuelle pourrait avoir en ce qui concerne ses
risques d'information identifiés par les processus d'évaluation et de gestion des risques.
Il s'agit d'un guide générique pour aider à examiner les contrôles de Nous avons délibérément modifié,
sécurité de l'organisation, principalement par rapport aux étendu ou développé les conseils
recommandations de l'annexe A de la norme ISO/IEC 27001, de la de la norme ISO/IEC 27002 dans
norme ISO/IEC 27002 et d'autres normes ISO27k. Il ne peut pas divers domaines, sur la base de
fournir de conseils spécifiques sur les risques et contrôles particuliers notre travail professionnel et de
applicables à chaque situation et doit donc être personnalisé et notre expérience d'audit des SGSI
interprété par des auditeurs informatiques expérimentés en fonction dans diverses organisations et
du contexte. Par exemple, l'analyse des risques de l'organisation peut industries qui prennent la sécurité
avoir déterminé que certains objectifs de contrôle des normes ne sont de l'information au sérieux (par
pas applicables et donc que les contrôles correspondants peuvent ne exemple, nous avons intégré des
pas être requis, alors que dans d'autres domaines, les objectifs de tests d'audit sur la continuité des
contrôle peuvent être plus rigoureux que ceux suggérés dans la norme activités). Il ne s'agit pas d'une
et des contrôles supplémentaires peuvent être requis. Le plan de liste de contrôle simple pour
traitement des risques et la déclaration d'applicabilité doivent fournir l'audit de conformité.
de plus amples détails à ce sujet.
Les tests d'audit mentionnés ci-dessous sont destinés à rappeler les principaux aspects que des auditeurs
informatiques compétents, qualifiés et expérimentés vérifient habituellement. Ils ne couvrent pas tous les
aspects des risques liés à l'information, de la sécurité et des domaines connexes. Ils ne sont pas destinés à
être demandés mot pour mot ou à être cochés au coup par coup. Ils ne conviennent pas aux auditeurs
inexpérimentés qui travaillent sans supervision.
La liste de contrôle n'est pas destinée à être utilisée sans avoir été dûment examinée et modifiée. Les
auditeurs de SGSI génèrent normalement des listes de contrôle personnalisées reflétant la portée et
l'échelle spécifiques du SGSI particulier audité, en tenant compte de toute exigence en matière de sécurité
de l'information déjà évidente à ce stade (comme les lois, règlements et normes en matière de sécurité de
l'information qui sont connus pour s'appliquer à des organisations similaires dans l'industrie). En outre, la
liste de contrôle de l'audit peut être modifiée au cours de l'audit si des sujets de préoccupation
précédemment sous-estimés sont mis en évidence. Enfin, la liste de contrôle doit refléter les pratiques de
travail normales des auditeurs, par exemple les colonnes des notes d'audit, les références aux preuves
d'audit figurant dans les dossiers, les analyses SWOT/PEST des constatations, etc.
Étant donné que les listes de contrôle, les dossiers, les notes et les preuves de l'audit du SGSI
contiennent des informations sensibles concernant les risques liés à l'information et les dispositions de
sécurité de l'organisation, ils doivent être correctement sécurisés pour garantir leur confidentialité et
leur intégrité.
Ligne directrice sur l'audit du SGSI v2
De nombreux contrôles de sécurité de

l'information impliquent des politiques,
c'est pourquoi les politiques
apparaissent souvent dans cette liste de
contrôle avec des tests d'audit reflétant
divers contextes et objectifs. Le point
A.5.1.1 donne un aperçu de l'ensemble
des politiques.
Boîte à outils ISO27k
A.5. Politiques de sécurité de l'information

A.5.1 Orientation de la gestion de la sécurité de l'information
A.5.1.1 Politiques en matière de sécurité de l'information :
examiner les politiques de l'organisation en matière de risque, de
sécurité et de domaines connexes (par exemple, confidentialité,
continuité des activités, conformité, gouvernance, gestion des
risques, ressources humaines, sécurité physique/site, gestion des
changements, gestion de la configuration, gestion des incidents,
journalisation, classification, développement et acquisition de
systèmes, etc.) Existe-t-il des preuves évidentes d'une
et géré un cadre/structure/hiérarchie global(e) ? Les politiques sont-elles raisonnablement complètes, couvrant
tous les risques d'information et les domaines de contrôle pertinents ? Comment les politiques sont-elles
autorisées, communiquées, comprises et acceptées ? Tous les travailleurs et, le cas échéant, leurs employeurs
sont-ils officiellement tenus de s'y conformer ? Existe-t-il des dispositions appropriées pour faire respecter et
renforcer la conformité ? Examinez les politiques, normes, procédures, lignes directrices, etc. pour vérifier leur
cohérence avec : les bonnes pratiques (telles que ISO27k, NIST SP800 et autres normes, avis et lignes directrices
pertinents) ; les obligations légales, réglementaires et contractuelles applicables ; les stratégies d'entreprise et
autres politiques. Existe-t-il des références croisées appropriées, tant internes qu'externes ? Les politiques sont-
elles bien rédigées, c'est-à-dire lisibles, raisonnables et applicables ? Comprennent-elles des contrôles
appropriés et suffisants ? Couvrent-elles tous les actifs, systèmes, services d'information essentiels, etc. Quel est
le degré de maturité de l'organisation dans ce domaine ? Recherchez les problèmes (lacunes, chevauchements,
incohérences/conflits, rédaction de mauvaise qualité, politiques obsolètes/non approuvées, délais de révision
non respectés, etc.
A.5.1.2 Examen des politiques de sécurité de l'information : évaluer le processus d'examen de la sécurité
de l'information et des politiques connexes. Examinez un échantillon de politiques pour obtenir des détails
tels que : le titre de la politique ; sa portée et son applicabilité ; son statut (par exemple, projet, autorisé,
remplacé, retiré) ; les noms des auteurs et des propriétaires responsables ; les numéros de version ; les
dates de publication ; la personne qui les a approuvées (par exemple, le comité de sécurité ou un organe de
gestion équivalent) ; l'historique du document / la date des derniers et prochains examens ; les dispositions
de conformité associées. Toutes les politiques ont-elles un format et un style cohérents ? Sont-elles toutes à
jour, ont-elles fait l'objet de toutes les révisions requises (y compris le retour d'information des révisions et
des audits de gestion du SGSI) et, le cas échéant, ont-elles été autorisées à nouveau et distribuées ? Vérifier
par recoupement les preuves d'approbations/autorisations pour un petit échantillon. Recherchez les
problèmes et les possibilités d'amélioration.
A.6. Organisation de la sécurité de l'information

A.6.1 Organisation interne
A.6.1.1 Rôles et responsabilités en matière de sécurité de l'information : vérifier le risque global lié à
l'information et la structure de gouvernance et de gestion de la sécurité. Les risques et la sécurité de
l'information sont-ils suffisamment pris en compte (y a-t-il une "force motrice" ?) et le soutien de la
direction ? Existe-t-il un forum de la haute direction pour discuter des politiques, des risques et des
problèmes liés aux risques et à la sécurité de l'information ? Les rôles et les responsabilités sont-ils
clairement définis et attribués à des personnes suffisamment qualifiées ? Chaque rôle a-t-il une
responsabilité spécifique à l'égard du risque et de la sécurité de l'information, une autorité compétente et
ces personnes sont-elles compétentes (qualifiées) pour ce rôle ? Existe-t-il un budget suffisant pour les
activités liées aux risques et à la sécurité de l'information ? Y a-t-il une coordination au sein de
l'organisation entre les unités opérationnelles et le siège ? Les flux d'information (par exemple, les rapports
d'incidents) fonctionnent-ils efficacement dans la pratique ? La structure et les dispositions de gouvernance
en matière de risque et de sécurité de l'information sont-elles suffisamment connues et soutenues ?
A.6.1.2 Séparation des tâches : vérifier que les tâches opérationnelles ou les tâches qui sont d'une
importance critique pour la sécurité de l'information ont été identifiées, en particulier celles qui sont
effectuées par le service de sécurité et de risque de l'information

du SGSI v2
les professionnels et le personnel informatique ayant des privilèges élevés sur les principaux systèmes
d'information (serveurs, dispositifs de réseau, bases de données, applications, etc.) Sur la base de
l'évaluation des risques, les tâches sont-elles séparées entre les rôles ou les personnes, le cas échéant, par
exemple pour réduire les risques d'incompétence, de négligence et d'activités inappropriées ? Idéalement,
une matrice de type RACI devrait être tenue à jour, identifiant pour chaque tâche/tâche clé qui est
Responsable, redevable, consulté ou tenu informé, en précisant par exemple que
• L'administration des réseaux et des systèmes doit être séparée de l'administration de la sécurité ;
• Un demandeur d'accès ne devrait pas pouvoir approuver ses propres demandes, ni pouvoir créer ses
propres identifiants de connexion ;
• Le rapprochement des droits d'accès ne doit pas être effectué uniquement par les administrateurs du
système ;
• Les développeurs d'applications et les testeurs ne devraient pas avoir un accès systématique aux
environnements de production ;
• Les demandeurs de changement ne devraient pas avoir le pouvoir d'approuver leurs propres demandes
;
• La révision des règles de pare-feu ne doit pas être effectuée uniquement par les administrateurs de
réseau ;
• Les journaux de sécurité, les rapports d'incidents, les alarmes et les alertes ne doivent pas être utilisés
et examinés uniquement par des professionnels de l'informatique ;
• Les audits doivent être réalisés par des auditeurs compétents et indépendants.
Existe-t-il une politique de séparation des tâches ? Comment les décisions concernant cette séparation
sont-elles prises ? Qui est habilité à prendre de telles décisions ? Les tâches séparées sont-elles
réexaminées périodiquement, lorsque les situations et les risques changent ou lorsque des incidents
surviennent ? Lorsque la séparation des tâches est impraticable ou irréalisable (par exemple, dans une
petite organisation), des contrôles compensatoires sont-ils utilisés (par exemple, enregistrement
supplémentaire ou surveillance de la gestion) ? Un suivi régulier des activités et des pistes d'audit est-il
effectué ? Y a-t-il une supervision adéquate de la gestion, en particulier pour les aspects critiques (par
exemple, des travailleurs inexpérimentés, stressés ou peu fiables effectuant un travail de sécurité peu
familier, complexe et/ou particulièrement important) ?
A.6.1.3 Contact avec les autorités : existe-t-il une liste facilement accessible des coordonnées des autorités
et organismes de régulation ou autres qui pourraient devoir être contactés en cas de questions, d'incidents
et d'urgences, par exemple les services de police, les services d'urgence et le personnel de
maintenance/support pour les services de chauffage, de ventilation et de climatisation, d'électricité,
d'approvisionnement en eau, de télécommunications, etc. Vérifiez qui est chargé de contacter les autorités
et à quel moment d'un incident / événement ce contact est-il établi et comment ? Vérifiez si cela a déjà été
fait auparavant et si un contact informel et régulier est maintenu avec ces autorités afin que les deux
parties (l'entreprise et ces autorités) ne soient pas surprises en cas d'urgence. Vérifiez, à l'aide des résultats
de l'évaluation des risques, si les coordonnées des autorités compétentes pour les risques significatifs
identifiés sont disponibles. La liste est-elle à jour et correcte ? Existe-t-il un processus de mise à jour ? (Voir
également le registre de conformité au point A.18.1.1).
A.6.1.4 Contacts avec les groupes d'intérêt spéciaux : existe-t-il des contacts réguliers ou ad hoc avec des
groupes d'intérêt spéciaux, des forums professionnels et des listes de diffusion sur les risques et la sécurité
de l'information, tels que les chapitres locaux de l'ISACA, l'ISC2, l'ISSA, le forum ISO27k, etc. Des
informations sont-elles partagées sur les menaces émergentes, les nouvelles technologies de sécurité, les
bonnes pratiques de sécurité, les alertes et avis précoces, les vulnérabilités récemment découvertes et la
disponibilité des correctifs, etc.
A.6.1.5 Sécurité de l'information dans la gestion de projet : examiner les aspects liés au risque et à la
sécurité de l'information dans les méthodes de gouvernance et de gestion de projet de l'organisation. Les
risques liés à l'information et les exigences en matière de sécurité sont-ils identifiés et pris en compte à tous
les stades de tous les projets, y compris tous les types de projets qui concernent l'information, les nouveaux
développements et les changements/améliorations des systèmes, applications et processus existants ?
Chaque étape du projet comprend-elle des activités appropriées ? Les propriétaires des
systèmes/applications/processus/risques acceptent-ils formellement les risques résiduels (par exemple
dans le cadre de l'acceptation finale) ?

du SGSI v2
A.6.2 Appareils mobiles et télétravail
A.6.2.1 Politique en matière de dispositifs mobiles : examiner la politique et les contrôles de sécurité
relatifs aux utilisateurs mobiles et domestiques travaillant sur des ordinateurs portables, des PDA, des
Smartphones, des iPads, des tablettes, des dispositifs de stockage mobiles USB/autres, des VPN, etc.
Comment les systèmes portables sont-ils entretenus et contrôlés (par exemple, pour s'assurer qu'ils sont
tenus à jour en ce qui concerne les définitions d'antivirus et les correctifs de sécurité) ? Confirmer que tous
les dispositifs portables contenant des données d'entreprise et personnelles sensibles et propriétaires
utilisent des contrôles d'accès adéquats, ce qui implique normalement l'installation d'images d'entreprise
par des solutions de GDR, des solutions de MAM pour contrôler les applications, le cryptage de l'ensemble
du disque, et des règles concernant cet accès au cas où il serait autorisé.
6.2.2 Télétravail : examiner les politiques, procédures, lignes directrices et pratiques relatives au télétravail,
au travail à distance et au travail portable. Vérifier que les risques liés au télétravail en matière
d'information sont déterminés, évalués et traités (par exemple, contrôles de sécurité techniques, physiques
et procéduraux appropriés). Les contrôles de sécurité pour le télétravail sont-ils équivalents à ceux des lieux
de travail classiques de type bureautique (toute différence doit refléter les risques respectifs en matière
d'information). Existe-t-il des dispositions appropriées pour l'authentification des utilisateurs, la sécurité du
réseau, les antivirus, les sauvegardes, les correctifs, la journalisation et la surveillance de la sécurité, le
cryptage et la continuité des activités ? Le cas échéant, comment l'organisation accède-t-elle aux dispositifs
et supports TIC de l'entreprise ou du secteur privé pour confirmer ou configurer leur sécurité, enquêter sur
les incidents, etc.
A.7. Sécurité des ressources humaines
A.7.1 Avant l'emploi

A.7.1.1 Vérification : le processus de vérification préalable à l'embauche tient-il compte des lois et règlements
pertinents en matière de protection de la vie privée et d'emploi ? Cette procédure est-elle effectuée en interne
ou confiée à un tiers ? Le personnel et les sous-traitants font-ils l'objet d'une vérification préalable à l'emploi (y
compris la prise de contact avec des références et la vérification de l'habilitation de sécurité, le cas échéant) ? Si
cette vérification est effectuée par les tiers eux-mêmes, leurs processus ont-ils été examinés et jugés
acceptables ? Existe-t-il des processus de contrôle renforcés pour les travailleurs occupant des postes
particulièrement dignes de confiance (par exemple, ceux qui ont un accès équivalent à l'accès de base aux
systèmes sensibles), les départements/fonctions, les unités opérationnelles ou les sites ? Comment tout cela
est-il réalisé ? Il devrait y avoir un processus documenté, cohérent et reproductible, qui soit détenu et tenu à
jour par les RH, et des preuves devraient être disponibles, par exemple les résultats de ces vérifications
d'antécédents. Les attributs de ces vérifications doivent être basés sur une évaluation des risques et être
conformes aux exigences de contrôle, l'acceptation des risques liés aux exigences qui ne peuvent être satisfaites
doit être documentée.
A.7.1.2 Conditions d'emploi : les rôles et responsabilités pertinents en matière de sécurité de l'information
sont-ils définis de manière adéquate dans les descriptions de poste, les lettres d'offre, les contrats de travail
et de service, les conditions d'emploi, etc. pour les professionnels de la sécurité et des risques liés à
l'information, les responsables de systèmes/réseaux informatiques, les gestionnaires, les auditeurs et les
travailleurs en général ? Les responsabilités spécifiques relatives au risque et à la sécurité de l'information
sont-elles identifiées, en fonction de la nature des rôles ? Vérifiez si les clauses de confidentialité et autres
clauses similaires (accords de non-divulgation) sont appropriées. Des registres sont-ils tenus pour prouver
que les travailleurs ont compris, reconnu et accepté leurs obligations en matière de sécurité de
l'information ? Certaines obligations sont-elles maintenues pour des périodes définies ou indéterminées au-
delà de la fin de l'emploi ?
A.7.2 Pendant l'emploi
A.7.2.1 Responsabilités de gestion : examiner la sensibilisation à la sécurité de l'information, la formation et les
dispositifs éducatifs destinés au public des cadres et des superviseurs. Sont-elles régulières et continues ? Le
contenu et la nature/le format/le style des informations et des activités de sensibilisation sont-ils adaptés au
public visé ? Les responsables reçoivent-ils une sensibilisation et une formation appropriées, en particulier sur
leurs rôles et responsabilités en matière de risques et de sécurité de l'information (par exemple, sensibilisation
aux notions d'"autorisation" et de "surveillance" en général, formation à la définition et à la révision des droits
d'accès) ? Les activités et les exigences en matière de risques liés à l'information, de sécurité et d'activités
connexes sont-elles
du SGSI v2
(telles que l'intégrité personnelle et la fiabilité) identifiées dans les descriptions de poste, et les travailleurs
sont-ils correctement sélectionnés, formés et qualifiés ? Le programme d'initiation s'adresse-t-il
spécifiquement aux cadres nouvellement recrutés ou promus et leur fournit-il des informations et des
conseils importants sur la position, les stratégies, les politiques, etc. de l'organisation en matière de
sécurité de l'information ?
A.7.2.2 Sensibilisation, éducation et formation à la sécurité de l'information : examiner la formation des
personnes spécifiquement impliquées dans l'exploitation du SGSI et les contrôles de sécurité de
La sensibilisation, la formation
et l'éducation continues en
matière de sécurité dans toute
l'organisation, de haut en bas,
contribuent à créer et à
maintenir une culture de la
sécurité au sein de l'entreprise
: la "formation à la sécurité de
l'utilisateur final" et les "mises à
jour annuelles de sensibilisation
à la sécurité",
traditionnellement axées sur les
technologies de l'information,
sont loin d'être des bonnes
pratiques dans ce domaine.
l'information, et les activités générales de sensibilisation à la sécurité de l'information ciblant tous les
travailleurs ou des groupes spécifiques de travailleurs. Les professionnels de la sécurité de l'information et
les autres personnes ayant des rôles spécifiques et
les responsabilités explicitement identifiées ? Existe-t-il un programme structuré
de la sensibilisation et de la formation initiales (initiation/orientation)
et régulières (continues/continues) à la sécurité de l'information pour
tous les types de travailleurs ? Existe-t-il une stratégie ou un plan de
communication, comprenant généralement des brochures et des
briefings, des affiches, des courriers électroniques, la gestion de
l'apprentissage en ligne, des quiz, des concours, des vidéos, des médias
sociaux (par exemple, des blogs) et d'autres méthodes ou activités sur
une séquence ou un éventail de sujets ? Outre les sujets spécifiques, le
contenu couvre-t-il des aspects plus généraux tels que le risque
d'information, la sécurité et les concepts connexes ; l'engagement et le
soutien de la direction ; les exigences légales, réglementaires,
contractuelles et politiques ; la responsabilité personnelle et les
responsabilités générales ; les points de contact et les ressources
supplémentaires ? Le contenu est-il mis à jour ou rafraîchi pour refléter
l'évolution des risques liés à l'information, tels que les nouvelles
menaces, les nouvelles
les vulnérabilités et les incidents récents ou les quasi-accidents, et les changements tels que les politiques
nouvelles/révisées ? Des tests et exercices périodiques sont-ils prévus pour vérifier le niveau de
sensibilisation (si oui, vérifier les résultats, y compris les tendances et les éventuels problèmes ou
préoccupations) ? Des actions de suivi sont-elles prévues pour les personnes qui obtiennent de mauvais
résultats lors de ces tests et/ou des changements sont-ils apportés aux supports de sensibilisation et de
formation ?
A.7.2.3 Procédure disciplinaire : les procédures disciplinaires concernent-elles les incidents de sécurité de
l'information, les atteintes à la vie privée, le piratage, le hacking, la fraude, l'espionnage industriel, etc.
Examinez les politiques, les procédures, les lignes directrices, les pratiques et les dossiers qui en découlent.
Comment les travailleurs sont-ils informés du processus, y compris des attentes de l'organisation et de leurs
droits ? Cela est-il couvert par des contrats et des accords, une formation d'initiation et une sensibilisation
continue ? Le processus disciplinaire a-t-il déjà été invoqué pour des incidents de sécurité de l'information
(si oui, examinez les cas récents ; si non, pourquoi) ?
A.7.3 Licenciement et changement d'emploi

A.7.3.1 Licenciement ou changement de responsabilités : examiner les politiques, normes, procédures,
lignes directrices et documents connexes relatifs à la sécurité des informations pour les travailleurs qui se
déplacent latéralement ou verticalement au sein de l'organisation (par exemple, promotions et
rétrogradations, changement de rôle, nouvelles responsabilités, nouvelles pratiques de travail, par exemple,
télétravail) ou qui quittent l'organisation (démissions, licenciements prévus ou non). Évaluer les risques liés
à l'information et les aspects de sécurité, par exemple la récupération des actifs d'information (papiers,
données, systèmes), les clés, la suppression des droits d'accès, le maintien de la confidentialité des
informations propriétaires et personnelles si nécessaire, etc.
A.8. Gestion des actifs
A.8.1 Responsabilité des actifs

A.8.1.1 Inventaire des biens : examiner tout inventaire des biens (d'information), couvrant
potentiellement :
• Données numériques : données commerciales de tous types et de tous lieux ; données
informatiques/support (par exemple, bases de données de configuration) ; mots de passe et
biométrie ; certificats et clés numériques, etc ;

du SGSI v2
• Informations sur papier : documentation sur les systèmes et les processus (couvrant les spécifications,
l'architecture et la conception, l'installation, l'exploitation, l'utilisation, la gestion, etc.) ; licences,
accords et contrats ; matériel de sensibilisation et de formation ; informations sur la gestion de la
continuité des activités, plans de reprise après sinistre, exercices, rapports, etc ;
• Logiciels : logiciels système plus correctifs et divulgations de vulnérabilités ; applications, utilitaires de
gestion informatique, bases de données et intergiciels, plus autres logiciels et correctifs packagés et sur
mesure ; supports d'installation originaux et/ou téléchargements vérifiés par hachage ; licences ;
accords de séquestre, etc ;
• Infrastructure : serveurs (physiques et virtuels, sur site et hors site) ; dispositifs de réseau (routeurs,
commutateurs, équilibreurs de charge, dispositifs VPN, serveurs proxy Web) ; dispositifs de sécurité
(serveurs d'authentification, systèmes de contrôle d'accès, passerelles et pare-feu, IDS/IPS, SIEM, filtres
antispam et antiprogrammes malveillants, systèmes de journalisation et d'alerte) ; dispositifs de
communication (modems, routeurs, lignes louées, connexions Internet, liaisons micro-ondes, points
d'accès WiFi) ; câbles, panneaux de brassage, prises et ports ; dispositifs pour utilisateurs finaux
(ordinateurs de bureau et portables, téléphones intelligents, tablettes, dispositifs BYOD) ; objets divers ;
SAN ; lecteurs et bandes de sauvegarde ; classeurs, boîtiers verrouillables, coffres-forts, etc.;
• Services d'information et fournisseurs de services : serveur, réseau, stockage et sauvegarde, sécurité,
support TIC et autres opérations et services liés à l'information ; services Internet et cloud ; Reuters,
CERT et autres flux d'informations similaires ; opérations, maintenance et services de support de tiers,
etc ;
• Sécurité et sûreté physiques : détecteurs de fumée, alarmes et systèmes d'extinction des incendies ;
alimentation électrique, y compris les onduleurs et les générateurs ; climatisation, surveillance de la
température et alarmes ; baies de serveurs, contrôles d'accès par carte, clôtures de périmètre, alarmes
anti-intrusion ; coffres-forts anti-incendie sur site et hors site ; clés, en particulier les passe-partout, etc
;
• Relations commerciales : avec les parties externes, par exemple les fournisseurs, les partenaires, les clients,
les conseillers, les régulateurs et les autorités, les propriétaires et les autres parties prenantes, en
particulier celles qui impliquent le passage d'informations ;
• Personnes : en particulier, toute personne critique (plus ou moins irremplaçable) ou de valeur
possédant des connaissances, une expérience, des compétences, une expertise ou des contacts
uniques, et jouant souvent un rôle essentiel.
A qui appartient l'inventaire ? Examinez la gestion, l'administration et l'utilisation qui y sont associées.
Comment l'inventaire est-il maintenu dans un état raisonnablement complet, précis et à jour malgré les
déménagements d'équipement/de personnel, les nouveaux systèmes, les changements commerciaux et
informatiques, etc. (par exemple, un processus d'enregistrement pour les nouveaux systèmes) ? Est-il
suffisamment détaillé et structuré de manière appropriée ? Recherchez les processus de gestion
d'inventaire automatisés et manuels (par exemple, codes-barres, étiquettes de sécurité, dossiers d'achat,
numéros de série/MAC/EMEI, rapports de vérification/audit des stocks, scanners de réseau, liens avec
d'autres bases de données).
A.8.1.2 Propriété des actifs : vérifiez que tous les actifs d'information critiques ont des propriétaires
responsables appropriés, et que leurs obligations (par exemple, l'analyse et le traitement des risques
d'information associés) sont clairement définies pour l'ensemble du cycle de vie de l'information. Vérifiez
comment la propriété est attribuée peu après la création ou l'acquisition des actifs critiques. Vérifiez si ce
processus se déroule de manière continue. Tous les actifs doivent être correctement étiquetés et les
étiquettes d'actifs et les propriétaires doivent être correctement référencés dans le registre des actifs.
Vérifier la propriété/contrôle des actifs par l'organisation (par exemple, si les actifs sont loués, quelles sont
les responsabilités des deux parties en cas d'incidents de sécurité de l'information les affectant).
A.8.1.3 Utilisation acceptable des ressources : existe-t-il une politique sur l'utilisation acceptable des
ressources technologiques telles que le courrier électronique, la messagerie instantanée, le FTP, les
responsabilités des utilisateurs, etc. Cette politique couvre-t-elle le comportement des utilisateurs sur
l'internet et les médias sociaux ? L'utilisation personnelle des ressources de l'entreprise est-elle autorisée ?
Si oui, dans quelle mesure et comment cette utilisation est-elle contrôlée/assurée ? Tout document fait-il
état de ce qu'il faut faire et de ce qu'il ne faut pas faire et de ce qui constitue une utilisation abusive ? Ce
document est-il diffusé dans l'entreprise ? Vérifiez si un message d'avertissement approprié ou une
bannière de connexion est présenté aux utilisateurs, dont ils doivent accuser réception pour poursuivre la
procédure de connexion. Vérifiez si des procédures de contrôle ont été approuvées par un conseiller
juridique. L'utilisation de la cryptographie est-elle conforme à l'ensemble des lois, accords/contrats et
réglementations applicables ?

du SGSI v2
A.8.1.4 Restitution des avoirs : comment est-elle gérée pour tous les déménageurs latéraux et pour ceux
qui ont démissionné ou qui ont mis fin à leur contrat. S'agit-il d'une procédure automatisée ou manuelle ?
Si elle est manuelle, comment s'assure-t-on qu'il n'y a pas de dérapages ? Les personnes qui quittent
l'entreprise sont-elles tenues de remettre tous les actifs émis par l'entreprise avant de partir
définitivement, et comment les actifs manquants sont-ils traités ?
A.8.2 Classification des informations

A.8.2.1 Classification des informations : politiques, normes, procédures, lignes directrices et documents
connexes relatifs à la classification des informations. La classification est-elle dictée par les obligations du
gouvernement ou de la défense ? La classification est-elle basée sur des exigences de confidentialité,
d'intégrité et/ou de disponibilité ? Les aspects suivants sont-ils évoqués dans la politique/procédure
concernant les informations classifiées : méthode d'étiquetage, de transfert, de stockage, de manipulation
des supports amovibles, d'élimination des supports électroniques et physiques, de divulgation, de partage,
d'échange avec des tiers, etc. Des marquages appropriés sont-ils utilisés sur les biens en fonction de la
classification des informations qu'ils contiennent ? La classification est également nécessaire pour les
documents, formulaires, rapports, écrans, supports de sauvegarde, courriers électroniques, transferts de
fichiers, etc. Le personnel est-il informé des exigences de sécurité correspondantes pour la manipulation de
matériel sensible (par exemple, aucune donnée classée "secrète" ne doit être générée, traitée ou stockée
sur un système connecté au réseau local/réseau local ou à l'internet de l'entreprise) ?
A.8.2.2 Étiquetage des informations : existe-t-il une procédure d'étiquetage des informations sous forme
physique et électronique ? Cette procédure est-elle en phase avec la politique de classification des
informations ? Comment l'étiquetage correct est-il assuré ? (Comment) est-il lié au mécanisme de contrôle
d'accès, par exemple le DRM ? Comment s'assure-t-on que seules les personnes ayant des autorisations
d'accès approuvées accèdent aux informations de la classification pertinente ? Et comment s'assure-t-on
qu'il n'y a pas d'accès non autorisé ? Les propriétaires des biens revoient-ils les niveaux de classification à
des intervalles prédéfinis ou en cas de changement important ? Vérifiez que les travailleurs savent ce que
signifient les étiquettes.
A.8.2.3 Gestion des biens : suite au point A.8.2.1, vérifier en ce qui concerne les informations classifiées
appartenant à des sources externes ou reçues de celles-ci : leurs niveaux de classification correspondent-ils
aux niveaux de classification propres à l'organisation ?
A.8.3 Traitement des médias

A.8.3.1 Gestion des supports amovibles : examiner la politique, la procédure, les normes, les pratiques et
les dossiers pertinents, en relation avec les risques liés à l'information. Existe-t-il un registre complet et à
jour des actifs pour les bandes, les paquets de disques amovibles, les CD/DVD, les clés USB et autres
supports amovibles ? Les supports amovibles sont-ils correctement étiquetés, le cas échéant (par exemple,
numéros de classification et de série) et sont-ils comptabilisés dans un registre des actifs ? Les supports
d'archives sont-ils dupliqués et vérifiés avant la suppression des données sources ? Les bandes d'archives
sont-elles périodiquement vérifiées et remises sous tension conformément aux spécifications du fabricant
(généralement chaque année) ? Existe-t-il des contrôles appropriés pour préserver la confidentialité des
données stockées (par exemple, cryptage si nécessaire, accès limité aux bandes et aux lecteurs, dispositions
de messagerie sécurisée pour le transport des supports à haut risque) ? Tous les supports sont-ils stockés
dans un environnement sûr et sécurisé conformément aux spécifications du fabricant ? Existe-t-il des
autorisations pour tous les supports qui doivent être déplacés d'un endroit à l'autre et sont-elles
comptabilisées à chaque étape ?
A.8.3.2 Mise au rebut des médias : conformément au point A.8.3.1, comment les médias sont-ils mis au
rebut (en interne ou en sous-traitance à un tiers - dans ce cas, le tiers a-t-il été sélectionné après avoir fait
preuve de la diligence requise et existe-t-il un contrat approprié avec les exigences de sécurité et
d'assurance applicables) ? Existe-t-il des exigences politiques, contractuelles, légales ou réglementaires
spécifiques pour la mise au rebut des médias ? Existe-t-il des autorisations documentées à chaque étape de
la cession des médias ? Les données qui doivent encore être conservées sont-elles copiées sur d'autres
supports et vérifiées avant d'être éliminées ? Les données particulièrement sensibles sont-elles effacées de
manière sûre avant l'élimination des supports (par exemple, par effacement cryptographique,
démagnétisation et/ou destruction physique) ? Les preuves documentaires de la destruction des supports
sont-elles conservées, et quelle est leur durée de conservation, les périodes d'examen, etc. Les dispositions
prennent-elles en compte les supports intégrés dans les équipements (par exemple, les appareils
multifonctions) ?

du SGSI v2
A.8.3.3 Transfert physique de supports : vérifier la politique et la procédure de contrôle A.8.3.1. Pour les
supports transportés vers d'autres lieux (par exemple, des sauvegardes stockées hors site), vérifiez si un
transport ou un service de messagerie fiable est utilisé à cette fin. Vérifiez qu'une personne qualifiée
identifie le contenu des médias avant le transfert et si le contenu est crypté ou non. Vérifier que ce transfert
est enregistré à chaque étape (remise aux dépositaires de transit, départ de l'installation/centre de
données initial, arrivée à destination, mise en stockage, etc. ). ). Vérifier que le transport est effectué
conformément aux spécifications du fabricant, que la protection appropriée est appliquée pendant le
transfert, que les heures de transfert et de réception à destination sont enregistrées.
A.9 Contrôle d'accès
A.9.1 Exigences commerciales du contrôle d'accès

A.9.1.1 Politique de contrôle d'accès : examiner toutes les politiques, procédures, lignes directrices,
pratiques et documents associés en matière de contrôle et de gestion des accès. Sont-ils conformes à la
politique de classification, aux procédures de rejoint/déplacement/départ, etc. Y a-t-il une séparation
appropriée des tâches ? L'accès initial au réseau/système est-il limité pour les nouveaux employés (par
exemple, le courrier électronique et l'intranet uniquement), l'accès ultérieur aux applications métier en
fonction des besoins spécifiques étant accordé sur la base d'un flux de travail défini qui comprend des
Comme les contrôles préventifs

sont limités et que les pirates
informatiques compétents
s'efforcent de dissimuler leurs
activités, la détection précoce et
la réaction rapide sont
généralement considérées
comme un contrôle essentiel.
approbations aux niveaux appropriés ?

A.9.1.2 Accès aux réseaux et aux services de réseau : revoir la politique des services de réseau (peut faire
partie d'une politique générale de contrôle d'accès). Outre les exigences standard de contrôle d'accès aux
réseaux, comment les VPN
et les accès sans fil autorisés, contrôlés et surveillés ? Les accès multi- et sans fil sont-ils autorisés, contrôlés
et surveillés ?
l'authentification des facteurs en place pour les réseaux, systèmes et
applications critiques, en particulier pour les utilisateurs privilégiés ?
Comment les réseaux sont-ils surveillés pour détecter les accès et
utilisations non autorisés ou les activités suspectes/anomalies ? Les
contrôles de sécurité des réseaux sont-ils régulièrement vérifiés et
prouvés (par exemple, par des tests de pénétration) ? L'organisation
mesure-t-elle et signale-t-elle les délais d'identification et de réaction
aux incidents ?
A.9.2 Gestion de l'accès des utilisateurs

A.9.2.1 Enregistrement et désenregistrement des utilisateurs : vérifier la couverture de la politique et des
procédures de contrôle d'accès. Existe-t-il des identifiants uniques pour chaque utilisateur, générés sur la
base d'un flux de demandes avec les approbations et les enregistrements appropriés ? Vérifiez que les ID
utilisateur des personnes qui quittent l'institution sont immédiatement désactivés sur la base d'un
workflow. Existe-t-il des liens efficaces entre l'administration de la sécurité et les RH plus les achats pour
une notification rapide lorsque les travailleurs quittent ou partent ? Existe-t-il un examen/audit périodique
pour identifier et suspendre les identifiants d'utilisateur redondants ? Les identifiants suspendus sont-ils
supprimés après confirmation qu'ils ne sont plus nécessaires ? Qu'est-ce qui empêche la réaffectation des
identifiants d'utilisateur à d'autres utilisateurs ? Si l'enregistrement et le désenregistrement sont un
processus manuel, vérifiez comment une piste d'audit est maintenue. Vérifiez que le moment de la
désinscription d'un compte n'est pas contre-productif pour l'entreprise (par exemple, les clients peuvent
envoyer des informations importantes à un compte de courrier électronique qui a été récemment désactivé
; la propriété d'informations commerciales précieuses peut devoir être réaffectée d'un compte redondant à
un utilisateur actif approprié).
A.9.2.2 Mise à disposition de l'accès aux utilisateurs : vérifier que l'accès initial pour tous les utilisateurs est de
base (par exemple, uniquement le courrier électronique et l'intranet) et que tout accès ultérieur aux systèmes et
services d'information est basé sur les besoins de l'entreprise. Vérifiez comment il est garanti que tous les accès
accordés sont conformes aux politiques de contrôle d'accès et de séparation des tâches. Au-delà de l'accès de
base, des demandes doivent être présentées pour tout accès supplémentaire avec les approbations appropriées
à tous les stades jusqu'à ce qu'il soit accordé. Exemples de dossiers prouvant que les droits d'accès accordés
sont normalement limités dans la mesure du possible, et que les droits d'accès sont régulièrement examinés et,
si nécessaire

du SGSI v2
révoqué rapidement (par exemple, en comparant un petit échantillon avec les comptes actifs pour vérifier si
tous les comptes actifs ont été correctement autorisés et si seul l'accès autorisé a été accordé).
A.9.2.3 Gestion des droits d'accès privilégiés : suite à A 9.2.2, accorder une attention particulière aux
utilisateurs privilégiés. Examinez les contrôles d'accès aux systèmes/comptes pour les utilisateurs de systèmes,
bases de données, applications et gestionnaires de réseaux privilégiés tels que SYSTEM, Admin et ROOT. Vérifier
qu'il existe des contrôles renforcés pour refléter le potentiel plus important d'abus de privilèges, par exemple
des procédures d'autorisation de compte spécial et des systèmes de surveillance pour détecter et répondre à de
tels abus. Existe-t-il un processus de révision plus fréquente et régulière des comptes privilégiés afin d'identifier
et de désactiver/supprimer les comptes privilégiés redondants et/ou de réduire les privilèges ? Vérifiez la
procédure d'octroi d'un tel accès élevé et que des identifiants d'utilisateur distincts sont générés pour l'octroi de
privilèges élevés. Une date limite d'expiration a-t-elle été fixée pour les ID utilisateur privilégiés ? Vérifiez la
procédure de modification des mots de passe ou de suspension des identifiants d'utilisateur dès que possible
lorsque des utilisateurs privilégiés quittent ou déménagent en interne. Les activités des utilisateurs privilégiés
sont-elles encore plus étroitement surveillées pendant cette période ?
A.9.2.4 Gestion des informations secrètes d'authentification des utilisateurs : examiner les contrôles
d'identification et d'authentification des utilisateurs, par exemple les politiques, normes, procédures, lignes
directrices et contrôles techniques tels que la longueur minimale des mots de passe, les règles de
complexité, le changement forcé des mots de passe lors de la première utilisation, l'authentification à
plusieurs facteurs, la biométrie, les mots de passe partagés, etc. Évaluer la combinaison de contrôles
techniques/automatiques et de procédures manuelles, les revues de direction, etc. Quelqu'un vérifie-t-il
régulièrement les mots de passe faibles et assure-t-il un suivi avec la sensibilisation/formation des
utilisateurs en matière de sécurité ? Les nouveaux mots de passe, les mots de passe de remplacement ou
les mots de passe temporaires sont-ils fournis aux utilisateurs uniquement après confirmation de leur
identité ? Ces informations sont-elles transmises par des moyens sûrs ? Les mots de passe générés ou par
défaut sont-ils suffisamment forts, c'est-à-dire difficiles à deviner ou à forcer ? Les destinataires sont-ils
tenus d'accuser réception des identités et des mots de passe ? Les mots de passe par défaut des
fournisseurs sont-ils modifiés immédiatement après l'installation des systèmes ou des logiciels ? Vérifiez les
procédures et les outils de génération des mots de passe temporaires : sont-ils manuels, semi-
automatiques ou entièrement automatisés ? Les utilisateurs sont-ils encouragés à utiliser un logiciel
approprié de stockage des mots de passe (si oui, est-il suffisamment sécurisé) ? Confirmez que les mots de
passe des systèmes/dispositifs et des applications sont stockés sous forme purement cryptée (de
préférence sous forme de hachis salés).
A.9.2.5 Examen des droits d'accès des utilisateurs : des examens périodiques des droits d'accès des
utilisateurs aux systèmes et applications sont-ils commandés/demandés par leurs "propriétaires" pour
vérifier les changements de rôles des utilisateurs, tels que les promotions, les mutations internes et/ou les
démissions ? Les droits d'accès et les autorisations sont-ils ajustés ou ré-autorisés en conséquence ? Existe-
t-il un mécanisme permettant de garantir que les réexamens sont effectués régulièrement et dans les délais
prévus ? Compte tenu des risques, les droits d'accès et les autorisations des utilisateurs privilégiés sont-ils
revus de manière plus approfondie et plus fréquente ?
A.9.2.6 Suppression ou ajustement des droits d'accès : vérifiez la procédure de suppression ou
d'ajustement des droits d'accès des employés, vendeurs et contractants lors de la résiliation ou du
changement de leur emploi, contrat ou accord. Cette procédure inclut-elle l'accès physique aux installations
et l'accès logique au réseau ? Vérifiez si les mots de passe des utilisateurs connus ou des groupes
d'utilisateurs (connus de ceux qui quittent ou déménagent en interne) sont modifiés lorsque ces départs ou
mouvements ont lieu. Dans ce cas, les personnes qui quittent ou déménagent sont-elles retirées des
groupes en même temps qu'elles changent de mot de passe ? Vérifiez un échantillon de dossiers.
A.9.3 Responsabilités des utilisateurs

A.9.3.1 Utilisation d'informations d'authentification secrètes : vérifier la politique sur la nécessité de
garder les mots de passe, codes PIN, etc. confidentiels, de ne pas les divulguer ou les enregistrer, de les
changer rapidement si une compromission est suspectée, et la nécessité d'avoir des mots de passe
différents pour les divers systèmes (y compris l'utilisation professionnelle ou personnelle). Comment tout
cela est-il garanti ? Examinez les risques liés aux informations et les contrôles de sécurité relatifs à tout
compte partagé (par exemple, les propriétaires de comptes sont-ils tenus personnellement responsables de
toutes les activités effectuées sur "leurs" comptes, indépendamment de la personne qui les utilise
réellement ?)

du SGSI v2
A.9.4 Contrôle de l'accès aux systèmes et applications
A.9.4.1 Restriction de l'accès aux informations : conformément au point 9.2.2, examiner les conceptions
de sécurité et d'autres documents pour un échantillon des principaux systèmes afin de déterminer si des
contrôles d'accès appropriés sont en place, y compris l'utilisation d'identités d'utilisateurs individuels,
l'authentification des utilisateurs, les contrôles d'accès automatisés, le cryptage, etc. Comment les droits
d'accès, les autorisations et les règles associées sont-ils définis, autorisés, attribués, surveillés/examinés,
gérés et retirés ?
A.9.4.2 Procédures de connexion sécurisées : les processus d'identification et d'authentification des
utilisateurs sont-ils sécurisés, par exemple en utilisant la séquence de clés contrôle-alt-suppression pour
déclencher une fonction privilégiée du noyau ? Des avertissements généraux sont-ils affichés lors de la
connexion pour dissuader tout accès non autorisé, mais pas les informations qui pourraient aider un
utilisateur non autorisé à identifier et à accéder au système/service ? Comment les identités des utilisateurs
revendiqués sont-elles authentifiées pendant le processus de connexion ? Une authentification à plusieurs
facteurs a-t-elle été mise en œuvre pour les systèmes/services critiques/les connexions à distance par
l'intermédiaire de VPN, etc. Les informations de connexion ne sont-elles validées qu'une fois la saisie
terminée ? Un mot de passe non valide déclenche-t-il des retards ou des blocages, des entrées de journal et
des alertes/alarmes ? Vérifiez également si les connexions réussies sont enregistrées. Vérifiez que les mots
de passe ne sont jamais transmis en clair sur des réseaux ou des liens.
A.9.4.3 Système de gestion des mots de passe : les systèmes appliquent-ils les exigences relatives à la force
des mots de passe définies dans les politiques et les normes des entreprises ? Ces règles définissent-elles la
longueur minimale des mots de passe, empêchent-elles la réutilisation d'un nombre déterminé de mots de
passe déjà utilisés, appliquent-elles les règles de complexité (majuscules, minuscules, chiffres, symboles,
espaces, etc.), le changement forcé des mots de passe lors de la première connexion, le non-affichage des
mots de passe lors de leur saisie, le stockage et (si nécessaire) la transmission des mots de passe sous
forme cryptée, etc.
A.9.4.4 Utilisation des programmes de services publics privilégiés : qui contrôle les services publics
privilégiés ? Qui peut y avoir accès, dans quelles conditions et à quelles fins ? Vérifiez si ces personnes ont
obtenu un accès sur la base d'un besoin professionnel et d'un processus d'approbation vérifiable, et si
chaque cas d'utilisation est consigné ? Confirmez que l'accès à tout programme de services publics n'a pas
été accordé à des utilisateurs d'applications ou de systèmes pour lesquels la séparation des tâches est
nécessaire.
A.9.4.5 Contrôle de l'accès au code source du programme : vérifier les contrôles autour du code source du
programme. Est-il stocké dans une ou plusieurs bibliothèques ou dépôts de sources de programmes, dans
des environnements sécurisés avec des contrôles d'accès et de version adéquats, une surveillance, une
journalisation, etc. Comment le code source est-il modifié ? Comment le code est-il émis (vérifié) et compilé
? Les journaux d'accès et de modification sont-ils stockés et examinés ? Cherchez des preuves.
A.10. Cryptographie
10.1 Contrôles cryptographiques

A.10.1.1 Politique relative à l'utilisation des contrôles cryptographiques : le cryptage est-il nécessaire ? Si
oui, quels sont les systèmes d'information, réseaux, applications, etc. couverts ? Existe-t-il une politique
couvrant l'utilisation des contrôles cryptographiques, couvrant les points suivants :
• Les principes généraux ou les circonstances dans lesquelles les informations doivent être protégées par
la cryptographie ;
• Normes à appliquer pour la mise en œuvre efficace de la cryptographie ;
• Un processus basé sur le risque pour déterminer et spécifier la protection requise ;
• Alignement sur toute exigence documentée relative aux équipements ou services informatiques
couverts par des contrats ;
• les questions de sécurité et les compromis connexes (par exemple, les effets du cryptage sur
l'inspection du contenu pour détecter les logiciels malveillants, la divulgation d'informations, etc ;)

du SGSI v2
- lois et règlements applicables tels que les restrictions à l'exportation (voir A.18.1.1).
Vérifiez comment toutes ces exigences sont satisfaites et évaluez les risques résiduels en matière
d'information.
A.10.1.2 Gestion des clés : vérifiez que la politique de cryptographie couvre l'ensemble du cycle de vie, du
berceau à la tombe
la gestion des clés, y compris :
• Protection des équipements utilisés pour générer, stocker et archiver les clés cryptographiques ;
• Génération de clés pour différents systèmes et applications ;
• Sources d'aléa, et évitement des clés faibles ;
• Règles relatives à la modification/mise à jour des clés, par exemple l'autorisation, la délivrance, la
communication et l'installation des clés ;
• Sauvegarde ou archivage des clés, récupération des clés corrompues ou perdues, et destruction des
clés ;
• Enregistrement et audit des principales activités de gestion ;
• Traitement des demandes officielles d'accès aux clés cryptographiques (par exemple, les ordonnances
des tribunaux).
Vérifiez comment toutes ces exigences sont satisfaites et évaluez les risques résiduels en matière
d'information.
A.11. Sécurité physique et environnementale
La santé et la sécurité du
personnel peuvent avoir la
priorité sur la sécurité de
l'information, par exemple en
protégeant les issues de
secours, en installant des
"barres de sécurité" en cas
les portes, le contrôle du pompier.
d'incendie
A.11.1 Zones sécurisées

A.11.1.1 Périmètre de sécurité physique : dans le cadre du SGSI, les installations sont-elles
raisonnablement discrètes et situées de manière à minimiser le potentiel de catastrophe ou le coût des
contre-mesures de protection (par exemple, elles ne sont pas adjacentes à des zones sujettes aux conflits,
sur la trajectoire de vol à proximité d'un aéroport, etc.) Vérifiez les périmètres de sécurité définis pour les
sites, les bâtiments, les bureaux, les salles informatiques et de réseau, les armoires de réseau, les archives,
les salles d'usine, les appareillages électriques, etc. Le toit, les murs et le sol extérieurs sont-ils de
construction solide ? Tous les points d'accès extérieurs sont-ils suffisamment protégés contre les accès non
autorisés ? La construction est-elle physiquement saine, par exemple des murs massifs "dalle contre dalle" ?
(dépassant les faux planchers et plafonds) ; des portes solides et verrouillables et
fenêtres ? Vérifiez si toutes les portes coupe-feu sur le mur d'enceinte
extérieur sont munies d'une alarme, ne peuvent pas être ouvertes de
l'extérieur, sont surveillées par des caméras, sont testées
périodiquement et fonctionnent de manière sûre. Confirmez
que seul le personnel autorisé peut entrer dans les locaux et comment
cela se fait. Vérifier les systèmes de détection des intrus, leur contrôle
périodique et les preuves de ce contrôle. Confirmer que les contrôles
sont conformes aux normes et lois locales ou nationales (par exemple,
codes de construction, règles de santé et de sécurité).
A.11.1.2 Contrôles physiques d'entrée : sont des systèmes de contrôle d'accès appropriés
employés (par exemple, proximité ou balayage de carte, serrures de sécurité, surveillance par télévision en
circuit fermé, détection d'intrus) avec des procédures correspondantes (par exemple, remise/retour de clés,
changement régulier de code d'accès, inspections en dehors des heures d'ouverture par des agents de
sécurité, visiteurs régulièrement escortés et visites enregistrées dans le registre des visiteurs de la salle,
mouvement de matériel, etc.) Vérifier l'existence d'une politique de sécurité physique qui couvre tous les
domaines pertinents tels que la délivrance des badges d'identification, la gestion des visiteurs, l'entrée dans
des zones définies du bâtiment en fonction des rôles et responsabilités, l'accès au(x) centre(s) de données,
aux salles de communication et autres zones critiques, etc. Existe-t-il des procédures couvrant tous ces
domaines ? Si une authentification à plusieurs facteurs (par exemple, biométrie plus code PIN) est
nécessaire pour les zones critiques, vérifiez comment elle est mise en œuvre, fonctionne, contrôlée et
administrée. Vérifiez les registres d'accès (par exemple, les livres des visiteurs) dans les centres de
données/salles informatiques : existe-t-il une piste d'audit solide de toutes les entrées et sorties ? Vérifier
s'il existe un audit d'examen des accès physiques pour l'organisation, sa méthode et sa périodicité.
A.11.1.3 Sécurisation des bureaux, des salles et des installations : il s'agit d'installations d'entreprise conçues
de manière à ce que tous les accès (entrées et sorties) aux installations soient physiquement surveillés et
contrôlés (par exemple, détecteurs de proximité, surveillance par télévision en circuit fermé). Veiller à ce que les
annuaires téléphoniques et les répertoires d'adresses de l'entreprise ne soient pas facilement accessibles à tous
et

du SGSI v2
divers. Vérifier que les contrôles de sécurité utilisés pour sécuriser les bureaux, les pièces et les installations
sont proportionnels aux risques encourus par les actifs d'information stockés, traités ou utilisés dans lesdits
lieux, avec des contrôles renforcés pour les actifs, pièces, zones, etc. à haut risque.
A.11.1.4 Protection contre les menaces externes et environnementales : revoir les contrôles de protection
contre le feu, la fumée, les inondations, la foudre, les intrus, le vandalisme, etc. Vérifier le niveau de
protection au niveau de la reprise après sinistre, des sites d'urgence et des sites éloignés également. Voir
également le point A.11.2.
A.11.1.5 Travailler dans des zones sécurisées : les bureaux, salles informatiques et autres lieux de travail
sécurisés supposés être libérés sont-ils contrôlés en fin de journée pour des raisons de sécurité et de sûreté
? Les zones sécurisées font-elles l'objet d'une évaluation des risques et de contrôles appropriés, tels que
• Contrôles d'accès physique ;
• Alarmes anti-intrusion ;
• Surveillance par télévision en circuit fermé (vérifier la conservation et la fréquence de l'examen) ;
• Interdiction d'utiliser du matériel photographique, vidéo, audio ou autre matériel d'enregistrement (y
compris les caméras et les microphones dans les appareils portables)
• Politiques, procédures et lignes directrices.
Comment les détails des processus/activités commerciales exclusives dans les différents secteurs de
l'installation sont-ils tenus confidentiels pour le personnel autorisé ?
A.11.1.6 Zones de livraison et de chargement : les livraisons sont-elles reçues et effectuées dans une zone
sécurisée (par exemple, dont l'accès est contrôlé et auquel seul le personnel autorisé a accès) ? Le matériel
reçu est-il contrôlé pour des raisons de sécurité et d'affaires (par exemple, un numéro de commande
correspondant à une commande autorisée) ? Les détails sont-ils enregistrés conformément aux politiques
et procédures de passation de marchés, de gestion des actifs et de sécurité ?
A.11.2 Équipement
A.11.2.1 Emplacement et protection des équipements : les TIC et les équipements connexes sont-ils situés
dans des zones suffisamment protégées ? Les écrans d'ordinateur, les imprimantes et les claviers sont-ils
placés ou protégés de manière à empêcher toute visualisation non autorisée ? Vérifiez les contrôles pour
minimiser le risque de menaces physiques et environnementales telles que
• Eau/inondation : installations convenablement situées pour minimiser le risque d'inondation (par
exemple, au-dessus de la nappe phréatique, non adjacentes à des réservoirs d'eau, pas de conduites
d'eau au-dessus, etc.) ). Le cas échéant, installation et entretien d'une protection
supplémentaire/secondaire, par exemple membranes imperméables, bacs de récupération sous les
unités de climatisation, détection de l'eau sous le plancher avec des alarmes à distance et des
procédures d'incident, enquêtes ou inspections régulières des toits, des vides sous le plancher, etc.
pour détecter les signes de fuite/pénétration d'eau ;
• Incendie et fumée : installations et équipements ininflammables, alarmes incendie, câblage à faible
émission de fumée, etc.
• Température, humidité et puissance : voir A.11.2.2
• Poussière : entretien (vérification, nettoyage, remplacement) régulier des filtres des équipements et
des climatiseurs. Les installations TIC sont maintenues propres, par exemple grâce à un "nettoyage en
profondeur" spécialisé, notamment les vides dans les sols et les plafonds, les revêtements muraux peu
poussiéreux, les planchers scellés, les couvercles/membranes anti-poussière, etc. Note : les personnes
chargées du nettoyage dans les zones sensibles telles que les salles informatiques doivent
normalement être accompagnées/supervisées, sauf si le nettoyage n'est effectué que par un personnel
compétent et digne de confiance. Les nettoyeurs peuvent devoir faire l'objet d'une autorisation de
sécurité et d'une surveillance proactive si l'organisation traite des informations classifiées du
gouvernement ou d'autres informations hautement sensibles/précieuses].
• Foudre, électricité statique et sécurité : confirmez que toutes les pièces métalliques exposées sont
reliées à la terre à un point de terre commun de sécurité, conformément à la réglementation
électrique. Confirmez l'utilisation de paratonnerres montés, d'isolateurs de câbles, de fusibles, etc. le
cas échéant. Ces contrôles sont-ils testés périodiquement et à la suite de changements importants ?

du SGSI v2
• Autres : par exemple, vol, explosifs, vibrations, contamination chimique, interférences dans
l'alimentation électrique, interférences dans les communications, radiations électromagnétiques et
vandalisme/dommages criminels.
A.11.2.2 Services d'appui - alimentation électrique : vérifiez et demandez aux responsables des
installations ou aux ingénieurs électriciens de vous expliquer les dispositions relatives à l'alimentation
électrique des salles informatiques, des armoires de réseau et des autres lieux abritant des systèmes
informatiques partagés ou critiques (serveurs, PABX, concentrateurs de communication, systèmes de
sécurité, systèmes de sécurité, systèmes de gestion des bâtiments, etc.) ). Existe-t-il des onduleurs, des
filtres, etc. de qualité informatique en ligne qui fournissent une alimentation électrique fiable et de haute
qualité ? La capacité des onduleurs est-elle suffisante pour prendre en charge tous les équipements
essentiels pendant une période suffisante (systèmes internes, montés en rack, dans toute la pièce ou sur
tout le site) ? Comment savoir si tous les équipements essentiels sont effectivement alimentés par des
sources sûres ? Existe-t-il des générateurs d'une capacité suffisante ? Les onduleurs et les générateurs sont-
ils exploités, surveillés et entretenus conformément aux spécifications du fabricant et testés en charge
régulièrement ? Le cas échéant, y a-t-il des alimentations secteur redondantes (à double circuit) provenant
de sous-stations ou de réseaux séparés ? Que se passe-t-il lorsque des modifications ou des essais sont
effectués sur le câblage électrique, les appareillages ou les équipements : les systèmes et les services sont-
ils concernés ?
Climatisation : existe-t-il des climatiseurs de qualité informatique correctement spécifiés et installés ? Les
refroidisseurs/condensateurs sont-ils correctement situés ? La capacité de climatisation est-elle suffisante
pour supporter la charge thermique, même en plein été ? Existe-t-il des unités ou des portables redondants
ou de rechange pour améliorer la résilience et permettre la maintenance sans affecter le service ? Existe-t-il
un système de détection de la température avec des alarmes de surchauffe à distance et des procédures en
cas d'incident ? Les équipements de climatisation sont-ils exploités, testés et entretenus par des
professionnels conformément aux spécifications du fabricant ? Existe-t-il des procédures d'exploitation et
d'entretien appropriées, y compris le nettoyage des filtres et le traitement des alarmes de surchauffe ou
autres ?
Autres : vérifiez si les installations et les services d'appui (par exemple, électricité, télécommunications,
approvisionnement en eau, gaz, eaux usées, ventilation et climatisation) sont régulièrement inspectés et
testés pour garantir leur bon fonctionnement. Il faut les alarmer en cas de dysfonctionnement et peut-être
d'activité non autorisée. Vérifiez comment les alarmes sont traitées en dehors des heures de travail (par
exemple, les agents de sécurité ont-ils des indicateurs/sons d'alarme à distance sur leurs consoles, avec des
procédures d'intervention appropriées, des formations/exercices, etc.)
A.11.2.3 Sécurité du câblage : existe-t-il une protection physique appropriée pour les câbles externes, les
boîtes de jonction, les refroidisseurs des climatiseurs, les antennes paraboliques des micro-ondes, les
entrées d'air, etc. contre les dommages accidentels ou les interférences délibérées ? Vérifiez si les câbles
d'alimentation sont séparés des câbles de communication pour éviter les interférences. Vérifiez si l'accès
aux panneaux de brassage et aux salles de câbles est contrôlé, les câbles étant dissimulés/protégés contre
les écoutes par des dispositifs malveillants ou contre les dommages physiques. Existe-t-il des procédures
appropriées pour confirmer tout cela ? Vérifiez que les installations de câblage sont effectuées
conformément aux codes de construction et aux autres règlements, normes et politiques applicables.
A.11.2.4 Entretien des équipements : vérifier que seul un personnel qualifié assure l'entretien des
équipements (infrastructure et dispositifs de réseau, ordinateurs portables, ordinateurs de bureau, etc. et
tous les équipements de sécurité et utilitaires tels que les détecteurs de fumée, les dispositifs d'extinction
d'incendie, le système de chauffage, de ventilation et de climatisation, le contrôle d'accès, la télévision en
circuit fermé, etc. Existe-t-il des programmes d'entretien et des registres/rapports à jour ? Si l'équipement
est assuré, la maintenance et les autres exigences du contrat d'assurance sont-elles satisfaites ?
A.11.2.5 Retrait des actifs : vérifier la politique et la procédure concernant le retrait des actifs d'information
(équipement TIC, supports de stockage et contenu de l'information) des sites, bâtiments, bureaux, archives
et autres lieux. Existe-t-il des approbations ou des autorisations documentées aux niveaux appropriés (par
exemple, propriétaires d'équipements ou d'informations) ? Comment] les mouvements sont-ils limités au
personnel autorisé ? Qu'est-ce qui empêche les gens de cacher des clés USB et autres petits dispositifs de
stockage sur leur personne ? Vérifiez les procédures de suivi des mouvements des biens de grande valeur
ou à haut risque. Suivez le processus. Vérifiez l'exactitude et l'exhaustivité d'un échantillon de dossiers
relatifs aux mouvements.
A.11.2.6 Sécurité des équipements et des biens hors site : existe-t-il une "politique d'utilisation
acceptable" ou des orientations équivalentes couvrant les exigences de sécurité et les "choses à faire et à
ne pas faire" pour tous les appareils mobiles ou portables qui sont
du SGSI v2
utilisé à partir de son domicile ou d'un lieu éloigné ? Prévoit-elle des exigences telles qu'une garde et un
stockage sécurisés appropriés, un contrôle d'accès physique et/ou logique (par exemple, armoires
verrouillables, cryptage), des connexions sécurisées (par exemple, VPN), des bureaux et des écrans clairs,
une protection contre les champs électromagnétiques forts, des sauvegardes régulières, etc. Comment tout
cela est-il réalisé et garanti dans la pratique ? Comment les travailleurs sont-ils informés de leurs obligations
? Bénéficient-ils d'un soutien suffisant pour atteindre un niveau de sécurité acceptable ?
A.11.2.7 Élimination ou réutilisation sécurisée des équipements : examiner les politiques, normes,
procédures, lignes directrices et documents connexes relatifs à la manière dont les supports de stockage et
les équipements TIC sont réutilisés ou éliminés. Comment l'organisation empêche-t-elle la divulgation des
informations stockées, à un niveau d'assurance suffisant compte tenu des risques associés aux informations
(par exemple, concernant la classification des données ou des systèmes) ? Si l'on s'appuie sur un cryptage
fort ou un effacement sécurisé, comment cela fonctionne-t-il et comment les dispositifs et supports non
fonctionnels sont-ils éliminés ? Des registres appropriés sont-ils tenus pour tous les supports qui sont
éliminés, avec des détails tels que la nature du contenu, la forme d'élimination et, le cas échéant, la
confirmation positive de l'élimination sécurisée ? La politique et le processus couvrent-ils tous les appareils
et supports TIC ? Recherchez des exceptions.
A.11.2.8 Équipement des utilisateurs non surveillés : si les sessions des utilisateurs actifs sont suspendues
ou interrompues après un temps d'inactivité défini, comment les applications sont-elles
suspendues/interrompues pour éviter la perte ou la corruption de données ? La définition du temps
d'inactivité est-elle appropriée, compte tenu des risques d'accès physique non autorisé à des dispositifs
actifs/logés ? Si des verrouillages d'écran sont utilisés, sont-ils protégés par un mot de passe ? Cette
politique s'applique-t-elle à tous les serveurs, ordinateurs de bureau, ordinateurs portables, téléphones
intelligents et autres dispositifs TIC ? Comment est-elle contrôlée et appliquée ? Les exceptions sont-elles
évaluées en fonction des risques et autorisées par la direction en tant qu'exemptions à la politique ?
A.11.2.9 Politique de clarté du bureau et de l'écran : revoir les politiques, normes, procédures et lignes
directrices dans ce domaine. Dans quelle mesure cela fonctionne-t-il dans la pratique ? Faites le tour en
vérifiant les actifs d'information non sécurisés tels que les serveurs, les PC, les ordinateurs portables et les
smartphones connectés mais non verrouillés, les supports de stockage numérique non sécurisés (tels que
les clés USB) et la paperasserie (par exemple, les agendas ; les mots de passe sur les Post-It ; les fichiers, les
formulaires et les notes contenant des informations professionnelles ou personnelles sensibles ; les
impressions abandonnées sur les imprimantes et les photocopieuses ; les classeurs non verrouillés). Tous
les appareils informatiques sont-ils dotés d'un économiseur d'écran ou d'un verrou protégé par un mot de
passe que les employés utilisent lorsqu'ils s'éloignent de leur appareil, ou qu'il s'enclenche après un temps
d'inactivité défini ? Vérifiez les procédures relatives à l'utilisation des imprimantes, photocopieurs,
scanners, appareils photo et autres technologies de reproduction.
A.12. Sécurité des opérations
A.12.1 Procédures opérationnelles et responsabilités

A.12.1.1 Procédures d'exploitation documentées : examiner l'état général des procédures pour les
opérations informatiques, la gestion des systèmes et des réseaux, la gestion des incidents, l'administration
de la sécurité informatique, les opérations de sécurité informatique et physique, la gestion des
changements, etc. Existe-t-il un ensemble complet de procédures de sécurité et quand ont-elles été
examinées pour la dernière fois ? Les processus sont-ils raisonnablement sûrs et bien contrôlés ? Les
aspects liés à la sécurité de l'information sont-ils correctement pris en compte (par exemple, les tâches
incompatibles sont séparées pour le personnel distinct, les procédures de notification des incidents, la
supervision de la gestion, etc.) Les responsabilités correspondantes sont-elles clairement attribuées aux
rôles et donc aux personnes, ainsi que la formation, les exercices, etc. Les domaines qui nécessitent
généralement une gestion et/ou des procédures opérationnelles documentées sont les suivants :
changement, configuration, version, capacité, performance, problème, incident, sauvegardes et archives (y
compris le stockage et la restauration), manipulation des supports, journaux et pistes d'audit, alarmes et
alertes, sécurité opérationnelle (par exemple, durcissement, évaluations de la vulnérabilité, correctifs,
configuration et mises à jour des antivirus, cryptage, etc.) ). Recherchez des preuves confirmant que les
procédures sont régulièrement examinées et maintenues, autorisées/mandées, diffusées et utilisées.
Prélever des échantillons et évaluer de manière plus approfondie les procédures à haut risque ou
problématiques connues.
A.12.1.2 Gestion des changements : examiner les politiques, procédures, normes et pratiques de gestion
des changements non informatiques et les documents connexes. Les changements sont-ils planifiés et
gérés, les impacts sont-ils évalués (en tenant compte des

du SGSI v2
les aspects liés aux risques et à la sécurité de l'information, ainsi que les conséquences de l' absence de
changement). Examinez un petit échantillon de dossiers de gestion du changement, en vous concentrant
sur les changements à haut risque. Les changements sont-ils correctement documentés, justifiés et
autorisés par la direction ? Cherchez des possibilités d'amélioration. (Voir aussi A.14.2.2).
Recoupement ave c les entreprises
Gestion de la continuité (par

exemple, les évaluations de l'impact
sur les entreprises de la gestion de la
continuité des activités identifient
systématiquement les informations
et les services de soutien qui sont
essentiels pour l'entreprise).
A.12.1.3 Gestion des capacités : examiner les politiques, procédures et pratiques de gestion des capacités et les
documents associés. Cela inclut-il des aspects tels que : des niveaux de service définis, la surveillance des
mesures pertinentes (par exemple, les serveurs
Utilisation du CPU, espace de stockage et défauts des pages dures, capacité du réseau,
demande d'électricité et capacité de climatisation, espace des
racks, taux d'utilisation et de stress des travailleurs clés),
alarmes/alertes aux niveaux critiques, planification prospective (en
tenant compte des délais d'approvisionnement et de la gestion des
changements) etc. Existe-t-il des preuves d'une approche fondée
sur les risques, par exemple une priorité visant à garantir la
performance et la disponibilité des services, serveurs,
infrastructures, applications, fonctions critiques, etc.
A.12.1.4 Séparation des environnements de développement, de test et d'exploitation : examiner les

politiques, procédures, pratiques, documents et architectures associés qui séparent ou séparent les
environnements de développement, de test et d'exploitation des TIC (y compris l'assurance et le contrôle
de la qualité, la préproduction, les configurations à double vie et en miroir, l'équilibrage des charges, le
basculement et la reprise après sinistre, ainsi que l'allocation dynamique des ressources dans le nuage).
Comment la séparation est-elle réalisée pour atteindre un niveau d'assurance adéquat (en fonction des
risques) ? Vérifier l'existence de contrôles adéquats isolant chaque environnement (par exemple, des
réseaux de production/entreprises séparés des autres réseaux utilisés pour le développement, les tests, la
gestion, y compris la sécurité, la journalisation, la surveillance et l'alerte). Vérifier les contrôles d'accès pour
ces environnements. Confirmer (par une enquête et des tests par échantillonnage) que seuls les travailleurs
autorisés ont accès à chacun de ces environnements par le biais de profils d'utilisateurs différenciés de
manière appropriée. Comment les logiciels sont-ils promus et diffusés ? Examiner les preuves de
l'approbation des demandes avant d'accorder l'accès, et procéder à des examens périodiques de l'accès.
Vérifier que la gestion des changements s'applique à l'autorisation et à la migration des logiciels, des
données, des métadonnées et des configurations entre les environnements dans un sens ou dans l'autre
(par exemple, les données de production copiées dans les environnements de développement ou de test).
Prendre en compte les risques liés à l'information et les aspects de sécurité, y compris la conformité (par
exemple, les implications en matière de vie privée si les données personnelles sont déplacées vers des
environnements moins sûrs ou en dehors de l'UE). Qui est chargé de veiller à ce que les logiciels nouveaux
ou modifiés ne perturbent pas l'infrastructure, les autres systèmes, les réseaux et les opérations, etc.
A.12.2 Protection contre les logiciels malveillants

A.12.2.1 Contrôles contre les logiciels malveillants : examiner les politiques, procédures, directives et pratiques
en matière de logiciels malveillants et les dossiers connexes. Vérifiez toute liste blanche ou liste noire
d'applications qui peuvent ou ne peuvent pas être utilisées dans l'entreprise. Comment la liste est-elle établie,
gérée et tenue à jour, et par qui ? Examinez les procédures de protection contre les logiciels malveillants et de
réponse aux incidents, ainsi qu'un échantillon de rapports d'incidents liés aux logiciels malveillants. Existe-t-il
des contrôles anti-virus continus/fréquents sur tous les appareils concernés, y compris les appareils autonomes,
les portables, les appareils embarqués et les équipements IdO ? Les niveaux d'infection sont-ils minimisés (c'est-
à-dire la situation est-elle globalement sous contrôle) ? Comment les logiciels anti-virus sont-ils mis à jour,
manuellement et automatiquement ? Les logiciels malveillants détectés par les scanners sont-ils signalés à un
coordinateur approprié ? Si la notification est manuelle, quelle est la proportion approximative de ceux qui sont
notifiés (tous, la plupart, certains ou seulement quelques-uns) ? Existe-t-il une protection adéquate contre les
logiciels de rançon, les chevaux de Troie, les vers, les logiciels espions, les rootkits, les enregistreurs de frappe,
les logiciels de sécurité avancés, les logiciels de sécurité et les logiciels d'exploitation de réseau ?
Menaces persistantes, etc. Comment les vulnérabilités techniques sont-elles gérées ? Existe-t-il une
formation et une sensibilisation continues appropriées couvrant la détection, le signalement et la résolution
des logiciels malveillants pour les utilisateurs, les gestionnaires et les spécialistes de l'assistance ? En cas
d'incident grave, vérifiez les contrôles associés pour enquêter sur l'incident et le résoudre, notamment la
détection rapide des épidémies et l'isolement du réseau, l'escalade vers la direction, la notification des
parties affectées, le recours à des dispositions de continuité des activités, l'analyse médico-légale, etc.

du SGSI v2
A.12.3 Sauvegarde
A.12.3.1 Sauvegarde des informations : examiner les politiques, procédures et pratiques de sauvegarde et
les dossiers associés. Existe-t-il un mandat basé sur le risque pour un enregistrement précis et complet des
sauvegardes dont l'étendue et la fréquence reflètent les besoins de l'entreprise ? Les stratégies de
sauvegarde couvrent-elles les données et les métadonnées, les programmes des systèmes et des
applications, y compris les utilitaires, les paramètres de configuration, etc. pour tous les systèmes, y
compris les serveurs, les ordinateurs de bureau, les systèmes de téléphonie/réseau, les systèmes de gestion
des systèmes/réseau, les systèmes autonomes/portables, les systèmes de contrôle, les systèmes de
sécurité, etc. Les supports de sauvegarde sont-ils physiquement protégés/sécurisés au moins au même
niveau que pour les données opérationnelles ? Les sauvegardes sont-elles stockées dans des endroits divers
et appropriés, afin de les protéger contre les catastrophes physiques, les incendies, les vols, etc. Les
sauvegardes sont-elles régulièrement testées pour s'assurer qu'elles peuvent effectivement être restaurées
intactes ? Les archives sont-elles explicitement conçues pour un stockage et une restauration sûrs,
diversifiés et garantis à long terme (par exemple, supports et dispositifs d'archivage) ? Vérifiez que tous les
objectifs définis en matière de temps et de points de récupération peuvent être atteints. En utilisant un
petit échantillon, vérifiez si les supports de sauvegarde énumérés dans les archives existent réellement au
bon endroit et sont correctement sécurisés et étiquetés. Vérifiez tout examen technique et de gestion dans
ce domaine, y compris les conclusions et les actions qui en découlent. Évaluer les risques associés aux
informations (aspects de confidentialité, d'intégrité et de disponibilité).
A.12.4 Logging and monitoring

A.12.4.1 Event logging: review event logging policies, procedures, practices and associated records. Are all
key systems (including event logging itself) being monitored and logged consistently and securely? What
events or parameters are being monitored (look for evidence of an architecture, design or structured
database)? Check for logging of security-relevant events such as: changes to user IDs, permissions and
access controls; privileged system activities; successful and unsuccessful access attempts including logon
and logoff; device identities and locations, plus network addresses and protocols; software installation and
changes to system configurations (e.g. clock resets, log stop/start, alarm cancel); use of system utilities and
applications; files accessed and the kind of access). Check by sampling that security incidents are being duly
reported, assessed and resolved. Who is responsible for reviewing and following-up on reported events?
How long are event logs etc. retained? Is there a process in place for reviewing and responding
appropriately to security alerts from vendors, CERTs, professional interest groups, government sources etc.?
Is the overall process running reasonably well in practice? How could it be improved?
A.12.4.2 Protection of log information: where appropriate, are logs being stored/archived in a non-
editable secure format or control mechanism? Is access to logs adequately controlled, authorized and
monitored? Who has, or might obtain, read/write/delete access to event logs, and is that appropriate? Is
there sufficient storage capacity given the average volume of logs being generated and the retention
requirements (duration)? Check the historical status of these requirements.
A.12.4.3 Administrator and operator logs: review policies, procedures, practices and associated records
concerning privileged administrators, operators etc. including security, SIEM and outsourced service
administrators. How are the logs collected, stored and secured, analysed/monitored and maintained (e.g.
archived for later forensic analysis)? Where appropriate, do the security arrangements limit the ability of
such individuals to interfere with the logs or the logging arrangements, at least not without raising security
alarms and incidents? Consider the risks and identify any issues or opportunities for improvement.
A.12.4.4 Clock synchronisation: review policies, architectures, procedures, practices, guidelines and
associated records concerning system clock synchronization and accuracy. Is there a defined reference time
(preferably based on atomic clocks e.g. GPS or NTP to a stratum 1 time reference)? Does the method for
synchronising clocks with the reference meet business, security, operational, legal, regulatory and
contractual requirements? Has this been implemented across the IT estate including monitoring systems
such as CCTVs, alerting and alarm systems, access control mechanisms, auditing and logging systems, IoT
things etc.? Check the monitoring arrangements. What actually happens if a time reference becomes

du SGSI v2
unavailable for some reason? Have the associated information risks been analysed and appropriately
treated? How are clock changes, leap seconds etc. handled?
A.12.5 Control of operational software

A.12.5.1 Installation of software on operational systems: review policies, procedures, practices and
associated records concerning software installation. Check that only fully tested, approved and currently
supported/maintained software is installed for production use. Hunt down any outdated and especially no
longer supported/maintained software on productions systems (firmware, operating systems, middleware,
applications and utilities). Check that desktops, laptops, servers, databases etc. are configured to prevent
software installation except by trained and authorized administrators under management authority. Do the
management and monitoring systems and practices flag-up any unapproved software installations,
reporting them to and recording them on the configuration management database, monitoring/alerting
systems etc.? Cross-check against change and configuration management, security management, business
continuity and other relevant areas, focusing on high-risk/critical systems.
A.12.6 Technical vulnerability management

A.12.6.1 Management of technical vulnerabilities: review policies, procedures, practices and associated
records concerning the management (identification, risk-evaluation and treatment) of technical
vulnerabilities. How does the organization discover and respond to technical vulnerabilities in desktops,
servers, applications, network devices and other components? Review incident and change control records
for evidence relating to recent patches, vulnerability assessments, penetration testing etc. Are there
suitable processes in place to check systems inventories and identify whether disclosed vulnerabilities are
relevant? Has a comprehensive risk assessment of ICT systems been performed? Have risks been identified
and appropriately treated, prioritized according to risk? Is risk assessment ongoing to identify changes such
as emerging threats, known or suspected vulnerabilities, and evolving business impacts or consequences?
Are patches assessed for applicability and risks before being implemented? Are the processes for
implementing urgent patches sufficiently slick and comprehensive? To what extent does the organization
depend on automated patch management, in effect accepting the associated risks of implementing rogue
patches? Look for any evidence of important systems that have not been maintained at current release
levels and/or patched against known vulnerabilities.
A.12.6.2 Restrictions on software installation: check that only authorised personnel having appropriate
system privileges are able to install software on systems. Check how many categories of such privileges are
there and what privileges each category has. Check what types of software each of these categories can
install, on which systems. Do the controls apply to patching, backup restores and online downloads as well
as conventional system installations?
A.12.7 Information systems audit considerations

A.12.7.1 Information systems audit controls: check that information security audits are a policy
requirement. Is there a defined program and procedure for audits? Verify whether audit requirements
involving checks on operational systems are carefully planned and agreed to minimise the risk of
disruptions to business process. Verify whether the audit scope is agreed to with appropriate management.
Verify that access to information system audit tools/software is controlled to prevent misuse and
compromise. Verify the segregation of system audit tools from development and operational systems, and
that they are provided an appropriate level of protection.

du SGSI v2
A.13. Communications security
A.13.1 Network security management

A.13.1.1 Network controls: check if there is a policy covering both wired and wireless networks. Is management
of computer operations separate from network operations? Check for adequate security protection mechanisms
on the networks. Check for appropriate logging and monitoring of the network and its devices, check for 'fail-
proof' authentication procedures for all access to the organisations network. Check how network access points
are secured against unauthorized access? How does the system limit access by authorized individuals to
legitimate applications/services? Are users authenticated appropriately at logon (including dial-in and
remote/Web users)? How are network nodes authenticated? Are distinct security domains established using
firewalls, VLANs, VPNs etc.? Confirm protection of any privileged system management and remote support ports
e.g. secure modems, challenge-response systems, key lock-out etc.
A.13.1.2 Security of network services: check for a policy on the following and how they are implemented in
day-to-day operations:
• Secure management of information services;
• Monitoring of network services;
• Right to audit as part of contract in case of managed network services by a third party (contracts, SLAs
and management reporting requirements);
• Authentication on the network, plus encryption and network connection controls;
• Periodic review of technical parameters, firewall rule review, IDS/IPS signatures etc.
A.13.1.3 Segregation in network services: check the policy on network segregation and consider the risks.
What types of network segregation are in place? Is network segregation based on classification, trust levels,
domains (public, desktops, servers, functions), a combination or something else? Check how segregation is
achieved, monitored and controlled. How are wireless networks segregated from wired networks? Check
how guest networks are segregated from corporate networks. Are there adequate controls between them?
If there are any extranets with vendors etc., how are these secured? Is the security adequate given the risks
and the risk appetite of the enterprise?
A.13.2 Information transfer

A.13.2.1 Information transfer policies and procedures: check for a policy on the subject and for procedures
around secure transmission of information via email, FTP and other data transfer applications and protocols,
Web (e.g. groups/forums), Dropbox and similar cloud services, WiFi and Bluetooth, CD/DVD, USB stick, courier
etc. Check how various categories (classification levels) of information are required to be secured when
transferred. Are access controls adequate? Where, when and how is cryptography mandated (e.g. link
encryption, email encryption, encrypted ZIPs)? Check that suitable confidentiality or privacy arrangements (such
as Non-Disclosure Agreements, identification and authentication, out-of-band disclosure of encryption keys,
non-repudiation/proof of receipt) are in place prior to the exchange of sensitive or valuable information. Check
the associated awareness, training and compliance arrangements too.
A.13.2.2 Agreements on information transfer: further to A.13.2.1, on what types of communications are
digital signatures implemented? Check liabilities and control in case of data loss, corruption, disclosure etc.
Check identification and synchronisation of information classification levels of all involved parties. How is a
chain of custody maintained for data transfers?
A.13.2.3 Electronic messaging: check for policy on control requirements around email, review policies and
procedures for data exchanges e.g. communications network links including email and FTP/SFTP, dial-up links
etc. Are there suitable security controls (e.g. email/link encryption, authentication and non-repudiation

du SGSI v2
based on message classification etc.)? Review security arrangements for Internet, Intranet and related
systems (bulletin boards etc.).
A.13.2.4 Confidentiality or non-disclosure agreements: locate and check the content of any such
agreements. Have they been reviewed and approved by Legal? When were they last reviewed (periodic or
change-driven)? Have they been approved and signed by the appropriate people? Are there suitable
penalties and expected actions in case of noncompliance and/or benefits for compliance (e.g. a
performance bonus)?
A.14. System acquisition, development and maintenance
A.14.1 Security requirements of information systems

A.14.1.1 Information security requirements analysis and specifications: check the policy, procedures,
guidelines, practices and records in this area. Are formal systems development methods used routinely for
high-risk systems e.g. safety-, business- or mission-critical? Are information risk analysis, functional and
technical requirement specification, security architecture/design, security testing and certification etc.
mandatory activities for all new developments and changes to existing systems (e.g. maintenance updates,
operating system/application upgrades, crypto changes etc.). Are information risks handled in a similar way
for commercial systems and software including bespoke, custom and off-the-shelf products?
A.14.1.2 Securing application services on public networks: if the organization uses or provides web based
applications or other eCommerce systems, review the corresponding information security controls for
access and user authentication, data integrity and service availability. Review security designs for a small
sample of major systems to determine whether controls such as input data validation, processing
validation, encryption, message authentication, non-repudiation etc. are employed appropriately. Check for
the enforced use of https, for example, to protect sensitive data en route between Web browser and server.
Review system security documentation. Are such requirements covered by policy? If the organisation
subscribes to a 'threat intelligence’ service, check which public websites are being monitored. Are identified
threats being routinely documented, risk-assessed and treated through incident and change management
procedures?
A.14.1.3 Protecting application services transactions: further to A.14.1.2, check how transaction integrity,
confidentiality, availability and prevention of mis-routing are achieved. Are transactions performed and
stored in a secure internal environment (not open to the Internet!)? Do they meet all jurisdictional legal,
regulatory and compliance requirements?
A.14.2 Security in development and support processes

A.14.2.1 Secure development policy: is there a policy on secure development covering security
architectures, services and software? Are development environments and repositories secure with access
control, security and change monitoring etc.? Do development methods include secure coding guidelines?
Confirm that developers have adequate knowledge about secure coding practices and are capable of using
secure programming techniques in instances of code re-use where development standards may not be fully
known. These checks are to be performed even if development is outsourced to third parties.
A.14.2.2 System change control procedures: review IT system change management policies, procedures,
standards, practices and related records. Do they include planning and testing of changes, impact assessments
(including information risk and security aspects, plus the impacts of not changing!), installation verification
checks and fall-back/back-out/reversion procedures (tested!), both standard (production and non-production)
and emergency changes etc.? Do they cover significant changes to computing and

du SGSI v2
telecommunications equipment (hardware), key system and security parameters, system and application
software, firmware etc.? Review a small sample of system change management records, focusing on high-
risk system changes. Are system changes properly documented, justified and authorized by management?
Look for improvement opportunities. (See also A.12.1.2).
A.14.2.3 Technical review of applications after operating platform changes: assess whether changes to
systems (e.g. maintenance updates, operating system/application upgrades and patches, crypto changes
etc.) trigger security reviews/risk assessments and, if necessary, re-certification of systems. Confirm that
this has been done on a sample of systems.
A.14.2.4 Restrictions on changes to software packages: check if changes have been made to software
packages, confirming that original built-in controls have not been compromised. Was vendor consent and
involvement obtained? Does the vendor support continue? Was the possibility of getting standard program
updates from vendors explored? Was compatibility checked with other software in use?
A.14.2.5 Secure system engineering principles: confirm that secure system engineering principles have
been documented and incorporated within the project governance framework/methods. Check security
aspects of the SDLC process which should have sections and steps to check for security controls, check for
endorsement from top management for all projects to follow the secure SDLC process, check if Developers
and Programmers are trained on secure software development, check for evidence of stage/phase/toll gate
checks which include security checks and approvals for all development and enhancement projects.
A.14.2.6 Secure development environment: review the controls isolating development from testing and
production environments. How is software developed, tested and released? Who is responsible for
ensuring that new/changed software does not disrupt other operations? Confirm if background checks
have been performed of developers and that they are mandated to abide by the NDA. What are the
applicable regulations and compliance requirements affecting development? How are test data derived and
protected against disclosure and where are they stored? Check for evidence or steps which include security
checks and approvals of software code before being released.
A.14.2.7 Outsourced development: further to A.14.2.6, check:
• Licensing arrangements, code ownership and intellectual property rights related to the outsourced
content;
• Contractual requirements for secure design, coding and testing practices e.g. secure development
methods; protection of specifications, designs, test data, test cases and test results;
• Escrow arrangements e.g. access to source code if executable code needs to be modified but the
supplier is no longer available or capable;
• Application security testing controls and the test results;
• Vulnerability assessment and mitigation.
A.14.2.8 System security testing: check for a thorough testing and verification procedure for all new and
updated systems which include a detailed schedule of activities, test inputs and outputs under a range of
conditions. Check licensing arrangements, code ownership and intellectual property rights related to the
outsourced content.
A.14.2.9 System acceptance testing: how are acceptance tests (including IT security aspects) completed
prior to the introduction of new systems onto the network? Evaluate in conjunction with A.14.1.1, A.14.1.2
and A.14.2.1. Is testing automated, manual or both? Do tests replicate realistic operational environments
and situations? Are security-related defects remediated before product are certified/passed? Is there user
acceptance testing before release to the operational environment? Check whether fault-tolerant or
redundant information systems, failover mechanisms, disaster recovery arrangements etc. are regularly

du SGSI v2
tested to ensure they work as intended. Are resilience and recovery controls updated to reflect new,
changed and retired systems?
A.14.3 Test data

A.14.3.1 Protection of test data: confirm that testing systems have appropriate access control. Check what
data is used for testing and how it is protected. If operational (‘production’) data is used for testing, confirm
that there is an appropriate approval process for use of this data before it is acquired for testing (especially
if it contains personal information or other sensitive content), check if such data is adequately masked
before use, and that it is erased immediately after testing. There should be audit logs when operational
data is being copied for testing and these should be archived.
A.15. Supplier relationships
A.15.1 Information security in supplier relationships

A.15.1.1 Information security policy for supplier relationships: review the policies, processes, practices
and records relating to the management of supplier relationships involving outsourced IT and cloud,
logistics, utilities, HR, medical, financial, legal and other services with significant information risk, security
or compliance implications. Where applicable, do contracts and agreements adequately address:
• Relationship management arrangements including the information risk and security aspects, metrics,
performance, issues, escalation routes etc.;
• Information/intellectual property ownership, and obligations/constraints arising;
• Accountability and responsibilities relating to information risk and security;
• Legal, regulatory and policy requirements, such as certified compliance with ISO/IEC 27001;
• Identification of and protection against information risks using physical, logical/technical
procedural/manual and legal/commercial controls (some of which may be specified e.g. collaborative
risk management);
• Handling of events, incidents and disasters including evaluation, classification, prioritization,
notification, escalation, response management and business continuity aspects;
• Security clearance of employees, plus awareness, training etc. (by either or both parties);
• A right of [security] audit by the organisation and/or whistleblowing mechanisms?
Is either party contractually bound to abide by [some of] the other’s information risk, security or related
policies in addition to their own, and how are any conflicts addressed? Are external service providers
routinely monitored and (if applicable) audited for compliance with security requirements, or only in
response to identified incidents or issues? How are any changes in the associated information risks
identified and responded to? Evaluate the available evidence.
A.15.1.2 Addressing security within supplier agreements: if applicable, check for formal contracts or
agreements with suppliers covering the following:
• Relationship management including information risk and security management, coordination,
reporting, metrics etc.;
• Comprehensive and binding non-disclosure agreement or clauses;
• Description of information that will be handled, methods of accessing the information;
• Information classification scheme that must be followed;

du SGSI v2
• Applicable policy, legal and regulatory compliance requirements, plus any obligation to implement
specific controls (e.g. access controls, performance reviews, monitoring, reporting, auditing);
• Prompt information security incident notification/escalation and collaboration during incident
management and resolution;
• Business continuity aspects such as no-fault resolution, best endeavours, alternative sources, escrow;
• Sub-contracting and constraints on relationships with other suppliers, customers, partners and
competitors;
• Personnel and HR aspects e.g. handling performance issues or trust concerns, no poaching our best
people!
Check that the associated security and compliance aspects are covered during periodic relationship
management meetings etc.
A.15.1.3 Information and communication technology supply chain: further to A.15.1.1 and A.15.1.2, check
how information risk and security practices propagate throughout the supply chain, especially when parts
are subcontracted. How are the security requirements of acquired products (goods and services) validated?
How is resilience achieved where critical products or services are supplied by others? Can their origin be
traced if needed (e.g. firmware and embedded systems)?
A.15.2 Supplier service delivery management

A.15.2.1 Monitoring and review of supplier services: how are services monitored and who is responsible
for this activity? Are service review meetings conducted, at what frequency and with what audiences?
Check security-related reports, presentations and metrics reviewed and decisions made at such meetings.
Are information risks, incidents, policies, compliance, management review and audit reports etc. discussed
during these meetings? Are there penalty or bonus clauses in the contract concerning information risk and
security requirements, and how well are they working in practice?
A.15.2.2 Managing changes to supplier services: what happens if there are any changes to information-related
services provided, such as additional services or changes to the way contracted services are delivered? Also if
the organization’s security policies, standards or laws and regulations change, and suppliers are required to
comply with them. How are such situations handled in practice? Look for examples.
A.16. Information security incident management
A.16.1 Management of information security incidents and improvements

A.16.1.1 Responsibilities and procedures: review the policy, procedures, guidelines etc. on incident
management covering:
• Incident response planning and preparations;
• Nominated point/s of contact for incident reporting, tracking and feedback (e.g. status updates);
• Monitoring/detecting and reporting information security events;
• Analysing, evaluating and where appropriate assigning events to resolving agencies, incident response
teams etc.;
• Escalation paths including emergency responses, business continuity invocation etc.;
• Planned methods of collecting digital forensic evidence where needed;
• Periodic and/or post-event security review meetings and learning/improvement processes etc.

du SGSI v2
Check a sample of records arising from incident reporting, logging, triage, assignment to resolution agencies,
mitigation, confirmation of closure, learning points etc. Look for issues and improvement opportunities.
A.16.1.2 Reporting information security events: how are information security events (plus incidents, near-
misses and weaknesses) reported e.g. phone call, email or SMS text to Help/Service Desk; incident
reporting app or form on the intranet; in person report to information security/line manager etc.? Are
workers aware of the need to report promptly, and do they do so routinely in fact (check the metrics!)?
What happens to such reports? Trace the information and workflow using relevant records, archived
incidents etc. comparing what actually happened against policies, procedures and guidelines. Speak with
people who have recently reported events to explore the experience and outcome from their perspectives.
A.16.1.3 Reporting information security weaknesses: further to A.16.1.2, check that workers are
mandated (and encouraged through awareness and training, and enabled through reporting mechanisms)
to report any kind of unusual occurrence such as systems and applications logging in or logging out
automatically, unprogrammed session timeouts, phishing or spam emails, or any other noticed or
suspected and unusual occurrence. Do the policies explicitly prohibit workers from ‘checking’, ‘exploring’,
‘validating’ or ‘confirming’ vulnerabilities unless they are expressly authorized to do so?
A.16.1.4 Assessment of and decisions on information security events: check what is expected of all
employees as far as reporting information security events and incidents are concerned. What exactly are
they expected to report? Are they expected to report each and every event or only just specific types of
events? To whom do they report? How are these events evaluated to decide if they qualify as incidents? Is
there a classification scale? Is there a triage and/or escalation process to prioritize serious incidents? What
is it based on?
A.16.1.5 Response to information security incidents: check what actions are taken once an incident is
identified and prioritised. How is evidence collected, stored and evaluated? Is there an escalation matrix to
use as needed? Are there means to communicate information of such incidents to internal and external
organisations on a need-to-know/inform basis? Check actions taken to resolve and finally close the incident
and record its occurrence.
A.16.1.6 Learning from information security incidents: check the evaluation/investigation mechanism in
place to identify recurring or high impact incidents. How is the information gained from the evaluation of
information security incidents used gainfully to prevent recurrence and implementing improvement
opportunities? Also, is this used for awareness and training purposes? Check later parts of the processes for
managing security incidents through to closure. Does the organization have a relatively mature incident
management process in place? Is it proactively learning from incidents, improving risk knowledge and
security controls accordingly? Check the records relating to recent incidents for evidence.
A.16.1.7 Collection of evidence: forensic collection of digital evidence is a specialised skill. Check whether
this is done competently in-house or by third parties specialising and trained in this area. If retained in-
house, confirm that there are trained, competent, trustworthy personnel with suitable tools and defined
processes for the role (e.g. chain-of-evidence rigorously maintained, evidence secured in storage; analysis
on forensically-sound copies using forensic-grade tools and techniques). Who decides to undertake
forensics, and on what authority and basis? How are issues relating to jurisdiction, differing forensic
standards and associated legal requirements (e.g. seizure, storage, analysis and presentation of evidence)
handled?

du SGSI v2
This section reflects business continuity

in general, not just the continuity of
information security operations and
controls in ISO/IEC 27002 section 17.
Please refer to ISO 22301 and other
guidance.
A.17. Business continuity management (per ISO 22301)
A.17.1 Business continuity

A.17.1.1 Business continuity planning: how does the
organization determine its business continuity requirements?
Review the associated policies, procedures, standards,
guidelines, practices and records (e.g. business continuity
plans). Determine whether suitable ‘high availability’ designs
are employed for IT systems, networks etc. supporting critical
business processes. Verify whether those involved understand
the risks the organization is facing, correctly identify business critical processes and the associated assets,
identify potential incident impacts, and mandate suitable preventative, detective and corrective controls.
Evaluate business continuity plans, continuity exercises/tests etc. by sampling and reviewing the process
documentation, reports etc. Verify that events likely to interrupt business processes will be promptly
identified and assessed, triggering disaster recovery-type activities.
A.17.1.2 Implementing information security continuity: verify that suitable plans are in place to maintain
business operations or restore them within defined timeframes following interruption or failure. Do the
plans take into account the identification and agreement of responsibilities, identification of acceptable
loss, implementation of recovery and restoration procedures, documentation of procedures and regular
testing/exercises? Verify that there is a single coherent framework for business continuity planning. Verify
whether the framework ensures that all plans are consistent and identify priorities for testing and
maintenance. Determine whether the business continuity plans and the planning process, taken as a whole,
are adequate to satisfy the identified information security requirements. Verify if business continuity plans
are regularly exercised/tested to ensure that they are remain up to date and effective. Verify whether
members of the crisis/incident management and recovery teams and other relevant staff are aware of the
plans and are clear on their personal roles and responsibilities. Check that security controls at disaster
recovery sites and alternative locations adequately mitigate the corresponding information risks (e.g. are
the controls substantially equivalent to those at primary operational sites?).
A.17.1.3 Verify, review and evaluate information security continuity: check that business continuity
policies and procedures include testing methods and frequency and evidence of actual testing and their
results. Check whether the validity and effectiveness of information security continuity measures have been
reviewed during the BC & DR execution, have any shortcomings been identified, have they (and how) been
remediated and retested till the results are satisfactory?
A.17.2 Redundancies
A.17.2.1 Availability of information processing facilities: check how the availability requirements for ICT
services are identified and satisfied. Verify resilience, capacity and performance arrangements, including
monitoring and adjustments (e.g. dynamic load balancing). Examine incident records for clues about
unreliable services, equipment, facilities, servers, apps, links, functions, organizations etc. Check that key
information security controls are implemented and functional at disaster recovery/fall-back sites. If controls
at DR/fall-back sites are less strict than those at primary sites, are the additional risks being treated
appropriately (e.g. compensating controls such as increased oversight, and risk acceptance for the limited
period of DR invocation)?

du SGSI v2
A.18. Compliance
A.18.1 Compliance with legal and contractual requirements

A.18.1.1 Identification of applicable legislation and contractual requirements: is there a policy on the
subject (probably not specific to information risk, security and related areas but covering compliance in
general)? Is there some form of compliance register or database maintained, listing all applicable legal,
regulatory and contractual requirements obligations and expectations, each with accountable owners?
Who owns, maintains, uses and controls the register? Are compliance requirements systematically
identified and registered, both initially and any subsequent changes? How is compliance achieved and
assured i.e. what activities are performed to meet the requirements and ensure they are met? For a sample
of information security-related compliance requirements (e.g. privacy acts, intellectual property, PCI DSS,
SOX, HIPAA, official secrets and relevant clauses in contracts, agreements and standards), ascertain whether
the corresponding information security controls are in place. Check for example that suitable controls are in
place to comply with requirements on:
• Privacy – soon including GDPR;
• Health and safety (most workers are valuable information assets!);
• The use of copyrighted materials such as licensed software (see A.18.1.2);
• Protection of important financial, tax and other business records against loss, destruction and
falsification (e.g. fraud);
• Cryptography e.g. export controls.
A.18.1.2 Intellectual property rights: confirm that policies and procedures are in place concerning
compliance with the associated requirements/obligations both by the organization and by second parties
(e.g. licensees of corporate patents and copyright content). Check the permitted methods of acquisition
and use of copyrighted materials, such as software licenses. Are there policies and procedures concerning
acquiring, using and licensing intellectual property, license management, compliance reviews etc.?
A.18.1.3 Protection of records: check for a policy on records management that covers control requirements
such as classification, categorisation, record types, retention periods, allowable storage media on which they are
stored etc. Check also for the related cryptographic keys and digital signatures of such records which must also
be securely stored. Ascertain how important organizational records are protected from loss, destruction and
falsification, unauthorised access and release in accordance with statutory, regulatory, contractual and business
requirements. Check whether the storage / archival arrangements take account of the possibility of media
deterioration (e.g. controlled storage conditions, periodic integrity checks and/or transfer to fresh media)?
Check if appropriate long-life storage media is used for long term storage.
A.18.1.4 Privacy and protection of personally identifiable information: check policies and procedures in
this area. Check if these have been appropriately disseminated to all staff handling PII. Confirm who is the
privacy officer of the enterprise and whether he/she is aware of what attributes of PII are collected and
processed/stored by the organisation for organic employees, contractors and other third party staff?
Confirm if the PII being collected is in line with legal and regulatory requirements, if the information assets
on which PII is stored, processed and the channels for their communication have been identified, what are
the access controls around such PII, what is the level of access and roles (of personnel) who have access on
these assets etc.
A.18.1.5 Regulation of cryptographic controls: verify that the organization’s use of cryptography is in
compliance with all relevant laws, agreements/contracts and regulations. Check for a policy on the subject
and if the organisation is involved in any import/export related activities of cryptographic material and/or
encrypted information, and whether such activities are in compliance with legal and regulatory

du SGSI v2
requirements. Check that the policy requires the organisation to comply with national legal mandates with
reference to disclosure of encryption keys.
A.18.2 Information security reviews

A.18.2.1 Independent review of information security: are the organisation’s information risk and security
arrangements reviewed for suitability in line with its objectives by independent internal or external
auditors? Are audit requirements involving checks on operational systems carefully planned, authorized,
conducted and controlled to minimise risks to the business? Are audit objectives and scopes agreed and
authorized by appropriate management? Is access to information system audit tools/software adequately
controlled to prevent misuse and compromise? Are system audit tools prohibited from or protected on
corporate systems, outside of authorized audits? Are audit findings recorded and acted on, and are audit
records securely preserved for future reference?
A.18.2.2 Compliance with security policies and standards: how do managers and supervisors ensure that all
security procedures within their area of responsibility are carried out correctly in compliance with security
policies, standards etc.? Are there regular security compliance reviews within their area of responsibility?
A.18.2.3 Technical compliance review: are IT systems and
networks regularly reviewed/tested for compliance Automated system security audit tools are
with defined technical security requirements powerful utilities but are not appropriate in all
e.g. through network vulnerability scans and environments. They can potentially undermine
penetration tests? Check the corresponding policies, system security, perhaps introducing additional
procedures, methods, tools and records. Are the tests technical vulnerabilities, extracting highly
conducted by appropriately qualified, competent and sensitive information and affecting system
trustworthy professionals? Review the information risks performance or availability. Furthermore,
and controls relating to the testing itself (e.g. legally auditors using such tools must be competent to
binding obligations in contracts if external organizations use and obtain meaningful data from them: a
are used; competent supervision, proactive/intense “pass” from an automated vulnerability
monitoring and thorough logging of activities). How are assessment tool does not necessarily mean that
the results reported, analysed and used? Given their a system is free of vulnerabilities and is hence
sensitivity, how are results secured? Review records of secure. A wrongly-configured or ineptly used
findings, analysis, prioritization, risk treatment database security review tool may bring down a
decisions, change requests etc. to confirm that production system. Such tools should only be
appropriate actions are in fact being taken to address introduced using the organization’s
identified issues. Cross-reference this with conventional change management processes,
nonconformity and corrective action in B.10.1. Look out including pre-implementation risk assessment
for longstanding, repeatedly reported issues that are and security testing, where appropriate.
evidently not being resolved.

du SGSI v2
Appendix B - Generic ISMS management system audit checklist
Introduction
The following ISMS management system audit checklist comprises a This audit checklist is NOT
generic set of audit tests. It is structured in line with and reflects intended for certification audits.
ISO/IEC 27001's requirements for all ISMSs without regard to any Certification auditors are required
specific requirements that an individual organization might have (for to follow their formally-
example legal, regulatory and contractual obligations concerning documented and accredited audit
particular information risk and security processes, activities or processes, using their own audit
controls). checklists and audit tests
Whereas ISMS certification audits are narrowly focused on the concerning the extent to which
explicit wording of the standard, this checklist is primarily intended the ISMS complies with the
to guide, or to be adapted and used by, competent internal requirements specified in ISO/IEC
auditors conducting ISMS internal audits. It can also be used for 27001.
internal management reviews of the ISMS including pre-certification
assessments to determine whether the ISMS is in a fit state to be formally audited. That said, internal
audits and management reviews along these lines should help the organization prepare and finalize the
necessary documentation that certification auditors will probably want to review.
Internal audit checklists may The extensive audit tests suggested below in the form of questions and
be further modified during the checks are intended as prompts or reminders of the main aspects to be
course of the audit if new or checked by competent, qualified and experienced IT auditors. They do not
previously unappreciated cover every single aspect of ISO/IEC 27001. They are not meant to be
areas of concern come to asked verbatim and simply checked-off, whether in whole or piecemeal.
light. Unlike strict compliance They are not suitable for use by inexperienced auditors working without
audits, internal audits may supervision.
delve into related issues that This checklist is not meant to be used without due consideration and
emerge as the audit proceeds, modification. It is anticipated that users will normally generate custom
within the more flexible checklists reflecting the specific scope and scale of the particular ISMS
boundaries of the scope, being audited, and the audit tests arising, taking into account any
timescales and resourcing information security requirements that are already evident at this stage
available. (such as information-security relevant laws, regulations and standards
that are known to apply to similar organizations in the industry).
Finally, checklists should support the auditors’ normal working practices, for example in a tabular format
with additional columns for the auditor to record notes and commentary, initial evaluation (e.g.
SWOT/PEST/PESTEL), references to audit evidence on file, maturity metrics etc. Once completed, the audit
checklist links the audit evidence and findings gathered and analysed during the fieldwork and analysis
phases through to the audit report.
Étant donné que les listes de contrôle, les dossiers, les notes et les preuves de l'audit du SGSI
contiennent des informations sensibles concernant les risques liés à l'information et les dispositions de
sécurité de l'organisation, ils doivent être correctement sécurisés pour garantir leur confidentialité et
leur intégrité.
du SGSI v2
B.4. Context of the organization
B.4.1 Understanding the organization and its context

Has the organization identified a number of external and internal issues that are relevant both to the
purposes of the organization and to the ISMS? How well are these described in the ISMS scope? How
relevant and important are they? Is there a strong impression that information is a business asset,
information risk is a business issue, information security supports the business in achieving its objectives,
and hence the ISMS is a valuable business-enabling governance structure?
If the ISMS scope only covers part of

the organization, the remainder is
probably an ‘interested party’ with
needs and expectations relevant to
the ISMS.
B.4.2 Understanding the needs and expectations of interested parties

Carefully consider the ISMS scope and related documents. Has
the organization identified external stakeholders or parties
outside the scope of the ISMS with an interest in the
organization’s information risks and security arrangements?
Check that all relevant interested parties have been identified
and duly considered e.g. suppliers; business partners;
customers and prospects; workers; governments, authorities
and regulators; owners; professional advisors; reviewers and auditors; decision makers; local communities
and society at large. Check that their information risk and security requirements been determined and
taken into account in the ISMS, in addition to the organization’s own e.g.:
• ISO/IEC 27001 certification of the organization’s ISMS by an accredited certification body;
• Applicable laws and regulations e.g. privacy, finance and tax laws; official secrets and freedom of
information acts;
• Contractual obligations, liabilities and constraints e.g. licenses for intellectual property;
• Security (particularly confidentiality but also integrity and availability) of
confidential personal and proprietary information; There is common ground
• Reliability, performance and capacity of information and information between internal and
external drivers for
services e.g. Internet and cloud service providers; information feeds;
information risk and
• Identifying, responding to and reporting information security incidents or security, since
breaches; information is a vital
• Enabling and limiting the information risks associated with various business business asset. This
activities and IT operations, supporting business objectives such as section emphasizes the
governance, profitability and continuity; external perspective.
• Maintaining a fit-for-purpose operational infrastructure and services (e.g.
systems maintenance and software support);
• Gaining assurance that the organization is competently, efficiently and effectively identifying and treating
information risks.
Compile and check the
B.4.4 Information Security Management System documentation and other evidence
concerning the establishment, implementation, maintenance and
continual improvement of the ISMS including mandatory ISMS
documents and records arising from the management processes,
metrics and trends demonstrating improvement, results of Check this detailed list of
management reviews and decisions taken at such reviews etc. mandatory and recommended
documentation from the free
ISO27k Toolkit.
Has management authorized the
du SGSI v2
implementation and operation of the ISMS, for example through a formal memorandum, project approval,
letter of support from the CEO etc.? Was this a mere formality or is there evidence that management
genuinely understands and supports the ISMS?
B.5. Leadership
B.5.1 Leadership and commitment

Evaluate the extent to which the organization’s management leads and supports the ISMS based on
evidence such as:
• Discussions, interviews, meetings etc. with management on and around this topic;
• Memoranda, emails, presentations, briefings etc. through which management expresses support for
and commitment to the ISMS and acceptance of ISMS objectives and implementation plans;
• The allocation of adequate resources and prioritization of the activities associated with designing and
building, implementing, operating and maintaining the ISMS (going beyond vocal support, is the
organization proactively investing in it?);
• Clear management direction where appropriate, such as risk acceptance criteria, risk
appetite/tolerance relating to information risk;
• Management-level interest and participation in ISMS activities such as meetings, workshops, focus groups,
policy development and approval, awareness activities and training courses, reviews and audits;
• Management’s prompt and positive responses to challenges, issues and concerns, incidents,
recommendations, tests and exercises, management review and audit reports etc.;
• Indications that workers in general understand the importance of the ISMS and willingly accept their
roles within it (implying a corporate security culture).
B.5.2 Policy
Review the information security policy suite and related This section concerns the governance
documentation (e.g. ISMS mission statement and scope). Check aspects: corporate policies must be
that it: driven and mandated by management.
Explicitly supports and enables the business purposes and The content of the information risk and
objectives of the organization, in the context of information security policies is specified in ISO/IEC
risk, security and related requirements (e.g. compliance, 27002 section 5.1.1.
protection, safety and business continuity);
• Specifies high-level information risk and security objectives, both internally and externally driven or
imposed, and clearly affirms the organization’s commitment to satisfy them;
• Is sufficiently formal and explicit to stand up in legal or disciplinary proceedings, yet readable and
pragmatic enough to be useful in practice (albeit supported by procedures, guidelines etc.);
• Supports continual improvement of the ISMS, reflecting
the evolving information risks and business situation, and Individual policies, procedures etc. may be
maturity; owned and authorized at lower levels, but
• Is approved, authorized and/or mandated as a coherent the overall structure needs senior
and reasonably comprehensive suite by “top” (senior) management’s explicit leadership and
management e.g. board, CEO, Executive Committee or mandate e.g. through an overarching
Security Committee; corporate strategy or policy on information
risk and security.

du SGSI v2
• Is communicated widely within the organization, including everyone within the scope of and directly
implicated in the ISMS;
• Is, where appropriate (possibly under nondisclosure agreements or in summary form) made available
to other interested parties.
B.5.3 Organizational roles, responsibilities and authorities

Check whether information risk and security-specific roles are
assigned, and related accountabilities, responsibilities and Accountability is a valuable control
authorities are defined and communicated e.g. in job descriptions approach. Holding people personally
and roles and responsibilities documents specifying key activities, accountable for their decisions, actions
necessary competences and qualifications etc. Are key and inactions reinforces their
responsibilities and authorities (e.g. compliance, metrics, obligations, for example to protect
authorizations, reviews and audits) appropriately assigned? Are information in their care.
there suitable, competent people in key roles?
Review the information risk and security management structure. Compared to other business activities and
functions, is information risk and security given sufficient emphasis and management support? Is there evidence of a
powerful ‘driving force’ at senior management level such as a management committee or forum to discuss
information risk and security policies, risks and issues, and take key decisions? Is there sufficient budget for
information risk and security activities? Are information risk and security-related activities effectively co-ordinated
and aligned among the various business units, departments, functions, teams, individuals and external parties with
interests in this area? Are the information flows (e.g. incident reporting and escalation) operating effectively in
practice?
B.6. Planning
B.6.1 Actions to address risks and opportunities

B.6.1.1 General
Check whether internal and external issues, as well as interested parties' requirements, are considered
while planning for ISMS and related risks and opportunities are considered (see also 4.1 and 4.2). Is there a
documented [information] risk management process to identify, assess/evaluate (according to estimated
probabilities and impacts) and treat information risks? Are the criteria for deciding on risk treatment
options clear, including the pros and cons of different approaches and risk appetite/tolerance levels?
B.6.1.2 Information security risk assessment

Ascertain and review the organization's choice/s of information risk assessment method/s, whether bespoke or
generally-accepted methods. Are the results of risk assessments comparable and reproducible? Look for
examples of anomalous or counterintuitive results to determine how they were addressed and resolved. Was
the risk assessment method updated as a result? Check that ‘risk scenarios’ are described for each risk, ‘risk
levels’ are assigned based on qualitative or quantitative measurement, ‘risk owners’ are nominated, and risks
are prioritised for treatment? Have recent changes (e.g. new/updated IT systems, business processes and
relationships) been suitably risk assessed? Are the Risk Treatment Plan, Statement of
Applicability, policies and procedures etc. being used proactively as information risk management tools?

du SGSI v2
B.6.1.3 Information security risk treatment
Review the organization's RTP. Are appropriate treatments specified for all identified information risks i.e.
avoiding risks by not undertaking risky activities; reducing risks through suitable controls; sharing risks with
third parties such as insurers; or accepting risks that fall within management's risk appetite? Check that risk
owners have approved the RTP and accepted the residual risks. Look for gaps, overlaps and other
anomalies (e.g. seemingly inappropriate or ineffective treatments). Check how the RTP relates to the
Statement of Applicability specifying the following for controls recommended in ISO/IEC 27001 Annex A
and/or other standards, control catalogues etc.:
• Whether it is applicable (include the justification if not); ISO/IEC 27002 may be
• Whether it arises from a legal, regulatory or contractual obligation, restructured to identify
or is business-driven (e.g. addresses an information risk of concern categories or types of security
to the business, or good practice); control. Doing so now puts the
• How it addresses the risk (e.g. preventive, detective or corrective; organization ahead of the game!
technical, procedural, physical or legal etc.).
B.6.2 Information security objectives and planning to achieve them

Review the ISMS mission, objectives, goals, strategies, plans etc. Does the ISMS explicitly support the
organization's strategic business objectives? Do the ISMS objectives reflect the organization’s key information
assets and risks, plus its legal, regulatory, contractual and other external obligations in this area?
Consider for each objective: Look for
• What, exactly, is the objective? What are we aiming to achieve or avoid here? What is objectives to
driving this – its purpose and value? be Specific,
• How will we know whether it has been achieved? How will progress and results be Measurable,
measured and evaluated (metrics plus success/failure criteria)? Achievable,
• What will be done to achieve it? What resources are required? Relevant and
Timebound.
• Who is accountable for achieving it, by what means, and by when?
B.7. Support
B.7.1 Resources
Review the resources allocated to the ISMS in terms of budget, manpower etc., in relation to the
organization's stated aims for the ISMS and (where applicable) by comparison to comparable organizations
(benchmarking). Is the ISMS adequately funded and resourced in practice? Are sufficient funds allocated by
management to address information security issues in a reasonable timescale and to a suitable level of
quality?
B.7.2 Competence
Review the qualifications, experience and training of those specifically involved in operating the ISMS, and
general information security awareness activities targeting all employees. Are necessary competencies and
training/awareness requirements for information security professionals and others with specific roles and
responsibilities explicitly identified and provided? Are training/awareness budgets adequate to fund the
associated training and awareness activities? Review training evaluation reports etc. and seek evidence to
confirm that any necessary improvement actions have in fact been taken. Check by sampling that employee HR
records note ISMS-related training etc. (where applicable). Assess the general level of information
du SGSI v2
security awareness by surveying/sampling, or review the results of surveys/samples conducted as part of
the ISMS.
B.7.3 Awareness
Are information security policies etc. well written and disseminated appropriately to all relevant parties?
Are recipients explicitly required to read and comply with them? How does the organisation confirm that all
have in fact read and agreed to comply with the policies e.g. signed acceptance or acknowledgement;
periodic quizzes/tests to confirm that recipients understand their obligations, including their wider role in
information risk management and making the ISMS effective and beneficial for the organisation? How are
policy compliance and non-compliance addressed e.g. benefits/rewards to reinforce compliance and
costs/penalties for non-compliance, through disciplinary procedures, relationship/contractual management
etc.? How are changes communicated e.g. new or revised policies, roles and responsibilities, information
risks (e.g. novel threats) and security controls? Is management sufficiently engaged and supportive e.g. do
managers actively participate in information risk and security awareness activities, training courses etc.?
Are training and awareness plans, budgets and priorities adequate?
B.7.4 Communication
Is there a documented communication plan identifying internal and external audiences to whom appropriate
and timely communication must be made with respect to all activities and occurrences related to information
security e.g. employees (need clear directions of what is expected of them, updates on policies, training in
procedures etc.); third parties/suppliers (need clear directions about what is expected of them; and legal and
regulatory authorities plus certification body and other stakeholders (need to be notified in the event of
breaches or incidents). Does the communication plan state what is to be communicated, when (timing or
Reminder: mandatory and

recommended documentation
frequency), by whom and by what means? Is there evidence confirming that previously planned
communications have taken place and been effective?
B.7.5 Documented information

B.7.5.1 General
Check for all the ‘documented information’ (= documentation!)
explicitly required by ISO/IEC 27001 (e.g. ISMS scope, roles and
responsibilities, risk assessment, Statement of Applicability, Risk
Treatment Plan, risk register, evidence of management reviews,
internal and external audit reports) and associated documentation (NCRs etc.). Has management identified
any additional documentation necessary for effectiveness of the ISMS and is it available? How is ISMS
information made available where needed (e.g. an intranet-based policy management system, SharePoint
repository and/or on paper)?
B.7.5.2 Creating and updating

Is the process for creating, updating and authorizing or mandating compliance with documentation suitably
controlled? Check for the presence of, and compliance with, policies and procedures for controlled and
authorized updates to ISMS documentation, policies, procedures, records etc. (How) are ISMS
documentation changes managed and controlled e.g. changes reviewed and approved by relevant
managers, and promulgated appropriately? Is document metadata standardised and adequate e.g.
document title, name of owner, date of publication, date of last and next review, distribution etc.? Is there
a list, inventory or database of controlled documentation?

du SGSI v2
B.7.5.3 Control of documented information
Further to 7.5.2, is important ISMS-related documentation adequately secured and protected (e.g. access
control, version control, a defined retention and revision policy, backups etc.)? Evaluate the controls
protecting important ISMS records such as various information security review and audit reports, action
plans, formal ISMS documents (including changes to same), visitors' books, access authorization/change
forms etc. Review the adequacy of controls over the identification, storage, protection, retrieval, retention
time and disposition of such records, particularly in situations where there are legal, regulatory or
contractual obligations to implement an ISO27k ISMS (e.g. to protect personal data or to supply a certified
organization).
Are important documents of external origin clearly identified as such and suitably controlled?
B.8. Operation
B.8.1 Operational planning and control

Check the plans in place to monitor and control all ISMS activities including continuous risk management
(see B.6.1) and actions to achieve information security objectives (see B.6.2). The information risk
management activities should cover commercial information services such as cloud computing where
applicable.
B.8.2 Information security risk assessment

Check that the ISMS-wide information risk assessment is repeated or at least reviewed and updated at
suitable intervals (e.g. annually or in the event of any significant change) to address any changes in threats,
vulnerabilities or impacts and hence risk levels. Review actions taken in response to previously-identified
changes in the risk levels. Are risk assessments and reviews documented appropriately e.g. records of risks
identified and treatments selected; who reviewed what and when; output reports and action plans, ideally
identifying those responsible and priorities/timelines?
B.8.3 Information security risk treatment

Review the Risk Treatment Plan. It should record management decisions to treat every identified
information risk through one or more defined forms of risk treatment:
1. Avoid: management typically decides not to do some activities at all (or at least not now) if the
information risks are considered too high relative to the business advantages of proceeding. What
prevents someone going ahead with these activities anyway, regardless of the formal decision to avoid
the risks?;
2. Reduce: information risks that are to be reduced (mitigated or ameliorated) should be listed in the RTP
along with details of how the risks will be reduced, typically through information security controls.
Other details typically recorded in the RTP include who is responsible for reducing the risk, the dates by
which controls are to be fully implemented and risks are to be reduced, who will or has
reviewed/checked and confirmed that risks have been sufficiently reduced etc.;
3. Share: if information risks are to be shared with (partially or wholly transferred to) third parties, check
that the documentation includes terms in contracts, agreements or cyberinsurance policies clarifying
obligations and liabilities relevant to information risks; security, privacy, compliance, incident
notification and management aspects including business continuity; right of audit; metrics etc.

du SGSI v2
4. Accept: all information risks that remain after the above treatments (including any that were not identified,
or where the risk treatments fail or fall short in some way) have to be accepted by the organization. In
addition, management may explicitly choose to accept some information risks. Check how the residual and
accepted risks are identified and managed e.g. assigned to appropriate accountable risk owners, monitored
and reviewed at predetermined intervals. Look for linkages to incident management, business continuity,
disaster recovery and all-purpose contingency arrangements.
B.9. Performance evaluation
B.9.1 Monitoring, measurement, analysis and evaluation

(How) does management monitor the ISMS to ensure that the
Metrics support decisions by addressing
security controls identified in the RTP, SoA, policies etc. are
questions relating to or arising from
effectively implemented, in operation and achieving objectives?
goals and objectives. High-level metrics
How does management promote and support continual
concerning the ISMS itself typically
improvement of information risk and security management,
measure its effectiveness and value to
driving the maturity of the ISMS while remaining aligned with
the organization, its compliance with
business objectives?
and achievement of various
Review the ISMS monitoring and measurement activities using requirements, mid- to long-term trends,
evidence gleaned from: security metrics; minutes of meetings resourcing and priorities, its
and actions arising; management review and internal audit implementation status and maturity
reports; breach/incident reports; security investment or project etc. in the organization’s broader
proposals, business cases etc. business context. Low-level detailed
Check how the metrics are specified/defined and used e.g. data metrics used within the ISMS to
sources; data collection, analysis and reporting frequencies; who manage information risks, security
collects, analyses and present/reports the data, and to whom. controls, incidents etc. depend heavily
Consider the purpose, quality, utility and value of the metrics e.g. on the particular situation, and tend to
using the PRAGMATIC criteria. Taken as a whole, do the metrics be more operational/short-term in
present a reasonably comprehensive, accurate and timely nature. See ISO/IEC 27004:2016 for
perspective to management? Are key management decisions more.
driven by the metrics, in fact?
[How] do the metrics drive continuous improvements?

du SGSI v2
B.9.2 Internal audit
Review the organization's internal audits of the ISMS as It is not uncommon for some agreed actions
documented in ISMS internal audit scopes, plans, reports, to remain incomplete at the planned
action plans etc. Is there an ISMS internal audit completion dates, especially if they are
programme, showing a planned set or series of audits? complex, costly or involve other parties. The
Are responsibilities for conducting ISMS internal audits point is not that everything must be done
formally assigned to competent, adequately trained exactly as planned so much as that
auditors (contractors or consultants if no suitable management remains on top of the situation,
employees are available)? proactively managing the work and allocating
To what extent to internal audits confirm that the ISMS sufficient resources to achieve a sensible rate
meets its requirements defined in ISO/IEC 27001 plus of progress, with a reasonable proportion of
relevant legal, regulatory or contractual obligations, and agreed actions being completed on time.
organizational ISMS requirements specified through the Continuous improvement and positive
risk assessment process? business outcomes are more important than
strict adherence to plans – see also section 8.
Check that recommendations, action plans, corrective
actions etc. are generally being addressed and verified within agreed timescales, paying particular attention
to any currently overdue actions for topical examples.
B.9.3 Management review

Management reviews of the ISMS should occur at least biannually Whether an ISMS certification audit,
or whenever there is a significant change to the ISMS. Is this performed at management's request,
defined e.g. in policy? When has management previously could be considered a “management
reviewed the ISMS, and when does it next plan to do so? review” strictly within the terms of
By reviewing management reports and other records, and/or by the ISO/IEC standard is unclear, but
interviewing those who were involved, check what went in to the that was not the intent. Their
previous management review/s (ISO/IEC 27001 identifies nine objectives and processes differ e.g.
items such as the results of other audits/reviews, feedback and audits are formalized, independent
improvement suggestions, information on vulnerabilities and assessments, whereas management
threats etc.). Assess the extent to which management played an reviews may not be.
active part and was fully engaged in the review/s.
Check the outputs of any previous management review/s including key management decisions, action
plans and records relating to the confirmation that agreed actions were duly actioned. If necessary, confirm
that closed actions have in fact been properly completed, focusing perhaps on any that were not
completed on time.
B.10. Improvement
B.10.1 Nonconformity and corrective action

Review a sample of records to evaluate what actually happens when a nonconformity is detected e.g.
through a review, audit, near-miss or incident. Are they routinely and consistently documented in the form
of Non-Conformance Reports (NCRs) including:

du SGSI v2
• Explicit details of the non-conformance including which obligations, requirements or controls it relates
to (e.g. clauses of ISO/IEC 27001; policies; laws and regulations; contractual terms; insurance
conditions; good practices);
• Root cause analysis, digging into the underlying reasons, gaps, Aside from the obvious but often
issues or failures that allowed the situation to occur; superficial symptoms and reactive
• Actions planned to address root causes, including any changes to aspects (such as compliance for the
ISMS strategies, policies, procedures, priorities, resourcing, sake of it), it is worthwhile
diagnosing and proactively treating
controls, metrics, oversight etc.;
any underlying root causes in order
• Specification, prioritization, scheduling/planning and resourcing of
to prevent issues from recurring
the actions arising; and perhaps worsening, like a
• Evidence demonstrating that the NCR has in fact been addressed cancer.
and resolved;
 Independent confirmation that the NCR has been resolved and hence can be closed?
Are appropriate corrective actions fully implemented and their effectiveness reviewed, routinely? Does
anyone make the effort to determining whether similar nonconformities exist, or may occur, elsewhere?
Are nonconformities and corrective actions considered in management reviews (B.9.3)?
B.10.2 Continual improvement

In addition to making ISMS improvements in response to reported nonconformities, does the organization
takes a more proactive stance towards addressing potential improvements, emerging or projected new
requirements etc.? How are potential ISMS improvements identified, assessed and (if applicable)
implemented? Obtain and review records relating to corrective actions such as reports and action plans
from ISMS management review/s or audits (see 9.2 and 9.3), ISMS change requests, budget/investment
proposals and business cases etc. Seek evidence that the ISMS is, in fact, being materially improved in
response to emerging or projected new requirements, emerging good security practices etc. Seek evidence
of ISMS changes (such as adding, changing or removing information security controls) corresponding to
significantly changed information risks.

Boîte À Outils ISO27k

Transféré par

Droits d'auteur :

Formats disponibles

Boîte À Outils ISO27k

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Boîte À Outils ISO27k

Transféré par

Droits d'auteur :

Formats disponibles

Abonnez-vous à DeepL Pro pour modifier ce document.

Visitez www.DeepL.com/Pro pour en savoir plus.

Boîte à outils ISO27k

Ligne directrice sur l'audit

Conseils génériques et pragmatiques pour

Complète la norme ISO27k (série ISO/IEC 27000)

Système de gestion de la sécurité de

Annexe A - Liste de contrôle générique pour l'audit de sécurité des

Copyright © ISO27k Forum, 2017 2|Page

Annexe B - Liste de contrôle générique pour l'audit du système de gestion du SGSI 42

2. Portée et objectif de la présente ligne directrice

Copyright © ISO27k Forum, 2017 5|Page

Copyright © ISO27k Forum, 2017 6|Page

Copyright © ISO27k Forum, 2017 7|Page

6.1 Gestion du programme d'audit du SGSI

6.2 Gestion d'un audit du SGSI

L'itération est courante, par exemple lorsque l'analyse ou le compte

7.1 Enquête de cadrage et de pré-audit

Copyright © ISO27k Forum, 2017 9|Page

7.2 Planification et préparation de l'audit

7.3 Travail d'audit sur le terrain

7.4 Analyse de l'audit

7.5 Rapports d'audit

Copyright © ISO27k Forum, 2017 11 | P a g e

Copyright © ISO27k Forum, 2017 12 | P a g e

7.6 Clôture de l'audit

8. Compétence et évaluation des auditeurs

Copyright © ISO27k Forum, 2017 13 | P a g e

8.2 Démonstration de la compétence de l'auditeur

Copyright © ISO27k Forum, 2017 14 | P a g e

9. Contrôle des documents

9.4 Droits d'auteur

Le Forum ISO27k est une communauté

Et surtout, c'est gratuit !

Annexe A - Liste de contrôle générique pour l'audit de sécurité

De nombreux contrôles de sécurité de

A.5. Politiques de sécurité de l'information

A.6. Organisation de la sécurité de l'information

Copyright © ISO27k Forum, 2017 17 | P a g e

Copyright © ISO27k Forum, 2017 18 | P a g e

A.7. Sécurité des ressources humaines

A.7.1 Avant l'emploi

A.7.3 Licenciement et changement d'emploi

A.8. Gestion des actifs

A.8.1 Responsabilité des actifs

Copyright © ISO27k Forum, 2017 20 | P a g e

Copyright © ISO27k Forum, 2017 21 | P a g e

A.8.2 Classification des informations

A.8.3 Traitement des médias

Copyright © ISO27k Forum, 2017 22 | P a g e

A.9 Contrôle d'accès

A.9.1 Exigences commerciales du contrôle d'accès

Comme les contrôles préventifs

approbations aux niveaux appropriés ?

A.9.2 Gestion de l'accès des utilisateurs

Copyright © ISO27k Forum, 2017 23 | P a g e

A.9.3 Responsabilités des utilisateurs

Copyright © ISO27k Forum, 2017 24 | P a g e

10.1 Contrôles cryptographiques