Introduction
À retenir :
- Le recensement des systèmes d’information est le premier objectif de sécurité du ReCyF : sans lui, le périmètre NIS2 reste déclaratif et indéfendable en audit.
- Un inventaire de conformité va au-delà de l’inventaire technique : il relie chaque actif à une activité, un propriétaire, une criticité, des mesures et des preuves.
- Un SI externalisé reste sous la responsabilité de l’entité : cloud, infogérance et SaaS critiques entrent dans le périmètre.
- La preuve d’audit se conçoit dès le recensement, pas en fin de projet : elle doit être traçable, datée et rattachée à une exigence.
- ISO 27001, ISO 27005 et EBIOS RM fournissent le cadre méthodologique pour passer de l’inventaire à la décision.
Dans beaucoup d’organisations, la mise en conformité NIS2 est abordée par le haut : gouvernance, politique de sécurité, rôles, plans d’action, comités cyber, reporting. Ces éléments sont indispensables. Mais ils ne suffisent pas si l’organisation ne sait pas précisément ce qu’elle protège.
La première difficulté de NIS2 n’est donc pas de rédiger une politique de sécurité. C’est de définir le périmètre réel : activités critiques, services essentiels, systèmes d’information support, dépendances techniques, prestataires, flux, données sensibles et mesures de sécurité associées.
En France, le ReCyF (Référentiel Cyber France) constitue aujourd’hui le point d’appui le plus concret pour anticiper la mise en œuvre opérationnelle de NIS2. L’ANSSI précise que le ReCyF est diffusé comme document de travail dans l’attente de la stabilisation des travaux de transposition, et que ses mesures visent un niveau de sécurité adapté contre la menace cybercriminelle de masse. Le référentiel est, par défaut, non obligatoire mais une entité qui décide de l’appliquer pourra s’en prévaloir en cas de contrôle. Autrement dit : l’appliquer aujourd’hui, c’est se constituer une position défendable demain.
Pour une lecture globale des objectifs, consultez notre article ReCyF de l’ANSSI : les 20 objectifs NIS2 à connaître. Ici, l’enjeu est plus opérationnel : comment transformer le recensement des SI en cartographie exploitable, puis en preuves auditables.
Pourquoi le recensement des SI est un prérequis de conformité
Une organisation ne peut pas démontrer sa conformité si elle ne sait pas relier ses activités à ses systèmes d’information. Sans recensement fiable, le périmètre de conformité devient déclaratif, instable et difficilement défendable face à un auditeur ou à une autorité de contrôle.
Ce n’est pas un hasard si le ReCyF place le recensement des systèmes d’information comme premier objectif de sécurité. Il demande de lister les activités et services de l’entité, d’identifier un responsable pour chaque activité ou service, puis de relier ces activités aux systèmes d’information qui les supportent. Il impose également un réexamen annuel de cette liste et une mise à jour à chaque évolution des activités, des services ou des systèmes.
Ce point est central : le recensement n’est pas une liste de serveurs, c’est une matrice de responsabilité. Elle doit permettre de répondre à des questions très concrètes :
- Quelle activité dépend de quel système ?
- Qui en est propriétaire ?
- Quelles données sont traitées ?
- Quels prestataires interviennent ?
- Quels flux sont nécessaires ?
- Quelles mesures de sécurité sont appliquées, et quelles preuves permettent de le démontrer ?
Sans cette base, la conformité NIS2 est fragile. Une PSSI peut exister, des procédures peuvent être rédigées, des outils peuvent être déployés mais l’organisation ne pourra pas démontrer que ces mesures couvrent effectivement les systèmes qui portent ses activités critiques.
Inventaire technique vs inventaire de conformité
Le premier travail consiste à distinguer deux objets souvent confondus. L’inventaire technique décrit des composants : serveurs, postes, machines virtuelles, conteneurs, bases de données, applications, comptes, équipements réseau, services cloud, outils SaaS, terminaux mobiles, certificats, secrets. Nécessaire, mais insuffisant. L’inventaire de conformité ajoute quatre dimensions : la criticité métier, la responsabilité, les dépendances et la preuve. Un actif ne doit pas seulement être connu ; il doit être rattaché à une activité, à un propriétaire, à un niveau d’impact et à des mesures de protection vérifiables. Un recensement NIS2/ReCyF devrait donc contenir, au minimum :
| Élément à recenser | Pourquoi c'est nécessaire |
|---|---|
| Activité ou service supporté | Définir le périmètre réel de conformité |
| Système d'information associé | Relier le métier au SI |
| Propriétaire métier | Porter le risque et les arbitrages |
| Propriétaire technique | Porter l'exploitation et la sécurité opérationnelle |
| Données traitées | Identifier les impacts en confidentialité, intégrité, disponibilité |
| Prestataires et fournisseurs | Maîtriser la chaîne de dépendance |
| Flux entrants et sortants | Comprendre l'exposition et les interconnexions |
| Mesures de sécurité associées | Relier l'actif aux contrôles appliqués |
| Preuves disponibles | Démontrer la mise en œuvre et l'efficacité |
| Date de dernière revue | Garantir la traçabilité et l'actualisation |
Le cas des prestataires : un SI externalisé reste votre SI
La question des tiers mérite une attention particulière. Le ReCyF distingue les systèmes d’information de l’entité, les SI d’infrastructure et les SI tiers et rappelle qu’un SI externalisé reste sous la responsabilité de l’entité : il n’est pas considéré comme un simple SI tiers au sens du référentiel.
Cette précision change tout pour les environnements cloud, les infogérances, les SOC externalisés, les plateformes SaaS critiques et les services opérés par des fournisseurs. En pratique, une entité ne peut pas exclure un système du périmètre au seul motif qu’il est hébergé ailleurs ou exploité par un prestataire. Elle doit démontrer qui le maîtrise, à quoi il sert, quels risques il porte, quelles mesures sont contractuellement et techniquement appliquées, et quelles preuves sont disponibles.
Cartographie métier vs cartographie technique
La cartographie est l’étape qui transforme l’inventaire en compréhension opérationnelle. Elle ne se limite pas à un schéma réseau : elle représente le SI selon plusieurs vues, chacune répondant à un usage différent.
La cartographie métier répond aux questions de gouvernance : quelles activités sont critiques ? Quels services doivent continuer en cas d’incident ? Quels processus manipulent des données sensibles ? Quels métiers seraient affectés par une interruption, une altération ou une divulgation ?
La cartographie technique répond aux questions d’exploitation et de sécurité : quelles applications supportent ces processus ? Sur quelles infrastructures reposent-elles ? Quels flux sont nécessaires ? Quels comptes à privilèges existent ? Quels accès distants sont ouverts ? Quelles interconnexions existent avec des fournisseurs ? Quels journaux sont collectés ?
Le guide ANSSI sur la cartographie du SI rappelle que celle-ci peut représenter les biens matériels, logiciels, réseaux, informations, activités et processus, et qu’elle sert à produire des vues lisibles du système d’information . Le ReCyF va dans le même sens : son objectif de sécurité 5 exige une cartographie suffisamment détaillée pour faciliter le maintien en condition opérationnelle et de sécurité, ainsi que la réaction en cas d’incident. La conformité NIS2 suppose d’articuler ces niveaux en vues complémentaires :
| Vue | Question principale | Exemple de livrable |
|---|---|---|
| Vue métier | Quelles activités doivent être protégées ? | Cartographie des activités, services, processus critiques |
| Vue applicative | Quels systèmes supportent ces activités ? | Cartographie applications / processus / données |
| Vue données | Quelles informations sensibles circulent ? | Registre des données critiques, flux de données |
| Vue infrastructure | Où sont hébergés les systèmes ? | Cartographie serveurs, cloud, réseau, sauvegardes |
| Vue identité | Qui accède à quoi ? | Matrice des droits, comptes à privilèges, annuaires |
| Vue prestataires | Qui intervient dans la chaîne ? | Cartographie fournisseurs, contrats, interconnexions |
| Vue sécurité | Quelles mesures couvrent quels actifs ? | Mapping contrôles / risques / preuves |
L’erreur classique : produire une cartographie trop technique pour être exploitée par les métiers, ou trop métier pour être utile aux équipes sécurité. Une cartographie NIS2 doit être traversable : partir d’un service critique, descendre vers les applications, les infrastructures, les flux et les prestataires, puis remonter vers les risques, les contrôles et les preuves.
CMDB, EDR, annuaire, cloud inventory : limites et complémentarités
Aucun outil ne donne, seul, une vision complète du SI. La conformité NIS2 impose de réconcilier plusieurs sources chacune avec ses angles morts.
- La CMDB apporte une vision structurée des actifs connus, de leurs relations et parfois de leurs propriétaires. Mais elle devient déclarative et obsolète si elle n’est pas connectée aux processus de changement.
- L’EDR donne une vision opérationnelle des terminaux et serveurs réellement observés : machines actives, versions, événements de sécurité. Mais il ne sait pas
dire à quelle activité métier un actif est rattaché, ni quelle criticité lui attribuer. - L’annuaire (Active Directory, Entra ID ou autre) éclaire les identités, les groupes, les privilèges et les accès. Source majeure pour la maîtrise des accès, mais qui ne remplace pas une cartographie applicative ou métier.
- Les inventaires cloud identifient les ressources dynamiques : instances, buckets, bases managées, rôles IAM, services serverless, réseaux virtuels. Mais ils restent fragmentés par compte, abonnement, région, tenant ou fournisseur.
- Les outils de vulnérabilité, CSPM, gestion de parc, MDM, SIEM ou GRC enrichissent chacun une partie du puzzle.
Le problème n’est donc pas le manque de données. Le problème est l’absence de modèle commun permettant de relier ces données à un périmètre NIS2 défendable.
Une démarche robuste consiste à créer un référentiel pivot : une base d’inventaire de conformité où chaque système est relié à ses sources techniques, son propriétaire, sa criticité, ses risques, ses mesures de sécurité et ses preuves. C’est ce référentiel qui devient le support de la gouvernance, de l’analyse de risques, de la remédiation et de l’audit. C’est précisément le rôle d’une plateforme GRC comme ConformEdge : centraliser le référentiel, tracer les preuves et piloter les écarts.
Les preuves attendues : passer de l'inventaire à l'auditabilité
Dans une logique NIS2/ReCyF, la preuve ne se collecte pas à la fin du projet.
Elle se conçoit dès le recensement. Une preuve d’audit n’est pas un document stocké dans un dossier. C’est un élément traçable, daté, rattaché à un périmètre, à une exigence, à un propriétaire et à une décision. Elle doit démontrer que l’organisation sait ce qu’elle protège, pourquoi elle le protège, comment elle le protège et comment elle vérifie l’efficacité des mesures.
Le ReCyF prévoit une analyse de conformité par système d’information, avec identification des écarts entre les mesures mises en œuvre et celles prévues par le référentiel. Son objectif relatif à l’audit demande de vérifier, sur un périmètre défini, l’atteinte des objectifs fixés par conformité aux mesures ou par mesures alternatives et d’évaluer le niveau de sécurité des SI couverts au regard des menaces et vulnérabilités connues.
Les preuves attendues couvrent l’ensemble de la chaîne :
| Domaine | Preuve attendue |
|---|---|
| Recensement | Liste des activités, services, SI support, propriétaires |
| Criticité | Matrice d'impact métier, classification des données |
| Cartographie | Vues métier, applicatives, techniques, flux, prestataires |
| Gouvernance | Rôles, responsabilités, validations, comités, décisions |
| Risques | Analyse de risques, scénarios, traitements, acceptations |
| Mesures | Politiques, procédures, configurations, contrôles déployés |
| Prestataires | Contrats, clauses sécurité, engagements, revues fournisseurs |
| Supervision | Journaux, couverture SIEM/EDR, alertes, rapports SOC |
| Vulnérabilités | Scans, priorisation, correctifs, dérogations, mesures compensatoires |
| Audit | Plan d'audit, constats, écarts, actions correctives, preuves de clôture |
L’objectif n’est pas de produire une masse documentaire. L’objectif est de créer une chaîne de traçabilité : un auditeur doit pouvoir partir d’une exigence ReCyF, identifier les SI concernés, vérifier les mesures appliquées, consulter les preuves, comprendre les écarts et suivre les actions correctives.
Comment ISO 27001, ISO 27005 et EBIOS RM structurent la démarche
Ces référentiels ne se superposent pas à NIS2 : ils fournissent la mécanique qui rend la conformité durable.
- ISO/IEC 27001 cadre le système de management : périmètre, gouvernance, responsabilités, audits internes, documentation, amélioration continue. L’ISO rappelle que la norme définit les exigences d’un système de management de la sécurité de l’information et aide les organisations à l’établir, le maintenir et l’améliorer continuellement.
- ISO/IEC 27005 apporte la méthode de gestion des risques : lignes directrices pour identifier, analyser, évaluer, traiter et suivre les risques de sécurité de l’information, en soutien d’un SMSI fondé sur ISO 27001.
- EBIOS RM ancre l’analyse dans le réel : scénarios de menace, valeurs métier, événements redoutés, chemins d’attaque.
- Le ReCyF traduit les attentes NIS2 en objectifs et en moyens acceptables de conformité.
Pour approfondir cette articulation, lisez notre analyse EBIOS RM et NIS2 : comment transformer la conformité en pilotage du risque cyber. Et pour structurer un programme complet, la formation NIS 2 Directive Lead Implementer couvre la gouvernance, les risques, les preuves et la préparation à l’audit ; la formation ISO/IEC 27001 Lead Implementer apporte le cadre SMSI nécessaire à une conformité durable.
Une méthode opérationnelle en sept étapes
Pour passer d’un recensement théorique à un dispositif audit-ready, la démarche peut être progressive :
1. Identifier les activités et services. Ne pas commencer par les outils, mais par les missions que l’organisation doit protéger. Cela évite un inventaire purement informatique, déconnecté des impacts réels.
2. Associer chaque activité aux SI qui la supportent. Faire apparaître les applications, infrastructures, services cloud, outils SaaS, bases de données, flux et dépendances externes.
3. Nommer les propriétaires. Chaque activité doit avoir un responsable métier, chaque système un responsable technique. Sans propriétaire : pas d’arbitrage clair, pas de validation, pas de preuve fiable.
4. Qualifier la criticité. Mesurer les impacts en disponibilité, intégrité et confidentialité selon des critères explicites : interruption d’activité, perte de données, indisponibilité client, atteinte réglementaire, impact financier, impact réputationnel.
5. Réconcilier les sources techniques. Comparer CMDB, EDR, annuaire, cloud inventory, scanners de vulnérabilités et outils GRC. Les écarts entre sources sont souvent les plus révélateurs : systèmes inconnus, actifs non supervisés, comptes orphelins, ressources cloud oubliées, flux non documentés.
6. Rattacher les mesures et les preuves. Relier chaque SI aux contrôles appliqués sauvegarde, MFA, segmentation, journalisation, supervision, gestion des vulnérabilités, gestion des accès, durcissement, clauses prestataires, PRA/PCA et disposer d’une preuve pour chaque contrôle.
7. Organiser la revue continue. Le recensement n’est pas un livrable figé : il s’intègre aux processus de changement, d’onboarding fournisseur, de mise en production, de revue d’accès, de gestion des vulnérabilités et d’audit interne.
FAQ - Recensement des SI et NIS2 / ReCyF
Le ReCyF est-il obligatoire pour être conforme à NIS2 ?
Non. L’ANSSI le diffuse comme document de travail, non obligatoire par défaut. Mais une entité qui choisit de l’appliquer pourra s’en prévaloir en cas de contrôle : c’est aujourd’hui la référence opérationnelle la plus concrète pour anticiper la transposition française de NIS2.
Quelle différence entre inventaire technique et inventaire de conformité ?
L’inventaire technique liste des composants (serveurs, applications, comptes). L’inventaire de conformité y ajoute la criticité métier, les propriétaires, les dépendances (prestataires, flux) et les preuves associées à chaque mesure de sécurité.
Un système hébergé dans le cloud ou infogéré entre-t-il dans le périmètre NIS2 ?
Oui. Le ReCyF précise qu’un SI externalisé reste sous la responsabilité de l’entité. Cloud, infogérance, SOC externalisé et SaaS critiques doivent figurer dans le recensement, avec les mesures contractuelles et techniques associées.
À quelle fréquence le recensement doit-il être mis à jour ?
Le ReCyF prévoit un réexamen au moins annuel, et une mise à jour à chaque évolution des activités, des services ou des systèmes. En pratique, le recensement doit être intégré aux processus de changement pour rester vivant.
Qu'est-ce qu'une preuve d'audit recevable ?
Un élément traçable, daté, rattaché à un périmètre, à une exigence, à un propriétaire et à une décision : politique validée, configuration exportée, rapport de scan, revue d’accès signée, compte rendu de comité, plan d’action suivi.
Conclusion : la conformité commence par la connaissance du SI
NIS2 ne demande pas seulement aux organisations d’affirmer qu’elles sont sécurisées. Elle les pousse à démontrer qu’elles connaissent leur périmètre, qu’elles comprennent leurs dépendances, qu’elles maîtrisent leurs risques et qu’elles peuvent produire des preuves.
Le ReCyF donne une lecture opérationnelle de cette exigence. Son premier objectif le recensement des SI est le socle de tout le reste : gouvernance, maîtrise de l’écosystème, cartographie, gestion des risques, supervision, continuité, audit et amélioration continue.
La question structurante devient : votre organisation est-elle capable de relier une activité critique à ses systèmes, ses prestataires, ses flux, ses risques, ses mesures de sécurité et ses preuves d’audit ?
Si la réponse est non, la priorité n’est pas de produire une politique supplémentaire. La priorité est de reprendre la maîtrise du patrimoine numérique.
DEVFORMA, organisme de formation certifié Qualiopi et cabinet de conseil GRC/cybersécurité, accompagne les organisations sur les deux volets de la conformité NIS2/ReCyF : la structuration opérationnelle (cartographie des SI, préparation des preuves d’audit, alignement ISO 27001, ISO 27005 et EBIOS RM, outillage via la plateforme ConformEdge) et la montée en compétence des équipes.
Pour vous former, découvrez nos parcours certifiants PECB : NIS 2 Directive Lead Implementer, ISO/IEC 27001 Lead Implementer et EBIOS Risk Manager. Pour un accompagnement sur votre périmètre, contactez-nous via le formulaire DEVFORMA.
