7.2 — Compétence

Les bonnes intentions ne sont pas un contrôle. C’est l’exigence qui transforme le « nos gens savent ce qu’ils font » en quelque chose que vous pouvez réellement prouver.

Exigence obligatoire · Information documentée requise : oui

En langage clair

La 7.2 exige de déterminer quelles compétences une personne doit réellement avoir pour effectuer un travail qui affecte la sécurité de l’information, de confirmer qu’elle possède ces compétences par l’éducation, la formation ou l’expérience, de combler les écarts constatés, et de conserver des preuves de tout cela.

Pourquoi cette exigence existe

Un contrôle confié à quelqu’un sans la compétence pour bien l’exécuter n’existe que sur papier. Cette exigence force les organisations à relier les rôles à une capacité réelle, plutôt que de supposer qu’un titre de poste implique la compétence qu’une tâche liée à la sécurité exige.

Scénario : une entreprise confie la revue des règles de pare-feu à un technicien de soutien TI junior sans formation en sécurité réseau, parce qu’il avait de la disponibilité. Les revues ont lieu selon l’horaire, satisfaisant techniquement une exigence de processus, mais personne ayant la compétence de détecter une règle réellement risquée ne regarde vraiment. La 7.2 existe pour attraper cet écart avant qu’un incident ne le fasse.

Ce que la norme attend

La norme attend que l’organisation détermine la compétence nécessaire des personnes effectuant, sous son contrôle, un travail qui affecte la performance de sécurité de l’information ; s’assure que ces personnes sont compétentes sur la base d’une éducation, d’une formation ou d’une expérience appropriées ; le cas échéant, prenne des mesures pour acquérir la compétence nécessaire et évalue si ces mesures ont fonctionné ; et conserve l’information documentée appropriée comme preuve de compétence.

En pratique

• Cartographier les rôles pertinents pour la sécurité (responsable du SGSI, exécutants de contrôles, auditeurs internes) aux compétences précises que chacun exige, plutôt que de supposer qu’une compétence TI générale suffit.
• Tenir un registre de compétence simple par rôle : ce qui est requis, comment cela a été démontré (certification, complétion de formation, années d’expérience pertinente), et quand cela a été revu pour la dernière fois.
• Lorsqu’un écart apparaît — une nouvelle embauche, un nouvel outil, un périmètre élargi — traiter sa fermeture comme une action avec une échéance, pas comme un espoir.

Preuves que l’auditeur demandera

• Une matrice de compétence ou un profil de rôle reliant les rôles pertinents pour la sécurité aux compétences requises.
• Des certifications, registres de formation ou une expérience documentée pour les personnes occupant ces rôles.
• Une preuve que les écarts de compétence identifiés ont été traités, avec une évaluation de l’efficacité de l’action.

Pièges courants

• Supposer qu’un titre de poste (« gestionnaire TI ») implique automatiquement la compétence précise qu’une tâche de sécurité exige.
• Aucun registre expliquant pourquoi une personne a été jugée compétente — seulement une supposition sans rien conservé comme preuve.
• Une formation complétée une fois, il y a des années, sans réévaluation à mesure que les outils, les menaces ou les rôles changent.

Exigences liées

• 7.1 Ressources — les écarts de compétence sont généralement comblés grâce aux ressources allouées ici.
• 7.3 Sensibilisation — la compétence est une habileté propre au rôle ; la sensibilisation est le socle dont tout le monde a besoin.
• Clause parente : Clause 7 Support.