Décisions budgétaires sous NIS2 : calcul des investissements dans les technologies, le personnel et les audits

Lorsqu’on prépare aujourd’hui des décisions budgétaires sous NIS2, on se pose rarement la question « combien coûte la sécurité ? », mais trois problèmes plus précis : qu’est‑ce qui est imposé par la réglementation, qu’est‑ce qui est pertinent au regard du risque — et comment représenter cela dans un budget de sorte que l’exploitation, les achats, les RH, la conformité et la direction partagent la même logique. NIS2 n’est pas pour autant un simple sujet technique. La directive vise des mesures de gestion des risques, la capacité de produire des preuves et les obligations de gouvernance. Le budget ne signifie donc pas seulement licences et matériel, mais surtout personnel, processus, audits et la capacité, en cas de besoin, à notifier dans des délais clairs et à rester opérationnel.

Ce billet présente une logique de calcul robuste pour les investissements en technique, personnel et audits — en regard de la gouvernance, des conséquences opérationnelles et de la perspective d’audit. Vous disposez d’aides à la décision, de check‑lists et de modules de modèles que vous pouvez transférer dans votre planification (CapEx/OpEx), votre registre des risques et votre feuille de route des mesures.

Pourquoi la planification budgétaire sous NIS2 fonctionne différemment des « projets de sécurité »

Dans les programmes de sécurité classiques, on budgétise souvent « l’outil d’abord » : EDR ici, SIEM là, une formation d’awareness en complément. Sous NIS2, cet ordre change. L’essentiel est que votre entreprise identifie systématiquement les risques, met en place des contrôles efficaces et puisse démontrer que ces contrôles sont exploités. « Démontrer » signifie : décisions traçables, responsabilités documentées, journaux, rapports, tests, preuves issues d’exercices d’incident et évaluations des fournisseurs.

Cela engendre trois réalités de coûts souvent sous‑estimées dans les budgets :

• Coûts d’exploitation : exploitation, maintenance, optimisation, traitement des alertes, reporting, formations, recertification des accès.
• Coûts liés aux preuves : produire, versionner et vérifier les preuves ; répondre aux questions d’audit ; rendre les contrôles testables.
• Coûts de coordination : rôles, instances, autorisations, acceptations de risque, escalades — en particulier en cas d’externalisation et de sites multiples.

La question budgétaire devient donc : quelle combinaison de mesures permet d’atteindre une réduction effective des risques et une préparation à l’audit, sans surcharger l’exploitation IT par une complexité additionnelle ?

Clarifier le périmètre et l’étendue : sans délimitation, tout chiffre est arbitraire

Avant de calculer, vous avez besoin d’une définition robuste du périmètre. Ce n’est pas un formalisme, mais le levier capable de modifier votre budget de façon significative. Périmètre signifie ici : quels secteurs d’activité, sites, services critiques, systèmes et prestataires sont concernés par les exigences de NIS2 et doivent être pris en compte dans les analyses de risque, les contrôles et les preuves ?

Dans la pratique, une approche en trois niveaux du périmètre s’est avérée efficace :

Il est pertinent pour le budget que NIS2 ne se limite pas au « Core ». En particulier, les risques liés à la chaîne d’approvisionnement (risques issus des prestataires et des dépendances logicielles/cloud) constituent un poste de coûts à part entière : clauses contractuelles, due diligence, exigences de sécurité envers les fournisseurs, preuves et, le cas échéant, coûts de migration.

Mini-checklist : données de périmètre nécessaires pour une estimation de coûts fiable

• Inventaire des services et systèmes (au minimum sommaire) : applications, serveurs/VMs, comptes cloud, segments réseau, sites.
• Criticité par service : impact sur le chiffre d’affaires, la sécurité, l’approvisionnement/la production, les obligations légales.
• Dépendances : identité (IAM), DNS, e-mail, stockage, sauvegarde, monitoring, prestataires tiers.
• Modèle opérationnel actuel : interne/externe, astreinte, SLAs, points de transfert.
• Interfaces réglementaires : protection des données, exigences proches de KRITIS (le cas échéant), standards sectoriels.

Décisions budgétaires sous NIS2 : le cadre de coûts en trois blocs

Pour la planification avec la direction et le contrôle de gestion, une structure simple est essentielle. La répartition en trois volets suivante a fait ses preuves et peut servir de structure de budget et de reporting :

• Technique (Controls & plateformes) : outils, intégrations, mesures d’architecture.
• Personnel (Build & Run) : rôles, charge d’exploitation, qualifications, astreinte.
• Vérifications (Assurance) : audits, évaluations, tests d’intrusion, exercices, contrôles des fournisseurs.

Important : chaque dépense doit pouvoir être rattachée à un risque et à une preuve. Sinon vous essuierez plus tard des discussions sur la raison pour laquelle un poste est qualifié de « NIS2 » et l’audit manquera de cohérence.

Calculer les investissements techniques : moins de liste d’outils, plus d’efficacité des contrôles

Les budgets techniques deviennent soutenables sous NIS2 si vous les planifiez en tant que familles de contrôles. Les familles de contrôles sont des groupes de mesures couvrant ensemble une zone de risque (p. ex. identités, journalisation, gestion des vulnérabilités). Elles permettent de prioriser, même si tout n’est pas financé immédiatement.

1) Identity & Access : MFA, rôles, accès privilégiés

L’identité est le levier le plus courant pour limiter les dommages. Les principaux postes de coûts ne sont pas tant les licences MFA que les concepts de rôles, les processus de cycle de vie et, le cas échéant, le PAM (Privileged Access Management : gestion sécurisée des comptes hautement privilégiés avec approbations, contrôle des sessions et journalisation).

• Coûts initiaux : définir le modèle de rôles, l’interface des droits, la connexion des systèmes, les accès d’urgence (Break-Glass).
• En continu : recertification, processus Joiner/Mover/Leaver, revue des droits administrateurs, gestion des tokens et des appareils.

2) Gestion des actifs et des vulnérabilités : inventaire, priorisation, réalité des correctifs

Sans inventaire fiable, on ne peut justifier proprement ni les risques ni le budget. Un registre des actifs n’a pas besoin d’être parfait immédiatement, mais il doit être vérifiable : quels systèmes sont dans le périmètre, qui est responsable, comment les mises à jour et les vulnérabilités sont traitées.

Points budgétaires souvent omis en pratique :

• Scan-Infrastruktur (on-prem, Cloud, Remote Standorte) und Wartung der Scanner.
• Processus d’exception (z. B. Legacy-Systeme) : évaluation des risques, contrôles compensatoires, documentation.
• Fenêtres de patch et charge opérationnelle : tests, rollback, gestion des changements (CAB), validation.

3) Journalisation, supervision et détection : SIEM, XDR, Use Cases, Betrieb

Sous NIS2, l’objectif n’est pas « acheter un SIEM », mais détecter, évaluer et réagir. SIEM (Security Information and Event Management) collecte et corrèle les logs ; XDR (Extended Detection and Response) relie la détection au niveau des endpoints, de l’identité, du réseau et du cloud. La décision budgétaire dépend de savoir si vous l‘exploitez en interne ou si vous le fournissez comme service géré.

Facteurs de coût typiques :

• Volume de logs (Stockage, Ingestion), conservation (Retention) et exigences en matière de protection des données.
• Conception des cas d’usage : règles d’alerte, corrélation, baselines, réglages fins pour réduire les faux positifs.
• Disponibilité 24/7 ou temps de réponse définis, y compris les chaînes d’escalade.

Une décision budgétaire ferme nécessite un état cible : quels événements devez-vous voir de manière fiable (p. ex. connexions administrateur, élévation de privilèges, flux de données inhabituels, modifications de politiques critiques), et en combien de temps devez-vous être en mesure de réagir ?

4) Sauvegarde, récupération et continuité d’activité : RTO/RPO comme paramètres budgétaires

De nombreux incidents ne coûtent cher que parce que la récupération prend trop de temps ou ne fonctionne pas de manière fiable. Une traduction claire en RTO (Recovery Time Objective : temps maximal de redémarrage) et RPO (Recovery Point Objective : perte de données maximale en temps) aide ici. Ces deux indicateurs sont le « régulateur » de votre budget.

• Coût ponctuel : architecture (sauvegardes immuables, domaines d’administration séparés), tests de RESTauration, documentation.
• En continu : validation régulière des RESTaurations, rotation des supports, monitoring, planification de capacité.

Sous NIS2, il ne suffit pas de « l’avoir », il faut aussi s’entraîner et pouvoir démontrer les résultats. Cela déplace le budget vers les tests et le personnel (voir ci‑dessous).

5) Segmentation du réseau et durcissement : mesures planifiables plutôt qu’un « Big Bang »

La segmentation (séparation des zones réseau) et le durcissement des systèmes (configuration de base sécurisée) sont souvent plus efficaces que des outils supplémentaires, mais ils entraînent des charges projets et d’exploitation : règles de firewall, processus d’exception, troubleshooting, documentation. Si vous budgétez pour cela, prévoyez impérativement le effort de changement et la coordination avec les services métiers, car les modifications réseau deviennent rapidement critiques en production.

Calcul du personnel : rôles, logique FTE et conséquences opérationnelles

NIS2 met en lumière ce qui manque déjà dans de nombreuses organisations IT : du temps pour une exploitation propre et un management des risques fiable. Le budget personnel n’est donc pas un « nice to have », mais une condition pour que les mesures techniques ne RESTent pas des projets à moitié achevés.

Modèle de rôles : qui doit être financé, même s’il n’y avait pas de « Security-Headcount » ?

Selon la taille et le niveau de maturité, vous n’avez pas nécessairement besoin de nouveaux postes à temps plein, mais vous avez besoin de parts de rôle clairement définies. Rôles typiques sous NIS2 :

• CISO/responsable de la sécurité de l’information : pilotage, portefeuille de risques et de mesures, reporting au management.
• ISMS-Manager (ISMS = système de management de la sécurité de l’information : processus et règles pour piloter la sécurité de façon systématique) : politiques, éléments probants, contrôles internes.
• Security Operations : monitoring, triage, gestion des incidents, renseignement sur les menaces (selon les besoins).
• Exploitation IT/équipes plateforme : gestion des correctifs, durcissement, sauvegarde/RESTauration, identité, réseau – co-responsables des contrôles.
• Compliance/Legal : processus de notification, obligations de documentation, chaîne d’approvisionnement, clauses contractuelles.

Logique budgétaire : si vous introduisez de nouveaux outils, vous devez prévoir des heures d’exploitation (triage, maintenance, reporting). Sans ces heures, l’efficacité diminue et l’audit manque de « preuve d’exploitation ».

Estimation FTE pragmatique : paniers d’effort plutôt que chiffres fantaisistes

Plutôt que de donner un chiffre FTE forfaitaire, de nombreuses organisations travaillent mieux avec des paniers d’effort que vous budgétez par trimestre et faites évoluer selon le niveau de maturité :

• Gouvernance & reporting : tenue du registre des risques, reporting au management, cycles de revue des politiques.
• Vulnérabilités & correctifs : scans, évaluation, planification des changements, mise en œuvre, gestion des exceptions.
• Détection & réponse : traitement des alertes, maintenance des cas d’usage, playbooks, retours d’expérience.
• Sensibilisation & exercices : planification des formations, simulation de phishing (si utilisée), exercices tabletop.
• Chaîne d’approvisionnement : évaluations de sécurité, exigences en matière d’éléments probants pour les fournisseurs, revue des rapports.

Ces paniers peuvent être présentés en OpEx et réduits proportionnellement via des services gérés – en précisant que le pilotage et la responsabilité RESTent internes.

Formation et qualification : budgétez du temps, pas seulement les coûts de formation

La sensibilisation n’est pas sous NIS2 une « case à cocher e‑learning ». Ce qui compte pour la décision, c’est de différencier les publics cibles : administrateur IT, service desk, équipes de développement (si présentes), direction, métiers avec des processus critiques. Le poste de coût principal est souvent le temps de travail et la coordination (rendez‑vous, suivi, mesure de l’efficacité). Pour être prêt à un audit, vous avez besoin d’éléments probants : taux de participation, contenus, cycles de répétition, mesures en cas de non‑participation.

Évaluations et éléments probants : ce que coûte réellement « l’assurance »

Les évaluations sous NIS2 ne sont pas seulement un audit externe, mais un continuum d’inspections internes, de tests techniques et de revues de management. L’objectif est que, en cas de contrôles ou d’incidents, vous puissiez de manière traçable démontrer ce qui a été décidé et mis en œuvre.

Tests d’intrusion, Red Teaming, évaluations techniques : définir clairement le périmètre

Une erreur budgétaire fréquente est d’acheter « un pentest » sans définir le périmètre et l’objectif. Pour obtenir des offres fiables et planifier en interne, vous devriez au minimum préciser :

• Objets de test : surface d’attaque externe, applications centrales, identité, configuration cloud, segments réseau.
• Type de test : Blackbox/Graybox, authentifié/non authentifié, social engineering oui/non.
• Travail de suivi : re‑test, priorisation, suivi de remédiation, acceptation du risque sur les constats.

Prévoyez également l‘accompagnement interne : fourniture des accès, fenêtres de maintenance, coordination avec l’exploitation et les métiers, ainsi que la mise en œuvre des constats (qui représente souvent la part la plus importante).

Préparation à l’audit : collecte d’éléments probants comme processus continu

La préparation à l’audit ne consiste pas à rassembler des documents juste avant un contrôle. Il vous faut un fonctionnement qui produit des preuves « en continu » : journaux, rapports, autorisations, tickets, états de configuration, rapports d’exercices. Cela exige de la structure.

Minimum pratique de catégories d’éléments probants :

• Gouvernance : rôles, responsabilités, instances de décision, procès‑verbaux de revues de management.
• Risque : méthodologie, évaluation, acceptations, plan d’actions, statut.
• Contrôles techniques : lignes de base, rapports de correctifs, tests de sauvegarde, couverture des logs, revues IAM.
• Réponse aux incidents : playbooks, exercices, retours d’expérience, voies de communication et de notification.
• Chaîne d’approvisionnement : classification des fournisseurs, exigences de sécurité, éléments probants/rapports, dérogations.

Exercices tabletop et gestion de crise : budget pour créneaux et formation à la prise de décision

NIS2 est étroitement lié aux obligations de notification et aux responsabilités de la direction. Les exercices tabletop (scénarios joués autour d’une table) sont donc un moyen efficace de tester les voies de notification, les droits de décision et les routines de communication. Les coûts portent principalement sur : le temps de préparation, l’animation, la participation des cadres, le suivi et l’ajustement des runbooks.

Priorisation : un portefeuille basé sur le risque plutôt que « tout en même temps »

Peu d’entreprises peuvent mettre en œuvre toutes les mesures immédiatement. L’essentiel est que votre priorisation soit plausible en cas d’audit. Basée sur le risque signifie : vous combinez la probabilité d’occurrence, l‘impact et la capacité de détection / de réaction en une séquence justifiable.

Un cadre de priorisation opérationnel

• Limiter les dommages en priorité : identité (MFA/PAM), sauvegarde/récupération, séparation des comptes administrateurs, réponse aux incidents.
• Assurer la visibilité: Couverture des logs, alerting centralisé, monitoring de base (baseline), inventaire des actifs.
• Réduire la surface d’attaque: processus de patch et de gestion des vulnérabilités, durcissement, segmentation, configurations standard sécurisées.
• Renforcer la capacité de preuve: processus de gestion des preuves, revues régulières, audits/contrôles internes, dossier fournisseur.

Cet ordre n’est délibérément pas centré sur les outils. Il est centré sur l’exploitation : qu’est-ce qui vous aide à éviter les incidents, à les détecter plus rapidement et à rétablir l’exploitation — et cela de façon démontrable ?

Build vs. Buy : services gérés, équipes internes et coûts cachés de transfert

Sous NIS2, « externaliser » n’est pas un blanc-seing. Vous pouvez confier la détection, l’exploitation des logs ou la gestion des vulnérabilités à un prestataire, mais vous conservez la responsabilité et devez pouvoir piloter. Les décisions budgétaires devraient donc distinguer trois niveaux :

• Prestation : que fait concrètement le fournisseur (monitoring, triage, assistance à la réponse) ?
• Interfaces : comment sont transférés tickets, alertes et changements (ITSM, API, e‑mail) ?
• Justificatifs : quels rapports, journaux et KPI fournissent des preuves recevables en audit ?

Les coûts cachés apparaissent typiquement lors des transferts : chaînes d’escalade floues, responsabilités non définies, absence de définitions communes de la sévérité, et ruptures de médias entre l’outillage SOC et l’ITSM. Ces coûts sont réels, même s’ils ne figurent pas sur une facture : retards, faux positifs, décisions floues lors d’un incident.

Modèle de calcul : comment construire un budget NIS2 qui tient devant le contrôle de gestion et l’audit

Un modèle robuste se compose de trois tableaux liés logiquement : Risque → Mesure → Poste budgétaire. Ci‑dessous une structure compacte que vous pouvez transposer dans Excel/Sheets ou dans votre outil portefeuille.

1) Liste des risques et mesures (niveau portefeuille)

Champs (recommandés)
- ID du risque
- Service/Système (référence de périmètre)
- Description du risque
- Impact (financier/opérationnel/juridique)
- Probabilité d'occurrence (qualitative ou échelle)
- Contrôles existants
- Contrôles planifiés (ID de la mesure)
- Date cible / jalon
- Acceptation du risque requise ? (oui/non, par qui)
- Source de preuves (quel élément justifie l'efficacité ?)

2) Postes budgétaires (CapEx/OpEx, technique/personnel/audit)

Champs (recommandés)
- ID de la mesure
- Poste de coût (Technique / Personnel / Audits)
- Type de coût (CapEx / OpEx)
- Ponctuel (setup/projet) / Recurrent (exploitation)
- Facteur de coût (p. ex. volume de logs, endpoints, sites, criticité)
- Dépendances (p. ex. IAM avant PAM, inventaire des actifs avant programme de vulnérabilités)
- Conséquences opérationnelles (changements supplémentaires, fenêtres de maintenance, astreinte)
- Preuve/bénéfice (quel justificatif d'audit ou quelle réduction de risque)
- Responsable (owner) + contributeurs

3) Plan de preuves (ossature d’audit-readiness)

Champs (recommandés)
- Contrôle/processus (p. ex. patch management)
- Artefact de preuve (rapport, extrait de ticket, journal, document d'exercice)
- Fréquence (mensuelle/trimestrielle/annuelle/basée sur les événements)
- Producteur (rôle/équipe)
- Emplacement de stockage (DMS, outil GRC, ticketing, repo)
- Revue (qui vérifie, qui signe)
- Conservation (rétention) et contrôle d'accès

Avec ce triptyque, les décisions budgétaires sous NIS2 ne sont plus une affaire de « ressenti », mais un portefeuille pilotable avec une logique de preuves.

Gouvernance et responsabilités : le budget nécessite des voies de décision

NIS2 rend la direction plus proche des responsabilités : les décisions doivent être prises en connaissance de cause et documentées. Pour le budget, cela signifie : vous avez besoin d’un organe ou d’un processus fixe qui tranche sur les acceptations de risque, les priorités et les dérogations. Dans la pratique, il s’agit souvent d’un Security Steering Committee ou d’un comité élargi de gestion des risques IT.

Ensemble minimal de gouvernance qui stabilise la planification budgétaire :

• RACI (Responsible, Accountable, Consulted, Informed) : qui met en œuvre, qui décide, qui est impliqué ?
• Limites décisionnelles : à partir de quel niveau de risque la direction doit-elle décider ?
• Processus de dérogation : comment les écarts (p. ex. systèmes Legacy non patchés) sont-ils autorisés de façon limitée dans le temps ?
• Cadence de reporting : rapport opérationnel mensuel, revue de gestion trimestrielle.

Sans ces voies, le budget est «découpé» au fil de l’année : des projets démarrent, mais les charges d’exploitation et les contrôles RESTent non financés ou sont reportés sur des équipes déjà à leur limite.

Pièges budgétaires typiques — et comment les éviter dans la planification

Piège 1 : Outils sans concept d’exploitation

Quand les sources d’alerte augmentent, le travail de triage augmente. Prévoyez au minimum : responsabilité, temps de réaction, flux de tickets, jeu d’indicateurs KPI (p. ex. Time to Acknowledge, Time to Contain) et réglages réguliers.

Piège 2 : Correctifs et mesures de durcissement sans capacité de changement

La dette technique ne se règle pas en l’achetant. Si vos fenêtres de changement sont RESTreintes, prévoyez un budget pour l’automatisation des tests (lorsque possible), pour des fenêtres de maintenance supplémentaires, ou pour le retrait progressif des systèmes Legacy. Sinon, les constats RESTent en suspens et les questions d’audit deviennent gênantes.

Piège 3 : Considérer la chaîne d’approvisionnement comme un poste résiduel

NIS2 exige que vous gériez activement les risques fournisseurs. Budgétez la capacité à classifier les fournisseurs, à demander des preuves, à adapter les contrats et à évaluer des alternatives en cas de dépendances critiques. Cela représente un effort pour les achats, l’IT et la conformité — pas seulement un annexage contractuel.

Piège 4 : «Un audit ponctuel, puis terminé»

Les preuves vieillissent. Les responsables changent. Les systèmes évoluent. Planifiez donc des contrôles continus et des exercices réguliers — sinon la préparation à l’audit devient chaque année un projet exceptionnel à forte friction.

Aide à la décision : Quelles questions doivent figurer dans chaque proposition budgétaire NIS2 ?

• Quels risques réduisons-nous concrètement, et comment le mesurons‑nous (KPI/preuves) ?
• Quelles conséquences opérationnelles entraînent les mesures (charge de changement, astreinte, formations, volume de tickets) ?
• Quelles dépendances a la mesure, et quel est le calendrier réaliste ?
• Qu’est‑ce qui est décidé en interne, qu’est‑ce qui peut être fourni en externe, et comment pilotons‑nous le pRESTataire ?
• Quelles preuves devons‑nous fournir dans 6 et 12 mois, et qui les produit ?

Conclusion : Un bon NIS2‑budget est un système exploité — pas une liste d’achats

Le changement central pour la direction IT et le management est le suivant : les décisions budgétaires sous NIS2 doivent financer la technique, le personnel et les contrôles comme un système cohérent. La technique sans exploitation génère de nouveaux risques. Le personnel sans gouvernance claire se dilue dans le quotidien. Les contrôles sans processus de preuves deviennent des efforts exceptionnels et précipités. Si vous délimitez clairement le périmètre, priorisez les mesures en fonction du risque et liez chaque dépense au risque et aux preuves, vous obtenez un budget intégrable en interne — et crédible lors d’un audit externe.

Lorsque vous planifiez les étapes suivantes, le point de départ le plus pragmatique est généralement : définir précisément le périmètre, mettre en place un portefeuille de risques, prioriser trois à cinq familles de contrôles (identité, reprise après sinistre, visibilité, correctifs/durcissement, réponse aux incidents) et, parallèlement, établir le plan de collecte des preuves. Ensuite, les investissements deviennent planifiables – et NIS2 passe d’un projet ponctuel à une discipline opérationnelle maîtrisable.

Pour ce sujet, le budget Nis2 et les coûts de conformité Nis2 sont également importants. Cet article replace ces aspects de manière claire et montre ce qui compte dans la pratique.