Mesures de sécurité : comment passer d’un référentiel théorique à un plan d’action opérationnel

Un référentiel de cybersécurité donne une direction. Il décrit les mesures attendues, les domaines à couvrir et les bonnes pratiques à mettre en place.

Mais une fois le référentiel choisi, une question très concrète apparaît :

Que faut-il faire lundi matin ?

Une mesure comme « gérer les accès », « sécuriser les sauvegardes » ou « traiter les vulnérabilités » reste trop générale pour être exécutée directement. Tant qu’elle n’est pas traduite en responsable, tâches, échéances, preuves et critères de réussite, elle reste une intention.

Le vrai enjeu consiste donc à transformer chaque exigence théorique en une mesure opérationnelle, suffisamment claire pour être exécutée, suivie et démontrée.

Le NIST Cybersecurity Framework 2.0 recommande justement de comparer la posture actuelle avec une posture cible, d’identifier les écarts et d’en déduire un plan d’action priorisé. ISO 27001 repose également sur une logique de mise en œuvre, de maintien et d’amélioration continue, et pas seulement sur l’existence d’un référentiel documentaire.

Pourquoi les référentiels restent souvent théoriques

Les référentiels comme ISO 27001, NIS2, le NIST CSF ou les guides de l’ANSSI fournissent un cadre indispensable. Mais ils ne connaissent pas votre organisation.

Ils ne savent pas :

1. quels outils vous utilisez ;
2. qui peut prendre en charge une mesure ;
3. quel budget est disponible ;
4. quelles preuves existent déjà ;
5. quels actifs sont prioritaires ;
6. quel niveau de maturité est réaliste à court terme.

C’est normal. Un référentiel explique principalement ce qui doit être maîtrisé. L’entreprise doit ensuite déterminer comment le mettre en œuvre dans son contexte.

Le problème apparaît lorsque cette étape de traduction n’est pas réalisée. Les équipes se retrouvent alors avec :

1. des mesures trop vagues ;
2. des plans d’action difficiles à exécuter ;
3. des responsabilités mal définies ;
4. des actions bloquées pendant plusieurs mois ;
5. une conformité principalement déclarative.

Une mesure n’est pas encore une action

Prenons une mesure très fréquente :

Gérer les accès aux systèmes d’information.

Cette formulation donne un objectif, mais elle ne dit pas :

1. quels systèmes sont concernés ;
2. quels accès doivent être revus ;
3. qui réalise la revue ;
4. à quelle fréquence ;
5. quelle preuve doit être conservée ;
6. comment traiter les écarts.

Pour devenir opérationnelle, cette mesure doit être décomposée.

Par exemple :

1. identifier les applications et accès sensibles ;
2. recenser les comptes administrateurs ;
3. vérifier les droits des utilisateurs ;
4. désactiver les comptes inutilisés ;
5. activer la MFA sur les accès critiques ;
6. organiser une revue trimestrielle ;
7. conserver le compte rendu et les corrections réalisées.

La mesure théorique devient alors un ensemble d’actions concrètes.

Les 8 éléments nécessaires pour rendre une mesure opérationnelle

Chaque mesure de sécurité devrait être décrite à l’aide de quelques informations simples.

1. Un objectif clair

L’objectif explique ce que l’entreprise cherche réellement à obtenir.

Pour la gestion des accès, l’objectif peut être :

Garantir que seuls les utilisateurs autorisés disposent d’un accès adapté à leurs fonctions, pendant la durée nécessaire.

L’objectif donne du sens à la mesure. Il évite de transformer la conformité en une simple liste de tâches.

2. Un périmètre défini

Une mesure doit préciser ce qu’elle couvre :

1. applications métiers ;
2. infrastructure ;
3. comptes cloud ;
4. postes de travail ;
5. accès administrateurs ;
6. prestataires ;
7. filiales ou sites concernés.

Sans périmètre, il devient impossible de savoir si la mesure est réellement terminée.

3. Un responsable

Chaque mesure doit avoir un pilote clairement identifié.

Il peut s’agir :

1. du responsable IT ;
2. du RSSI ;
3. d’un responsable métier ;
4. des ressources humaines ;
5. d’un prestataire ;
6. du dirigeant dans une petite structure.

Le responsable ne réalise pas nécessairement toutes les tâches. Il s’assure que la mesure avance, que les blocages sont traités et que les preuves existent.

Une mesure attribuée à « l’IT » ou à « l’équipe sécurité » reste souvent trop imprécise.

4. Des tâches concrètes

La mesure doit être transformée en actions réalisables.

Pour « gérer les accès », les tâches peuvent être :

1. établir la liste des applications critiques ;
2. exporter les comptes utilisateurs ;
3. identifier les comptes inactifs ou orphelins ;
4. vérifier les privilèges élevés ;
5. faire valider les droits par les responsables métiers ;
6. supprimer ou corriger les accès injustifiés ;
7. conserver la preuve de la revue.

Chaque tâche doit pouvoir être comprise sans devoir relire l’ensemble du référentiel.

5. Une échéance réaliste

Une mesure sans échéance reste facilement reportée.

Il faut distinguer :

1. la date de mise en œuvre initiale ;
2. les échéances intermédiaires ;
3. la fréquence de contrôle ou de révision.

Par exemple :

1. première revue des accès avant le 30 septembre ;
2. correction des écarts critiques sous 15 jours ;
3. nouvelle revue tous les trimestres.

Une échéance doit être réaliste. Fixer des dates impossibles ne renforce pas la sécurité : cela rend simplement le plan de traitement moins crédible.

6. Une preuve attendue

Une action n’est pas réellement terminée tant que l’entreprise ne peut pas démontrer son exécution.

Pour une revue des accès, les preuves peuvent être :

1. export des comptes ;
2. liste des droits examinés ;
3. validation des responsables ;
4. compte rendu de revue ;
5. tickets de suppression ou de modification ;
6. capture de la configuration MFA ;
7. historique des corrections.

ENISA insiste sur cette logique en proposant des exemples de preuves pour aider les organisations à démontrer la mise en œuvre effective des mesures de gestion du risque.

La preuve doit être définie dès la création de la mesure, et non recherchée dans l’urgence avant l’audit.

7. Un niveau de maturité actuel et cible

Une mesure n’est pas toujours simplement « faite » ou « non faite ».

Elle peut être :

1. inexistante ;
2. partiellement mise en œuvre ;
3. formalisée ;
4. appliquée de manière régulière ;
5. mesurée et améliorée.

Une échelle simple de maturité permet de représenter cette progression.

Exemple :

Pour la gestion des accès, une PME peut être au niveau 1 aujourd’hui et viser le niveau 3 dans les douze prochains mois.

Cette approche est plus réaliste qu’une conformité binaire.

8. Un coût et un effort estimés

Une mesure doit aussi être arbitrable.

Il est utile d’estimer :

1. le coût d’achat éventuel ;
2. le coût récurrent ;
3. le nombre de jours de mise en œuvre ;
4. le temps nécessaire pour la maintenir ;
5. les ressources internes ou externes requises.

Par exemple :

Cette estimation aide la direction à comprendre ce que représente réellement la mesure et à arbitrer les priorités.

Exemple complet : rendre opérationnelle la mesure « gérer les accès »

Voici comment une mesure générique peut devenir un plan d’action exploitable.

Mesure

Gérer et contrôler les accès aux systèmes et applications critiques.

Objectif

Limiter les accès aux personnes autorisées et réduire les risques liés aux comptes inutiles, excessifs ou compromis.

Responsable

Responsable IT.

Périmètre

Microsoft 365, ERP, outil de paie, VPN et comptes administrateurs.

Niveau actuel

Niveau 1 : gestion principalement réalisée à la demande, sans revue formelle.

Niveau cible

Niveau 3 : processus défini, MFA activée sur les accès critiques et revue trimestrielle documentée.

Tâches

1. recenser les comptes et applications critiques ;
2. identifier les comptes administrateurs ;
3. activer la MFA ;
4. supprimer les comptes inutilisés ;
5. faire valider les droits par les managers ;
6. créer une procédure d’arrivée, mobilité et départ ;
7. planifier une revue trimestrielle.

Échéance

Mise en œuvre initiale sous trois mois.

Fréquence de revue

Tous les trimestres et après chaque départ sensible.

Preuves attendues

1. export des comptes ;
2. rapport de couverture MFA ;
3. compte rendu de revue ;
4. tickets de suppression ;
5. procédure d’habilitation ;
6. validation des responsables métiers.

Coût estimé

1. quatre à six jours de travail interne ;
2. éventuels coûts de licence MFA ;
3. une demi-journée par trimestre pour la revue.

À ce stade, la mesure n’est plus théorique. Elle peut être assignée, budgétée, suivie et auditée.

Comment prioriser les mesures à mettre en œuvre

Transformer toutes les mesures en actions ne signifie pas qu’il faut tout lancer en même temps.

La priorisation peut reposer sur quatre critères :

1. impact métier ;
2. exposition au risque ;
3. exigence réglementaire ou client ;
4. faisabilité.

Une PME peut alors organiser ses mesures en trois vagues.

Vague 1 : réduction immédiate du risque

Exemples :

1. MFA sur les comptes critiques ;
2. sauvegardes et tests de restauration ;
3. correction des vulnérabilités majeures ;
4. suppression des comptes inutilisés.

Vague 2 : structuration

Exemples :

1. procédures de gestion des accès ;
2. gestion des incidents ;
3. inventaire des actifs ;
4. suivi des fournisseurs critiques.

Vague 3 : amélioration et industrialisation

Exemples :

1. indicateurs de performance ;
2. automatisation de certains contrôles ;
3. amélioration des tableaux de bord ;
4. contrôles plus avancés.

Le but est de créer une trajectoire réaliste, et non un plan d’action dans lequel toutes les mesures sont urgentes.

Comment suivre l’avancement sans créer une usine à gaz

Un suivi simple peut déjà apporter beaucoup de valeur.

Pour chaque mesure, il faut pouvoir voir :

1. son responsable ;
2. son niveau actuel ;
3. son niveau cible ;
4. les tâches ouvertes ;
5. les échéances ;
6. les preuves disponibles ;
7. les coûts ;
8. les blocages ;
9. la prochaine date de revue.

Un tableau de pilotage peut alors répondre rapidement à des questions essentielles :

1. quelles mesures sont en retard ;
2. quelles preuves manquent ;
3. quels domaines progressent ;
4. quelles mesures nécessitent un budget ;
5. quels sujets doivent être arbitrés par la direction.

Le suivi ne doit pas seulement montrer le nombre de tâches terminées. Il doit montrer si le niveau de maîtrise progresse réellement.

Les erreurs les plus fréquentes

Copier directement les exigences dans un plan d’action

Une exigence normative n’est pas toujours une action opérationnelle. Elle doit être adaptée au contexte de l’entreprise.

Créer des tâches sans responsable

Sans responsable clairement identifié, les échéances glissent et les blocages restent invisibles.

Définir la preuve uniquement à la fin

La preuve attendue doit être connue dès le départ.

Chercher à atteindre immédiatement le niveau maximal

Une PME doit viser une progression réaliste. Le niveau cible dépend du risque, du contexte et des ressources disponibles.

Ne pas prendre en compte les coûts de maintien

Certaines mesures sont faciles à lancer, mais plus difficiles à maintenir. Le temps récurrent doit être anticipé.

Confondre tâche terminée et mesure maîtrisée

Activer la MFA est une tâche. Maintenir sa couverture, gérer les exceptions et contrôler les comptes sensibles constitue la mesure dans la durée.

Du référentiel au pilotage continu

Le bon modèle peut être résumé ainsi :

référentiel → mesure → objectif → responsable → tâches → preuve → maturité → revue

Cette chaîne permet de transformer une exigence générale en réalité opérationnelle.

Le référentiel reste indispensable, car il donne la structure. Mais la valeur apparaît lorsque chaque mesure devient :

1. compréhensible ;
2. assignable ;
3. mesurable ;
4. démontrable ;
5. réévaluable.

C’est cette transformation qui permet de passer de la conformité théorique au pilotage réel.

Là où CompliKey apporte une réponse concrète

C’est précisément le cœur du positionnement de CompliKey.

CompliKey ne se limite pas à afficher des référentiels ou à fournir une liste de contrôles. La plateforme aide les PME, ETI et consultants à transformer les mesures de sécurité en objets de pilotage concrets.

Pour chaque mesure, il devient possible de suivre :

1. le responsable ;
2. les tâches ;
3. les preuves ;
4. le niveau de maturité ;
5. les échéances ;
6. les coûts ;
7. les référentiels couverts ;
8. l’évolution dans le temps.

L’objectif n’est pas d’ajouter une couche documentaire supplémentaire. Il est de rendre les mesures réellement exécutables et de conserver une vision claire de leur progression.

FAQ

Comment transformer une mesure ISO 27001 en action concrète ?

Il faut adapter la mesure au contexte de l’entreprise, préciser son périmètre, désigner un responsable, créer des tâches, définir les preuves attendues et fixer une échéance.

Une mesure de sécurité doit-elle avoir une seule tâche ?

Non. Une mesure correspond généralement à un objectif de maîtrise et peut nécessiter plusieurs tâches techniques, organisationnelles ou documentaires.

Comment savoir si une mesure est terminée ?

Une mesure ne doit pas être considérée comme maîtrisée uniquement parce que ses tâches initiales sont terminées. Elle doit être mise en œuvre, prouvée, revue et maintenue dans le temps.

Pourquoi suivre un niveau de maturité ?

Le niveau de maturité permet de représenter une progression plus réaliste qu’un simple statut conforme ou non conforme. Il aide aussi à définir une cible adaptée aux moyens et aux risques de l’entreprise.

Quelles preuves conserver pour une mesure de sécurité ?

Cela dépend de la mesure : configurations, exports, rapports de test, tickets, comptes rendus, validations, journaux, procédures ou historiques de revue.

Conclusion

La difficulté d’un programme de cybersécurité ne consiste pas seulement à choisir le bon référentiel. Elle consiste à traduire ce référentiel en décisions et en actions compréhensibles par les équipes.

Une mesure trop générale reste théorique. Une mesure avec un responsable, des tâches, une échéance, une preuve, un coût et un niveau cible devient pilotable.

C’est cette transformation qui répond à la vraie question des PME :

Maintenant que nous avons un référentiel, qu’est-ce que nous faisons concrètement lundi matin ?