SMSI ISO 27001 industriel : guide de mise en œuvre 2026

Déployer un système de management de la sécurité de l'information conforme à l'ISO/IEC 27001 dans une usine ne ressemble en rien à le déployer dans un siège social. Les actifs à protéger ne sont pas des serveurs de messagerie mais des automates programmables qui pilotent des vannes, des fours, des lignes de conditionnement ou des réacteurs chimiques. L'indisponibilité n'y coûte pas quelques heures de productivité bureautique : elle coûte des tonnes de produit perdu, des redémarrages de process de plusieurs jours, parfois des conséquences pour la sécurité des personnes. À cela s'ajoute une contrainte que les référentiels informatiques ignorent superbement : une bonne partie du parc industriel tourne sur des systèmes d'exploitation qui n'ont plus reçu de correctif depuis une décennie, et qu'il est contractuellement interdit de modifier sans casser la garantie de l'intégrateur. Ce guide détaille la mise en œuvre concrète d'un SMSI ISO 27001:2022 sur un périmètre industriel : définition du périmètre IT/OT, cartographie des actifs SCADA, PLC et DCS, adaptation des 93 contrôles de l'Annexe A, articulation avec l'IEC 62443, traitement des systèmes obsolètes, continuité industrielle et convergence avec les obligations de la directive NIS 2.

Pourquoi l'ISO 27001 s'impose dans l'industrie en 2026

Pendant vingt ans, la sécurité des systèmes industriels a reposé sur un postulat simple : l'isolement. Les réseaux d'automatismes étaient physiquement séparés, les protocoles étaient exotiques, et personne ne savait ce qu'était un Modbus en dehors du service maintenance. Ce postulat est mort. La convergence IT/OT, portée par les projets d'industrie 4.0, la maintenance prédictive, la télémétrie des équipements et l'accès distant des intégrateurs, a percé l'isolement de part en part. Un automate qui remonte ses données de production vers un MES, lui-même connecté à l'ERP, lui-même exposé à Internet pour les échanges EDI avec les clients, n'est plus isolé — quel que soit le schéma d'architecture accroché au mur de la salle serveur.

Trois moteurs poussent aujourd'hui les industriels vers la certification. Le premier est réglementaire : la directive NIS 2 a considérablement élargi le champ des entités soumises à des obligations de cybersécurité, en incluant nommément la fabrication de produits alimentaires, la chimie, la fabrication de dispositifs médicaux, de matériel informatique, de machines et d'équipements de transport. Le deuxième est contractuel : les donneurs d'ordre de l'aéronautique, de l'automobile et de la défense imposent désormais des exigences de maturité cyber à leurs fournisseurs de rang 1 et 2, et l'ISO 27001 est le langage commun accepté par tous. Le troisième est assurantiel : les assureurs cyber conditionnent leurs garanties, et surtout leurs franchises, à des preuves de maîtrise que seul un système de management documenté permet de produire.

L'ISO 27001 n'est pas un référentiel technique de sécurité industrielle — l'IEC 62443 remplit ce rôle bien mieux. C'est un cadre de gouvernance qui oblige une organisation à savoir ce qu'elle possède, à évaluer ce qu'elle risque, à décider ce qu'elle traite, et à prouver qu'elle le fait dans la durée. Dans un contexte industriel où la connaissance du parc est souvent détenue par trois personnes proches de la retraite, cette discipline documentaire vaut à elle seule le projet.

Définir le périmètre d'un SMSI industriel : IT, OT et zone grise

La définition du périmètre est la décision structurante de tout le projet. Elle détermine le coût, la durée, la charge d'audit et — surtout — la crédibilité du certificat. Un certificat ISO 27001 dont le périmètre se limite à « la direction des systèmes d'information du siège » ne rassurera aucun donneur d'ordre industriel, et n'apportera rien au regard de NIS 2.

Trois options se présentent en pratique. Le périmètre site industriel complet englobe l'ensemble des systèmes d'un ou plusieurs sites de production, IT locale comprise. C'est le plus crédible et le plus exigeant. Le périmètre chaîne de valeur suit un processus métier de bout en bout — de la prise de commande à l'expédition — en incluant tous les systèmes qui le supportent. Il est élégant mais difficile à défendre en audit, car les frontières sont fonctionnelles et non physiques. Le périmètre progressif, enfin, certifie d'abord l'IT d'entreprise et un site pilote, puis étend le certificat aux autres sites lors des audits de surveillance. C'est l'approche la plus réaliste pour un groupe multi-sites.

Quelle que soit l'option retenue, le document de périmètre doit trancher explicitement sur la « zone grise » : les systèmes qui ne sont ni franchement IT ni franchement OT. On y trouve les serveurs MES et historiens de données, les postes d'ingénierie sur lesquels sont stockés les programmes automates, les serveurs de licence des logiciels de supervision, les passerelles OPC UA, les systèmes de gestion de la maintenance assistée par ordinateur, et les infrastructures de contrôle d'accès physique des bâtiments industriels. Ces systèmes sont presque toujours les premiers compromis lors d'une attaque, et presque toujours oubliés dans les premiers périmètres.

Les exclusions doivent être justifiées, pas seulement énoncées. Exclure les systèmes de sécurité fonctionnelle certifiés SIL (les systèmes instrumentés de sécurité) du périmètre du SMSI est légitime — ils relèvent de l'IEC 61511 et leur modification est encadrée — mais la justification doit figurer dans la déclaration d'applicabilité, accompagnée des mesures d'interface : qui peut accéder physiquement à ces systèmes, comment leurs paramètres sont contrôlés, comment une modification est tracée.

Cartographier les actifs industriels : SCADA, PLC, DCS et automates orphelins

Le contrôle A.5.9 de l'Annexe A 2022 exige un inventaire des informations et autres actifs associés. Sur un périmètre industriel, cet inventaire est le livrable le plus long à produire et le plus révélateur. Il est courant qu'un site de production découvre à cette occasion 15 à 30 % d'équipements dont l'existence n'était documentée nulle part : automates de machines achetées avec la ligne, PC de test laissés par un intégrateur, modems 4G installés pour un dépannage urgent en 2019 et jamais retirés.

Un inventaire industriel exploitable dépasse largement l'adresse IP et le numéro de série. Pour chaque équipement, il faut renseigner :

• Fonction process : ce que l'équipement pilote physiquement, et l'impact d'un arrêt sur la production ou la sécurité.
• Criticité opérationnelle : durée d'indisponibilité tolérable avant impact matériel, et non pas simplement « critique / non critique ».
• Version firmware et logiciel de programmation — souvent la donnée la plus difficile à obtenir sur les automates anciens.
• Propriétaire technique et propriétaire métier, distincts : le service maintenance et le responsable de production.
• Contrat de maintenance et clauses associées : qui a le droit d'accéder à distance, sous quel préavis, avec quel compte.
• Zone et conduit au sens IEC 62443-3-2, ce qui prépare directement l'analyse de risque.
• Fin de support constructeur, réelle et non commerciale.

La méthode de collecte compte autant que le résultat. Le scan actif est à proscrire sans précaution : un balayage de ports classique peut faire tomber un automate ancien dont la pile réseau ne supporte pas les paquets malformés — des incidents de ce type ont provoqué des arrêts de ligne bien réels. La bonne pratique combine trois sources : l'écoute passive du trafic réseau via un TAP ou un port mirroir, l'extraction des configurations depuis les logiciels d'ingénierie, et le relevé physique en atelier avec les équipes de maintenance. Cette dernière source est irremplaçable ; elle est aussi celle qui crée l'adhésion des équipes OT au projet.

Analyse de risque industrielle : quand l'indisponibilité prime sur la confidentialité

La clause 6.1.2 de l'ISO 27001 laisse l'organisation libre de sa méthode d'appréciation des risques, à condition qu'elle soit reproductible et qu'elle produise des résultats cohérents. Cette liberté est précieuse en milieu industriel, car la transposition mécanique d'une méthode conçue pour l'informatique de gestion conduit à des conclusions absurdes.

La première adaptation concerne la pondération DIC. En informatique de gestion, la confidentialité domine généralement l'échelle d'impact. Sur un périmètre industriel, l'ordre s'inverse : l'intégrité et la disponibilité portent l'essentiel du risque. Une consigne de température altérée dans un automate de pasteurisation ne pose pas un problème de confidentialité — elle pose un problème de sécurité sanitaire. Certaines organisations ajoutent une quatrième dimension, la sûreté de fonctionnement (safety), pour matérialiser les scénarios où la compromission d'un système peut entraîner un dommage physique. Cet ajout est parfaitement compatible avec la norme et considérablement plus parlant pour un comité de direction industriel.

La deuxième adaptation concerne l'échelle d'impact. Il faut abandonner les échelles génériques en euros au profit d'unités que les opérationnels manipulent : durée d'arrêt de ligne, tonnage perdu, lots à détruire, temps de redémarrage d'un process continu. Sur un four de cimenterie ou un réacteur chimique, la distinction entre un arrêt de 2 heures et un arrêt de 12 heures n'est pas quantitative mais qualitative : au-delà d'un certain seuil, le redémarrage devient une opération de plusieurs jours.

La troisième adaptation est méthodologique : les scénarios de risque doivent être construits avec les équipes de production, pas pour elles. Un atelier de deux heures réunissant responsable de production, chef de maintenance, automaticien et RSSI produit systématiquement des scénarios plus pertinents qu'une analyse documentaire, parce que les opérationnels connaissent les contournements réels — le compte partagé de l'équipe de nuit, la clé USB qui circule entre postes d'ingénierie, l'accès distant laissé ouvert le week-end pendant une mise en service.

L'Annexe A 2022 relue à travers le prisme industriel

La révision 2022 de l'ISO/IEC 27001 a restructuré l'Annexe A : les 114 contrôles répartis en 14 chapitres de la version 2013 sont devenus 93 contrôles répartis en 4 thèmes — A.5 Contrôles organisationnels (37), A.6 Contrôles liés aux personnes (8), A.7 Contrôles physiques (14), A.8 Contrôles technologiques (34). Ce point mérite d'être signalé car de nombreux documents de projet circulent encore avec l'ancienne numérotation : la gestion des actifs, qui était le chapitre A.8 en 2013, se retrouve désormais en A.5.9 à A.5.14, tandis que A.8 désigne à présent l'ensemble des contrôles technologiques. Une déclaration d'applicabilité rédigée avec la numérotation 2013 sera rejetée en audit initial.

Les contrôles suivants demandent une adaptation substantielle en environnement industriel.

Contrôles organisationnels (A.5)

• A.5.1 Politiques de sécurité de l'information — La politique générale doit être déclinée en une politique de sécurité des systèmes industriels distincte, validée par la direction industrielle et non par la seule DSI. Sans ce portage, la politique reste lettre morte en atelier.
• A.5.9 à A.5.14 Gestion des actifs — Inventaire, propriété, usage acceptable, restitution, classification et étiquetage. Sur le parc OT, la classification doit intégrer la criticité process, et l'étiquetage physique des armoires électriques est souvent plus efficace qu'un marquage logique.
• A.5.7 Renseignement sur les menaces — Contrôle nouveau en 2022. Pour l'industrie, il implique de suivre les avis du CERT-FR et les publications de la CISA sur les vulnérabilités des systèmes de contrôle industriel, en filtrant sur les constructeurs réellement présents au parc.
• A.5.19 à A.5.22 Relations fournisseurs — Le point le plus sous-traité et le plus critique. Les contrats d'intégration et de maintenance doivent être revus pour intégrer les exigences d'accès distant, de gestion des comptes, de notification d'incident et de droit d'audit. C'est un travail juridique autant que technique.
• A.5.29 et A.5.30 Continuité — Traités en détail plus loin.

Contrôles physiques (A.7)

• A.7.1 à A.7.4 Périmètres et surveillance — Les armoires d'automates, les locaux techniques d'atelier et les salles de contrôle doivent être traités comme des zones sécurisées au même titre qu'une salle serveur. Dans les faits, beaucoup d'armoires industrielles partagent une clé unique, parfois disponible sur un tableau à clés en libre accès.
• A.7.9 Sécurité des actifs hors des locaux — Concerne les PC portables d'ingénierie des intégrateurs, qui circulent d'un client à l'autre et constituent un vecteur de propagation documenté.
• A.7.10 Supports de stockage — La politique de gestion des supports amovibles est le point de friction le plus fréquent avec les équipes de maintenance. Le blocage pur et simple des ports USB est rarement tenable ; une station de décontamination en entrée d'atelier, couplée à une liste blanche de supports, l'est davantage.

Contrôles technologiques (A.8)

• A.8.8 Gestion des vulnérabilités techniques — Le contrôle qui ne peut pas être appliqué tel quel. Voir la section consacrée aux systèmes legacy.
• A.8.20 à A.8.22 Sécurité des réseaux et cloisonnement — Le cœur du dispositif industriel. La segmentation en zones et conduits, avec pare-feu industriels entre niveaux, porte à elle seule une part majoritaire de la réduction de risque.
• A.8.16 Activités de surveillance — La détection en environnement OT repose sur l'analyse passive des protocoles industriels plutôt que sur l'agent installé sur le poste, ce dernier étant souvent interdit par l'intégrateur.
• A.8.7 Protection contre les logiciels malveillants — Sur les systèmes où aucun antivirus n'est homologué par le constructeur, la mesure compensatoire est la liste blanche applicative ou le figeage de configuration.
• A.8.13 Sauvegarde — Doit couvrir les programmes automates et les configurations de variateurs, pas seulement les serveurs. Une sauvegarde de programme PLC non testée en restauration ne vaut rien : le test de rechargement sur banc doit être planifié.

Articuler ISO 27001 et IEC 62443 : deux référentiels complémentaires

La question revient dans chaque projet : faut-il choisir entre ISO 27001 et IEC 62443 ? La réponse est non, et la confusion vient d'une méprise sur leur nature respective. L'ISO 27001 est un référentiel de système de management : il définit comment une organisation gouverne sa sécurité, avec des exigences de politique, de rôles, d'analyse de risque, d'audit interne et de revue de direction. L'IEC 62443 est une famille de normes techniques et organisationnelles spécifiques aux systèmes d'automatisation et de contrôle industriels, qui descend à un niveau de détail que l'ISO 27001 n'atteint jamais.

Les parties de l'IEC 62443 les plus directement mobilisables dans un SMSI industriel sont les suivantes :

• IEC 62443-2-1 — Exigences relatives au programme de sécurité de l'exploitant (CSMS). C'est la partie qui recouvre le plus l'ISO 27001, et qui permet de justifier qu'un contrôle de l'Annexe A est traité par un dispositif spécifiquement industriel.
• IEC 62443-2-4 — Exigences applicables aux fournisseurs de services d'intégration et de maintenance. Support direct des contrôles A.5.19 à A.5.22.
• IEC 62443-3-2 — Appréciation du risque et conception en zones et conduits. C'est la méthode qui structure le découpage réseau et alimente directement l'analyse de risque de la clause 6.1.2.
• IEC 62443-3-3 — Exigences de sécurité système et niveaux de sécurité SL 1 à SL 4. Permet de fixer un objectif de sécurité mesurable par zone plutôt qu'un vague « renforcer la sécurité ».
• IEC 62443-4-1 et 4-2 — Cycle de développement sécurisé et exigences techniques des composants. Utiles comme critères de sélection à l'achat d'équipements neufs.

Le montage le plus efficace consiste à utiliser l'ISO 27001 comme ossature de gouvernance et l'IEC 62443 comme corps de mesures techniques sur le périmètre OT. Concrètement, la déclaration d'applicabilité mentionne pour chaque contrôle Annexe A concerné la référence 62443 qui l'implémente sur le périmètre industriel. Un auditeur ISO 27001 accepte parfaitement cette construction, à condition que la traçabilité soit explicite et que les preuves existent.

Sur le cadrage des zones et conduits, le modèle de référence reste la segmentation en niveaux inspirée du modèle Purdue : niveau 0 pour les capteurs et actionneurs, niveau 1 pour les automates, niveau 2 pour la supervision, niveau 3 pour les systèmes d'exécution de la production, niveau 4 pour l'informatique d'entreprise, avec une zone démilitarisée industrielle entre les niveaux 3 et 4. Ce modèle est un point de départ, pas un dogme : les architectures modernes intégrant du edge computing et des passerelles cloud demandent des adaptations que le découpage historique ne prévoit pas.

Traiter les systèmes legacy : la question qui décide du projet

C'est ici que la plupart des projets ISO 27001 industriels échouent, ou plutôt qu'ils se réduisent à un exercice documentaire. Un site de production typique héberge des postes de supervision sous des systèmes d'exploitation dont le support a pris fin il y a plusieurs années, des automates dont le firmware n'est plus mis à jour par le constructeur, et des logiciels d'ingénierie qui refusent de fonctionner sur un système récent. Le contrôle A.8.8 exige la gestion des vulnérabilités techniques ; l'application littérale — corriger dans un délai défini — est impossible.

La norme n'exige pourtant pas l'impossible. Elle exige que le risque soit identifié, évalué, traité par une décision explicite et documentée, et acceptée au bon niveau hiérarchique. La démarche défendable en audit repose sur quatre étapes.

Première étape : documenter l'impossibilité, pas la contourner. Pour chaque système non corrigeable, il faut une preuve écrite : courrier du constructeur attestant la fin de support, clause contractuelle de l'intégrateur interdisant la modification, ou analyse d'impact démontrant que la mise à jour nécessiterait une requalification process de plusieurs mois. Cette preuve est ce qui transforme une négligence en décision de gestion.

Deuxième étape : appliquer des mesures compensatoires proportionnées. L'isolement réseau strict de l'équipement dans une zone dédiée, avec des règles de filtrage en liste blanche autorisant uniquement les flux nécessaires au process, réduit l'exposition davantage qu'un correctif. S'y ajoutent le durcissement des postes accessibles (retrait des navigateurs et clients de messagerie, désactivation des services inutiles), la liste blanche applicative, le contrôle strict des supports amovibles, et la surveillance passive des protocoles industriels pour détecter toute commande anormale.

Troisième étape : formaliser l'acceptation du risque résiduel. La clause 6.1.3 e) exige l'approbation du risque résiduel par les propriétaires de risque. Sur un système legacy critique, ce propriétaire doit être le directeur industriel ou le directeur de site — pas le RSSI. Cette signature est le mécanisme qui, année après année, finit par débloquer les budgets de modernisation.

Quatrième étape : inscrire la sortie de l'obsolescence dans un plan pluriannuel. L'auditeur ne demande pas que tout soit résolu ; il demande une trajectoire. Un plan de renouvellement aligné sur les arrêts de maintenance planifiés et sur les investissements industriels déjà budgétés est infiniment plus crédible qu'un plan de sécurité isolé.

Continuité industrielle : au-delà du plan de reprise informatique

Les contrôles A.5.29 et A.5.30 traitent de la sécurité de l'information pendant une perturbation et de la préparation des technologies de l'information et de la communication à la continuité d'activité. En milieu industriel, leur mise en œuvre déborde très largement le périmètre habituel d'un plan de reprise informatique.

La première spécificité tient aux objectifs de temps de reprise. Sur un process continu, le RTO n'est pas une variable de négociation avec la DSI : il est imposé par la physique du procédé. Un four verrier ne se redémarre pas en quatre heures. Une cuve de fermentation dont la régulation s'arrête produit un lot perdu au bout d'un délai déterminé par la biologie, pas par le contrat de service. L'analyse d'impact sur l'activité doit donc être conduite avec les équipes process et exprimée en contraintes physiques.

La deuxième spécificité est le mode dégradé manuel. Beaucoup de sites peuvent, pendant un temps limité, piloter tout ou partie de leur process sans supervision informatique, en local sur les armoires. Cette capacité doit être identifiée, documentée sous forme de procédures accessibles hors ligne, et surtout testée régulièrement — car elle repose sur des compétences qui se perdent lorsque les opérateurs formés au pilotage manuel partent en retraite. Un exercice annuel de conduite en mode dégradé vaut, en réduction de risque réelle, plusieurs mesures techniques.

La troisième spécificité concerne les sauvegardes de programmes. La restauration d'un automate suppose de disposer non seulement du programme, mais aussi de la version exacte du logiciel d'ingénierie qui permet de le recharger, de la licence associée, du câble ou de l'adaptateur de programmation, et d'une personne qui sait le faire. Un plan de continuité industriel sérieux stocke ces quatre éléments ensemble et vérifie leur cohérence lors d'un test annuel.

La quatrième spécificité, enfin, est la coordination avec la gestion de crise industrielle existante. Les sites soumis à la réglementation Seveso, les industries agroalimentaires soumises aux plans de retrait-rappel, les sites disposant d'un plan d'opération interne : tous ont déjà des dispositifs de crise rodés. Greffer la crise cyber sur ces dispositifs existants est infiniment plus efficace que de créer une cellule parallèle que personne n'activera.

Agroalimentaire, chimie, manufacture : trois terrains, trois postures

Les principes sont communs, les priorités ne le sont pas. Trois secteurs illustrent l'écart.

Agroalimentaire : l'intégrité au service de la sécurité sanitaire

Le risque dominant est l'altération des paramètres de process ayant un impact sanitaire — barèmes de pasteurisation, températures de chaîne du froid, dosages d'additifs — et la perte de traçabilité des lots. Le SMSI y trouve un terrain favorable : les industriels du secteur maîtrisent déjà les systèmes de management (ISO 22000, IFS, BRC) et l'analyse des dangers par le HACCP. La démarche gagnante consiste à s'appuyer sur cette culture : l'analyse de risque cyber est présentée comme une extension de l'analyse des dangers, les CCP existants sont examinés sous l'angle de leur dépendance à un système numérique, et les audits internes cyber sont couplés aux audits qualité. La documentation exigée par l'ISO 27001 s'insère dans un système documentaire déjà structuré, ce qui divise la charge de mise en œuvre. Point d'attention spécifique : les lignes de conditionnement récentes embarquent souvent des équipements connectés fournis par des sous-traitants de rang 2, dont la sécurité n'a jamais été évaluée.

Chimie : la sûreté avant tout, et une frontière à ne pas franchir

Le risque dominant est l'atteinte à la sûreté de fonctionnement. La question structurante est l'articulation entre les systèmes de contrôle-commande, dans le périmètre du SMSI, et les systèmes instrumentés de sécurité, qui n'y sont généralement pas. La règle est claire : le SMSI protège les premiers et documente l'indépendance des seconds. Toute mesure de sécurité informatique susceptible d'affecter un SIS doit être écartée. En pratique, cela signifie que la segmentation réseau doit garantir l'absence de chemin logique entre le réseau de contrôle et les systèmes de sécurité, et que la démonstration de cette indépendance devient une pièce du dossier d'audit. La coordination avec le responsable HSE et l'inspection des installations classées est ici incontournable, d'autant que la maîtrise des risques accidentels relève d'un corpus réglementaire propre.

Manufacture discrète : la disponibilité et la pression de la supply chain

Le risque dominant est l'arrêt de production et l'incapacité à livrer un donneur d'ordre en flux tendu. Les sites de mécanique, d'électronique ou d'assemblage automobile exploitent des parcs de machines-outils à commande numérique hétérogènes, souvent acquis d'occasion, avec des générations de commandes s'échelonnant sur vingt-cinq ans. La priorité y est la segmentation par îlot de production, de sorte qu'une compromission n'entraîne pas l'arrêt simultané de toutes les lignes. Le second axe est contractuel : ces entreprises subissent des questionnaires de sécurité de leurs clients — notamment dans l'aéronautique et l'automobile, où des référentiels sectoriels de maturité comme AirCyber se sont imposés dans la filière. Aligner le SMSI sur ces exigences clients dès la conception évite de refaire deux fois le même travail, et transforme le certificat en argument commercial.

Synergies avec NIS 2 : un SMSI qui sert deux exigences

La directive (UE) 2022/2555, dite NIS 2, a profondément élargi le champ des entités soumises à des obligations de cybersécurité. Le vocabulaire a changé au passage : là où NIS 1 parlait d'opérateurs de services essentiels, NIS 2 distingue les entités essentielles et les entités importantes, avec des régimes de supervision différenciés — contrôle ex ante pour les premières, ex post pour les secondes — mais des obligations de sécurité identiques. De nombreux industriels précédemment hors périmètre s'y trouvent désormais inclus, notamment dans la fabrication de denrées alimentaires, la production chimique, la fabrication de dispositifs médicaux, d'équipements électroniques, de machines et de véhicules.

L'article 21 de la directive énumère les mesures minimales de gestion des risques attendues : politiques d'analyse des risques et de sécurité des systèmes d'information, gestion des incidents, continuité d'activité et gestion des crises, sécurité de la chaîne d'approvisionnement, sécurité de l'acquisition et du développement, évaluation de l'efficacité des mesures, hygiène informatique et formation, cryptographie, sécurité des ressources humaines et contrôle d'accès, authentification à plusieurs facteurs et communications sécurisées. Cette liste est, à peu de choses près, la table des matières d'un SMSI ISO 27001:2022 correctement déployé.

Trois écarts subsistent toutefois, et ils doivent être traités spécifiquement. Le premier est le régime de notification de l'article 23, qui impose une alerte précoce dans les 24 heures, une notification d'incident dans les 72 heures et un rapport final sous un mois — des délais qui doivent être câblés dans la procédure de gestion d'incident du SMSI, avec les canaux de déclaration nationaux identifiés à l'avance. Le deuxième est la responsabilité des organes de direction, que la directive rend explicite : les dirigeants doivent approuver les mesures et suivre une formation ; la revue de direction ISO 27001 devient le véhicule naturel de cette exigence, à condition d'en formaliser la participation. Le troisième est l'obligation de déclaration et d'enregistrement auprès de l'autorité nationale compétente, qui n'a pas d'équivalent dans la norme.

Un SMSI certifié ne dispense donc pas des obligations NIS 2, mais il en couvre l'essentiel du contenu technique et organisationnel et fournit les preuves attendues lors d'un contrôle. Pour les entités qui se lancent, le séquencement le plus économique consiste à construire le SMSI en intégrant dès le départ les écarts NIS 2 identifiés ci-dessus, plutôt que de mener deux chantiers en parallèle. Un accompagnement à la mise en conformité NIS 2 conduit conjointement au projet de certification divise significativement la charge globale.

Feuille de route de mise en œuvre sur quatorze mois

Un projet de certification ISO 27001 sur périmètre industriel demande typiquement douze à dix-huit mois pour une entreprise de taille intermédiaire mono-site, davantage pour un groupe multi-sites. Le séquencement suivant a fait ses preuves.

• Mois 1 à 2 — Cadrage et gouvernance. Définition du périmètre, désignation des rôles, engagement formel de la direction, constitution du comité de pilotage incluant impérativement la direction industrielle. Analyse d'écart initiale.
• Mois 2 à 5 — Inventaire et cartographie. Collecte des actifs IT et OT, cartographie des flux réseau, découpage préliminaire en zones et conduits. C'est la phase la plus longue et la plus sous-estimée.
• Mois 4 à 7 — Analyse de risque. Ateliers de scénarios avec les équipes de production, appréciation, plan de traitement, déclaration d'applicabilité, acceptation formelle des risques résiduels.
• Mois 5 à 11 — Mise en œuvre. Segmentation réseau, durcissement, gestion des accès distants fournisseurs, sauvegardes de programmes, déploiement de la détection, refonte documentaire. Les travaux d'infrastructure doivent être calés sur les fenêtres d'arrêt planifiées.
• Mois 8 à 12 — Exploitation du système. Formation et sensibilisation différenciées IT et OT, exercices d'incident et de continuité, production des indicateurs. La norme exige des preuves de fonctionnement dans la durée : il faut plusieurs mois d'historique.
• Mois 11 à 13 — Audit interne et revue de direction. Audit interne complet couvrant clauses et Annexe A, traitement des non-conformités, première revue de direction formelle.
• Mois 13 à 14 — Certification. Audit de certification en deux étapes : revue documentaire puis audit sur site, avec visite d'atelier.

Le facteur de réussite le plus déterminant n'est pas technique : c'est la présence d'un porteur légitime auprès des équipes industrielles. Un RSSI perçu comme une émanation de la DSI se heurtera à une résistance passive en atelier. Lorsque cette compétence n'existe pas en interne, le recours à un RSSI externalisé disposant d'une expérience industrielle réelle accélère considérablement la phase de cadrage et évite les faux départs.

Erreurs fréquentes et pièges de certification

Certaines erreurs se répètent d'un projet à l'autre avec une régularité remarquable.

• Transposer les politiques IT sans adaptation. Une politique de mots de passe imposant un changement tous les 90 jours sur des comptes de supervision partagés en 3×8 sera contournée dès la première semaine. Une politique impossible à appliquer est une non-conformité en puissance.
• Exclure l'OT du périmètre pour aller plus vite. Le certificat obtenu n'aura ni valeur commerciale ni valeur réglementaire, et l'extension ultérieure coûtera plus cher que l'inclusion initiale.
• Confondre inventaire et cartographie. Une liste d'équipements sans les flux qui les relient ne permet pas de concevoir une segmentation.
• Négliger la gestion des changements industriels. Le contrôle A.8.32 doit s'articuler avec le processus de management of change existant sur le site, pas le doubler.
• Sous-estimer la charge documentaire de la déclaration d'applicabilité. Justifier 93 contrôles, dont les exclusions, demande un travail de plusieurs semaines et une relecture par quelqu'un qui connaît l'atelier.
• Oublier les preuves. L'audit ne vérifie pas que les mesures existent, mais qu'elles fonctionnent : registres de revue d'accès, comptes rendus d'exercices, rapports de test de restauration, indicateurs suivis dans le temps.
• Choisir un organisme certificateur sans expérience industrielle. Un auditeur qui n'a jamais mis les pieds dans un atelier passera à côté de l'essentiel — ou exigera l'inapplicable.

Questions fréquentes

Faut-il certifier ISO 27001 tout le site industriel ou seulement l'informatique de gestion ?

Certifier uniquement l'informatique de gestion est possible techniquement mais produit un certificat de faible valeur : il ne répondra pas aux questionnaires de vos donneurs d'ordre industriels et ne couvrira pas le périmètre visé par NIS 2. L'approche recommandée est un périmètre incluant au minimum un site de production complet, quitte à étendre progressivement aux autres sites lors des audits de surveillance annuels.

L'ISO 27001 remplace-t-elle l'IEC 62443 ?

Non, les deux référentiels opèrent à des niveaux différents. L'ISO 27001 fournit le cadre de gouvernance et l'exigence de certification reconnue par les clients et les assureurs ; l'IEC 62443 fournit les mesures techniques détaillées propres aux systèmes industriels. La combinaison la plus efficace utilise l'ISO 27001 comme ossature et référence les parties 2-1, 3-2 et 3-3 de l'IEC 62443 dans la déclaration d'applicabilité pour justifier le traitement des contrôles sur le périmètre OT.

Comment traiter un automate qui ne peut plus recevoir de correctif de sécurité ?

En documentant l'impossibilité par une preuve constructeur ou contractuelle, en appliquant des mesures compensatoires — isolement réseau strict, filtrage en liste blanche, contrôle des accès physiques, surveillance passive du trafic —, en faisant accepter formellement le risque résiduel par le propriétaire de risque au niveau de la direction industrielle, et en inscrivant le remplacement dans un plan pluriannuel aligné sur les investissements industriels. Un auditeur valide cette démarche ; il ne valide pas l'absence de décision.

Un certificat ISO 27001 suffit-il pour être conforme à NIS 2 ?

Il couvre l'essentiel des mesures de gestion des risques de l'article 21 de la directive, mais il ne suffit pas. Trois écarts demandent un traitement dédié : le régime de notification en 24 h / 72 h / un mois prévu à l'article 23, la responsabilité et la formation obligatoires des organes de direction, et l'obligation d'enregistrement auprès de l'autorité nationale compétente. Un SMSI conçu dès l'origine en intégrant ces écarts couvre les deux exigences avec un seul chantier.

Combien de temps et de ressources faut-il prévoir pour un site industriel ?

Comptez douze à dix-huit mois pour une ETI mono-site, avec un équivalent temps plein dédié au pilotage et une contribution significative des équipes de maintenance et de production, particulièrement pendant la phase d'inventaire. Les investissements techniques — pare-feu industriels, bastion d'accès distant, sonde de détection, refonte de la sauvegarde des programmes — représentent généralement le poste budgétaire principal et doivent être planifiés sur les fenêtres d'arrêt.

Peut-on réaliser un test d'intrusion sur un réseau industriel en production ?

Pas dans les conditions habituelles d'un test informatique. Les tests actifs sur des équipements industriels anciens présentent un risque réel d'arrêt de production. La pratique recommandée combine un audit d'architecture et de configuration, une analyse passive du trafic réel, et des tests actifs limités à un banc de test ou à un environnement de reproduction. Lorsqu'un test sur production est indispensable, il se conduit pendant un arrêt planifié, avec les équipes de maintenance présentes et une procédure de retour arrière validée.

Par où commencer si le budget est contraint ?

Par l'inventaire et la cartographie des flux. C'est la brique qui conditionne toutes les autres, elle coûte du temps plus que de l'argent, et elle produit systématiquement des gains immédiats — suppression des accès distants oubliés, retrait des équipements non nécessaires, correction des points d'interconnexion non maîtrisés. Vient ensuite la segmentation entre le réseau bureautique et le réseau industriel, qui offre le meilleur rapport entre réduction de risque et investissement.

Ressources de référence

Pour approfondir, trois sources font autorité : le guide de l'ANSSI consacré à la cybersécurité des systèmes industriels, qui propose une méthode de classification des installations en trois classes et des mesures associées ; le texte officiel de la norme sur le site de l'ISO, dont la lecture intégrale reste indispensable avant tout engagement de certification ; et les publications de l'ENISA sur la mise en œuvre de NIS 2, qui précisent les attentes des autorités européennes en matière de mesures de gestion des risques.

Pour aller plus loin

• ISO 27001:2022 : guide complet de certification
• SMSI ISO 27001 : implémentation version 2022 pas à pas
• Checklist des 93 contrôles ISO 27001 Annexe A
• NIS 2 pour les opérateurs industriels et secteurs OT
• NIS2, DORA et RGPD : convergence réglementaire 2026