ReCyF : comment transformer une exigence ANSSI en tâche, preuve et indicateur ?

Une exigence ReCyF ne devrait pas devenir directement une case « fait / pas fait » dans un tableur. Le référentiel décrit un résultat de sécurité attendu ; l’organisation doit ensuite déterminer les mesures concrètes permettant de l’atteindre, les actions nécessaires, les responsables, les preuves qui permettront de démontrer son application et les indicateurs utiles pour vérifier qu’elle reste maîtrisée.

Une méthode opérationnelle consiste à suivre cette chaîne :

exigence → mesure → sous-actions → responsable → preuve → maturité → KPI

Par exemple, l’exigence ReCyF 13.2-EI/EE demande de tester au minimum une fois par an les processus de sauvegarde et de restauration. Cela ne devient réellement pilotable qu’après avoir défini les systèmes à tester, planifié les tests, attribué leur réalisation, conservé leurs résultats et suivi leur couverture dans le temps.

Que contient réellement le ReCyF ?

Depuis le 17 mars 2026, l’ANSSI met à disposition le Référentiel Cyber France - ReCyF, qui liste les mesures qu’elle recommande pour atteindre les objectifs de sécurité fixés par NIS2. À ce jour, le ReCyF est toujours présenté par l’ANSSI comme un document de travail dans le contexte de la transposition française.

Le référentiel ne se limite pas à une liste abstraite de thèmes.

Il organise notamment :

1. des objectifs de sécurité ;
2. des moyens acceptables de conformité ;
3. des exigences identifiées individuellement ;
4. leur applicabilité aux entités importantes ou essentielles.

Un identifiant comme :

13.2-EI/EE

permet par exemple de comprendre que la mesure relève de l’objectif 13 consacré à la continuité et à la reprise d’activité et qu’elle est attendue pour les entités importantes comme essentielles.

Depuis mars 2026, l’ANSSI propose également sur MesServicesCyber un comparateur permettant notamment de rapprocher les exigences ReCyF :

1. de référentiels ISO 2700X ;
2. de l’annexe au règlement d’exécution (UE) 2024/2690.

L’objectif annoncé est de faciliter l’appropriation de ReCyF par les organisations déjà engagées dans d’autres démarches de sécurisation.

Et depuis le 7 septembre 2026, l’ANSSI publie également une collection de fiches « ReCyF en pratique », destinée à éclairer la mise en œuvre des principales mesures de gestion des risques. Ces fiches sont organisées autour de cinq rubriques : Défense, Protection, Gouvernance, Résilience et Obligations NIS2.

Le mouvement est donc clair :

le référentiel dit ce qui est attendu ; il reste ensuite à organiser sa mise en œuvre dans l’organisation.

Une exigence ReCyF n’est pas une tâche

C’est probablement la distinction la plus importante.

Prenons :

13.2-EI/EE - l’entité s’assure que les processus de sauvegarde et de restauration sont testés au minimum une fois par an.

L’objectif est également de vérifier la bonne réalisation des sauvegardes et leur capacité de restauration.

Créer directement une tâche :

Tester les sauvegardes

est insuffisant.

Pourquoi ?

Parce que cette ligne ne précise pas :

1. quelles sauvegardes ;
2. quels systèmes ;
3. quel type de test ;
4. selon quelle fréquence ;
5. qui le réalise ;
6. ce qui constitue un succès ;
7. où conserver le résultat ;
8. comment traiter un échec ;
9. comment vérifier la couverture du périmètre.

L’exigence décrit l’état attendu.

Le plan d’action doit décrire comment l’atteindre.

La chaîne complète : exigence → mesure → actions → preuve → KPI

Voici le modèle général.

Cette structure peut être appliquée à la plupart des exigences organisationnelles ou techniques du ReCyF.

Exemple complet avec l’exigence ReCyF 13.2-EI/EE

Partons maintenant d’une seule exigence et transformons-la en dispositif réellement exploitable.

1. Exigence ReCyF

L’objectif 13 porte sur la continuité et la reprise d’activité.

La mesure 13.2-EI/EE prévoit que l’organisation s’assure que ses processus de sauvegarde et de restauration sont testés au minimum une fois par an, notamment afin de vérifier la bonne réalisation des sauvegardes et leur restauration.

L’exigence s’applique dans le ReCyF 2.5 aussi bien aux EI qu’aux EE.

2. Transformer l’exigence en mesure

Une formulation exploitable de la mesure pourrait être :

Tester périodiquement la capacité de restauration des sauvegardes couvrant les systèmes et données du périmètre.

La mesure est volontairement différente d’une tâche.

Elle décrit un contrôle qui doit continuer à exister dans le temps.

Une tâche possède une date de fin.

Une mesure doit rester maintenue.

Mauvaise modélisation

Mesure :

Faire un test de sauvegarde avant décembre.

Une fois la tâche clôturée, la mesure semble terminée.

Meilleure modélisation

Mesure :

Maintenir un processus de tests périodiques de sauvegarde et de restauration.

Puis :

Tâche :

Réaliser le test de restauration 2026.

L’année suivante, une nouvelle occurrence est créée sans reconstruire la mesure.

3. Décomposer la mesure en sous-actions

Une exigence relativement courte peut nécessiter plusieurs actions.

Pour 13.2-EI/EE, une organisation pourrait utiliser la séquence suivante.

Cette décomposition n’est pas imposée telle quelle par le ReCyF.

Elle transforme simplement l’objectif du référentiel en processus opérationnel.

L’ANSSI recommande plus largement que les sauvegardes soient testées régulièrement et qu’une procédure de restauration du SI soit rédigée et effectivement mise en œuvre.

4. Attribuer un responsable

Une exigence sans propriétaire devient facilement :

« sujet sécurité ».

Le responsable doit être la personne ou la fonction qui répond du maintien de la mesure.

Dans notre exemple :

Responsable de la mesure : responsable infrastructure

Contributeur : prestataire de sauvegarde

Validation du test : RSSI ou responsable sécurité

Sponsor en cas de blocage : DSI

Il est utile de distinguer :

Responsable de la mesure

Il garantit que le contrôle existe dans le temps.

Responsable d’une tâche

Il réalise une action particulière.

Valideur

Il vérifie que le résultat peut être accepté.

Ces rôles peuvent parfois être tenus par la même personne dans une petite PME.

Ils doivent néanmoins rester conceptuellement distincts.

5. Définir les preuves avant de lancer l’action

La question essentielle est :

Qu’est-ce qui permettra, lors du prochain audit, de démontrer que l’exigence a été réellement appliquée ?

Pour notre exemple, une politique de sauvegarde ne suffit pas.

Elle démontre que le processus est prévu.

L’exigence 13.2 porte sur le test effectif des processus de sauvegarde et de restauration.

Preuves possibles

Une preuve de qualité doit toujours rester reliée à ce qu’elle permet réellement de conclure.

Exemple de preuve solide

Rapport de test de restauration ERP - 17 juin 2026 - sauvegarde du 16 juin restaurée dans un environnement isolé - intégrité vérifiée - durée : 2 h 14 - une anomalie détectée et ticketée sous INC-247.

Cette preuve est beaucoup plus exploitable que :

capture_backup.png

6. Ajouter un score de maturité sans l’appeler « score ReCyF »

Le ReCyF ne fournit pas, dans sa version 2.5, une échelle officielle de maturité 0 à 4 ou 1 à 5 pour chacune de ses exigences.

Il faut donc éviter d’écrire :

« Maturité ReCyF officielle : 3/4 »

si ce barème provient de votre propre méthode.

Une organisation peut néanmoins ajouter un indicateur de maturité pour suivre la progression de la mesure.

Exemple de grille interne

Cette grille est un outil de pilotage interne.

Elle ne modifie pas le contenu de l’exigence ANSSI.

Pourquoi conserver cette distinction ?

Parce qu’une organisation peut être :

conforme à l’exigence

mais posséder un processus encore relativement peu mature.

Exemple :

un test annuel a bien été effectué et démontre la capacité de restauration.

L’exigence est satisfaite.

Mais :

1. le périmètre est préparé manuellement ;
2. les résultats sont peu exploités ;
3. les anomalies ne sont pas analysées dans le temps.

Le score de maturité peut alors aider à poursuivre l’amélioration sans inventer une nouvelle non-conformité.

7. Ajouter des KPI réellement utiles

Une mesure ne doit pas nécessairement posséder dix indicateurs.

Un bon KPI doit permettre de détecter :

1. une dérive ;
2. un défaut de couverture ;
3. un retard ;
4. une dégradation du résultat.

Pour notre exigence de sauvegarde, plusieurs indicateurs sont possibles.

Exemple

L’organisation possède dix systèmes considérés comme critiques.

Huit ont fait l’objet du test prévu.

Couverture = 8 / 10 = 80 %.

Deux systèmes restent donc à examiner.

L’indicateur permet immédiatement de détecter une faiblesse que le simple statut :

« test de restauration réalisé »

aurait masquée.

KPI, preuve et maturité ne répondent pas à la même question

C’est une distinction particulièrement utile.

Prenons :

Preuve

Rapport de test du 17 juin.

Maturité

3/4 - processus planifié et contrôlé.

KPI

80 % des systèmes critiques testés dans les douze derniers mois.

Les trois informations sont complémentaires.

Aucune ne remplace les deux autres.

Le modèle complet : d’une exigence ReCyF à une mesure pilotable

Voici une fiche directement réutilisable.

Cette fiche constitue une véritable unité de pilotage GRC.

Toutes les exigences ReCyF doivent-elles devenir autant de tâches ?

Non.

C’est précisément l’un des pièges à éviter.

Un référentiel peut contenir plusieurs exigences qui dépendent du même chantier.

Prenons par exemple les mesures de sauvegarde de l’objectif 13.

Le ReCyF prévoit notamment :

1. 13.1-EI/EE : procédures de sauvegarde et restauration ;
2. 13.2-EI/EE : tests au minimum annuels ;
3. 13.3-EI/EE : protection des sauvegardes contre un incident les rendant inutilisables ;
4. 13.5-EI/EE : dimensionnement des mécanismes selon les besoins de disponibilité.

Il serait artificiel de créer quatre projets totalement indépendants.

Une PME peut plutôt construire un chantier :

Sécuriser le dispositif de sauvegarde

Lot 1 - Gouvernance

1. définir le périmètre ;
2. formaliser la politique ;
3. attribuer les responsabilités.

Lot 2 - Architecture

1. définir les mécanismes ;
2. protéger les sauvegardes ;
3. isoler les copies nécessaires.

Lot 3 - Exploitation

1. superviser les sauvegardes ;
2. traiter les échecs.

Lot 4 - Tests

1. réaliser les restaurations ;
2. documenter les résultats.

Chaque action reste liée aux exigences qu’elle contribue à satisfaire.

On évite ainsi :

1 exigence = 1 tâche

tout en conservant la traçabilité réglementaire.

À l’inverse, une exigence peut nécessiter plusieurs tâches

C’est l’autre erreur classique.

Une exigence comme :

« tester les processus de sauvegarde et de restauration »

ne se résume pas toujours à :

« faire un test ».

Pour une organisation qui ne possède encore aucune démarche structurée, il peut être nécessaire de :

1. inventorier les systèmes ;
2. définir la criticité ;
3. identifier les sauvegardes existantes ;
4. définir le scénario ;
5. construire l’environnement de restauration ;
6. effectuer le test ;
7. traiter les anomalies ;
8. définir le calendrier futur.

Une seule exigence ReCyF peut donc générer plusieurs sous-actions.

Comment utiliser le comparateur ReCyF sans créer de faux raccourcis ?

Le comparateur publié par l’ANSSI permet de rapprocher les exigences ReCyF d’autres cadres, notamment ISO 2700X et l’annexe au règlement d’exécution (UE) 2024/2690.

C’est extrêmement utile pour éviter de reconstruire une démarche déjà existante.

Mais il faut éviter une conclusion trop rapide :

« Nous appliquons ISO 27001, donc toutes les exigences ReCyF correspondantes sont déjà satisfaites. »

Une correspondance entre référentiels signifie avant tout :

ces exigences traitent de sujets suffisamment proches pour être comparées.

Elle ne démontre pas automatiquement que :

1. les périmètres sont identiques ;
2. la profondeur attendue est la même ;
3. les fréquences sont identiques ;
4. la preuve disponible satisfait les deux cadres ;
5. tous les détails de l’exigence sont couverts.

Bonne utilisation du comparateur

Pour chaque correspondance :

1. Identifier le contrôle déjà existant.

2. Examiner les exigences ReCyF correspondantes.

3. Comparer les périmètres et résultats attendus.

4. Réutiliser les actions et preuves communes.

5. Créer uniquement les compléments nécessaires.

La mutualisation doit se faire au niveau des mesures et des preuves, pas en déclarant artificiellement une conformité équivalente.

Une même preuve peut-elle servir à plusieurs référentiels ?

Oui, et c’est même l’un des principaux avantages d’un pilotage multi-référentiels correctement structuré.

Exemple :

un rapport de test de restauration peut contribuer à démontrer :

1. une exigence ReCyF ;
2. un contrôle ISO/IEC 27001 associé à la continuité ;
3. une exigence interne ;
4. éventuellement une autre obligation réglementaire applicable.

Il serait inutile de dupliquer quatre fois le même fichier.

La bonne architecture devient :

une preuve → plusieurs mesures correspondantes

à condition d’indiquer clairement ce que la preuve démontre pour chacune.

Attention

Une preuve commune ne signifie pas nécessairement que tous les contrôles sont satisfaits.

Elle peut couvrir :

1. entièrement une exigence ;
2. partiellement une autre.

L’évaluation doit rester distincte.

Comment choisir le bon responsable pour une mesure ReCyF ?

Le RSSI ne doit pas devenir propriétaire de l’intégralité du ReCyF.

Selon les mesures, les responsables pourront être :

Le RSSI ou le consultant peut :

1. structurer le référentiel ;
2. coordonner l’évaluation ;
3. suivre les échéances ;
4. challenger les preuves ;
5. consolider les résultats.

Mais la mise en œuvre doit rester distribuée dans l’organisation.

Comment construire un plan d’action ReCyF cohérent ?

Une bonne feuille de route ne classe pas automatiquement les exigences de 1.1 à 21.x.

Elle regroupe les actions selon les chantiers réellement nécessaires.

Exemple

Chantier 1 - Gouvernance

1. responsabilités ;
2. politiques ;
3. risques ;
4. décisions.

Chantier 2 - Identités et accès

1. comptes ;
2. MFA ;
3. privilèges ;
4. revues.

Chantier 3 - Résilience

1. sauvegardes ;
2. restauration ;
3. continuité ;
4. crise.

Chantier 4 - Écosystème

1. fournisseurs ;
2. exigences contractuelles ;
3. contrôles.

Chantier 5 - Détection et réponse

1. journalisation ;
2. supervision ;
3. incidents.

Chaque action conserve ensuite ses liens avec les mesures ReCyF auxquelles elle contribue.

On obtient ainsi à la fois :

une feuille de route lisible pour la direction

et

une traçabilité précise pour l’audit.

Comment mesurer la maturité sans déformer ReCyF ?

Le score doit rester séparé du référentiel.

Une approche robuste consiste à évaluer quatre dimensions.

1. Effectivité

La mesure existe-t-elle réellement ?

2. Preuves

Peut-on démontrer sa mise en œuvre ?

3. Pilotage

Est-elle suivie avec des responsabilités et des contrôles ?

4. Pérennité

Le dispositif peut-il continuer à fonctionner sans dépendre d’une action ponctuelle ?

Une organisation peut alors construire sa propre échelle.

Exemple

Cette notation peut être utile pour :

1. comparer deux audits ;
2. mesurer la progression ;
3. construire une trajectoire cible ;
4. prioriser certains sujets.

Elle ne doit jamais être présentée comme une note officielle de l’ANSSI.

Comment construire de bons KPI ReCyF ?

L’erreur consiste à ajouter un indicateur à toutes les exigences simplement parce qu’un champ « KPI » existe.

Certains contrôles n’en nécessitent aucun.

Un KPI est pertinent lorsqu’il aide réellement à prendre une décision.

Quatre familles sont généralement suffisantes

Couverture

Quelle part du périmètre est effectivement couverte ?

Exemple :

98 % des comptes privilégiés protégés par MFA.

Respect de la fréquence

Les activités prévues sont-elles réalisées dans les délais ?

Exemple :

4 revues des habilitations réalisées sur 4 prévues.

Résultat

Le contrôle produit-il le résultat attendu ?

Exemple :

93 % des tests de restauration réussis sans anomalie majeure.

Remédiation

Les problèmes détectés sont-ils effectivement corrigés ?

Exemple :

2 anomalies de sauvegarde ouvertes, dont 1 hors délai.

Cette logique transforme la conformité en pilotage.

Quelle différence entre un KPI et une preuve ?

Prenons une revue trimestrielle des accès.

Preuve

Compte rendu de la revue du troisième trimestre.

Elle démontre qu’une activité a eu lieu.

KPI

100 % des comptes privilégiés ont été examinés ; 6 anomalies détectées ; 5 corrigées dans le délai défini.

Il synthétise le résultat.

Le KPI ne remplace pas la preuve.

Une valeur :

100 %

sans population, source ou élément vérifiable ne permet pas à elle seule de démontrer la conformité.

Inversement, conserver cinquante rapports sans indicateur peut rendre le pilotage inutilement difficile.

Comment passer d’une exigence ReCyF à un dashboard de direction ?

La direction n’a pas besoin de consulter chaque identifiant du référentiel.

Le travail consiste à agréger progressivement les données.

Exigence

→ 13.2-EI/EE

Mesure

→ programme de tests de restauration

KPI opérationnel

→ couverture des tests : 80 %

Risque

→ deux applications critiques encore non testées

Action

→ tests programmés pour octobre

Dashboard direction

→ Résilience : attention - couverture restauration incomplète

Le dashboard ne remplace pas la traçabilité détaillée.

Il en constitue la synthèse.

Exemple de deuxième chaîne : gestion d’un fournisseur

Le même modèle peut être appliqué à l’écosystème.

Le ReCyF 3.B.2-EI/EE prévoit que l’entité vérifie périodiquement la conformité de la prestation informatique aux obligations auxquelles elle est assujettie.

Exigence

Vérifier périodiquement la conformité des prestations.

Mesure

Maintenir un processus de revue des fournisseurs informatiques critiques.

Sous-actions

1. identifier les fournisseurs concernés ;
2. définir leur criticité ;
3. définir les contrôles attendus ;
4. collecter les éléments ;
5. réaliser la revue ;
6. enregistrer les écarts ;
7. suivre les actions.

Responsable

Responsable achats ou DSI selon l’organisation.

Preuves

1. évaluation fournisseur ;
2. compte rendu de revue ;
3. clauses contractuelles ;
4. attestations ;
5. rapports d’audit selon le cas.

Maturité

1 : contrôles ponctuels

2 : processus défini

3 : revues périodiques et écarts suivis

4 : dispositif piloté et adapté au risque

Barème interne, non ANSSI.

KPI

1. % des fournisseurs critiques revus dans les délais ;
2. nombre d’écarts critiques ouverts ;
3. fournisseurs sans preuve à jour.

La logique reste exactement la même.

Les erreurs fréquentes lors de l’opérationnalisation du ReCyF

Transformer chaque exigence en tâche

Une mesure récurrente ne doit pas disparaître une fois la première action clôturée.

Séparez le contrôle permanent des tâches de mise en œuvre.

Copier le texte ReCyF dans une colonne « action »

Le responsable ne saura toujours pas concrètement quoi faire.

Décomposez le résultat attendu.

Créer trop de tâches

Plusieurs exigences peuvent dépendre d’un même chantier.

Mutualisez les actions lorsque c’est pertinent.

Donner toutes les actions au RSSI

Le RSSI coordonne.

Les responsables opérationnels doivent porter les mesures relevant de leur périmètre.

Collecter des preuves sans les rattacher

Un dossier contenant 150 documents n’est pas un système de conformité.

Chaque preuve doit contribuer à démontrer une ou plusieurs mesures précises.

Considérer la correspondance ISO comme une conformité automatique

Le comparateur facilite l’analyse.

Il ne remplace pas l’évaluation des différences de périmètre ou de profondeur.

Confondre maturité et conformité

Une note interne sur 4 peut faciliter le pilotage.

Elle ne modifie pas ce que demande ReCyF.

Inventer un KPI pour chaque mesure

Un indicateur inutile génère du reporting sans décision.

Mesurez uniquement ce qui aide à détecter une dérive ou à arbitrer.

Clôturer une mesure après une première action

Une mesure récurrente doit continuer à être contrôlée après l’action initiale.

Oublier les changements du SI

Une preuve ou un contrôle peut devenir obsolète après :

1. migration ;
2. nouveau fournisseur ;
3. nouvelle application ;
4. changement d’architecture ;
5. incident.

Quel modèle utiliser pour toutes les exigences ReCyF ?

Voici un modèle générique réutilisable.

Fiche de mise en œuvre ReCyF

Référence ReCyF :

[ID]

Objectif de sécurité :

[objectif]

Texte ou synthèse de l’exigence :

[résultat attendu]

Applicabilité :

EI / EE / selon exigence

Mesure opérationnelle :

[contrôle permanent à maintenir]

Périmètre :

[SI / processus / population]

Responsable :

[fonction]

Sous-actions initiales :

1. [action]
2. [action]
3. [action]

Preuves attendues :

1. [preuve 1]
2. [preuve 2]

Fréquence :

[selon l’exigence et le risque]

Maturité interne :

[niveau + justification]

KPI :

[indicateur réellement utile]

Cible :

[objectif interne lorsque pertinent]

Dernière revue :

[date]

Prochaine revue :

[date]

Écarts :

[constats]

Actions de remédiation :

[liens vers tâches]

Cette fiche suffit à transformer une exigence statique en objet réellement pilotable.

Comment CompliKey applique cette logique

Cette chaîne correspond directement à la philosophie de CompliKey :

le référentiel ne doit pas rester une checklist ; chaque exigence doit pouvoir devenir un objet de gouvernance suivi dans le temps.

1. Partir du référentiel ReCyF

Les exigences sont structurées dans le référentiel applicable.

Le consultant ou l’organisation peut ainsi conserver la référence ReCyF tout en travaillant sur une représentation plus opérationnelle de la mesure.

2. Mutualiser avec les autres référentiels

Une même mesure de sécurité peut contribuer à plusieurs cadres.

Par exemple, un processus de sauvegarde ne doit pas nécessairement être recréé séparément pour :

1. ReCyF ;
2. ISO 27001 ;
3. un référentiel interne ;
4. un autre cadre applicable.

L’objectif est de mutualiser le contrôle opérationnel, puis de conserver ses correspondances avec les normes concernées.

Cette approche est cohérente avec l’intérêt même du comparateur publié par l’ANSSI pour aider les organisations déjà engagées dans ISO 2700X ou le règlement 2024/2690 à comprendre les correspondances avec ReCyF.

3. Décomposer la mesure en tâches

La mesure décrit l’état de sécurité recherché.

Les tâches permettent de gérer :

1. sa mise en œuvre initiale ;
2. les actions correctives ;
3. les travaux périodiques ;
4. les dépendances.

Une mesure ne disparaît pas lorsque ses tâches sont clôturées.

4. Attribuer la responsabilité

Les actions peuvent être affectées aux personnes chargées de leur réalisation.

Le pilotage GRC reste ainsi séparé de l’exécution opérationnelle.

5. Rattacher les preuves

Les preuves sont reliées aux mesures auxquelles elles contribuent.

CompliKey privilégie leur référencement par lien plutôt que la multiplication de copies de documents sensibles.

La relation devient :

mesure ReCyF → preuve → audit → conclusion.

6. Évaluer la maturité

Le consultant ou le RSSI peut appliquer une méthode homogène d’évaluation afin de suivre la progression.

Cette notation est une couche de pilotage CompliKey ou propre à l’organisation.

Elle ne doit pas être présentée comme un scoring officiel ReCyF.

7. Transformer les écarts en remédiations

Lorsqu’un audit montre qu’une mesure est :

1. inexistante ;
2. partiellement appliquée ;
3. insuffisamment démontrée ;
4. ou inefficace ;

le constat peut alimenter directement une remédiation puis des tâches.

La chaîne devient alors :

ReCyF → mesure → audit → preuve → constat → action → nouvelle preuve → réévaluation.

8. Suivre avec des indicateurs utiles

L’objectif n’est pas de créer automatiquement des dizaines de KPI.

Les indicateurs doivent permettre de répondre à des questions opérationnelles :

1. combien d’actions prioritaires restent ouvertes ?
2. quelle part du périmètre est couverte ?
3. quelles preuves doivent être renouvelées ?
4. quelles mesures sont en retard ?
5. quels contrôles doivent être revus ?

C’est cette continuité qui transforme un référentiel réglementaire en outil de gouvernance quotidien.

Ce que CompliKey ne doit pas automatiser à tort

Un logiciel ne devrait pas décider seul :

« Cette exigence ReCyF est conforme. »

La conclusion dépend toujours :

1. du périmètre ;
2. des preuves ;
3. du contexte ;
4. de la qualité de mise en œuvre ;
5. du risque ;
6. des éventuelles mesures alternatives ;
7. du jugement du responsable ou de l’auditeur.

De même, une correspondance automatique :

ReCyF ↔ ISO 27001

ne devrait pas entraîner :

« conforme dans les deux référentiels ».

La plateforme peut accélérer la mutualisation.

Elle ne doit pas supprimer l’analyse.

Conclusion

Le ReCyF devient réellement exploitable lorsqu’on cesse de le lire uniquement comme une liste d’exigences.

Pour chaque exigence, posez successivement sept questions :

1. Que demande réellement l’ANSSI ?
2. Quel contrôle devons-nous maintenir pour y répondre ?
3. Quelles actions sont nécessaires pour le mettre en œuvre ?
4. Qui en est responsable ?
5. Quelles preuves permettront de le démontrer ?
6. Quel niveau de maturité observons-nous ?
7. Quel indicateur permet de détecter une dérive ?

Pour 13.2-EI/EE, la chaîne devient par exemple :

tester les restaurations → maintenir un programme de tests → planifier et exécuter les restaurations → responsable infrastructure → rapport de test → maturité du processus → taux de couverture des systèmes critiques.

Le ReCyF fournit le résultat de sécurité attendu.

Le rôle du dispositif GRC est ensuite de le transformer en :

responsabilités, travaux, preuves et décisions suivies dans le temps.

C’est à ce moment que le référentiel cesse d’être une checklist et devient un véritable système de pilotage.

FAQ

Comment transformer une exigence ReCyF en plan d’action ?

Commencez par reformuler l’exigence sous la forme d’un contrôle permanent à maintenir, puis identifiez les écarts entre ce contrôle et la situation actuelle. Décomposez ces écarts en actions concrètes avec responsable, échéance et preuve attendue. Une exigence peut nécessiter plusieurs actions et, inversement, une même action peut contribuer à plusieurs exigences. Il faut donc éviter la règle simpliste « une exigence = une tâche ».

Quelle différence entre une exigence ReCyF et une mesure opérationnelle ?

L’exigence ReCyF décrit le résultat attendu selon le référentiel. La mesure opérationnelle décrit le contrôle que l’organisation décide de maintenir pour atteindre ce résultat. Par exemple, l’exigence 13.2-EI/EE prévoit des tests annuels de sauvegarde et restauration ; la mesure peut être formulée comme « maintenir un programme de tests de restauration couvrant le périmètre concerné ». Les tâches correspondent ensuite aux actions nécessaires pour faire vivre cette mesure.

Le ReCyF fournit-il une notation de maturité ?

Le ReCyF 2.5 ne fournit pas une échelle générique officielle de maturité 0-4 ou 1-5 permettant de noter chacune de ses exigences. Une organisation ou un outil GRC peut ajouter son propre modèle afin de suivre la progression, mais il doit être présenté comme une méthode interne. La conformité à l’exigence et le score de maturité doivent rester deux informations distinctes.

Quelles preuves conserver pour une exigence ReCyF ?

Les preuves dépendent du résultat demandé. Il peut s’agir d’une politique, d’une configuration, d’un export, d’un compte rendu, d’un rapport de test ou d’un historique. Pour 13.2-EI/EE, une procédure montre que les tests sont prévus, mais le rapport de restauration permet de démontrer qu’ils ont effectivement eu lieu. Une même preuve peut contribuer à plusieurs référentiels lorsqu’elle répond réellement à leurs critères.

Le comparateur ANSSI prouve-t-il qu’une exigence ISO 27001 couvre ReCyF ?

Non. Le comparateur permet de rapprocher ReCyF d’ISO 2700X et de l’annexe au règlement d’exécution 2024/2690 afin de faciliter l’analyse des organisations déjà engagées dans ces cadres. Une correspondance ne démontre pas automatiquement que les périmètres, fréquences, niveaux de détail ou preuves sont équivalents. Il faut vérifier les écarts avant de réutiliser un contrôle existant.

Quels KPI utiliser pour ReCyF ?

Il n’existe pas un catalogue universel de KPI ReCyF à associer systématiquement à chaque exigence. Choisissez des indicateurs qui permettent de détecter une dérive : taux de couverture, respect d’une fréquence, résultat du contrôle ou nombre d’actions en retard. Pour un test de restauration, le pourcentage de systèmes critiques testés dans la période constitue par exemple un KPI plus utile qu’un simple statut « test effectué ».

Passez de l’exigence ReCyF au pilotage opérationnel

Structurez les mesures, tâches, responsables, preuves, niveaux de maturité et remédiations dans un même environnement.

Transformer les exigences ReCyF en mesures pilotables avec CompliKey

Sources utilisées

1. ANSSI - ReCyF version 2.5 du 17 mars 2026. Source principale pour les exigences utilisées dans les exemples, notamment 13.1-EI/EE à 13.7-EE sur la continuité et les sauvegardes ainsi que 3.B.2-EI/EE sur la vérification périodique des prestations informatiques.
2. ANSSI - Directive NIS2. Source officielle pour le statut actuel de ReCyF : référentiel listant les mesures recommandées par l’ANSSI pour atteindre les objectifs de sécurité NIS2 et toujours diffusé comme document de travail à ce stade.
3. Lab ANSSI - publication de ReCyF et du comparateur, 24 mars 2026. Source pour le fonctionnement du comparateur permettant notamment de rapprocher les exigences ReCyF des référentiels ISO 2700X et de l’annexe au règlement d’exécution 2024/2690.
4. ANSSI - Fiches pratiques ReCyF, publiées le 7 septembre 2026. Nouvelle ressource destinée aux équipes techniques chargées de mettre en œuvre les principales mesures de gestion des risques du référentiel.
5. ANSSI - Les fondamentaux de la sauvegarde des systèmes d’information. Utilisé comme source technique complémentaire pour les tests réguliers de sauvegarde et la mise en œuvre d’une procédure de restauration.