5.3 — Rôles, responsabilités et autorités organisationnels

Quand quelque chose tourne mal à 2 h du matin, tout le monde sait-il déjà à qui revient la réponse — ou l’organigramme ne répond-il à cette question qu’en théorie ?

En langage clair

La 5.3 exige que la direction attribue et communique clairement qui est responsable de quoi à travers le SGSI, et nomme spécifiquement qui est responsable de s’assurer que le SGSI est conforme à la norme et de rapporter sa performance à la direction.

Pourquoi cette exigence existe

Une responsabilité diffuse n’est aucune responsabilité. Quand « la sécurité est l’affaire de tous » est la seule réponse donnée, en pratique elle devient l’affaire de personne dès que quelque chose de gênant doit être fait. Cette exigence force des noms précis, ou du moins des rôles précis, sur les responsabilités qui comptent le plus — pour que l’imputabilité survive au contact d’un mardi chargé.

Scénario : un incident de sécurité soupçonné survient une fin de semaine. Trois personnes différentes supposent chacune que quelqu’un d’autre gère l’escalade, parce que la responsabilité de réponse aux incidents n’a jamais été attribuée à un rôle précis — elle était supposée appartenir à « l’équipe TI » en général. D’ici lundi, quatre heures se sont écoulées sans réponse formelle, non pas parce que personne ne s’en souciait, mais parce que personne n’était réellement imputable.

Ce que la norme attend

La norme attend que la direction s’assure que les responsabilités et autorités pour les rôles pertinents pour la sécurité de l’information sont attribuées et communiquées au sein de l’organisation. La direction doit spécifiquement attribuer la responsabilité et l’autorité pour s’assurer que le SGSI est conforme aux exigences de la norme, et pour rapporter la performance du SGSI à la direction — avec une note précisant que d’autres responsabilités de rapport au sein de l’organisation peuvent aussi être attribuées.

En pratique

• Nommer un responsable précis du SGSI, imputable pour la conformité globale — un rôle, pas une équipe diffuse — et s’assurer que cette attribution est documentée et connue.
• Bâtir une matrice simple des rôles et responsabilités couvrant les fonctions pertinentes pour la sécurité : propriété des risques, exécution des contrôles, réponse aux incidents, indépendance de l’audit interne.
• Communiquer les attributions activement — un organigramme seul ne suffit pas si les personnes dans les rôles ne savent pas qu’elles les occupent.
• Revoir les attributions lorsque des personnes changent de rôle ou quittent — une responsabilité rattachée à un nom qui ne travaille plus là est un écart qui attend d’être découvert.

Preuves que l’auditeur demandera

• Une matrice des rôles et responsabilités ou un organigramme documenté, propre au SGSI.
• Une personne nommée, imputable pour la conformité du SGSI et pour rapporter la performance à la direction.
• Une preuve que les attributions sont à jour — ne faisant pas référence à quelqu’un ayant depuis quitté le rôle.

Pièges courants

• Des responsabilités attribuées à un département (« TI », « sécurité ») plutôt qu’à un rôle ou une personne précise.
• Une matrice de rôles périmée nommant encore quelqu’un ayant quitté l’organisation il y a des mois.
• Aucune ligne claire vers la direction pour le rapport de performance du SGSI — les constats remontent mais n’atteignent jamais formellement la direction.

Exigences liées

• 5.1 Leadership et engagement — les attributions de rôles ici sont l’une des façons concrètes dont la direction démontre cet engagement.
• 9.3.1 Revue de direction, généralités — là où la ligne de rapport attribuée ici est réellement utilisée.
• Clause parente : Clause 5 · Leadership