Pouvons-nous accepter certains risques liés à la sécurité de l’information au titre d’ISO 27001 ?

Oui. ISO 27001 vous autorise explicitement à accepter des risques liés à la sécurité de l’information au lieu de les traiter, mais uniquement de manière maîtrisée et documentée, alignée sur vos obligations commerciales, 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 :

En 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’évaluation des risques définie et reproductible (incluant des critères de vraisemblance et d’impact).
• Déterminer les critères d’acceptation des risques applicables à l’échelle de votre 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 entités gouvernementales imposent souvent des normes ou des contrôles nommément désignés (par exemple, un chiffrement spécifique, des modèles de contrôle d’accès ou une journalisation). L’acceptation du risque ne peut pas les supplanter.
• Politiques internes : Les politiques d’entreprise en matière de sécurité de l’information et de sécurité peuvent définir des exigences non négociables (par exemple, l’authentification multifacteur pour l’accès distant 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 mettre hors service le processus ou le système concerné, plutôt qu’à accepter le risque.

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

Pour les risques qui peuvent légitimement être acceptés, vous devez pouvoir présenter 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, incluant une comparaison avec vos critères d’acceptation.
• Contexte et contraintes : pourquoi un traitement supplémentaire n’est pas proportionné ou réalisable (par exemple, des équipements existants qui ne peuvent pas être corrigés 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).
• Responsable du risque : un responsable nommé disposant de l’autorité appropriée (généralement au niveau de la direction métier ou de la direction de site, et pas seulement de l’IT).
• Approbation formelle : validation documentée par la direction, 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, le prochain cycle de revue du SMSI, une mise à niveau système, un renouvellement de contrat).

Ce niveau de documentation est important lors des audits : vous ne démontrez pas une « absence de risque », vous démontrez une acceptation maîtrisée et motivée dans des limites définies.

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

Dans les environnements OT/IT mixtes, de nombreux sites font face à des risques liés aux équipements hérités et aux longs cycles de vie des actifs. Exemples fréquents :

• Systèmes de contrôle-commande hérités qui ne peuvent pas recevoir de correctifs ni être mis à niveau sans revalidation ou recertification.
• 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.
• Équipements verrouillés par fournisseur, pour lesquels les options de configuration sécurisée sont limitées.

Dans ces situations, ISO 27001 n’exige 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 de contrôle compensatoires réalisables (par exemple, segmentation, contrôle d’accès strict, maîtrise rigoureuse des changements, journalisation renforcée et procédures).
• Preniez une décision documentée si le risque résiduel, au-delà de ces mesures de contrôle, 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 de production et de la complexité d’intégration. Une acceptation du risque compatible avec ISO 27001 peut combler cet écart, à condition que la décision soit explicite, justifiée et réexaminée périodiquement.

Mesures de maîtrise opérationnelles autour des risques acceptés

Si vous acceptez un risque, vous avez néanmoins besoin de 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 une nouvelle vérification 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 impacts en aval sur la qualité et la conformité.

Ces pratiques ne font pas disparaître le risque ; elles réduisent l’effet de surprise 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 démarche est mal gérée. Les problèmes d’audit typiques incluent :

• Des critères d’acceptation des risques qui ne sont pas clairement définis ou qui ne sont pas approuvés au niveau approprié.
• 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 des responsables 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.