ISO 27001 : prospectives et limites

Premier élément, il s’agit d’une dérive possible que j’ai pu détecter, avec les équipes de ma DSI : le risque que la 27001 finisse de facto par diriger la DSI, et que le(la) DSI s’en trouve réduit(e) à venir prendre ses instructions auprès du comité opérationnel de l’ISO en interne. À partir du moment où tout projet SI comporte forcément un volet SSI et que ce volet doit passer par les fourches caudines de la certification (que personne n’a les « moyens politiques » de perdre), alors le comité opérationnel 27001 se retrouve, par extension, en position de décider si tel ou tel projet est autorisé ou pas à démarrer, avec quelles contraintes et selon quel calendrier (il est facile de dire que si telle brique de sécurité n’est pas en place, alors le projet X est bloqué). Le DPO n’est pas sujet à une telle dérive dans son domaine, dans la mesure où le RGPD stipule bien qu’il a « seulement » un rôle de conseil et d’alerte : nul texte équivalent pour le RSSI (même si la directive NIS est contraignante pour l’entreprise).

À ce stade de la réflexion, c’est, selon moi, une dérive : le RSSI n’est pas plus en position légitime de diriger une DSI que le qualiticien de diriger l’entreprise. Certes, il est facile d’argumenter qu’au final la MOA est propriétaire de ses risques et donc que le RSSI se retrouve en position de conseil et d’alerte, mais dans les faits cela ne se passe pas comme cela sur un sujet aussi technique : ce risque de dérive est réel, et des consultants m’ont confirmé que je ne suis pas le seul à avoir abouti à cette conclusion.

Deuxième élément : si, dans l’esprit, la 27001 revient à piloter des risques, il s’agit bien de risques opérationnels supposés être couverts par les 114 mesures de l’annexe A. Il est peu question de risques de niveau processus (le PDCA de toute norme ISO et donc ses dérives potentielles, cf. le point précédent). À un moment donné, le pilote global de la démarche 27001 se doit d’intégrer cette question du risque de niveau macroprocessus, ce qui implique une appréciation des risques particulière (et bien distincte des risques opérationnels), une révision, etc. Il est assez facile de les articuler avec les audits internes et les révisions annuelles, mais encore faut-il avoir bien identifié le sujet. Là où cela se complexifie, c’est lorsque le RSSI (dont l’une des qualités premières est d’avoir d’immenses oreilles) identifie des dysfonctionnements managériaux au sein de la DSI qui, sans relever de la SSI, vont immanquablement donner lieu à des incidents soit 27001, soit SSI. Quelle attitude adopter alors ? Cela rejoint le point précédent.

Troisième élément, qui a été soulevé récemment par Alain Bouillé (président du Cesin) : un des risques « processus » de la 27001 est de finir par faire de la conformité aux dépens de la sécurité SI. En d’autres termes, la dérive de l’art pour l’art. Si vous pensez que ce risque général est hypothétique, sachez qu’en 23 ans de pratique je suis tombé plus d’une fois sur des technocrates plus occupés à calibrer les cartouches de documents qu’à produire de la valeur ajoutée – et je n’exagère rien.

Enfin, dernier élément, l’articulation entre les normes ISO 27001 et d’autres démarches de type Itil, Lean, Six Sigma, etc.

À ce stade de la réflexion, j’ai une bonne et une mauvaise nouvelle.
La mauvaise, c’est que pour tous les sujets évoqués, je n’ai, à ce niveau de discussion, aucune solution correcte à vous apporter.
La bonne, c’est que quand on en est rendu à ce niveau de discussion, clairement aucun auditeur ISO digne de ce nom ne va venir vous expliquer que votre système de management ne fonctionne pas.

Bonne semaine à vous,

L'auteur 

Responsable Sécurité des systèmes d’information et correspondant Informatique et Libertés au CHU de Nantes, Cédric Cartau est également chargé de cours à l’École des hautes études en santé publique (EHESP). On lui doit aussi plusieurs ouvrages spécialisés publiés par les Presses de l’EHESP, dont La Sécurité du système d’information des établissements de santé.