GRC Ops : la GRC opérationnelle et continue

La GRC Ops (ou GRC opérationnelle) est une manière de conduire la gouvernance, la gestion des risques et la conformité comme une activité continue : les contrôles sont suivis toute l'année, les données sont partagées entre risques, conformité et tiers, les preuves sont collectées au fil de l'eau, les tâches répétitives sont automatisées et le pilotage repose sur des indicateurs à jour. Elle s'oppose à la GRC « par campagnes », où tout se joue quelques semaines avant l'audit annuel. Le terme est récent et n'est défini par aucune norme ; ses idées, elles, sont éprouvées, et NIS 2, DORA et ISO 27001 les rendent de plus en plus nécessaires.

La GRC (gouvernance, risques et conformité) rassemble trois activités que le RSSI connaît bien : fixer les règles (politique de sécurité, référentiels, rôles), analyser et traiter les risques, et vérifier que les exigences sont respectées, en interne comme chez les prestataires. Dans beaucoup d'organisations, ces activités vivent au rythme d'un calendrier : une analyse de risques tous les trois ans, une campagne de conformité par an, un audit de certification, puis une longue période où les tableurs ne bougent plus.

La GRC Ops change ce rythme. Nous la définissons ainsi : une GRC menée en continu, où chaque contrôle a un responsable, une fréquence et une preuve attendue, où risques, conformité et tiers partagent les mêmes données, et où les écarts déclenchent des actions suivies jusqu'à leur clôture, mesurées par des indicateurs à jour. Le suffixe « Ops », pour opérations, fait écho à DevOps et à DevSecOps : il désigne une activité intégrée au fonctionnement quotidien, plutôt qu'un projet ponctuel.

Les cinq composantes de la GRC opérationnelle

• Des contrôles suivis en continu : chaque mesure de sécurité est vérifiée à une fréquence adaptée à son risque, pas seulement l'année de l'audit.
• Des données uniques : un même référentiel d'exigences, un même inventaire d'actifs et de tiers, une même échelle de risque, partagés par toutes les équipes.
• Des preuves collectées au fil de l'eau : la preuve est produite au moment où le contrôle est réalisé, datée et rattachée à l'exigence, au lieu d'être recherchée dans l'urgence.
• L'automatisation des tâches répétitives : relances, consolidation, calcul des indicateurs et rapports se font sans recopie manuelle.
• Un pilotage par indicateurs : la direction suit quelques mesures qui disent si les contrôles tiennent, pas un empilement de documents.

GRC Ops, GRCOps, GRC en continu : un terme encore neuf

Soyons clairs : « GRC Ops » n'est ni une norme, ni une méthode publiée par l'ANSSI, ni une marque déposée par un organisme. En septembre 2026, le terme est très peu employé, en France comme ailleurs. Ce qui existe, en revanche, c'est un mouvement américain appelé GRC Engineering, des pratiques de surveillance continue des contrôles connues depuis plus de dix ans, et des textes européens qui demandent de vérifier l'efficacité des mesures dans la durée. La GRC Ops rassemble ces idées sous un nom simple, accessible à des équipes qui n'ont pas de développeurs. C'est le sens que nous lui donnons dans ce dossier.

La GRC Ops ne part pas de zéro. Elle s'appuie sur trois courants qui ont chacun fait leurs preuves.

La surveillance continue des contrôles

Dès septembre 2011, l'institut américain de normalisation NIST publiait le guide SP 800-137 sur la surveillance continue de la sécurité de l'information (Information Security Continuous Monitoring). L'idée : donner une visibilité permanente sur les actifs, les menaces et les vulnérabilités, et s'assurer en continu que les contrôles restent adaptés à la tolérance au risque de l'organisation. Dans le monde de l'audit, la même idée porte le nom de continuous control monitoring, la surveillance continue des contrôles.

DevSecOps

Les équipes de développement ont appris à intégrer la sécurité dans leurs chaînes de livraison : tests automatiques à chaque modification, analyse des dépendances, règles bloquantes. Le principe, souvent résumé par « décaler la sécurité vers la gauche », consiste à traiter un problème au moment où il apparaît plutôt qu'après coup. La GRC Ops applique ce réflexe aux exigences de conformité.

Le GRC Engineering

Depuis quelques années, et plus nettement depuis 2025, une communauté de praticiens américains défend l'idée que la GRC doit emprunter les méthodes du génie logiciel. Leur manifeste, publié sur grc.engineering par neuf auteurs, préfère notamment « l'automatisation tôt et souvent » aux processus manuels, et une assurance continue et approfondie à une surveillance périodique superficielle. En août 2025, un article du SANS Institute signé AJ Yawn décrivait le GRC Engineering comme l'usage du développement logiciel, de l'automatisation et du cloud pour rationaliser les processus de GRC. Côté administrations, le programme américain FedRAMP 20x, annoncé en mars 2025, teste des indicateurs de sécurité validés automatiquement pour remplacer une partie des évaluations annuelles statiques. Nous détaillons ce mouvement, ses outils et ses limites dans notre article GRC Engineering : ce que la tendance change pour les RSSI.

La GRC Ops en est la version opérationnelle, pensée pour le contexte français : elle garde l'objectif (une GRC continue, mesurable, fondée sur des preuves) sans exiger que chaque contrôle soit écrit en code.

Aucun texte n'emploie le mot « GRC Ops ». Mais tous ceux qui comptent pour un RSSI français demandent de vérifier que les mesures fonctionnent dans la durée, et pas seulement qu'elles existent sur le papier.

NIS 2 : évaluer l'efficacité des mesures

L'article 21 de la directive NIS 2 range, parmi les mesures minimales de gestion des risques, des politiques et des procédures pour évaluer l'efficacité des mesures de cybersécurité (point f). L'article 20 demande aux organes de direction d'approuver ces mesures et d'en superviser la mise en œuvre. Le règlement d'exécution 2024/2690, qui précise ces mesures pour certaines catégories d'entités du numérique (fournisseurs de cloud, de centres de données, de services gérés…), va plus loin : il exige un examen régulier du respect des politiques de sécurité, un système de remontée de la conformité vers la direction et un suivi « à intervalles planifiés » (point 2.2), ainsi qu'une procédure qui fixe quelles mesures surveiller, comment, quand et par qui (point 7).

En France, la loi de transposition n'est toujours pas adoptée à la date de cet article : le projet de loi qui la transpose attend toujours son examen à l'Assemblée nationale. L'ANSSI accompagne déjà les entités concernées. Le détail figure dans notre article De NIS à NIS 2.

DORA : surveiller en permanence et réexaminer chaque année

Pour les entités financières, le règlement DORA, applicable depuis le 17 janvier 2025, est explicite. L'article 9 leur demande de surveiller et de contrôler en permanence la sécurité et le fonctionnement de leurs systèmes et outils TIC. L'article 6 impose de documenter le cadre de gestion du risque lié aux TIC, de le réexaminer au moins une fois par an et après tout incident majeur, de l'améliorer en continu à partir des enseignements tirés, et de le soumettre régulièrement à l'audit interne. L'article 5 place la responsabilité finale de ce risque sur l'organe de direction.

ISO 27001 : la clause 9 et l'amélioration continue

La norme ISO/IEC 27001:2022 consacre sa clause 9 à l'évaluation des performances : surveillance, mesure, analyse et évaluation (9.1), audit interne (9.2) et revue de direction (9.3). La clause 10 exige l'amélioration continue du SMSI et le traitement des non-conformités. Un SMSI qui ne vit qu'au moment de l'audit de surveillance remplit ces clauses sur la forme, rarement sur le fond.

La différence ne tient pas aux référentiels, qui restent les mêmes, mais à la façon de les faire vivre. Le tableau ci-dessous compare les deux approches sur les points qui pèsent au quotidien.

La GRC Ops se résume en une boucle : un contrôle est réalisé, il produit une preuve, la preuve révèle éventuellement un écart, l'écart devient une action, et l'avancement nourrit un indicateur. Puis le contrôle suivant repart, sans attendre l'audit de l'année d'après.

1. Le contrôle plutôt que le questionnaire

Une exigence (« les comptes à privilèges sont revus ») ne suffit pas : il faut un contrôle qui dit qui le vérifie, comment, à quelle fréquence et avec quel résultat attendu. Un contrôle trimestriel effectivement réalisé vaut mieux qu'une réponse « conforme » donnée une fois par an.

2. Une seule source de données

Une même exigence sert souvent à plusieurs textes : la gestion des accès figure dans ISO 27001, NIS 2, DORA et votre PSSI. En reliant ces référentiels, un seul contrôle répond à plusieurs obligations, et une mesure décidée dans une analyse de risques se retrouve directement dans le plan d'action de conformité. C'est aussi ce qui permet de comparer une filiale, un site ou un prestataire avec la même grille.

3. La preuve au fil de l'eau

La preuve n'est pas un document qu'on fabrique pour l'auditeur ; c'est la trace normale du travail. Export d'une revue des droits, procès-verbal d'un test de restauration, compte rendu d'exercice de crise : chaque preuve est datée, rattachée à l'exigence qu'elle couvre et conservée avec son historique.

4. Automatiser ce qui se répète

Relancer les contributeurs, consolider les réponses de vingt sites, recalculer un taux de conformité, produire le rapport trimestriel : ces tâches ne demandent pas d'expertise et consomment pourtant une bonne partie du temps des équipes GRC. Les automatiser libère du temps pour l'analyse. L'automatisation ne décide pas à votre place : elle prépare, l'humain valide.

5. Piloter par indicateurs

Un bon indicateur dit si les mesures tiennent : part des contrôles à jour, âge des écarts, délai de correction. Il permet à la direction, à qui NIS 2 et DORA confient la responsabilité de la cybersécurité, de suivre la situation sans lire cent pages de rapport.

Comment passer concrètement de l'audit annuel à ce contrôle permanent, et quels contrôles automatiser en premier : c'est l'objet de notre article sur la conformité continue.

Les exemples ci-dessous sont des situations types, construites à partir des obligations de chaque secteur, pour montrer à quoi ressemble la GRC opérationnelle au quotidien.

Le RSSI d'un centre hospitalier

Il porte à la fois la sécurité du système d'information de santé, les exigences liées à l'hébergement de données de santé, les attentes des programmes nationaux de financement et, demain, celles de NIS 2. Seul ou presque, il ne peut pas mener une campagne complète par référentiel. En GRC Ops, il relie ces textes dans un référentiel commun, suit une vingtaine de contrôles prioritaires (sauvegardes déconnectées testées, comptes à privilèges revus, correctifs des équipements exposés, accès des prestataires de maintenance) et fait renseigner les preuves par les équipes qui réalisent le travail. Quand la direction ou l'agence régionale de santé demande où en est l'établissement, l'indicateur est déjà à jour. Voir aussi notre page cybersécurité santé.

Une collectivité territoriale

Une communauté d'agglomération doit tenir à jour l'homologation de ses téléservices, encadrer ses nombreux prestataires et se préparer à NIS 2. Ses services sont dispersés et la sécurité n'est le métier principal de personne. La GRC Ops lui permet de confier chaque contrôle à un responsable identifié dans chaque direction, de relancer automatiquement, et de suivre les prestataires critiques avec la même grille que les services internes. L'homologation cesse d'être un dossier refait tous les trois ans pour devenir un suivi continu des risques résiduels. Voir aussi notre page cybersécurité du secteur public.

Une ETI industrielle

Une entreprise de taille intermédiaire avec plusieurs sites et filiales reçoit des questionnaires de sécurité de ses grands clients, vise la certification ISO 27001 et pourrait entrer dans le champ de NIS 2. Plutôt que de répondre au cas par cas, elle mène une campagne de conformité sur ses sites à partir d'un référentiel unique, suit les écarts site par site et réutilise les mêmes preuves pour l'audit de certification et pour ses clients. La direction suit un tableau de bord trimestriel, comparable d'un site à l'autre.

Inutile de tout transformer d'un coup. Les organisations qui réussissent ce passage commencent petit, mesurent, puis élargissent.

1. Faire l'inventaire des obligations

Listez ce qui s'applique réellement à vous : NIS 2, DORA, RGPD, HDS, ISO 27001, exigences contractuelles de vos clients, votre PSSI. Rassemblez-les dans un référentiel commun et reliez les exigences qui se recoupent.

2. Choisir une dizaine de contrôles prioritaires

Partez de vos risques majeurs, issus de votre dernière analyse de risques ou de votre matrice des risques. Retenez les contrôles qui couvrent le plus de risques et d'exigences à la fois : sauvegardes, gestion des accès, correctifs, authentification multifacteur, prestataires critiques.

3. Définir pour chaque contrôle un responsable, une fréquence et une preuve

C'est l'étape qui fait toute la différence. « Revue trimestrielle des comptes à privilèges par l'administrateur système, preuve : export de la liste validée et daté » est un contrôle. « Les accès sont maîtrisés » n'en est pas un.

4. Outiller le cycle

Un tableur partagé peut suffire pour tester sur dix contrôles. Au-delà, il faut une plateforme GRC qui relie référentiels, contrôles, preuves, plans d'action et indicateurs, et qui relance à votre place. Les équipes qui ont des développeurs peuvent aussi automatiser certains contrôles techniques par des scripts, à la manière du GRC Engineering.

5. Traiter les écarts comme des actions

Chaque écart devient une action avec un responsable et une échéance, ou un risque accepté explicitement par la personne habilitée. Un écart sans suite n'a aucune valeur.

6. Mesurer, présenter, élargir

Après un trimestre, présentez les premiers indicateurs à la direction, ajustez les fréquences, puis ajoutez de nouveaux contrôles et de nouveaux périmètres. La méthode, les rôles et le comité de suivi sont détaillés dans notre article sur la gestion de la conformité.

Quelques indicateurs bien choisis suffisent. Ils doivent mesurer la tenue des mesures, pas le volume de documents produits.

Ces indicateurs n'ont de sens que suivis dans le temps : une tendance compte plus qu'une valeur isolée. Ils servent aussi de base au réexamen annuel exigé par DORA et à la revue de direction d'ISO 27001.

• « Tout peut être automatisé. » Non. Une configuration technique se vérifie automatiquement ; la pertinence d'une politique, la qualité d'une analyse de risques ou la décision d'accepter un risque restent humaines.
• « Un outil suffit. » Un outil sans contrôles bien définis ne fait qu'automatiser le désordre. La méthode d'abord, l'outil ensuite.
• « Le continu remplace l'audit. » Non : l'audit interne et l'audit de certification restent exigés par ISO 27001 et DORA. La GRC Ops les rend plus simples, car les preuves sont déjà là.
• « Plus de contrôles, c'est mieux. » Un contrôle mal choisi coûte du temps sans réduire de risque. Le choix part de l'analyse de risques.
• « L'IA fera le travail. » Elle peut accélérer la lecture des preuves ou la rédaction, à condition que chaque proposition soit validée par une personne. Nous examinons ce qu'elle apporte et ses limites dans notre article IA et GRC.

Phinasoft est un logiciel GRC français, conçu pour la cybersécurité. Il se place sur la partie pilotage de la boucle GRC Ops : référentiels, évaluations, preuves, plans d'action et indicateurs. Ses cinq modules partagent les mêmes données : une mesure décidée dans une analyse de risques se retrouve dans le plan d'action, et une exigence de votre PSSI sert à évaluer une filiale comme un prestataire.

• Un référentiel commun : un catalogue de plus de vingt référentiels (ISO 27001/2, NIS 2, DORA, RGPD, IGI 1300…) et votre PSSI, versionnés et reliés entre eux dans l'éditeur de politiques, avec les preuves attendues pour chaque exigence.
• Des campagnes suivies dans le temps : les campagnes de conformité recueillent niveaux de conformité, justifications et preuves, avec suivi de l'avancement et relances, et montrent l'évolution d'un périmètre d'une campagne à l'autre.
• Des tiers dans la même boucle : le portail d'évaluation des prestataires applique les mêmes exigences à vos fournisseurs.
• Des actions et des indicateurs sans recopie : plans d'action consolidés que chaque responsable met à jour lui-même, notifications de relance, indicateurs calculés automatiquement et tableaux de bord personnalisés.
• Une IA qui prépare, vous qui validez : l'IA intégrée analyse vos documents, répartit les preuves sur les bonnes exigences et propose une première évaluation ; chaque proposition passe par une validation explicite.

Pour voir comment ce cycle s'applique à vos propres référentiels, réservez une démonstration.