Le Référentiel Cyber France, ou ReCyF, aide les organisations françaises à traduire les objectifs de sécurité de NIS2 en mesures plus opérationnelles.
Mais une fois le référentiel lu, une question reste entière :
Quelles preuves faut-il réellement présenter pour démontrer que les mesures sont appliquées ?
Une politique de sécurité ne suffit pas toujours. Elle décrit ce que l’organisation prévoit de faire, mais ne prouve pas nécessairement que les mesures sont mises en œuvre, suivies et maintenues.
Pour préparer une conformité ReCyF défendable, il faut généralement réunir plusieurs niveaux de preuve :
L’objectif n’est pas d’accumuler des documents. Il est de pouvoir relier chaque objectif ReCyF à des éléments récents, contextualisés et vérifiables.
Non.
La version 2.5 du ReCyF, publiée comme document de travail le 17 mars 2026, présente vingt objectifs de sécurité et des moyens acceptables de conformité proposés par l’ANSSI.
Elle ne fournit pas, pour chaque mesure, une liste exhaustive de documents à produire.
Une organisation peut donc utiliser différentes preuves selon :
La bonne preuve n’est pas nécessairement un document formel. Il peut aussi s’agir d’un export, d’un journal, d’un ticket, d’un rapport de test, d’une configuration ou d’un compte rendu de décision.
Une preuve utile doit répondre à plusieurs questions.
Elle doit être rattachée à une mesure précise. Une politique générale de cybersécurité ne peut pas prouver à elle seule que les sauvegardes sont testées ou que les comptes sont régulièrement revus.
La preuve doit préciser les systèmes, entités, sites, applications ou populations concernés.
Une preuve trop ancienne peut ne plus représenter la situation actuelle.
Son propriétaire et, lorsque cela est pertinent, son approbateur doivent être identifiables.
Elle doit permettre de distinguer une mesure réellement appliquée d’une simple intention.
Une preuve peut être valable tout en montrant une couverture partielle. L’écart doit alors être documenté et suivi.
Pour chaque objectif, une organisation peut rechercher quatre catégories complémentaires.
| Niveau | Ce qu’il démontre | Exemples |
| Gouvernance | La règle et les responsabilités sont définies | Politique, procédure, RACI, décision |
| Mise en œuvre | La mesure est effectivement déployée | Configuration, inventaire, contrat, export |
| Contrôle | Son application est vérifiée | Revue, audit, test, journal |
| Amélioration | Les écarts sont traités | Plan d’action, ticket, arbitrage, réévaluation |
Une politique accompagnée d’une preuve de mise en œuvre et d’une revue récente sera toujours plus crédible qu’un document isolé.
Les objectifs 1 à 15 concernent, dans la version de travail actuelle, les entités importantes et les entités essentielles. Les objectifs 16 à 20 prévoient des attentes supplémentaires pour les entités essentielles.
Les exemples ci-dessous constituent une grille de préparation. Ils doivent être adaptés aux mesures applicables et au périmètre réel de l’organisation.
L’organisation doit connaître les activités et services concernés, ainsi que les systèmes d’information qui les supportent.
L’inventaire est suffisamment complet, attribué à des responsables et actualisé après les changements significatifs.
Cet objectif couvre la responsabilité de la direction, les rôles, les politiques, la gestion de la conformité et le suivi des actions.
Le ReCyF prévoit explicitement une analyse de conformité par système d’information et un plan d’action suivi dans la durée. Un fichier évaluant les mesures sans responsable ni échéance restera insuffisant.
L’organisation doit maîtriser les risques associés à ses prestataires, fournisseurs et partenaires.
Les fournisseurs les plus sensibles sont connus, évalués avant ou pendant la relation, et suivis selon leur niveau de risque.
Cet objectif couvre les arrivées, mobilités, départs, engagements de confidentialité et formations adaptées.
Une procédure RH n’est pas suffisante sans traces montrant qu’elle est appliquée sur des cas réels.
L’organisation doit maîtriser les ressources de ses systèmes, leur cycle de vie, leur maintenance et les versions utilisées.
L’organisation sait quels systèmes sont supportés, lesquels sont obsolètes et comment les risques associés sont traités.
Cet objectif concerne la protection des locaux, salles techniques et équipements sensibles.
La liste des badges actifs doit pouvoir être rapprochée des collaborateurs et prestataires réellement autorisés.
L’objectif vise notamment le cloisonnement, le filtrage, la protection des flux et la maîtrise de l’architecture.
Les flux autorisés correspondent aux besoins réels, les zones sont correctement séparées et les règles sont régulièrement revues.
L’organisation doit maîtriser les accès externes au système d’information.
Une licence MFA ne démontre pas que l’authentification forte est effectivement imposée à l’ensemble du périmètre concerné.
Cet objectif couvre la prévention, la détection et le traitement des logiciels malveillants.
Les outils sont réellement déployés, supervisés et associés à une procédure de réaction.
L’organisation doit maîtriser la création, l’attribution, la modification, la revue et la suppression des droits.
La preuve la plus forte n’est pas seulement la procédure : c’est la trace d’une revue récente, avec les écarts détectés et corrigés.
L’objectif vise les comptes, postes, flux et pratiques d’administration.
Les privilèges sont nominatifs, limités, protégés, traçables et régulièrement contrôlés.
L’organisation doit savoir détecter, qualifier, traiter, documenter et signaler les incidents.
Le ReCyF mentionne explicitement la conservation de relevés techniques. L’organisation doit s’assurer qu’ils restent disponibles même si l’incident affecte le système qui les produit.
Cet objectif couvre les sauvegardes, la restauration, la continuité et la reprise des systèmes importants.
Les sauvegardes existent, sont protégées et peuvent effectivement être restaurées dans des conditions compatibles avec les besoins métiers.
L’organisation doit être capable de coordonner une crise dépassant le traitement technique courant d’un incident.
La gestion de crise doit prévoir l’indisponibilité possible des moyens habituels de communication et des outils internes.
L’organisation doit vérifier que ses dispositifs fonctionnent et que les personnes savent les utiliser.
Les exercices produisent des enseignements concrets et les améliorations décidées sont suivies dans le temps.
Les entités essentielles doivent structurer une analyse de risques adaptée à leurs systèmes d’information.
Une analyse de risques n’est pas un document figé. Elle doit évoluer avec le contexte technique, métier et organisationnel.
Les entités essentielles doivent programmer des audits réguliers et planifiés.
Les audits couvrent progressivement les systèmes selon leur criticité et débouchent sur des remédiations réellement suivies.
L’objectif vise la réduction de la surface d’attaque et le maintien de configurations sécurisées.
Le ReCyF recommande une revue annuelle des configurations pour vérifier l’application des mesures de sécurisation.
Les entités essentielles doivent renforcer la séparation et la protection des activités d’administration.
Les opérations sensibles ne sont pas réalisées depuis des postes bureautiques ordinaires sans protections et séparation adaptées.
L’entité essentielle doit collecter, analyser et exploiter les événements nécessaires à la détection des activités malveillantes.
La présence d’un SIEM ou d’un prestataire SOC ne suffit pas. Il faut pouvoir démontrer que les alertes pertinentes sont effectivement analysées et traitées.
| Objectif ReCyF | Preuves principales |
| 1. Recensement des SI | Inventaire, cartographie, périmètre, responsables |
| 2. Gouvernance | PSSI, RACI, comités, analyse de conformité, plan d’action |
| 3. Écosystème | Registre fournisseurs, évaluations, contrats, revues |
| 4. Ressources humaines | Procédures RH, habilitations, formations, départs |
| 5. Maîtrise des SI | Inventaire technique, correctifs, versions, obsolescence |
| 6. Accès physiques | Badges, autorisations, journaux, revues |
| 7. Architecture | Schémas, matrices de flux, filtrage, tests |
| 8. Accès distants | VPN, MFA, utilisateurs autorisés, journaux |
| 9. Codes malveillants | Couverture EDR, alertes, traitement |
| 10. Identités et accès | Comptes, droits, revues, MFA, corrections |
| 11. Administration | Comptes privilégiés, journaux, PAM, revues |
| 12. Incidents | Procédure, registre, chronologie, rapports, REX |
| 13. Continuité | Sauvegardes, restaurations, PRA, tests |
| 14. Crise cyber | Plan de crise, annuaire, communications, exercices |
| 15. Exercices | Programme, scénarios, comptes rendus, améliorations |
| 16. Risques | Méthode, analyses, risques résiduels, décisions |
| 17. Audits | Programme, rapports, constats, remédiations |
| 18. Configurations | Standards, scans, revues, exceptions |
| 19. Administration dédiée | Postes dédiés, architecture, filtrage, journaux |
| 20. Supervision | Sources, règles, alertes, investigations, couverture |
Toutes les preuves ne vieillissent pas à la même vitesse.
Elles doivent néanmoins être revues après une évolution majeure ou selon une fréquence définie.
Elles doivent comporter une date de prochaine revue.
Ces éléments doivent être actualisés beaucoup plus régulièrement.
Une bonne gestion des preuves doit donc enregistrer :
La préparation peut suivre une méthode simple.
Identifiez les systèmes et activités concernés, ainsi que le statut EI ou EE envisagé.
Toutes les mesures ne produisent pas nécessairement les mêmes attentes selon la catégorie d’entité.
Une mesure sans preuve doit être considérée comme déclarative ou à confirmer.
Contrôlez sa date, son périmètre, son propriétaire et ce qu’elle démontre réellement.
Si l’organisation ne suit pas un moyen acceptable de conformité du ReCyF, elle doit expliquer la solution retenue et la manière dont elle atteint l’objectif.
Une preuve partielle ne doit pas être masquée. Elle doit conduire à une action, un responsable et une échéance.
Gardez les versions précédentes, les décisions et les preuves de correction pour démontrer la progression.
Un dossier contenant cent fichiers ne constitue pas une démonstration structurée.
Les politiques montrent l’intention. Les journaux, rapports, tests et revues montrent l’exécution.
Une configuration couvrant le siège ne prouve pas que les filiales ou environnements cloud sont également couverts.
Une preuve sans date ne permet pas de juger sa fraîcheur.
Un EDR installé ne prouve pas que les alertes sont analysées. Une sauvegarde exécutée ne prouve pas qu’elle peut être restaurée.
Une tâche marquée « terminée » doit être associée au résultat obtenu.
Les reports, acceptations de risques et arbitrages budgétaires doivent rester traçables.
Le principal défi n’est pas seulement de produire les preuves. Il est de les relier aux bonnes mesures et de les maintenir dans le temps.
CompliKey permet notamment de :
CompliKey ne remplace pas les outils techniques qui génèrent les journaux, les rapports de vulnérabilités ou les sauvegardes. Les preuves peuvent être référencées par des liens vers les espaces où elles sont conservées.
L’objectif est de disposer d’une vue claire :
objectif ReCyF → mesure → état de maîtrise → preuve → écart → action
Cette organisation facilite les audits, les revues internes et la préparation d’un éventuel contrôle NIS2.
Une preuve ReCyF ne se limite pas à une politique ou à une déclaration.
Pour chaque objectif, l’organisation doit idéalement pouvoir présenter :
Les preuves peuvent prendre de nombreuses formes :
La meilleure preuve est celle qui est récente, contextualisée, rattachée à une mesure précise et capable de démontrer une application réelle.
Le ReCyF ne fixe pas une liste fermée. Les preuves peuvent inclure des politiques, inventaires, configurations, journaux, rapports de test, comptes rendus, tickets et décisions, selon la mesure concernée.
Rarement à elle seule. Elle doit généralement être complétée par des preuves de mise en œuvre, de contrôle et de traitement des écarts.
Toute mesure déclarée mise en œuvre devrait être soutenue par un ou plusieurs éléments vérifiables. Les mesures non applicables ou alternatives doivent être justifiées.
Cela dépend de sa nature. Une politique peut rester valable plus longtemps qu’un export de comptes ou un rapport de vulnérabilités. Chaque preuve devrait avoir une date de revue adaptée.
Dans la version 2.5 du ReCyF, ces objectifs complémentaires sont prévus pour les entités essentielles. Les objectifs 1 à 15 concernent les entités importantes et essentielles.
Oui, si leur contenu, leur date et leur périmètre couvrent réellement la mesure ReCyF. Une correspondance entre référentiels ne garantit pas automatiquement que la preuve est suffisante.
Il faut documenter la mesure retenue, justifier son efficacité au regard de l’objectif de sécurité et conserver les preuves permettant de vérifier sa mise en œuvre.
La préparation au ReCyF ne doit pas se transformer en collecte massive de documents.
Le vrai objectif est de construire une démonstration cohérente :
objectif → mesure appliquée → preuve récente → contrôle → écart → remédiation
Cette logique permet de répondre à la question centrale d’un audit NIS2 :
Pouvez-vous démontrer que vos mesures existent, fonctionnent et sont maintenues dans le temps ?
Les organisations qui structurent dès maintenant leurs preuves gagneront en efficacité lors des audits, mais aussi dans leur pilotage quotidien. Elles sauront plus facilement ce qui est réellement maîtrisé, ce qui reste déclaratif et ce qui doit encore être corrigé.
