GRC cybersécurité : gouvernance, risques et conformité, sans le
jargon d'éditeur

Le point conformité passe en fin de comité, entre le budget et les questions diverses. Une diapositive, une jauge à "72 % conforme", trois pastilles vertes et une orange, et le sujet est réputé traité jusqu'au trimestre suivant. Derrière la diapositive, dans la plupart des organisations de moins de cinq cents personnes, il y a un classeur partagé : une ligne par exigence, une colonne "statut", une colonne "commentaire", et quelqu'un qui l'a rempli avec ce qu'il savait le jour où il l'a ouvert. Ce classeur n'a rien de ridicule, tout le monde commence par là. Il devient un problème le jour du contrôle, et un vrai problème le jour de l'incident.

Le sigle GRC cybersécurité tient en trois mots, gouvernance, risques et conformité, et recouvre une boucle bien plus simple que ne le laissent croire les plaquettes des éditeurs. La boucle, elle, tourne correctement. Ce qui se casse est au milieu : le lien entre la case cochée dans l'outil et l'état réel du système. Et ça se casse en silence, sans jamais faire bouger la jauge du tableau de bord. Un pentest ou une surveillance de surface d'attaque rétablissent ce lien, à condition de savoir à quelle mesure rattacher leurs constats, ce qui n'a rien d'évident quand on tient cinq référentiels à la fois.

GRC cybersécurité : les trois briques derrière le sigle

La gouvernance, c'est ce que décide la direction : ce qu'on protège en priorité, combien on y met, qui est responsable, et quel niveau de risque on accepte de porter sans rien faire. Ça se matérialise dans une politique de sécurité des systèmes d'information, dans le rattachement du RSSI et dans des comités qui tranchent. NIS2 a rendu cette brique juridiquement inconfortable : l'article 20 de la directive demande aux organes de direction d'approuver les mesures de gestion des risques, d'en superviser la mise en œuvre, de suivre une formation, et prévoit qu'ils puissent être tenus responsables des manquements. Le sujet n'est plus délégable au service informatique.

Les risques, c'est l'analyse de ce qui peut arriver, par où, avec quelle vraisemblance et quel dégât. En France, la méthode de référence est EBIOS Risk Manager, publiée par l'ANSSI, en cinq ateliers qui partent des missions de l'organisation pour descendre jusqu'aux scénarios techniques. Le cadre international équivalent est ISO/IEC 27005, révisée en 2022. Le produit de cette brique, ce sont des risques cotés, une décision par risque (réduire, transférer à un assureur, accepter, éviter) et un plan de traitement.

La conformité, enfin, c'est la démonstration, référentiel par référentiel, que les mesures décidées existent et fonctionnent. Elle se lit dans un dossier : la déclaration d'applicabilité d'ISO 27001, la matrice de couverture des dix mesures de l'article 21.2 de NIS2, le registre d'informations de DORA, le rapport de conformité PCI DSS. Elle est jugée par quelqu'un d'autre que vous : un certificateur, l'ANSSI, un assureur, un client qui envoie son questionnaire. Elle se juge sur pièces, et le dossier vaut ce que valent les pièces qu'on y a rangées.

Le schéma compte deux flèches en pointillé, et ce sont les deux que le tableur ne sait pas tenir. La première ramène les écarts d'audit à la direction, pour qu'ils soient arbitrés plutôt qu'enterrés dans un plan d'action que personne ne relit. La seconde renvoie les constats de terrain vers l'analyse de risques : un pentest qui trouve un chemin d'attaque que l'atelier EBIOS n'avait pas imaginé doit modifier la cotation, sinon l'analyse décrit un système qui n'existe plus.

Ce qu'un outil GRC fait concrètement

Une fois le vocabulaire posé, un outil GRC est moins mystérieux que ses plaquettes. Il fait six choses, et les fait mieux qu'un classeur partagé à partir du moment où vous avez plus d'un référentiel à tenir ou plus d'une personne pour les tenir.

Des référentiels mappés entre eux

C'est la fonction qui justifie l'achat. Une même mesure, disons "les accès privilégiés sont revus tous les trimestres", répond à un contrôle d'ISO 27002, à la mesure (i) de l'article 21.2 de NIS2, à un objectif du ReCyF, à une exigence PCI DSS et à trois questions du questionnaire de votre plus gros client. Dans un tableur, vous la documentez cinq fois et elle dérive cinq fois. Dans un outil GRC, elle existe une fois, et les cinq référentiels pointent vers elle. Tenacy annonce plus de cinquante référentiels mappés, Egerie plus de cent vingt ; ce qui compte est moins le nombre que la présence des vôtres, et la qualité du mapping, qui est toujours une interprétation.

Un dossier de mesures, avec un propriétaire par ligne

Chaque mesure porte un responsable nommé, un état (non traitée, en cours, en place, non applicable avec justification), une fréquence de revue et une date de dernière vérification. C'est ce qui transforme une liste de bonnes intentions en quelque chose qu'on peut relancer. La mesure "non applicable" est d'ailleurs le premier endroit où un auditeur creuse : une exclusion sans justification écrite est une non-conformité qui s'ignore.

Des preuves attachées, datées, versionnées

Une capture d'écran de la console MFA, l'export d'une revue de comptes, le rapport de pentest de mars, le procès-verbal du test de restauration. Chaque pièce est rattachée aux mesures qu'elle soutient, avec sa date et sa durée de validité. Les plateformes nées autour de SOC 2, comme Vanta ou Drata, branchent en plus des connecteurs sur le cloud, l'IdP et l'outil de tickets pour collecter certaines preuves automatiquement. Ça marche pour ce qui est lisible par API, la configuration d'un compte AWS ou l'état du MFA sur l'annuaire, et pas du tout pour ce qui demande un jugement humain.

Un plan d'action qui survit aux réunions

Chaque écart devient une action avec une échéance, un porteur et un lien vers la mesure d'origine. La différence avec un ticket Jira tient à ce lien : quand l'action est close, la mesure repasse en "en place" et la preuve de clôture est attendue, comme dans un plan de remédiation après un audit.

Les obligations périodiques

La conformité a un calendrier, et il est chargé. Revue de direction annuelle et audits de surveillance pour ISO 27001, test du plan de continuité, revue des droits, mise à jour du registre d'informations DORA, exercice de gestion de crise, renouvellement des attestations fournisseurs, scans trimestriels PCI DSS. L'outil rappelle, relance, et horodate la relance elle-même, ce qui sert autant que le rappel. Un plan de continuité d'activité jamais testé et un plan de gestion de crise jamais joué se ressemblent beaucoup : bien rédigés, jamais éprouvés.

Les livrables pour l'auditeur

La déclaration d'applicabilité, la matrice de couverture par référentiel, la liste des écarts ouverts avec leur ancienneté, l'historique des preuves, le registre des risques et des acceptations signées. Produire tout cela à la main, la semaine qui précède l'audit, occupe une personne à plein temps et laisse toujours passer une incohérence entre deux onglets.

Les limites du déclaratif : cocher une case ne prouve rien

Les démonstrations d'éditeurs s'attardent rarement sur ce point. La jauge de conformité en haut du tableau de bord additionne des cases. Qui les a cochées ? La personne en charge du dossier, à partir de ce qu'elle sait ou de ce qu'on lui a répondu par mail. Une mesure "en place" dans l'outil signifie qu'un humain l'a déclarée en place. C'est le même mécanisme que le questionnaire de sécurité fournisseur que vous recevez de vos clients, retourné vers vous-même.

Le "72 % conforme" cumule trois défauts. Il pondère à plat, donc une mesure critique absente (pas de MFA sur l'accès administrateur exposé) pèse autant qu'une mesure de forme en place (la charte est signée). Il ne date pas, donc la case cochée en janvier reste verte en novembre alors que le prestataire a changé et que trois sous-domaines ont été créés entre-temps. Et il ne distingue pas le niveau de preuve derrière la case, qui est pourtant la seule chose qu'un auditeur regarde.

La plupart des dossiers de conformité sont du niveau documentaire, et c'est déjà honorable. Mais certaines mesures n'ont de sens qu'au niveau constaté, parce qu'elles sont formulées comme un résultat et non comme une intention. "Les vulnérabilités sont gérées" ne se prouve pas par une procédure de gestion des vulnérabilités ; il faut montrer un inventaire, une détection datée, une correction datée. Pour "les applications sont testées avant mise en production", une politique de développement sécurisé ne suffira pas davantage : l'auditeur attend le rapport de test. Les référentiels formulent rarement cette exigence de façon aussi nette, mais elle est comprise ainsi par ceux qui contrôlent.

Relier les preuves techniques aux mesures

C'est le chaînon manquant de la plupart des dossiers GRC, et c'est celui sur lequel own2pwn a une opinion, parce que c'est son métier. Un rapport de pentest rangé dans un dossier partagé ne sert la conformité que s'il est rattaché aux mesures qu'il éprouve. Le travail consiste à faire le lien dans les deux sens : de la mesure vers la preuve attendue, et du constat vers les mesures qu'il invalide.

Prenons les référentiels les plus courants. Dans NIS2, la mesure (e) de l'article 21.2 porte sur la sécurité de l'acquisition, du développement et de la maintenance des systèmes, y compris le traitement des vulnérabilités, et la mesure (f) sur l'évaluation de l'efficacité des mesures. Dans l'Annexe A d'ISO 27001:2022, le contrôle 8.8 (gestion des vulnérabilités techniques) et le contrôle 8.29 (tests de sécurité en développement et en recette) sont les deux qui appellent un constat, comme le détaille l'article sur la certification ISO 27001 et qui produit les preuves. Dans DORA, les articles 24 à 27 imposent un programme de tests de résilience, avec un test d'intrusion fondé sur la menace pour les entités les plus importantes. Dans PCI DSS v4.0.1, l'exigence 11.3 demande des scans de vulnérabilités et l'exigence 11.4 un test d'intrusion, au numéro près.

Ce second circuit consomme du terrain. Un rapport de test d'intrusion documente ce qui passe sur un périmètre écrit, à une date, et couvre les mesures de test et de développement sécurisé ; c'est aussi ce que rend le volet technique d'un audit NIS2, dont la matrice de couverture fait le rattachement mesure par mesure. Une surveillance de surface d'attaque externe, ou EASM, couvre l'autre moitié du besoin, l'inventaire des actifs exposés et la gestion des vulnérabilités, avec l'avantage de se régénérer d'elle-même entre deux audits de surveillance. Le pilier sur la gestion de surface d'attaque externe détaille ce que l'outil voit et ne voit pas.

Quel référentiel pour qui : panorama FR et UE

En réunion, personne ne demande comment faire de la GRC. On demande à quoi on est soumis, et la réponse se cherche dans deux familles de référentiels qu'il faut arrêter de confondre : ceux qu'une loi, un règlement ou un contrat impose, et ceux qu'on adopte parce qu'ils structurent le travail ou rassurent un acheteur. L'article sur la conformité réglementaire en cybersécurité déroule les critères d'assujettissement texte par texte ; voici la vue d'ensemble.

Le tableau tient dans des cellules, et trois sujets n'y tiennent pas. NIS2 en France, pour commencer : au moment de la rédaction (septembre 2026), le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité, adopté par le Sénat le 12 mars 2025 puis amendé en commission spéciale de l'Assemblée nationale en septembre 2025, n'est toujours pas promulgué, et aucun décret d'application n'existe. L'ANSSI n'a pas attendu : elle met à disposition depuis le 17 mars 2026 le Référentiel Cyber France (ReCyF), en version de travail, dont le statut, tel que l'ANSSI le formule, est "par défaut non-obligatoire", mais dont celui qui l'applique pourra se prévaloir lors d'un contrôle. La formule demande une nuance, que le document porte lui-même : ce sont les moyens acceptables de conformité, la colonne "comment", qui ne sont pas d'application obligatoire, alors que les vingt objectifs de sécurité y sont décrits comme l'obligation fixée par le décret à prendre en application de l'article 14 du projet de loi. Tant que ce décret n'est pas pris, rien n'est opposable ; les objectifs, eux, ont vocation à le devenir. Pour savoir si vous êtes dans le champ, le pilier sur la directive NIS2 détaille secteurs, seuils et calendrier.

Ensuite, sur DORA : c'est un règlement, donc d'application directe, et le texte du règlement (UE) 2022/2554 fait porter par l'organe de direction la responsabilité du cadre de gestion du risque TIC (article 5) et impose un registre d'informations sur les contrats de services TIC (article 28) ; le guide sur le règlement DORA en détaille les piliers. Enfin, sur HDS : l'article L1111-8 du code de la santé publique rend le certificat obligatoire pour l'hébergeur, délivré par un organisme accrédité, avec un stockage dans un État membre de l'Union ou de l'Espace économique européen ; le référentiel de certification est passé en version 2 par arrêté en 2024. L'article sur la certification HDS explique ce que l'hébergeur garantit et ce qui reste à votre charge.

Par où commencer, sans acheter l'outil d'abord

L'erreur classique consiste à choisir la plateforme avant d'avoir la liste des référentiels qui s'imposent, puis à passer six mois à la remplir de déclaratif pour obtenir une jauge. L'ordre inverse coûte moins cher. Établissez d'abord, texte par texte, ce qui vous est opposable ; le tableau ci-dessus et l'auto-diagnostic NIS2 suffisent pour un premier tri. Nommez un responsable, interne ou externalisé, parce qu'une GRC sans RSSI, même à temps partiel, se dégrade en quelques trimestres. Faites une analyse de risques courte : un EBIOS RM de deux jours sur le périmètre qui fait vivre l'entreprise vaut mieux qu'un catalogue de 93 contrôles appliqué à plat, parce qu'il dit quelles mesures doivent être au niveau constaté et lesquelles peuvent rester documentaires. Produisez ensuite les premières preuves constatées là où elles pèsent, l'exposition externe et les applications métier. L'outil GRC arrive en dernier, quand il y a assez de mesures, de référentiels et de personnes pour qu'un tableur ne suive plus. À ce stade, il rend service ; avant, il habille le vide.

Les articles du cocon GRC

Ce pilier ouvre une série sur la gouvernance et la conformité. Chaque article ci-dessous traite une brique en profondeur, avec les mêmes partis pris : des références vérifiées, et la distinction entre ce qui se déclare et ce qui se prouve.

• PSSI : structure, exemple et ce qu'un auditeur y cherche : le document de gouvernance par lequel tout commence, et les endroits où il sonne creux.
• Charte informatique : contenu, valeur juridique et plan : ce qui rend la sécurité opposable aux salariés, si elle a été adoptée dans les formes.
• RSSI : rôle, missions, rattachement et externalisation : la personne qui porte la boucle GRC, et pourquoi son rattachement à la DSI pose problème.
• ISO 27005 : la gestion des risques étape par étape : la méthode de risques compatible ISO 27001, et ce qui la distingue d'EBIOS RM.
• ISO 27002 : les 93 contrôles, thème par thème : le catalogue derrière l'Annexe A, et lesquels exigent une preuve technique.
• Certification HDS : ce que l'hébergeur garantit : le périmètre du certificat, et la part de sécurité qui reste chez le client de l'hébergeur.
• RGS : le référentiel général de sécurité et l'homologation : la mécanique d'homologation des téléservices publics, dossier par dossier.
• Plan de gestion de crise cyber : cellule, fiches réflexes et exercices, avec ce qu'un exercice révèle que le plan cachait.
• Plan de continuité d'activité (PCA) : BIA, RTO, RPO et structure d'un plan, à lire avec le plan de reprise d'activité face au rançongiciel.
• Assurance cyber : ce que l'assureur exige et exclut : le transfert de risque, ses conditions d'entrée et les clauses qui vident la garantie.
• TPRM : la gestion des risques tiers sous NIS2 et DORA : le registre des fournisseurs, les clauses et les preuves à leur demander.
• Authentification multifacteur (MFA) : la mesure (j) de l'article 21.2, ce que l'assureur en attend, ce qu'un attaquant contourne.
• Zero trust : par où commencer sans tout refaire : le modèle derrière beaucoup de mesures de contrôle d'accès, ramené à des décisions concrètes.

À retenir

• La GRC cybersécurité est une boucle : la direction cadre, l'analyse de risques choisit les mesures, les preuves alimentent l'audit, l'audit remonte des écarts. Un tableur tient les mesures, pas les retours de boucle.
• Un outil GRC mappe les référentiels, tient un dossier de mesures avec un propriétaire par ligne, attache des preuves datées, suit un plan d'action, rappelle les obligations périodiques et produit les livrables d'audit. Il ne vérifie rien lui-même.
• Une jauge "72 % conforme" additionne des cases déclaratives, sans pondération ni date. Seul le niveau constaté tient face à un auditeur pour les mesures de test et de gestion des vulnérabilités.
• NIS2 21.2 (e) et (f), ISO 27001 contrôles 8.8 et 8.29, DORA articles 24 à 27, PCI DSS 11.3 et 11.4 attendent un constat, et chaque constat doit repasser les mesures concernées en écart.
• En septembre 2026, la loi française de transposition de NIS2 n'est pas promulguée, mais le ReCyF de l'ANSSI, disponible depuis le 17 mars 2026, décrit déjà la cible. DORA s'applique depuis le 17 janvier 2025.
• Ordre de marche : textes opposables, un responsable, une analyse de risques courte, les premières preuves constatées sur l'exposition externe et les applications métier, puis seulement l'outil.

Si votre dossier est déjà rempli et qu'il lui manque le niveau constaté sur les mesures de test et de gestion des vulnérabilités, c'est ce qu'own2pwn produit : un volet technique d'audit NIS2 avec sa matrice de couverture, ou un pentest web à verser tel quel dans l'outil GRC que vous aurez choisi. Si vous n'en êtes pas là, commencez par l'auto-diagnostic NIS2 : dix mesures, quelques minutes, et une idée honnête de ce qui vous manque avant d'ouvrir un tableur.

Questions fréquentes sur la GRC en cybersécurité