Gestion de la conformité cyber : méthode, rôles et indicateurs

La gestion de la conformité cyber consiste à recenser les exigences de sécurité qui s'appliquent à votre organisation, à les traduire en contrôles, à prouver qu'ils sont appliqués et à traiter les écarts, de façon permanente. Avec NIS 2, DORA, le RGPD, HDS, ISO 27001 et désormais l'AI Act et le Cyber Resilience Act, un RSSI peut avoir cinq ou six textes sur la table. La clé est de ne pas les traiter un par un : on les fait converger vers un socle commun de contrôles, évalué une fois. Cet article du dossier GRC Ops détaille la méthode, les rôles et les indicateurs.

La conformité est le « C » de la GRC (gouvernance, risques et conformité). En cybersécurité, elle couvre quatre sources d'exigences :

• la loi et les règlements : NIS 2, DORA, RGPD, AI Act, CRA, et des textes sectoriels comme la certification HDS pour l'hébergement de données de santé ;
• les normes que vous avez choisi de suivre ou de certifier, ISO 27001 en tête ;
• les contrats : exigences de vos clients, plans d'assurance sécurité, clauses imposées par DORA à vos prestataires ;
• vos propres règles, réunies dans votre politique de sécurité des systèmes d'information (PSSI).

Il faut distinguer la mise en conformité, projet ponctuel qui comble des écarts avant une échéance, de la gestion de la conformité, activité permanente qui maintient ce niveau, absorbe les nouveaux textes et produit des preuves à la demande. La conformité réglementaire en cybersécurité ne remplace pas la gestion des risques : elle fixe un socle minimal, que l'analyse de risques complète là où les menaces propres à votre activité l'exigent.

Tout part d'une question simple, souvent mal traitée : quels textes s'appliquent vraiment à nous, et sur quel périmètre ? Une même entreprise peut être entité importante au titre de NIS 2 pour une filiale, sous-traitant au sens du RGPD pour une autre activité, et fabricant au sens du CRA pour un produit logiciel. Le tableau ci-dessous résume l'état des principaux textes au 8 octobre 2026.

Pour chaque texte retenu, notez le périmètre concerné (entités, sites, produits, traitements), l'autorité compétente, les échéances et la personne chargée de la veille. Nos dossiers sur l'AI Act, le Cyber Resilience Act, NIS 2 et l'hébergement de données de santé détaillent chacun de ces textes. N'oubliez pas les exigences contractuelles : ce sont souvent elles qui arrivent en premier, sous forme de questionnaires de vos clients soumis à DORA ou à NIS 2 (voir ce qu'exigent NIS 2 et DORA face aux prestataires).

Lus côte à côte, ces textes se recouvrent largement. Tous demandent une gestion des accès, des sauvegardes, une gestion des incidents, une maîtrise des fournisseurs, une journalisation et une sensibilisation du personnel. Les évaluer texte par texte revient à poser cinq fois la même question aux mêmes équipes. La correspondance entre référentiels (en anglais mapping) consiste à rattacher chaque exigence à un contrôle d'un socle commun, évalué une seule fois.

Choisir un pivot

En pratique, on choisit un référentiel pivot, le plus souvent ISO 27001 et ses 93 mesures de l'annexe A, parce que la plupart des équipes le connaissent et que les autres textes y renvoient facilement. Le cadre du NIST (Cybersecurity Framework 2.0) peut jouer le même rôle dans un groupe international. Votre SMSI devient alors la colonne vertébrale, et chaque texte s'y accroche.

S'appuyer sur les correspondances publiées

Vous n'avez pas à tout construire. Le guide de mise en œuvre de l'ENISA pour les mesures NIS 2 (juin 2025) comprend des tables qui rattachent chaque exigence du règlement d'exécution 2024/2690 à des normes européennes et internationales. En France, l'ANSSI accompagne son référentiel ReCyF, publié en mars 2026 comme document de travail, d'un outil de comparaison avec les référentiels, normes et réglementations existants.

Garder les spécificités à part

La correspondance est rarement exacte. Une mesure ISO 27001 peut couvrir une exigence NIS 2 en partie seulement ; certains textes imposent des obligations sans équivalent ailleurs : délais de signalement des incidents de l'article 23 de NIS 2, registre d'information de DORA, analyse d'impact du RGPD (voir notre article sur l'AIPD), signalement des vulnérabilités du CRA. Notez pour chaque lien s'il est total ou partiel, et traitez les compléments comme des exigences propres. Une correspondance trop optimiste est l'erreur la plus coûteuse, car elle ne se révèle qu'au contrôle.

Le RGPD l'a posé dès 2018 avec le principe de responsabilité (article 5 §2) : il ne suffit pas d'être conforme, il faut pouvoir le démontrer. Une bonne preuve est :

• rattachée à un contrôle, et par lui à toutes les exigences concernées ;
• datée et assortie d'une durée de validité (une extraction de comptes vaut quelques mois, une politique approuvée un an) ;
• attribuée à un propriétaire, qui sait qu'il devra la renouveler ;
• limitée à un périmètre clair : quelle filiale, quel système, quel site.

L'évaluation se fait par campagnes auprès des équipes concernées, par audits internes, et de plus en plus par collecte automatique pour les contrôles techniques. Cette dernière approche, la conformité continue, remplace la photo annuelle par une mesure régulière. Les assistants d'IA peuvent aider à rattacher des preuves aux exigences ou à pré-remplir des questionnaires, sous contrôle humain : c'est l'objet de notre article IA et GRC.

Chaque non-conformité constatée suit le même chemin :

1. Qualifier l'écart : quelle exigence, quel périmètre, quelle gravité au regard des risques.
2. Décider : corriger, compenser par une autre mesure, ou accepter l'écart de façon formelle et temporaire.
3. Planifier l'action corrective : propriétaire, échéance, budget si nécessaire.
4. Vérifier la clôture par une nouvelle preuve, pas par une simple déclaration.

Les exceptions (ou dérogations) méritent une attention particulière. Une exception acceptée doit être signée par la bonne personne, justifiée, assortie de mesures compensatoires et d'une date de fin. Sans date, elle devient un risque accepté par défaut, que personne ne revoit.

La conformité cyber échoue rarement faute de méthode ; elle échoue faute de responsables. Les textes récents ont clarifié le rôle du sommet : l'article 20 de NIS 2 demande aux organes de direction d'approuver les mesures de cybersécurité, d'en superviser la mise en œuvre et de suivre une formation ; l'article 5 de DORA leur confie la responsabilité ultime de la gestion du risque lié aux TIC, et l'article 6 demande de séparer les fonctions de gestion, de contrôle et d'audit interne.

Dans une organisation de taille moyenne, plusieurs rôles sont tenus par la même personne. L'essentiel est que chaque exigence et chaque contrôle aient un propriétaire nommé, et que celui qui exploite un contrôle ne soit pas le seul à l'évaluer.

Pour piloter, et pour rendre compte à la direction comme l'exigent NIS 2 et DORA, une poignée d'indicateurs suffit :

• Taux de conformité par référentiel et par périmètre, calculé à partir du socle commun.
• Couverture : part des exigences applicables rattachées à au moins un contrôle.
• Fraîcheur des preuves : part des contrôles dont la preuve est encore valide.
• Écarts ouverts par gravité, et leur ancienneté.
• Délai moyen de traitement d'un écart, comparé à l'objectif.
• Exceptions en cours, avec leur échéance.
• Avancement des campagnes d'évaluation : qui a répondu, qui doit être relancé.

Grâce à la correspondance, ces indicateurs se déclinent par texte sans double saisie : un même contrôle alimente le taux NIS 2, le taux DORA et le taux ISO 27001.