La directive européenne NIS2 est entrée en vigueur il y a plusieurs années. Son ambition ne se limite pas à encourager les organisations à renforcer leur arsenal d’outils de cybersécurité. Elle impose une gouvernance du risque cyber fondée sur des processus techniques, opérationnels et organisationnels démontrables, couvrant aussi bien la gestion des incidents que la continuité des activités, la gestion des changements ou encore la sécurité de la chaîne d’approvisionnement.
Le constat est simple : la plupart de ces processus existent déjà au sein de la gestion des services IT (ITSM). Pourtant, dans de nombreuses organisations, la conformité à la directive NIS2 reste abordée comme un projet indépendant, confié presque exclusivement aux équipes cybersécurité, gestion des risques ou juridique.
Dans le même temps, une part importante des preuves attendues par les autorités de contrôle est produite au quotidien par le service desk, les processus de gestion des incidents, les workflows de gestion des changements et les dispositifs de gestion des fournisseurs.
Le véritable défi n’est donc pas de créer de nouveaux mécanismes de contrôle. Il consiste à relier les obligations réglementaires, comme celles imposées par la directive NIS2, aux processus ITSM déjà en place, à faire évoluer leur niveau de maturité et à transformer les données opérationnelles en preuves de conformité fiables et exploitables.
C’est précisément l’objectif de cet article.
Des exigences réglementaires à la gouvernance opérationnelle
Prenons un peu de recul afin de replacer ces enjeux dans leur contexte à travers un exemple concret.
La directive NIS2, officiellement directive (UE) 2022/2555, est entrée en vigueur le 16 janvier 2023. Les États membres devaient la transposer dans leur droit national avant le 17 octobre 2024, les nouvelles dispositions étant applicables à compter du 18 octobre 2024 selon les modalités prévues par chaque législation nationale. Pour les organisations présentes dans plusieurs pays européens, il est donc indispensable de vérifier les conditions de transposition propres à chaque juridiction.
Son champ d’application est nettement plus large que celui de la première directive NIS. Elle concerne désormais les organisations publiques et privées de dix-huit secteurs critiques, parmi lesquels l’énergie, les transports, la santé, les infrastructures numériques, les services cloud, les datacenters, les prestataires de services TIC managés, les administrations publiques, l’industrie manufacturière ou encore la recherche.
Mais l’évolution la plus importante ne réside pas uniquement dans l’élargissement du périmètre des entités concernées.
La directive NIS2 fait entrer la cybersécurité au cœur de la gouvernance de l’entreprise. Les organes de direction doivent approuver et superviser les mesures de gestion des cyber-risques et peuvent être tenus pour responsables en cas de défaillance organisationnelle. La sécurité ne peut donc plus être cantonnée au SOC ni reposer sur un cercle restreint d’experts : elle doit désormais s’intégrer pleinement aux opérations quotidiennes de l’organisation.
C’est précisément à ce niveau que l’ITSM prend toute sa dimension.
Pourquoi la conformité passe par l’IT Service Management
Un environnement ITSM mature repose sur des principes qui répondent directement aux exigences d’une réglementation comme la directive NIS2 :
- Des responsabilités clairement définies
- Des règles de qualification et de priorisation des événements
- Des mécanismes d’escalade fondés sur des règles établies
- Des SLA et des délais de traitement maîtrisés
- Des processus de validation et de suivi des changements
- Une visibilité complète sur les actifs et les services concernés
- Un suivi de la performance des fournisseurs
- Une traçabilité exhaustive des activités
- Une démarche d’amélioration continue
Un ticket correctement géré ne constitue pas seulement une demande de support. Il représente une trace documentée des décisions prises, des responsabilités engagées, des échanges réalisés et des actions menées.
De la même manière, un enregistrement de changement ne se limite pas à autoriser le déploiement d’une nouvelle version logicielle. Il peut démontrer que l’organisation a évalué les risques, analysé les impacts, défini un plan de retour arrière et obtenu l’ensemble des validations requises.
Ce principe rejoint celui présenté dans notre précédent article consacré à l’intégration de l’intelligence artificielle dans l’ITSM au regard de l’AI Act européen. À mesure que les technologies s’intègrent aux processus métiers, les exigences en matière de gouvernance, de contrôle, de documentation et de traçabilité deviennent plus fortes.
Dans les deux cas, la plateforme ITSM fait le lien entre les politiques de gouvernance et leur mise en œuvre opérationnelle. C’est à ce stade que la conformité cesse d’être un simple ensemble de documents pour devenir un processus pleinement intégré aux opérations.
Gestion des incidents : la conformité se joue dès le premier ticket
Prenons un autre exemple concret issu de la directive NIS2.
Le texte instaure un processus de notification en plusieurs étapes pour les incidents de sécurité significatifs. De manière générale, les organisations doivent être en mesure de produire :
- Une alerte précoce dans les 24 heures suivant la prise de connaissance de l’incident
- Une notification dans les 72 heures comprenant une première évaluation de la situation
- Un rapport final dans un délai d’un mois, détaillant l’impact de l’incident, ses causes profondes et les mesures correctives mises en œuvre
Le respect de ces échéances ne dépend pas uniquement des équipes cybersécurité. Il se joue dès les premières minutes de traitement au niveau du service desk.
Le processus de gestion des incidents doit d’abord être capable de distinguer avec fiabilité un incident technique courant d’un incident susceptible de relever de la cybersécurité. Il doit ensuite recueillir immédiatement les informations essentielles : le service concerné, les actifs impactés, les utilisateurs affectés, l’origine du signalement, le niveau de criticité, le risque de propagation, les dépendances techniques ainsi que les conséquences potentielles sur l’activité.
Cette qualification ne peut pas reposer uniquement sur l’appréciation individuelle d’un opérateur. Elle doit s’appuyer sur des catégories communes, une matrice de priorisation et des règles d’escalade clairement définies.
Lorsqu’un ticket est susceptible d’entrer dans le périmètre de la directive NIS2, il devrait déclencher automatiquement :
- La notification du responsable cybersécurité
- L’implication du gestionnaire d’incident
- La création d’une chronologie des événements entièrement traçable
- L’application de SLA alignés sur les délais réglementaires
- La conservation des preuves techniques et décisionnelles
- Le lancement du processus de communication vers la direction, les équipes juridiques et les responsables conformité
Une solution d’automatisation de la gestion des incidents, comme celle d’EasyVista permet de centraliser l’enregistrement, la qualification, l’affectation et le suivi des incidents. Elle réduit ainsi le risque qu’un événement critique reste bloqué dans un échange d’e-mails, une conversation Teams ou Slack, ou une file d’attente générique.
C’est une première étape concrète vers une conformité durable.
Gestion des changements : aucun changement sans évaluation des risques
Tous les incidents ne résultent pas d’une attaque externe. Une part importante des perturbations provient de changements mal préparés, de mauvaises configurations, de mises à jour incomplètes ou de modifications déployées sans analyse suffisante de leurs dépendances.
C’est pourquoi la gestion des changements constitue l’un des principaux points de convergence entre les exigences de la directive NIS2, la conformité ITSM et la gestion quotidienne des services.
Un processus de gestion des changements conçu pour répondre aux exigences de conformité doit, a minima, documenter :
- Le motif et l’objectif du changement
- Les services, actifs et éléments de configuration concernés
- L’évaluation des impacts opérationnels et des risques de sécurité
- Les dépendances techniques identifiées
- Les validations obtenues
- Le plan de tests
- La fenêtre de mise en œuvre
- Le plan de retour arrière (rollback)
- Le résultat du changement
- Les incidents ou vulnérabilités éventuellement constatés après son déploiement
Les changements standard et à faible risque peuvent être largement automatisés. En revanche, ceux qui concernent des services essentiels, des accès privilégiés, des configurations de sécurité ou des composants exposés nécessitent des mécanismes de contrôle plus rigoureux ainsi que, lorsque cela s’impose, l’intervention des équipes cybersécurité.
Gestion des fournisseurs : intégrer la chaîne d’approvisionnement aux processus ITSM
La sécurité de la chaîne d’approvisionnement constitue l’un des piliers de la directive NIS2.
Les organisations ne doivent plus seulement maîtriser les risques présents dans leurs propres systèmes. Elles sont également tenues d’évaluer ceux liés à leurs fournisseurs de produits et de services numériques. Les fournisseurs cloud, les prestataires de services managés (MSP), les éditeurs de logiciels, les partenaires de support ou encore les sous-traitants représentent souvent des maillons essentiels à la continuité des services.
Autrement dit, il ne suffit plus d’insérer une clause de sécurité générique dans un contrat.
Une démarche de gestion des fournisseurs conforme aux exigences de la directive doit notamment prévoir :
- Un inventaire à jour des fournisseurs et des services qu’ils délivrent
- Une classification des fournisseurs selon leur niveau de criticité
- La cartographie des liens entre chaque fournisseur, ses contrats, les services concernés et les actifs associés
- La définition d’exigences minimales en matière de sécurité
- Des délais obligatoires de notification des incidents
- Des droits d’audit et de contrôle clairement établis
- Des procédures d’escalade formalisées
- Des évaluations périodiques des risques
Qu’est‑ce qu’un ITSM “prêt pour la conformité” ?
La réponse est moins évidente qu’il n’y paraît. Être prêt à répondre aux exigences de conformité ne signifie pas qu’une plateforme, à elle seule, puisse rendre une organisation conforme à la directive NIS2.
La conformité repose sur l’interaction entre les personnes, les processus, les technologies, les mécanismes de gouvernance et les mesures de sécurité. En revanche, une plateforme ITSM fournit l’architecture opérationnelle nécessaire pour appliquer les contrôles, orchestrer les processus et produire les preuves attendues.
Un environnement ITSM conçu pour accompagner la conformité doit être capable d’apporter rapidement des réponses à des questions très concrètes :
- Qui a qualifié cet incident, et selon quels critères ?
- À quel moment le délai réglementaire de 24 heures a-t-il commencé à courir ?
- Quels services et quels actifs ont été impactés ?
- Qui a autorisé ce changement critique ?
- Quelle évaluation des risques a été réalisée ?
- Quel fournisseur était responsable du composant concerné ?
- Quelles actions correctives ont été mises en œuvre ?
- Comment leur efficacité a-t-elle été vérifiée ?
- Quelles améliorations ont été décidées à l’issue de l’analyse post-incident ?
Les réponses à ces questions ne doivent jamais dépendre de la mémoire des équipes ou des connaissances d’une personne en particulier. Elles doivent être directement issues des workflows, des enregistrements et des pistes d’audit de la plateforme.
C’est précisément ce que permet une solution comme EV Service Manager : structurer les processus de gestion des services, centraliser les informations et automatiser les mécanismes d’affectation, d’escalade, de validation et de reporting.
Conclusion
La directive NIS2, à l’instar des autres réglementations européennes, ne doit pas conduire les organisations à créer une infrastructure de conformité parallèle à leurs opérations informatiques.
La gestion des incidents, la gestion des changements, la gestion des problèmes, la gestion des actifs et la gestion des fournisseurs constituent déjà la colonne vertébrale de la fourniture des services IT. Dissocier la conformité de ces processus revient à multiplier les activités, alourdir les coûts et fragmenter les preuves nécessaires aux audits.
À l’inverse, intégrer les exigences réglementaires au sein de l’IT Service Management permet de faire de chaque ticket, de chaque validation, de chaque escalade et de chaque revue un élément cohérent de la gouvernance de l’organisation.
Cette approche produit un double bénéfice. D’une part, elle renforce la capacité de l’organisation à démontrer sa conformité. D’autre part, elle améliore concrètement sa résilience opérationnelle : les incidents sont détectés plus tôt, les réponses sont mieux coordonnées, les changements sont davantage maîtrisés, les dépendances sont mieux comprises et les risques liés aux fournisseurs sont gérés de manière plus proactive.
FAQ
Qu’est-ce que la directive NIS2 ?
La directive NIS2 est la réglementation européenne qui renforce et élargit les obligations de cybersécurité applicables aux organisations opérant dans des secteurs critiques. Elle impose notamment des exigences en matière de gestion des risques, de détection et de notification des incidents, de continuité des activités, de sécurité de la chaîne d’approvisionnement et de responsabilité des organes de direction.
En quoi l’ITSM contribue-t-il à la conformité aux réglementations européennes ?
L’IT Service Management fournit des processus structurés permettant d’enregistrer, de qualifier, d’affecter, de suivre et de documenter les incidents, les changements, les problèmes, les actifs et les activités des fournisseurs. Ces processus facilitent la mise en œuvre des contrôles exigés par des réglementations telles que la directive NIS2 et permettent de produire des preuves de conformité ainsi que des pistes d’audit fiables.
Une plateforme ITSM garantit-elle automatiquement la conformité à la directive NIS2 ?
Non. Aucun logiciel ne peut, à lui seul, garantir la conformité réglementaire. En revanche, une plateforme ITSM constitue un levier essentiel pour standardiser les processus, automatiser les contrôles, centraliser les informations, favoriser la collaboration entre les équipes et produire les éléments de preuve nécessaires aux audits.
