- 01Pourquoi la refonte 2022 a été nécessaire
- 02La nouvelle structure : 4 thèmes
- 03La taxonomie d'attributs : 5 axes
- 04A.5 — Contrôles organisationnels (37 contrôles)
- 05A.6 — Contrôles humains (8 contrôles)
- 06A.7 — Contrôles physiques (14 contrôles)
- 07A.8 — Contrôles technologiques (34 contrôles)
- 08Les 11 nouveaux contrôles 2022 expliqués
- 09La SoA — Statement of Applicability
- 10Comment aborder concrètement les 93 contrôles
- 11L'erreur la plus coûteuse : sous-estimer la transition
- 12En synthèse
L'Annexe A d'ISO 27001:2022 a été refondue en profondeur. Ceux qui ont connu la version 2013 — ses 14 chapitres et ses 114 contrôles — doivent désormais composer avec une structure plus compacte, plus moderne, et alignée sur ISO 27002:2022. Quatre thèmes au lieu de quatorze. Quatre-vingt-treize contrôles au lieu de cent quatorze. Et surtout, onze contrôles entièrement nouveaux qui reflètent l'évolution réelle des menaces : threat intelligence, cloud, data masking, secure coding, web filtering…
Cet article passe en revue chacun des 93 contrôles, thème par thème, avec une explication concrète et un niveau de difficulté indicatif. Il détaille également la taxonomie d'attributs introduite en 2022 (les fameux cinq axes) et les implications pratiques sur la SoA — la Statement of Applicability — qui reste la pierre angulaire du SMSI.
La transition entre la version 2013 et la version 2022 doit être achevée pour les certifications maintenues après le 31 octobre 2025. À l'heure où vous lisez ces lignes, la 2013 n'est plus reconnue. Si votre SoA n'a pas encore été refondue, il est temps de s'y mettre.
#Pourquoi la refonte 2022 a été nécessaire
ISO 27001:2013 avait été publiée à une époque où le cloud était encore minoritaire en entreprise, où le DevSecOps n'avait pas encore son nom, où la threat intelligence relevait des grandes structures financières et où la résilience face aux ransomwares n'était pas encore le sujet brûlant qu'elle est devenue. Les 114 contrôles couvraient bien les fondamentaux, mais souffraient de redondances, d'angles morts (cloud, supply chain logicielle), et d'une structure en 14 chapitres parfois artificielle.
La version 2022 répond à trois objectifs :
- Simplifier la structure : passer de 14 chapitres thématiques à 4 grands thèmes (organisationnel, humain, physique, technologique) qui correspondent à des responsabilités identifiables dans une organisation.
- Couvrir les nouveaux risques : ajouter explicitement la threat intelligence, le cloud, la résilience BC, la prévention de fuite de données, le web filtering, le secure coding, le data masking…
- Faciliter la lecture transverse : introduire une taxonomie d'attributs à cinq axes qui permet de filtrer les contrôles selon plusieurs dimensions (préventif/détectif/correctif, CIA, fonctions NIST, capacités, domaines).
Le résultat : 93 contrôles, dont 11 totalement nouveaux, 24 issus de fusions, 58 simplement renommés ou réorganisés, et plusieurs disparitions (politiques redondantes, contrôles devenus obsolètes).
#La nouvelle structure : 4 thèmes
L'Annexe A 2022 organise les 93 contrôles en quatre thèmes uniques :
| Thème | Préfixe | Nombre de contrôles | Responsable typique |
|---|---|---|---|
| Organisationnels | A.5 | 37 | RSSI, direction, juridique |
| Humains | A.6 | 8 | RH, RSSI |
| Physiques | A.7 | 14 | Services généraux, sécurité physique |
| Technologiques | A.8 | 34 | DSI, équipes ops, dev, SOC |
Cette répartition est plus claire que les 14 chapitres de 2013. Elle facilite l'attribution des responsabilités : chaque thème a un — ou deux — propriétaires identifiables au sein de l'organisation. Elle facilite aussi la SoA, en regroupant les contrôles par interlocuteur naturel.
#La taxonomie d'attributs : 5 axes
Nouveauté majeure de la 2022 : chaque contrôle est désormais classé selon cinq axes d'attributs. Cette taxonomie n'est pas obligatoire au sens normatif (vous n'avez pas à la documenter), mais elle est extrêmement utile pour piloter votre SMSI et présenter les contrôles à votre Comex sous différents angles.
#Axe 1 — Type de contrôle
- Préventif : empêche l'incident (chiffrement, MFA, durcissement)
- Détectif : détecte l'incident en cours (SIEM, monitoring, IDS)
- Correctif : ramène à l'état sain après incident (BCP, restauration, IR)
#Axe 2 — Propriétés de sécurité de l'information
Reprise du triptyque classique : Confidentialité, Intégrité, Disponibilité. Un même contrôle peut couvrir plusieurs propriétés (le chiffrement protège la confidentialité, mais aussi l'intégrité dans certaines mises en œuvre).
#Axe 3 — Concepts de cybersécurité (alignés NIST CSF)
- Identifier : inventaires, analyse de risque
- Protéger : mesures préventives
- Détecter : SIEM, SOC, anomalie
- Répondre : IR, communication de crise
- Récupérer : restauration, BC, retour d'expérience
#Axe 4 — Capacités opérationnelles
15 capacités regroupant les contrôles par domaine fonctionnel : Governance, Asset_management, Information_protection, Human_resource_security, Physical_security, System_and_network_security, Application_security, Secure_configuration, Identity_and_access_management, Threat_and_vulnerability_management, Continuity, Supplier_relationships_security, Legal_and_compliance, Information_security_event_management, Information_security_assurance.
#Axe 5 — Domaines de sécurité
- Governance_and_Ecosystem
- Protection
- Defence
- Resilience
Ces cinq axes sont précieux pour répondre rapidement à des questions du type : "Combien de contrôles préventifs avons-nous activés en sécurité applicative ?" ou "Quels contrôles couvrent à la fois la disponibilité et la fonction Récupérer ?". La checklist Excel que nous mettons à disposition intègre ces cinq axes en colonnes filtrables.
#A.5 — Contrôles organisationnels (37 contrôles)
Le thème le plus volumineux. Il couvre la gouvernance, les politiques, les rôles, la classification, la gestion des fournisseurs, la conformité légale et la gestion des incidents.
| ID | Titre | Explication concrète | Difficulté |
|---|---|---|---|
| A.5.1 | Policies for information security | Politique SI globale + politiques thématiques (mot de passe, classification, télétravail). Validée direction, revue annuellement. | Moyenne |
| A.5.2 | Information security roles and responsibilities | Rôles SI documentés (RSSI, propriétaires d'actifs, RACI). | Faible |
| A.5.3 | Segregation of duties | Séparation des tâches sensibles (qui demande, qui approuve, qui exécute). | Moyenne |
| A.5.4 | Management responsibilities | Engagement direction sur conformité aux politiques. | Faible |
| A.5.5 | Contact with authorities | Annuaire CNIL, ANSSI, gendarmerie/police, CERT. À jour. | Faible |
| A.5.6 | Contact with special interest groups | Adhésion CLUSIF, CERT-FR, ISACA, OWASP… | Faible |
| A.5.7 | Threat intelligence | Veille menaces (sources OSINT, CTI, IoC) intégrée à la gestion de risque. | Élevée |
| A.5.8 | Information security in project management | Sécurité dans cycle projet (analyse de risque dès cadrage). | Moyenne |
| A.5.9 | Inventory of information and other associated assets | Inventaire des actifs (info, hardware, software, services). À jour. | Moyenne |
| A.5.10 | Acceptable use of information and other associated assets | Charte informatique signée. | Faible |
| A.5.11 | Return of assets | Procédure de restitution départ collaborateur (laptop, badge, mobile). | Faible |
| A.5.12 | Classification of information | Schéma de classification (public/interne/confidentiel/secret). | Moyenne |
| A.5.13 | Labelling of information | Marquage documents selon classification. | Moyenne |
| A.5.14 | Information transfer | Règles de transfert (chiffrement, NDA, canaux autorisés). | Moyenne |
| A.5.15 | Access control | Politique de contrôle d'accès (RBAC, moindre privilège). | Moyenne |
| A.5.16 | Identity management | Cycle de vie des identités (création, modification, suppression). | Moyenne |
| A.5.17 | Authentication information | Gestion mots de passe, secrets, clés. | Moyenne |
| A.5.18 | Access rights | Revue périodique des droits d'accès. | Élevée |
| A.5.19 | Information security in supplier relationships | Politique fournisseurs (risk assessment, NDA, clauses SI). | Moyenne |
| A.5.20 | Addressing information security within supplier agreements | Clauses SI dans contrats fournisseurs. | Moyenne |
| A.5.21 | Managing information security in the ICT supply chain | Sécurité supply chain logicielle (SBOM, signatures). | Élevée |
| A.5.22 | Monitoring, review and change management of supplier services | Suivi performance/sécurité fournisseurs (SLA, audits). | Moyenne |
| A.5.23 | Information security for use of cloud services | Politique cloud (IaaS/PaaS/SaaS), responsabilités partagées, sortie réversibilité. | Élevée |
| A.5.24 | Information security incident management planning and preparation | Plan de gestion d'incident SI (équipe, process, escalade). | Moyenne |
| A.5.25 | Assessment and decision on information security events | Triage : incident vs événement, criticité, traitement. | Moyenne |
| A.5.26 | Response to information security incidents | Procédure de réponse (containment, eradication, recovery). | Élevée |
| A.5.27 | Learning from information security incidents | Post-mortem, REX, plan d'amélioration. | Moyenne |
| A.5.28 | Collection of evidence | Préservation preuves (chain of custody, forensics). | Élevée |
| A.5.29 | Information security during disruption | Maintien SI en cas de crise (BC). | Élevée |
| A.5.30 | ICT readiness for business continuity | Préparation TIC à la continuité (RTO/RPO, tests PRA, redondance). | Élevée |
| A.5.31 | Legal, statutory, regulatory and contractual requirements | Registre des exigences légales applicables (RGPD, NIS2…). | Moyenne |
| A.5.32 | Intellectual property rights | Gestion DPI (licences logicielles, contrefaçon). | Faible |
| A.5.33 | Protection of records | Conservation registres (logs, contrats, traçabilité). | Moyenne |
| A.5.34 | Privacy and protection of PII | Conformité RGPD (registres, DPIA, droits personnes). | Élevée |
| A.5.35 | Independent review of information security | Audit indépendant SI (interne ou externe). | Moyenne |
| A.5.36 | Compliance with policies, rules and standards for information security | Vérification application des politiques. | Moyenne |
| A.5.37 | Documented operating procedures | Procédures opérationnelles documentées. | Faible |
#A.6 — Contrôles humains (8 contrôles)
Le thème le plus court mais loin d'être anecdotique : la majorité des incidents trouvent leur origine dans une erreur humaine, une malveillance interne, ou un manquement de sensibilisation.
| ID | Titre | Explication concrète | Difficulté |
|---|---|---|---|
| A.6.1 | Screening | Vérifications d'antécédents avant embauche (selon poste). | Moyenne |
| A.6.2 | Terms and conditions of employment | Clauses SI dans contrat de travail (confidentialité, charte). | Faible |
| A.6.3 | Information security awareness, education and training | Programme de sensibilisation (e-learning, phishing, onboarding). | Moyenne |
| A.6.4 | Disciplinary process | Procédure disciplinaire en cas de violation SI. | Faible |
| A.6.5 | Responsibilities after termination or change of employment | Obligations post-emploi (NDA, restitution, désactivation comptes). | Faible |
| A.6.6 | Confidentiality or non-disclosure agreements | NDA collaborateurs, prestataires, partenaires. | Faible |
| A.6.7 | Remote working | Politique télétravail (VPN, MFA, EDR, domicile sécurisé). | Moyenne |
| A.6.8 | Information security event reporting | Procédure de signalement par les collaborateurs. | Faible |
#A.7 — Contrôles physiques (14 contrôles)
Souvent négligé en SaaS pur — à tort. Même une organisation 100 % cloud doit traiter le bureau, le datacenter de son hébergeur (par revue de certification), et les actifs mobiles.
| ID | Titre | Explication concrète | Difficulté |
|---|---|---|---|
| A.7.1 | Physical security perimeters | Périmètres physiques sécurisés (zones, contrôle d'accès). | Moyenne |
| A.7.2 | Physical entry | Contrôle d'accès aux locaux (badges, biométrie, sas). | Moyenne |
| A.7.3 | Securing offices, rooms and facilities | Sécurisation bureaux, salles serveurs, archives. | Moyenne |
| A.7.4 | Physical security monitoring | Vidéosurveillance, alarmes, détection intrusion physique. | Moyenne |
| A.7.5 | Protecting against physical and environmental threats | Protection incendie, dégât des eaux, séismes selon contexte. | Moyenne |
| A.7.6 | Working in secure areas | Règles dans zones sécurisées (pas de mobile, pas de photo). | Faible |
| A.7.7 | Clear desk and clear screen | Bureau dégagé, écran verrouillé en absence. | Faible |
| A.7.8 | Equipment siting and protection | Implantation et protection des équipements. | Faible |
| A.7.9 | Security of assets off-premises | Sécurité des actifs hors site (laptops voyageurs). | Moyenne |
| A.7.10 | Storage media | Gestion supports amovibles (USB, disques). | Moyenne |
| A.7.11 | Supporting utilities | Services support (électricité, climatisation, eau). | Moyenne |
| A.7.12 | Cabling security | Sécurité des câblages (alimentation, données). | Faible |
| A.7.13 | Equipment maintenance | Maintenance équipements (sous-traitance, accès). | Faible |
| A.7.14 | Secure disposal or re-use of equipment | Mise au rebut sécurisée (effacement, destruction). | Moyenne |
#A.8 — Contrôles technologiques (34 contrôles)
Le thème qui mobilise le plus la DSI et les équipes ops. Il intègre les nouveautés majeures de 2022 : configuration management, data masking, DLP, monitoring, web filtering, secure coding.
| ID | Titre | Explication concrète | Difficulté |
|---|---|---|---|
| A.8.1 | User end point devices | Sécurisation postes utilisateurs (EDR, MDM, durcissement). | Moyenne |
| A.8.2 | Privileged access rights | Gestion comptes à privilèges (PAM, MFA, audit). | Élevée |
| A.8.3 | Information access restriction | Restriction d'accès aux informations selon le besoin. | Moyenne |
| A.8.4 | Access to source code | Contrôle d'accès au code source (Git, branches protégées). | Moyenne |
| A.8.5 | Secure authentication | Authentification forte (MFA, SSO, FIDO2). | Moyenne |
| A.8.6 | Capacity management | Gestion capacité (CPU, stockage, bande passante). | Moyenne |
| A.8.7 | Protection against malware | Antimalware, EDR, sandbox, scan. | Moyenne |
| A.8.8 | Management of technical vulnerabilities | Gestion vulnérabilités (scan, patch, CVE). | Élevée |
| A.8.9 | Configuration management | Gestion des configurations (baselines, IaC, drift detection). | Élevée |
| A.8.10 | Information deletion | Effacement sécurisé des données (RGPD, fin de contrat). | Moyenne |
| A.8.11 | Data masking | Masquage / anonymisation données sensibles (test, dev, BI). | Élevée |
| A.8.12 | Data leakage prevention | DLP (e-mail, endpoint, cloud) pour prévenir l'exfiltration. | Élevée |
| A.8.13 | Information backup | Sauvegardes régulières, testées, hors-ligne (3-2-1). | Moyenne |
| A.8.14 | Redundancy of information processing facilities | Redondance des installations de traitement. | Élevée |
| A.8.15 | Logging | Journalisation des événements (système, applicatif, sécurité). | Moyenne |
| A.8.16 | Monitoring activities | Supervision SI active (SIEM, SOC, alertes, corrélation). | Élevée |
| A.8.17 | Clock synchronization | Synchronisation NTP des systèmes. | Faible |
| A.8.18 | Use of privileged utility programs | Maîtrise utilitaires à privilèges (sysinternals, scripts admin). | Moyenne |
| A.8.19 | Installation of software on operational systems | Contrôle de l'installation logicielle en production. | Moyenne |
| A.8.20 | Networks security | Sécurité réseau (segmentation, VLAN, firewall). | Moyenne |
| A.8.21 | Security of network services | Sécurité services réseau (DNS, mail, proxy). | Moyenne |
| A.8.22 | Segregation of networks | Cloisonnement réseau (DMZ, zones de confiance). | Moyenne |
| A.8.23 | Web filtering | Filtrage URL / DNS / catégories de sites web. | Moyenne |
| A.8.24 | Use of cryptography | Politique de cryptographie (algos, clés, KMS). | Élevée |
| A.8.25 | Secure development life cycle | Cycle de développement sécurisé (SDLC, SSDLC). | Élevée |
| A.8.26 | Application security requirements | Exigences de sécurité applicative (OWASP, threat modeling). | Élevée |
| A.8.27 | Secure system architecture and engineering principles | Architecture sécurisée par conception (zero trust, least privilege). | Élevée |
| A.8.28 | Secure coding | Pratiques de codage sécurisé (lint, SAST, revue, OWASP Top 10). | Élevée |
| A.8.29 | Security testing in development and acceptance | Tests sécurité (DAST, SAST, pentest). | Élevée |
| A.8.30 | Outsourced development | Développement externalisé encadré. | Moyenne |
| A.8.31 | Separation of development, test and production environments | Séparation dev/test/prod. | Moyenne |
| A.8.32 | Change management | Gestion du changement (CAB, ITIL, traçabilité). | Moyenne |
| A.8.33 | Test information | Données de test (anonymisation, dérivation). | Moyenne |
| A.8.34 | Protection of information systems during audit testing | Précautions durant audits (read-only, fenêtre, sauvegarde). | Moyenne |
#Les 11 nouveaux contrôles 2022 expliqués
Ce sont eux qui font la différence avec la version 2013, et ce sont eux que les auditeurs scrutent en priorité lors des audits de transition. Voici, pour chacun, le contexte d'apparition et les preuves typiques attendues.
#A.5.7 — Threat intelligence
Contexte : avant 2022, la veille menaces était implicite. La 2022 l'explicite. L'organisation doit collecter, analyser et utiliser les renseignements sur les menaces qui la concernent, à trois niveaux : stratégique (paysage de menace), tactique (TTP des attaquants), opérationnel (IoC à bloquer).
Preuves attendues : abonnement à des sources CTI (CERT-FR, MISP, vendor feeds), procédure d'intégration des IoC dans les outils (SIEM, EDR, firewall), revue trimestrielle du paysage de menace présentée au Comex SI.
Difficulté : élevée. Beaucoup d'organisations confondent CTI et abonnement à une newsletter. L'auditeur cherche une intégration opérationnelle.
#A.5.23 — Information security for use of cloud services
Contexte : le cloud n'avait pas de contrôle dédié en 2013. La 2022 en fait un sujet explicite, couvrant IaaS, PaaS et SaaS.
Preuves attendues : politique cloud, registre des services cloud utilisés (shadow IT inclus), responsabilités partagées documentées (matrice CSP/client), clauses contractuelles, plan de réversibilité, monitoring de la posture cloud (CSPM).
Difficulté : élevée. Le shadow IT cloud est souvent sous-estimé.
#A.5.30 — ICT readiness for business continuity
Contexte : la BC existait dans la 2013, mais la composante TIC était diluée. La 2022 crée un contrôle dédié à la préparation des SI à la continuité.
Preuves attendues : RTO/RPO documentés par service critique, plan de reprise informatique (PRI) testé, redondance multi-région ou multi-site, procédure de bascule, tests annuels avec compte rendu.
Difficulté : élevée. Les tests réels (et non sur table) sont la preuve la plus solide.
#A.7.4 — Physical security monitoring
Contexte : la surveillance physique était mentionnée mais pas isolée. La 2022 l'érige en contrôle.
Preuves attendues : vidéosurveillance avec rétention, alarmes intrusion, journal des accès physiques, procédure d'investigation post-incident physique.
Difficulté : moyenne. Souvent déjà en place dans les bureaux, à formaliser.
#A.8.9 — Configuration management
Contexte : la gestion des configurations était implicite dans la 2013. La 2022 la rend explicite.
Preuves attendues : baselines de sécurité documentées (CIS, ANSSI), Infrastructure as Code (Terraform, Ansible), détection de drift (CSPM, hardening checks), revue régulière.
Difficulté : élevée. Beaucoup d'organisations ont des baselines sur le papier sans vérification automatisée.
#A.8.10 — Information deletion
Contexte : avec le RGPD et les obligations de minimisation, la suppression effective devient un sujet à part entière.
Preuves attendues : procédure de suppression par type de donnée, calendriers de rétention, suppression effective vérifiable (logs, tests), gestion fin de contrat fournisseur.
Difficulté : moyenne. Le piège : les sauvegardes anciennes contiennent souvent des données qui devaient être supprimées.
#A.8.11 — Data masking
Contexte : les jeux de données de test ou d'analyse en clair sont une cause récurrente de fuite. La 2022 oblige à traiter le sujet.
Preuves attendues : politique de masquage (anonymisation, pseudonymisation, tokenisation), outils utilisés, procédure pour les environnements non-production, revue.
Difficulté : élevée. Implique souvent une refonte des pipelines de données.
#A.8.12 — Data leakage prevention
Contexte : la prévention de fuite (DLP) devient un contrôle à part entière, intégrant e-mail, endpoint et cloud.
Preuves attendues : solution DLP déployée (Microsoft Purview, Symantec, Forcepoint…), règles documentées (catégories de données, canaux), tableau de bord des incidents DLP, traitement des alertes.
Difficulté : élevée. Le DLP est un projet pluriannuel, à phaser.
#A.8.16 — Monitoring activities
Contexte : le logging existait déjà (A.8.15 / ancien A.12.4). La 2022 ajoute un contrôle distinct sur la supervision active.
Preuves attendues : SIEM ou SOC en place (interne, externalisé ou hybride), use cases de détection documentés, KPI (MTTR, taux de faux positifs), revue mensuelle.
Difficulté : élevée. Les organisations qui ont des logs sans les analyser ne couvrent pas ce contrôle.
#A.8.23 — Web filtering
Contexte : le filtrage des accès web sortants est devenu un standard pour limiter l'exposition aux sites malveillants, au phishing, et à l'exfiltration.
Preuves attendues : solution de filtrage (Zscaler, Cisco Umbrella, Fortinet, Cloudflare Gateway), catégories bloquées documentées, procédure de demande de déblocage, journalisation.
Difficulté : moyenne. Souvent déjà en place via la passerelle internet, à formaliser dans la SoA.
#A.8.28 — Secure coding
Contexte : la sécurité applicative monte en puissance. La 2022 dédie un contrôle au codage sécurisé.
Preuves attendues : standards de codage (OWASP ASVS, secure coding guidelines internes), outils SAST/SCA dans la CI, revue de code orientée sécurité, formation des dev, gestion des dépendances.
Difficulté : élevée. C'est un changement culturel autant qu'un sujet outillage. Voir notre accompagnement ISO 27001 pour structurer la démarche SSDLC.
#La SoA — Statement of Applicability
La SoA reste, en 2022 comme en 2013, le document central du SMSI. Elle liste les 93 contrôles et indique pour chacun :
- L'applicabilité : oui / non / partiel
- La justification : pourquoi applicable (analyse de risque, exigence légale, contractuelle) ou pourquoi exclu
- Le statut de mise en œuvre : non démarré / en cours / opérationnel / optimisé
- Les preuves : références documentaires, captures, procédures
- Le responsable : owner du contrôle
- L'échéance : date cible si en cours
#Applicabilité : peut-on exclure des contrôles ?
Oui — c'est même le principe de la SoA. Tous les contrôles ne sont pas pertinents pour toutes les organisations. Une PME 100 % SaaS qui n'a pas de bureau peut exclure une partie du chapitre A.7. Une organisation sans développement interne peut réduire la portée d'A.8.25 à A.8.30.
Mais attention : exclure un contrôle exige une justification écrite, traçable et raisonnable. L'auditeur ne contestera pas une exclusion bien argumentée — il contestera une exclusion qui ressemble à une fuite.
#Erreurs fréquentes en SoA
- SoA copiée-collée : la SoA d'un autre est une SoA fausse. Elle reflète son contexte, pas le vôtre.
- Tous les contrôles "applicables" et "opérationnels" : irréaliste, l'auditeur cherchera le pot aux roses.
- Justifications floues : "non applicable car non pertinent" ne suffit pas. Il faut expliquer pourquoi.
- SoA non datée / non versionnée : sans historique, impossible de prouver l'amélioration continue.
- Pas de preuve associée : un contrôle "opérationnel" sans aucune preuve est une déclaration, pas un contrôle.
- Oubli des 11 nouveaux contrôles : ceux qui ont juste fait un mapping 2013→2022 sans regarder les nouveautés ratent l'essentiel de la transition.
- Confusion entre risque et contrôle : la SoA n'est pas l'analyse de risque. Elle traite des contrôles, pas des risques.
#Transition octobre 2025 : où en êtes-vous ?
La période de transition s'est officiellement terminée le 31 octobre 2025. Toute certification 27001 maintenue après cette date doit être en version 2022. Concrètement :
- Si votre certificat 2013 a été délivré avant fin 2022, il a expiré au plus tard en octobre 2025.
- Si vous renouvelez votre certificat aujourd'hui, c'est obligatoirement en 2022.
- Les organismes certificateurs ont audité les transitions tout au long de 2024 et 2025, et la fenêtre est désormais close.
Si vous lisez cet article et que votre SMSI est encore structuré sur la 2013, il faut agir vite : refondre la SoA, traiter les 11 nouveaux contrôles, et enchaîner un audit de transition (ou un audit initial complet selon votre situation).
#Comment aborder concrètement les 93 contrôles
Quelques principes pratiques pour piloter la mise en œuvre :
- Partir de l'analyse de risque, pas de la liste. La liste des 93 contrôles est un outil de couverture, pas un point de départ. C'est l'analyse de risque qui dicte les priorités.
- Distinguer "applicable" et "implémenté". Un contrôle peut être applicable sans être encore en place. La SoA documente l'écart et le plan d'action.
- Ne pas viser le 100 % opérationnel d'emblée. Une SoA mature montre une trajectoire d'amélioration, pas un état figé.
- Aligner SoA, plan d'action, et indicateurs. Les trois doivent dialoguer en continu.
- Tirer parti de la taxonomie d'attributs. Filtrer par type, par fonction NIST, par capacité opérationnelle aide à prioriser et à présenter.
- Documenter au fil de l'eau. Les preuves accumulées au fil des mois valent mieux qu'un dossier reconstitué la veille de l'audit.
- Préparer les revues de direction. Le management review (clause 9.3) est l'occasion de revisiter la SoA avec la direction.
#L'erreur la plus coûteuse : sous-estimer la transition
Beaucoup d'organisations ont vécu la transition 2013→2022 comme un simple toilettage. Elles ont produit une table de correspondance, supprimé les contrôles fusionnés, et gardé leur SoA quasi inchangée. Résultat : une SoA qui ne traite pas réellement les 11 nouveaux contrôles, des audits de transition tendus, et parfois des non-conformités majeures.
La 2022 n'est pas une évolution cosmétique. Threat intelligence, cloud, DLP, secure coding, monitoring : ces sujets exigent des projets, des outils, des compétences. S'ils n'étaient pas déjà couverts en 2013 (et ils l'étaient rarement de manière formelle), ils nécessitent une démarche dédiée.
C'est précisément l'objet de l'accompagnement ISO 27001 : structurer la mise en conformité sans inventer ce qui existe déjà, et combler les angles morts qui font perdre des audits.
#En synthèse
L'Annexe A 2022 est plus claire, plus moderne, plus opérationnelle que la 2013. Quatre thèmes au lieu de quatorze. Quatre-vingt-treize contrôles au lieu de cent quatorze. Une taxonomie d'attributs précieuse pour filtrer et présenter. Onze contrôles nouveaux qui reflètent l'état réel des menaces.
Bien menée, la transition est un excellent levier pour moderniser le SMSI. Mal menée, elle accumule des angles morts qui finiront par ressortir à l'audit, ou pire, lors d'un incident.
On a préparé un Excel listant les 93 contrôles avec colonnes statut/preuve/responsable/échéance — utile pour gérer votre SoA. Récupérer la checklist gratuite →
— Équipe M-KIS
Cet article vous parle ?
On accompagne PME, ESN et éditeurs SaaS dans leur conformité ISO 27001 / NIS2 — Lead Auditor certifié, tarifs publics, 100 % open source.