NIS2 n'est pas un sujet qui peut disparaître entièrement dans le département IT. C'est un sujet de direction parce qu'il touche aux priorités, aux ressources, à l'acceptation du risque et à la capacité de l'organisation à défendre ses décisions lorsqu'un incident survient.
Pour beaucoup d'organisations, c'est la partie la moins confortable. Pendant longtemps, la cybersécurité a été traitée comme une spécialité technique déléguée à l'IT interne ou à des prestataires. NIS2 renforce l'attente selon laquelle la direction reste responsable de l'approche globale. Cela ne signifie pas qu'un dirigeant doit devenir analyste SOC ou expert forensique. Cela signifie qu'il doit poser les bonnes questions, exiger des preuves et refuser de piloter sur des suppositions faibles.
Ce contenu ne constitue pas un conseil juridique. Il sert de guide pratique pour les équipes de direction qui doivent comprendre leur rôle dans la préparation à NIS2.
Pour qui cette page est faite
Cette page est particulièrement pertinente pour :
- les dirigeants et directions générales,
- les membres de comités exécutifs,
- les responsables finance, opérations et gouvernance,
- les cadres qui arbitrent les budgets, les priorités et le risque.
Ce que vous devez en retenir
Après lecture, vous devriez mieux voir :
- pourquoi la direction ne peut pas déléguer entièrement NIS2 à l'IT,
- ce qu'elle doit réellement garantir,
- quelles questions donnent de la visibilité sur la preuve et la maturité du logging,
- à quoi ressemble un premier plan réaliste sur 90 jours.
Pourquoi NIS2 n'est pas qu'un sujet IT
NIS2 concerne la résilience cyber de l'organisation, pas uniquement la configuration de son outillage technique. En pratique, la direction décide :
- si le risque cyber est traité comme une priorité d'entreprise,
- quel niveau de preuve et de traçabilité est jugé acceptable,
- à quelle vitesse les lacunes évidentes sont financées et corrigées,
- quel niveau d'exposition non traité l'organisation accepte consciemment.
Les équipes IT peuvent proposer et mettre en œuvre des mesures. Elles ne peuvent pas décider seules de l'importance donnée au logging, à la rétention, au contrôle des identités, aux risques fournisseurs ou à la préparation aux incidents. Ce sont des décisions de management éclairées par la réalité technique.
Ce que la direction doit réellement assurer
La direction n'a pas besoin d'exploiter elle-même les contrôles. En revanche, elle doit s'assurer que l'organisation :
- comprend son exposition au risque cyber,
- a des rôles et responsabilités clairs,
- finance un minimum adapté,
- peut montrer que les contrôles fonctionnent,
- dispose d'une base de preuve pour l'audit, les investigations et les incidents.
On peut traduire cela en cinq responsabilités concrètes.
1. La responsabilité et le portage
Sans responsable clairement nommé, NIS2 devient un sujet flottant entre IT, conformité et juridique. La direction doit désigner un porteur du sujet et instaurer un rythme de reporting.
2. Le budget et les ressources
Un logging crédible, une base de preuve exploitable et une meilleure résilience ne naissent pas de la bonne volonté seule. S'il n'y a ni temps ni budget pour un minimum défendable, la direction accepte de fait une position de risque difficile à justifier ensuite.
3. La priorisation
La plupart des organisations de taille intermédiaire ne peuvent pas tout faire en même temps. La direction doit donc décider à quoi ressemble la première couche défendable. Dans beaucoup d'environnements, cela signifie : identités, accès privilégiés, serveurs clés, firewalls, VPN et conservation centralisée hors des systèmes sources.
4. Le pilotage et la supervision
La direction doit avoir une visibilité régulière sur :
- l'exposition réglementaire probable,
- la maturité actuelle en matière de preuve et de logging,
- les angles morts majeurs,
- les risques non financés ou non traités,
- la capacité réelle à répondre à un incident ou à un audit.
5. La preuve plutôt que le simple réassurance
Un changement d'état d'esprit très utile consiste à ne plus demander uniquement "sommes-nous couverts ?", mais "qu'est-ce que nous pouvons démontrer aujourd'hui ?". C'est une bien meilleure base de décision.
Pourquoi la preuve et la traçabilité importent à la direction
Le reporting sécurité peut vite devenir trop vague :
- "le logging est en place",
- "la supervision est couverte",
- "les accès sont contrôlés",
- "la réponse à incident existe".
Ces formulations restent faibles si personne ne peut montrer rapidement :
- quels systèmes envoient réellement leurs logs,
- si ces logs sont conservés hors des systèmes sources,
- combien de temps ils restent accessibles,
- si l'historique des accès et des changements peut être retrouvé,
- ce qu'il advient de la preuve si un serveur critique ou un poste d'administration est compromis.
Des logs locaux et des traces fragmentées affaiblissent la capacité de la direction à défendre la préparation de l'organisation. Ce point compte non seulement vis-à-vis d'une autorité, mais aussi face aux clients, assureurs, enquêteurs externes et au conseil lui-même.
Quelles questions la direction doit poser à l'IT
Une bonne gouvernance commence souvent par de meilleures questions.
Périmètre et exposition
- Sommes-nous probablement directement dans le périmètre NIS2 ou subissons-nous surtout une pression client et chaîne d'approvisionnement ?
- Quels services et quels systèmes sont réellement critiques ?
- Où se trouvent aujourd'hui les angles morts majeurs ?
Logging et preuve
- Quels logs collectons-nous réellement aujourd'hui, et quels logs supposons-nous simplement exister ?
- Les logs critiques sont-ils conservés en dehors des systèmes d'origine ?
- À quelle vitesse pouvons-nous retrouver des preuves d'accès, de changement et d'événements de sécurité ?
- Que devient notre preuve si un serveur clé, un compte admin ou notre plateforme d'identité est compromis ?
Préparation à l'incident
- À quelle vitesse pouvons-nous construire une première chronologie d'incident ?
- Sur quelles données reposeront les premières décisions de management ?
- Qui prépare un point de situation pour la direction, et à partir de quelles preuves ?
Modèle d'exploitation
- L'approche actuelle est-elle durable ?
- Avons-nous la capacité interne de maintenir notre propre pile, ou un modèle centralisé ou SaaS est-il plus réaliste en première phase ?
Budget, ressources et impact métier
Le budget sécurité est souvent présenté comme un centre de coût. Sous NIS2, une question plus utile est : quel est le coût d'une traçabilité faible ?
Les conséquences typiques d'un sous-investissement dans la preuve et le logging sont :
- une réponse plus lente aux incidents,
- des décisions de direction plus fragiles,
- des coûts d'investigation plus élevés,
- une défendabilité réglementaire plus faible,
- davantage de dommages réputationnels parce que l'organisation ne peut pas expliquer clairement ce qui s'est passé.
La direction n'a pas besoin d'acheter la plateforme la plus complexe du marché. Elle doit en revanche financer un socle qui tienne en exploitation et qui soit défendable.
À quoi ressemble un premier plan réaliste sur 90 jours
La première phase n'a pas besoin d'être parfaite. Elle doit en revanche poser un socle qui permette de meilleures décisions et une progression visible.
Dans les 30 premiers jours
- désigner le portage du sujet au niveau direction,
- confirmer ou cadrer l'exposition probable,
- cartographier les services critiques, les identités, les serveurs et les contrôles réseau,
- évaluer la maturité actuelle du logging et de la preuve.
D'ici 60 jours
- décider du périmètre minimal de logging centralisé,
- prioriser les sources les plus importantes,
- mettre en place un reporting court mais utile pour la direction,
- identifier les principales lacunes et risques non couverts.
D'ici 90 jours
- mettre en œuvre une collecte centralisée des logs critiques hors des systèmes sources,
- vérifier concrètement que la restitution fonctionne,
- clarifier les attentes d'accès et de rétention,
- aligner la réponse à incident et les décisions de direction sur les preuves réellement disponibles.
Pourquoi les logs locaux affaiblissent la direction
Lors d'une compromission, les attaquants cherchent souvent à modifier, supprimer ou rendre inaccessibles les traces locales. Cela a une conséquence très managériale : si la preuve vit uniquement sur les systèmes attaqués, la direction perd la base nécessaire pour prendre des décisions solides.
Cela affecte :
- la qualité des premiers points de situation internes,
- les décisions d'escalade,
- la communication avec les clients et partenaires,
- la défendabilité réglementaire,
- la réputation de l'organisation après l'événement.
Une preuve centralisée hors des systèmes sources n'est donc pas un luxe technique. C'est l'une des mesures les plus pratiques pour éviter que la direction décide dans le brouillard.
À quoi doit ressembler un bon reporting de direction
La direction n'a pas besoin de bruit technique brut. Elle a besoin d'un reporting concis qui réponde à cinq questions :
- quelle est l'exposition actuelle,
- où se trouvent les principales lacunes,
- qu'est-ce qui a déjà été amélioré,
- quelle est la prochaine étape,
- quelles décisions la direction doit-elle prendre maintenant.
La maturité du logging et de la preuve doit en faire explicitement partie. Si ce volet est flou, la vision du risque est incomplète.
Recommandations pratiques pour la direction
Si vous voulez tester rapidement si le sujet est correctement piloté, recherchez ces signaux :
- NIS2 a un responsable clair,
- l'IT peut nommer les systèmes prioritaires et les sources de logs prioritaires,
- la preuve n'est pas conservée uniquement en local,
- la direction reçoit un état régulier et prend des décisions explicites,
- l'organisation construit un minimum exploitable au lieu d'attendre un programme idéal futur.
FAQ
La direction doit-elle comprendre le logging dans le détail technique ?
Non. En revanche, elle doit comprendre ce que le logging signifie pour l'auditabilité, la gestion d'incident et la défendabilité des décisions.
Suffit-il que le CIO ou le MSP gère le sujet ?
Pas entièrement. Ils peuvent être essentiels pour l'exécution, mais la responsabilité des priorités, des ressources et de la supervision reste du côté de la direction.
Pourquoi la direction devrait-elle s'intéresser aux logs si ce sont des artefacts techniques ?
Parce que sans logs, l'organisation peine à démontrer la réalité, à reconstruire les incidents et à justifier ses décisions. C'est un problème de management, pas uniquement un sujet technique.
Liens internes
- Retour à la vue d'ensemble NIS2
- Votre organisation relève-t-elle de NIS2 ?
- Les différents niveaux d'obligations NIS2
- Audit, traçabilité et preuve
Prochaine étape
- Obtenir la checklist exécutive pour les 90 premiers jours de préparation NIS2.
- Réserver un briefing de direction centré sur la responsabilité, la preuve et les arbitrages prioritaires.
- Demander une consultation initiale sur le minimum de logging nécessaire pour les audits et les incidents.