Pouvons-nous accepter certains risques de sécurité de l’information dans le cadre d’ISO 27001 ?

Oui. ISO 27001 vous autorise explicitement à accepter des risques liés à la sécurité de l’information plutôt qu’à les traiter, mais uniquement de manière maîtrisée et documentée, en cohérence avec vos obligations métier, contractuelles et réglementaires.

Ce qu’ISO 27001 attend réellement

L’acceptation du risque est l’un des résultats possibles du processus de traitement des risques. Pour être cohérent avec ISO 27001, vous devez :

Dans la pratique, cela se rattache aux preuves de sécurité industrielle lorsque les équipes doivent transformer la réponse en habitudes d’exécution répétables.

• Utiliser une méthode d’appréciation des risques définie et répétable, incluant des critères de vraisemblance et d’impact.
• Déterminer les critères d’acceptation des risques applicables à l’ensemble de l’organisation et les faire approuver par la direction.
• Évaluer chaque risque au regard de ces critères et des obligations applicables (réglementaires, contractuelles, politiques internes).
• Choisir une option de traitement : réduire, éviter, partager/transférer ou accepter.
• Documenter la décision et sa justification lorsqu’un risque est accepté.

ISO 27001 n’interdit pas d’accepter des risques ; elle exige que vous maîtrisiez le processus et que vous soyez en mesure de démontrer comment et pourquoi un risque a été accepté.

Quand l’acceptation du risque n’est généralement pas appropriée

Même si ISO 27001 prévoit ce mécanisme, vous ne pouvez pas simplement « accepter » un risque qui entre en conflit avec des exigences externes impératives. Dans les environnements de fabrication réglementés, l’acceptation du risque est souvent limitée par :

• Réglementation et droit : Les contrôles à l’exportation, les lois sur la protection de la vie privée, les règles de cybersécurité propres à un secteur et les réglementations liées à la sécurité peuvent imposer des contrôles spécifiques. Vous ne pouvez pas accepter une non-conformité comme décision de risque.
• Obligations contractuelles : Les contrats avec des OEM ou des administrations imposent souvent des normes ou des contrôles désignés (par exemple, un chiffrement spécifique, des modèles de contrôle d’accès ou la journalisation). L’acceptation du risque ne peut pas les supplanter.
• Politiques internes : Les politiques d’entreprise relatives à la sécurité de l’information et à la sécurité peuvent définir des exigences non négociables (par exemple, l’authentification multifacteur pour l’accès à distance aux réseaux OT).
• Sécurité et intégrité du produit : Pour les systèmes liés à la qualité produit, à la sécurité des patients ou à la navigabilité, « accepter » des risques susceptibles de compromettre la traçabilité, les enregistrements qualité ou les fonctions de sécurité n’est généralement pas tolérable.

Dans ces cas, vos options consistent généralement à corriger, reconcevoir ou, dans de rares cas, restreindre ou retirer le processus ou le système concerné, plutôt qu’à accepter le risque.

À quoi ressemble une décision d’acceptation du risque conforme

Pour les risques qui peuvent légitimement être acceptés, vous devez être en mesure de démontrer les éléments suivants :

• Description claire du risque : actif, menace, vulnérabilité, impact sur la confidentialité, l’intégrité et la disponibilité, ainsi que tout impact en aval sur la qualité, la sécurité ou les enregistrements réglementaires.
• Niveau de risque mesuré : vraisemblance et impact évalués selon votre méthode définie, avec comparaison à vos critères d’acceptation.
• Contexte et contraintes : pourquoi un traitement supplémentaire n’est pas proportionné ou réalisable (par exemple, un équipement hérité qui ne peut pas être corrigé par correctif sans requalification ou sans temps d’arrêt inacceptable).
• Mesures compensatoires : toute atténuation partielle (segmentation réseau, contrôles procéduraux, surveillance renforcée, fenêtres d’utilisation restreintes).
• Propriétaire du risque : un responsable nommé disposant de l’autorité appropriée (généralement au niveau de la direction métier ou de l’usine, et pas seulement de l’IT).
• Approbation formelle : validation documentée par le management, souvent via le plan de traitement des risques et la Déclaration d’applicabilité.
• Cadence de revue : une date ou un déclencheur défini pour réévaluer le risque (par exemple, prochain cycle de revue du SMSI, mise à niveau du système, renouvellement de contrat).

Ce niveau de documentation est important lors des audits : vous ne démontrez pas qu’il n’y a « aucun risque », vous démontrez une acceptation maîtrisée et raisonnée dans des limites définies.

Réalités des environnements brownfield et de l’OT hérité

Dans les environnements mixtes OT/IT, de nombreuses usines sont exposées à des risques liés aux équipements hérités et aux longs cycles de vie des actifs. Les exemples courants incluent :

• Des systèmes de contrôle hérités qui ne peuvent pas être corrigés ou mis à niveau sans revalidation ou recertification.
• Des serveurs critiques pour la production exécutant des systèmes d’exploitation non pris en charge, liés à des intégrations MES/QMS validées.
• Des équipements verrouillés par le fournisseur, pour lesquels les options de configuration sécurisée sont limitées.

Dans ces situations, ISO 27001 ne vous impose pas de tout remplacer immédiatement. Elle attend de vous que vous :

• Identifiiez et évaluiez les risques de manière réaliste, en tenant compte de l’impact sur la production, la qualité et la sécurité.
• Appliquiez des mesures compensatoires réalisables (par exemple, segmentation, contrôle d’accès strict, maîtrise rigoureuse des changements, journalisation renforcée et procédures).
• Prendiez une décision documentée si le risque résiduel, une fois ces mesures appliquées, subsiste et doit être accepté temporairement.
• Reliiez l’acceptation du risque à une feuille de route (mises à niveau planifiées, remplacement de fournisseur ou évolutions d’architecture) plutôt que d’accepter le risque indéfiniment par défaut.

Le remplacement complet de systèmes critiques uniquement pour combler une seule lacune de sécurité de l’information est souvent impraticable dans une fabrication fortement réglementée, en raison de la charge de requalification, du risque d’arrêt et de la complexité d’intégration. Une acceptation du risque compatible avec ISO 27001 peut faire le lien, à condition que la décision soit explicite, justifiée et réexaminée périodiquement.

Garde-fous opérationnels autour des risques acceptés

Si vous acceptez un risque, vous devez tout de même mettre en place des garde-fous pour garder cette décision sous contrôle :

• Maîtrise des changements : Toute modification du système, du réseau ou du processus concerné doit déclencher un réexamen du risque accepté et de ses hypothèses.
• Surveillance et réponse aux incidents : Surveillance renforcée des actifs concernés, avec des procédures claires si des indicateurs de compromission ou des défaillances apparaissent.
• Traçabilité : Relier le risque accepté aux processus, équipements et enregistrements impactés afin que les responsables qualité et opérations comprennent les effets potentiels.
• Visibilité transverse : Impliquer les opérations, l’ingénierie, la qualité et l’IT dans les revues ; les risques de sécurité acceptés peuvent avoir des incidences en aval sur la qualité et la conformité.

Ces pratiques ne font pas disparaître le risque ; elles réduisent les surprises et soutiennent des décisions défendables lors des audits et des revues internes.

ISO 27001 et considérations d’audit

Accepter des risques ne vous empêche pas d’être certifié ISO 27001, mais cela peut générer des constats d’audit si la gestion est insuffisante. Les problèmes d’audit typiques comprennent :

• Des critères d’acceptation des risques qui ne sont pas clairement définis ou qui ne sont pas approuvés au bon niveau.
• Des risques acceptés « implicitement » parce qu’aucune décision de traitement n’a été enregistrée.
• Des risques acceptés qui contredisent des exigences légales, réglementaires ou contractuelles.
• Des décisions relatives aux risques prises uniquement par l’IT, sans implication des propriétaires de processus ou de la qualité.
• Des risques acceptés qui ne sont jamais réexaminés, même lorsque l’environnement évolue.

Pour éviter cela, assurez-vous que l’acceptation des risques suit les procédures de votre SMSI, qu’elle est clairement traçable et qu’elle est visible dans les revues de direction.