NIS2 : mettre son cloud en conformité

La directive NIS2 change d'échelle par rapport à sa version précédente : elle fait entrer dans le champ de la cybersécurité réglementée des milliers d'entreprises qui ne s'y croyaient pas soumises. Pour la plupart, l'essentiel du système d'information vit désormais sur Microsoft Azure ou AWS. La vraie question n'est donc pas juridique mais opérationnelle : comment une infrastructure cloud répond-elle, concrètement, aux dix mesures de l'article 21 ? Guide de la conformité NIS2 cloud, cette page projette chaque obligation de l'article 21 sur une architecture Azure ou AWS, détaille la notification d'incident en 24 h / 72 h / un mois, la responsabilité des dirigeants, et la démarche de mise en conformité côté cloud.

• Directive (UE) 2022/2555
• Entités essentielles & importantes
• Article 21 : 10 mesures
• Notification 24 h / 72 h / 1 mois
• Autorité : ANSSI

Qu'est-ce que la directive NIS2 et qui est concerné ?

NIS2 (directive (UE) 2022/2555) est le texte européen qui rehausse et harmonise le niveau de cybersécurité des entités opérant des services jugés importants pour l'économie et la société. Elle succède à la première directive NIS de 2016, dont le périmètre était jugé trop étroit et l'application trop inégale d'un pays à l'autre. Là où la version initiale visait surtout les opérateurs de services essentiels et quelques fournisseurs numériques, NIS2 étend le champ à un nombre bien plus large de secteurs et impose un socle commun d'obligations.

La logique de classement repose sur deux critères combinés : le secteur d'activité et la taille de l'entité. Deux catégories en résultent.

• Entités essentielles (EE)

  Grandes entreprises des secteurs de haute criticité (énergie, transport, banque, santé, eau, infrastructures et services numériques, administration). Elles font l'objet d'une supervision proactive, avant tout incident.

• Entités importantes (EI)

  Entités de taille moyenne des mêmes secteurs, et entités des autres secteurs critiques (agroalimentaire, fabrication, gestion des déchets, chimie, services postaux, recherche). Supervision a posteriori, en cas de signalement.

• Vos fournisseurs cloud

  Azure et AWS relèvent des infrastructures et services numériques. Mais l'entité régulée reste votre organisation : vous devez piloter le risque que représente votre fournisseur, pas vous reposer sur son statut.

Les seuils de taille repris de la définition européenne des PME servent de premier filtre. En simplifiant, une entité d'au moins 250 salariés ou dépassant 50 M€ de chiffre d'affaires bascule côté grande entreprise (donc essentielle dans les secteurs de haute criticité) ; une entité de 50 à 249 salariés ou de 10 à 50 M€ de chiffre d'affaires est de taille moyenne (donc importante). Certaines entités restent concernées quelle que soit leur taille, en raison de leur rôle critique (fournisseurs de services de communication, opérateurs d'infrastructures numériques, administrations désignées).

La distinction EE/EI n'est pas cosmétique : elle change le régime de supervision, le niveau des sanctions et l'intensité des contrôles. Elle ne change pas, en revanche, le socle des mesures techniques attendues. Ce panorama réglementaire complet (RGPD, ISO 27001, HDS, SecNumCloud, DORA, NIS2) est traité sur notre page conformité cloud ; ici, l'angle est délibérément opérationnel et centré sur la mise en œuvre côté Azure et AWS.

Calendrier et transposition française (ANSSI)

NIS2 est entrée en vigueur au niveau européen début 2023, avec une échéance de transposition par les États membres fixée à l'automne 2024. En France, la transposition s'inscrit dans un texte plus large portant aussi sur la résilience des entités critiques et sur DORA, dont le processus législatif et réglementaire est en cours de finalisation. L'autorité nationale compétente désignée est l'ANSSI (Agence nationale de la sécurité des systèmes d'information), qui supervise, contrôle et peut sanctionner.

Concrètement, l'entrée en application effective des obligations pour les entités françaises dépend de la publication de la loi de transposition et de ses décrets. Deux conséquences pratiques pour une DSI ou un RSSI.

• Ne pas attendre le décret pour agir. Les mesures attendues (analyse de risque, MFA, chiffrement, journalisation, plan de réponse) sont des fondamentaux de sécurité dont la mise en place prend des mois. Commencer maintenant, c'est étaler l'effort au lieu de le subir dans l'urgence.
• Cartographier son éligibilité tôt. L'ANSSI prévoit un mécanisme d'enregistrement des entités concernées. Savoir si vous êtes EE ou EI conditionne vos délais et vos obligations déclaratives.

Les 10 mesures de l'article 21

Le cœur de NIS2 tient dans l'article 21, qui impose aux entités des mesures techniques, opérationnelles et organisationnelles de gestion des risques « appropriées et proportionnées ». Le texte en liste dix, formant un socle minimal. Voici leur contenu, en langage clair.

1. Analyse des risques et politique de sécurité des systèmes d'information. Identifier les risques pesant sur vos systèmes et formaliser une politique de sécurité.
2. Gestion des incidents. Détecter, traiter, consigner et clôturer les incidents de sécurité.
3. Continuité d'activité. Gestion des sauvegardes, reprise après sinistre et gestion de crise.
4. Sécurité de la chaîne d'approvisionnement. Maîtriser le risque lié aux fournisseurs et prestataires directs, dont le cloud.
5. Sécurité de l'acquisition, du développement et de la maintenance. Y compris le traitement et la divulgation des vulnérabilités.
6. Évaluation de l'efficacité des mesures. Politiques et procédures pour mesurer que ce qui est en place fonctionne réellement.
7. Cyber-hygiène et formation. Pratiques de base et sensibilisation régulière des équipes.
8. Cryptographie et chiffrement. Politiques d'usage de la cryptographie, chiffrement le cas échéant.
9. Sécurité des ressources humaines, contrôle d'accès et gestion des actifs. Qui a accès à quoi, et inventaire des actifs.
10. Authentification multifacteur et communications sécurisées. MFA ou authentification continue, communications voix/vidéo/texte sécurisées, communications d'urgence.

Ces dix familles ne décrivent pas des outils, mais des résultats attendus. Toute la valeur d'une démarche cloud consiste à traduire chacune en configuration concrète, vérifiable et documentée sur votre plateforme. C'est l'objet de la section suivante.

Projeter les 10 mesures NIS2 sur une architecture Azure ou AWS

C'est ici que la plupart des contenus s'arrêtent à la théorie juridique. Voici, mesure par mesure, comment une infrastructure Azure ou AWS bien conçue répond à l'article 21. Cette projection sert de checklist technique de départ. Elle ne remplace pas une analyse de votre périmètre, mais elle montre que NIS2 se joue d'abord dans la configuration.

La lecture de ce tableau conduit à une conclusion nette : NIS2 ne demande presque rien qu'une infrastructure cloud bien gouvernée ne fasse déjà. Le durcissement technique de chacun de ces leviers (identités, chiffrement, journalisation, résilience, réponse à incident) est détaillé sur notre pilier sécurisation d'infrastructure cloud. NIS2 ajoute deux exigences que la sécurité seule n'impose pas toujours : la preuve organisée et la gouvernance au niveau des dirigeants.

Gestion des risques liés aux fournisseurs et au cloud

La mesure 4 de l'article 21, la sécurité de la chaîne d'approvisionnement, est celle qui bouscule le plus les habitudes, et celle qui touche le cloud de plein fouet. NIS2 vous rend responsable non seulement de votre propre sécurité, mais aussi de la maîtrise du risque introduit par vos fournisseurs directs, à commencer par votre hébergeur et vos prestataires d'infogérance.

Cela ne signifie pas auditer Microsoft ou Amazon, dont la sécurité de l'infrastructure relève du modèle de responsabilité partagée. Cela signifie documenter, pour chaque fournisseur critique, ce que vous savez de sa sécurité et ce que vous maîtrisez de la relation. Les points attendus sont les suivants.

• Inventaire des fournisseurs critiques. Qui héberge quoi, qui exploite quoi, qui a accès à vos données et à vos consoles d'administration. Sans cet inventaire, aucune maîtrise du risque tiers n'est possible.
• Attestations et certifications du fournisseur. Récupérer les rapports disponibles (dans le portail de confiance Azure ou dans AWS Artifact) et les intégrer à votre dossier comme éléments d'entrée, jamais comme conformité automatique.
• Clauses contractuelles. Sécurité, localisation des données, notification d'incident par le fournisseur, réversibilité. Ces clauses recoupent en partie le contrat de sous-traitance de l'article 28 du RGPD.
• Sécurité des dépendances logicielles. Le risque de chaîne d'approvisionnement inclut vos briques open source et vos images de conteneurs. L'inventaire des composants (SBOM) et le scan des dépendances relèvent de la démarche détaillée sur DevSecOps cloud.
• Stratégie de sortie. Pouvoir changer de prestataire ou rapatrier une charge sans blocage. C'est le point de rencontre avec DORA, traité sur notre page DORA cloud pour le secteur financier.

Le risque tiers est le fil qui relie NIS2, DORA et le RGPD : les trois textes convergent sur l'idée qu'un fournisseur externe ne dilue pas votre responsabilité, il l'étend. Une architecture pensée pour la réversibilité (code IaC dans vos dépôts, comptes cloud à votre nom, documentation remise) est structurellement plus facile à mettre en conformité qu'un environnement verrouillé chez un prestataire.

MFA, chiffrement, journalisation, vulnérabilités : le socle technique

Quatre mesures de l'article 21 forment le socle technique que tout auditeur regardera en premier. Elles sont aussi celles qui réduisent le plus de risque pour le moins d'effort. Voici ce qu'elles impliquent concrètement dans le cloud, sans re-détailler la mise en œuvre déjà couverte par notre pilier de sécurisation.

• MFA généralisée (mesure 10)

  Authentification multifacteur sur tous les comptes humains, en priorité les accès d'administration. Accès conditionnel Entra ID côté Azure, politiques d'authentification IAM Identity Center côté AWS. Aucun compte à privilèges sans second facteur.

• Chiffrement & clés (mesure 8)

  Chiffrement au repos et en transit (TLS), avec maîtrise des clés via Azure Key Vault ou AWS KMS. Le sujet n'est pas « est-ce chiffré » mais « qui détient la clé et peut la révoquer ».

• Journalisation (mesures 2 & 6)

  Journaux d'activité centralisés, inaltérables et conservés selon vos obligations : Azure Monitor / Log Analytics, AWS CloudTrail + CloudWatch. Sans journaux antérieurs à l'incident, impossible de le qualifier ni de le notifier.

• Vulnérabilités (mesure 5)

  Scan continu et patch discipliné : Defender for Cloud et Azure Update Manager, Amazon Inspector et Systems Manager Patch Manager. Un correctif appliqué tard est une fenêtre d'exposition ouverte.

Ces quatre briques ne sont pas des options : elles sont citées explicitement ou implicitement dans l'article 21, et leur absence est le premier signal d'alerte d'un contrôle. La bonne nouvelle est qu'elles se déploient nativement sur Azure et AWS, et se prouvent via les tableaux de bord de posture. Pour évaluer où vous en êtes, un audit de sécurité cloud mesure votre couverture réelle face à ces exigences avant toute remédiation.

Notification d'incident : 24 heures, 72 heures, rapport final

L'obligation de notification est l'une des nouveautés les plus structurantes de NIS2. En cas d'incident significatif (qui cause ou peut causer une perturbation opérationnelle grave ou des pertes financières, ou qui affecte des tiers), l'entité doit informer son autorité, en France l'ANSSI, selon un calendrier en cascade. La maîtriser suppose d'avoir préparé le dispositif avant l'incident.

1. Alerte précoce, sous 24 heures Dès la prise de connaissance de l'incident significatif, une première alerte indique s'il est présumé d'origine malveillante et s'il peut avoir un impact transfrontalier. Objectif : signaler vite, même sans analyse complète.
2. Notification d'incident, sous 72 heures Une évaluation initiale : gravité, impact, indicateurs de compromission connus. Elle actualise et précise l'alerte des 24 heures. C'est le rapport de qualification.
3. Rapport intermédiaire, sur demande Si l'autorité le demande, ou si l'incident est toujours en cours, un point d'étape sur l'évolution de la situation et des mesures prises.
4. Rapport final, sous un mois Une fois l'incident traité : description détaillée, cause racine, mesures d'atténuation appliquées, impact transfrontalier éventuel. Il clôt le cycle de notification.

Ce calendrier a une implication technique directe : sans journalisation antérieure à l'incident, vous ne pouvez ni qualifier la gravité en 72 heures, ni décrire la cause racine dans le rapport final. La capacité de notification se construit en amont, dans la configuration de la supervision. Le déroulé complet d'un plan de réponse à incident cloud (détecter, contenir, éradiquer, restaurer, notifier, analyser), y compris la notification CNIL sous 72 h au titre du RGPD lorsqu'il y a violation de données personnelles, est détaillé sur notre pilier sécurisation d'infrastructure cloud.

Gouvernance et responsabilité des dirigeants, sanctions

NIS2 hisse la cybersécurité au niveau du conseil d'administration. L'article consacré à la gouvernance impose que les organes de direction approuvent les mesures de gestion des risques, supervisent leur mise en œuvre, et suivent une formation pour comprendre les risques. Surtout, les dirigeants peuvent être tenus responsables en cas de manquement. Ce n'est plus un sujet délégué à la DSI : c'est une responsabilité de direction.

Les sanctions administratives suivent la distinction EE/EI et sont d'un ordre de grandeur qui capte l'attention d'un comité de direction.

• 10 M€ / 2 %plafond pour une entité essentielle : jusqu'à 10 M€ ou 2 % du CA mondial, le plus élevé
• 7 M€ / 1,4 %plafond pour une entité importante : jusqu'à 7 M€ ou 1,4 % du CA mondial
• Directionresponsabilité personnelle des dirigeants, formation obligatoire
• ANSSIautorité de supervision et de contrôle en France

Au-delà des amendes, l'autorité peut prononcer des mesures correctrices contraignantes, voire, pour les entités essentielles, suspendre temporairement certaines fonctions dirigeantes. La logique est claire : responsabiliser le sommet de l'organisation, pas seulement les équipes techniques. Traduire ces enjeux en langage de décision (risque juridique, risque financier, risque de contrat perdu) fait partie de la valeur d'un bon cadrage, et rejoint la démarche décrite sur notre page cybersécurité cloud.

NIS2, ISO 27001 et DORA : comment s'articulent-ils ?

Les entreprises confondent souvent ces trois cadres, ou pensent devoir tout mener de front. En réalité, ils se recouvrent largement et se renforcent. Comprendre leur articulation évite de payer deux fois pour le même travail.

Le fil conducteur : un système de management ISO 27001 solide couvre une grande partie des attentes de NIS2, car les mesures de l'article 21 recoupent l'Annexe A de la norme. Construire ou aligner un SMSI, c'est donc préparer NIS2 en même temps. Pour les acteurs financiers, DORA est plus exigeant que NIS2 sur la résilience et prime en tant que règlement sectoriel spécialisé. Un établissement de paiement conjuguera DORA, DSP2 et, selon son statut, NIS2. La bonne approche consiste à cartographier une fois les exigences communes, puis à traiter les spécificités de chaque texte, plutôt que de mener des chantiers en silo.

La démarche de mise en conformité NIS2 côté cloud

Une mise en conformité NIS2 ne s'improvise pas davantage qu'une certification. Appliquée à un périmètre Azure ou AWS, elle suit une trajectoire lisible.

1. Qualification de l'éligibilité Déterminer si vous êtes entité essentielle, importante ou hors périmètre, secteur par secteur et seuil par seuil. C'est le préalable qui fixe vos délais et vos obligations.
2. Analyse des risques et écart Cartographier les actifs cloud, évaluer la posture face aux dix mesures de l'article 21, et produire une matrice d'écart : conforme, écart, preuve manquante.
3. Plan d'action priorisé Traiter d'abord ce qui réduit le plus de risque : MFA, fermeture des expositions, journalisation, sauvegardes immuables. Puis industrialiser les politiques en Policy as Code.
4. Mise en œuvre outillée Déployer les correctifs sur Azure ou AWS, versionnés en Infrastructure as Code (Terraform, Bicep) dans vos dépôts, pour la traçabilité et la réversibilité.
5. Preuves et gouvernance Formaliser les politiques, organiser la conservation des preuves, préparer le runbook de notification d'incident et la supervision par la direction.
6. Supervision continue Maintenir la posture dans le temps : détection, revue périodique, mesure de la dérive. La conformité NIS2 est un état à entretenir, pas un projet à clore.

Les repères de durée et de budget ci-dessous concernent le cadrage et la mise en conformité du périmètre cloud. Ils sont indicatifs et dépendent surtout du nombre de comptes ou d'abonnements, de la maturité de départ et du niveau d'exigence propre à votre statut EE ou EI.

• 3 à 10 jcadrage et mise en conformité du périmètre cloud (selon maturité)
• 7 à 18 k€budget indicatif, sur devis selon le périmètre
• 10mesures de l'article 21 à couvrir et à prouver
• IaCconfigurations versionnées, réutilisables comme preuves

Notre rôle : intermédiaire indépendant

Cette conformité se cadre au sein d'une démarche plus large. Voyez nos services, notre cybersécurité cloud, le panorama complet de la conformité cloud, l'approche par secteur industrie et secteur santé souvent concernés par NIS2, ainsi que le guide du cloud pour les fondamentaux.

Vous vous demandez si vous êtes concerné par NIS2 et où se situent vos écarts sur Azure ou AWS ? Faites le point en quelques minutes avec notre diagnostic en ligne, ou échangez avec notre équipe : nous qualifions votre éligibilité et vous orientons vers des prestataires disposant des certifications requises. Réponse sous 48 h ouvrées.

FAQ : NIS2 dans le cloud

Qu'est-ce que la directive NIS2 et concerne-t-elle mon infrastructure cloud ?

NIS2 (directive UE 2022/2555) rehausse le niveau de cybersécurité d'un large ensemble d'entités jugées importantes pour l'économie. Elle concerne directement votre cloud : la plupart des dix mesures de l'article 21 (analyse de risque, gestion d'incident, continuité, chiffrement, MFA, contrôle d'accès) se mettent en œuvre et se prouvent sur votre environnement Azure ou AWS. Votre statut de fournisseur ne vous exonère pas : c'est votre organisation qui est l'entité régulée.

Comment savoir si je suis une entité essentielle ou importante ?

Le classement croise le secteur d'activité et la taille. Les grandes entreprises des secteurs de haute criticité (énergie, transport, banque, santé, eau, infrastructures numériques, administration) sont essentielles ; les entités de taille moyenne et celles des autres secteurs critiques sont importantes. Le seuil de bascule reprend la définition européenne des PME (250 salariés ou 50 M€ de chiffre d'affaires pour la grande entreprise). Certaines entités sont concernées quelle que soit leur taille. La qualification précise est le premier travail de conformité.

Quelles sont les 10 mesures de l'article 21 de NIS2 ?

Analyse des risques et politique de sécurité, gestion des incidents, continuité d'activité, sécurité de la chaîne d'approvisionnement, sécurité du développement et gestion des vulnérabilités, évaluation de l'efficacité des mesures, cyber-hygiène et formation, cryptographie et chiffrement, sécurité RH et contrôle d'accès et gestion des actifs, enfin authentification multifacteur et communications sécurisées. Ce sont des résultats attendus, à traduire en configuration concrète sur votre cloud.

Héberger chez Azure ou AWS me met-il automatiquement en conformité NIS2 ?

Non. Vos fournisseurs sécurisent leur infrastructure au titre du modèle de responsabilité partagée, mais l'entité régulée reste votre organisation. Vous devez couvrir et prouver les dix mesures sur votre propre périmètre : vos comptes, vos identités, vos configurations, vos procédures. Les attestations du fournisseur sont un élément d'entrée utile pour la mesure « chaîne d'approvisionnement », jamais une conformité automatique.

Quels sont les délais de notification d'incident sous NIS2 ?

Pour un incident significatif : une alerte précoce sous 24 heures après la prise de connaissance, une notification d'incident sous 72 heures avec évaluation de la gravité et de l'impact, un rapport intermédiaire sur demande de l'autorité, et un rapport final sous un mois décrivant la cause racine et les mesures prises. En France, l'autorité destinataire est l'ANSSI.

NIS2 et RGPD imposent-ils une double notification ?

Oui, si l'incident touche des données personnelles. NIS2 impose une notification à l'ANSSI (24 h / 72 h / 1 mois) et le RGPD une notification à la CNIL sous 72 heures en cas de violation de données personnelles. Ces obligations coexistent. Un runbook de réponse à incident unique doit orchestrer les deux, avec des modèles de rapport prêts à l'emploi.

Quelles sanctions en cas de non-conformité NIS2 ?

Pour une entité essentielle, jusqu'à 10 M€ ou 2 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu. Pour une entité importante, jusqu'à 7 M€ ou 1,4 %. S'ajoutent des mesures correctrices contraignantes et, pour les entités essentielles, la possibilité de suspendre temporairement certaines fonctions dirigeantes. Les dirigeants peuvent être tenus personnellement responsables.

Les dirigeants sont-ils personnellement responsables sous NIS2 ?

Oui. NIS2 impose aux organes de direction d'approuver les mesures de gestion des risques, d'en superviser la mise en œuvre et de suivre une formation adaptée. En cas de manquement, leur responsabilité peut être engagée. La cybersécurité cesse d'être un sujet purement technique délégué à la DSI pour devenir une responsabilité de gouvernance.

Quelle différence entre NIS2, ISO 27001 et DORA ?

NIS2 est une directive obligatoire de cybersécurité pour de nombreux secteurs, centrée sur la gouvernance, la notification et le risque tiers. ISO 27001 est une norme certifiable volontaire qui structure un système de management de la sécurité et fournit un socle de preuves réutilisable. DORA est un règlement obligatoire propre au secteur financier, plus exigeant sur la résilience opérationnelle. Un bon SMSI ISO 27001 couvre une large part de NIS2 ; pour la finance, DORA prime en tant que texte sectoriel spécialisé.

Comment gérer le risque lié à mes fournisseurs cloud sous NIS2 ?

La mesure 4 de l'article 21 vous rend responsable du risque de chaîne d'approvisionnement. Il ne s'agit pas d'auditer Azure ou AWS, mais de tenir un inventaire des fournisseurs critiques, de récupérer et documenter leurs attestations, d'encadrer contractuellement la sécurité et la notification, de scanner vos dépendances logicielles, et de préparer une stratégie de sortie. Une architecture réversible (code IaC dans vos dépôts, comptes à votre nom) facilite structurellement cette maîtrise.

Par où commencer une mise en conformité NIS2 sur Azure ou AWS ?

Par la qualification de votre éligibilité (EE, EI ou hors périmètre), puis une analyse d'écart face aux dix mesures de l'article 21 sur votre périmètre cloud. Elle débouche sur une matrice d'écart et un plan d'action priorisé : d'abord MFA, fermeture des expositions, journalisation et sauvegardes immuables, ensuite l'industrialisation des politiques et la préparation des preuves. Un diagnostic mesure votre point de départ avant toute remédiation.

Combien de temps et de budget prévoir pour se mettre en conformité NIS2 ?

Pour le cadrage et la mise en conformité d'un périmètre cloud, comptez un budget indicatif de 7 000 à 18 000 € et une durée de 3 à 10 jours, sur devis selon le périmètre. Ces repères dépendent du nombre de comptes ou d'abonnements, de la maturité de départ et de votre statut EE ou EI. La conformité elle-même se maintient ensuite dans la durée par une supervision continue.