Source: OJ L, 2024/2690, 18.10.2024Current language: FR
Cybersecurity measures and significant incidents for relevant entities
RÈGLEMENT D’EXÉCUTION (UE) 2024/2690 DE LA COMMISSION
du 17 octobre 2024
établissant des règles relatives à l’application de la directive (UE) 2022/2555 pour ce qui est des exigences techniques et méthodologiques liées aux mesures de gestion des risques en matière de cybersécurité et précisant plus en détail les cas dans lesquels un incident est considéré comme important, en ce qui concerne les fournisseurs de services DNS, les registres des noms de domaine de premier niveau, les fournisseurs de services d’informatique en nuage, les fournisseurs de services de centres de données, les fournisseurs de réseaux de diffusion de contenu, les fournisseurs de services gérés, les fournisseurs de services de sécurité gérés, ainsi que les fournisseurs de places de marché en ligne, de moteurs de recherche en ligne et de plateformes de services de réseaux sociaux, et les prestataires de services de confiance
LA COMMISSION EUROPÉENNE,
vu le traité sur le fonctionnement de l’Union européenne,
vu la directive (UE) 2022/2555 du Parlement européen et du Conseil du 14 décembre 2022 concernant des mesures destinées à assurer un niveau élevé commun de cybersécurité dans l’ensemble de l’Union, modifiant le règlement (UE) no 910/2014 et la directive (UE) 2018/1972, et abrogeant la directive (UE) 2016/1148 (directive SRI 2)(1)JO L 333 du 27.12.2022, p. 80, ELI: http://data.europa.eu/eli/dir/2022/2555/oj., et notamment son article 21, paragraphe 5, premier alinéa, et son article 23, paragraphe 11, deuxième alinéa,
considérant ce qui suit:
Considérant 1Relevant entities and purpose of regulation
En ce qui concerne les fournisseurs de services DNS, les registres des noms de domaines de premier niveau, les fournisseurs de services d’informatique en nuage, les fournisseurs de services de centres de données, les fournisseurs de réseaux de diffusion de contenu, les fournisseurs de services gérés, les fournisseurs de services de sécurité gérés, les fournisseurs de places de marché en ligne, de moteurs de recherche en ligne et de plateformes de services de réseaux sociaux et les fournisseurs de services de confiance relevant de l’article 3 de la directive (UE) 2022/2555 (ci-après les «entités concernées»), le présent règlement vise à établir les exigences techniques et méthodologiques liées aux mesures visées à l’article 21, paragraphe 2, de la directive (UE) 2022/2555 et à préciser plus en détail les cas dans lesquels un incident devrait être considéré comme important au sens de l’article 23, paragraphe 3, de la directive (UE) 2022/2555.
Considérant 2Trust service providers
Compte tenu de la nature transfrontière de leurs activités et afin de garantir un cadre cohérent pour les prestataires de services de confiance, le présent règlement devrait, en ce qui concerne ces prestataires de services, préciser plus en détail les cas dans lesquels un incident est considéré comme important, en plus d’établir les exigences techniques et méthodologiques liées aux mesures de gestion des risques en matière de cybersécurité.
Considérant 3Based on standards and technical specifications
Conformément à l’article 21, paragraphe 5, troisième alinéa, de la directive (UE) 2022/2555, les exigences techniques et méthodologiques liées aux mesures de gestion des risques de cybersécurité énoncées à l’annexe du présent règlement sont fondées sur des normes européennes et internationales, telles que ISO/IEC 27001, ISO/IEC 27002 et ETSI EN 319401, et sur des spécifications techniques, telles que CEN/TS 18026: 2024, pertinentes pour la sécurité des réseaux et des systèmes d’information.
Considérant 4Principle of proportionality
En ce qui concerne la mise en œuvre et l’application des exigences techniques et méthodologiques liées aux mesures de gestion des risques en matière de cybersécurité énoncées à l’annexe du présent règlement, conformément au principe de proportionnalité, il convient de tenir dûment compte des différences d’exposition au risque des entités concernées, telles que la criticité de l’entité, les risques auxquels elle est exposée, la taille et la structure de l’entité, ainsi que la probabilité de survenance d’incidents et leur gravité, y compris leur impact sociétal et économique, lorsque ces entités se conforment aux exigences techniques et méthodologiques liées aux mesures de gestion des risques en matière de cybersécurité énoncées à l’annexe du présent règlement.
Considérant 5Compensating measures
Conformément au principe de proportionnalité, lorsque les entités concernées ne peuvent pas, en raison de leur taille, mettre en œuvre certaines des exigences techniques et méthodologiques liées aux mesures de gestion des risques en matière de cybersécurité, ces entités devraient être en mesure de prendre d’autres mesures compensatoires appropriées pour atteindre l’objectif de ces exigences. Par exemple, lors de la définition des rôles, des responsabilités et des pouvoirs en matière de sécurité des réseaux et des systèmes d’information au sein de l’entité concernée, les micro-entités pourraient éprouver des difficultés à séparer les fonctions incompatibles et les domaines de responsabilité contradictoires. Ces entités devraient être en mesure d’envisager des mesures compensatoires telles qu’une surveillance ciblée exercée par la direction de l’entité ou une intensification du suivi et de la journalisation.
Considérant 6Applicability of requirements
Certaines exigences techniques et méthodologiques énoncées à l’annexe du présent règlement devraient être appliquées par les entités concernées s’il est besoin, s’il y a lieu ou dans la mesure du possible. Lorsqu’une entité concernée estime qu’il n’est pas besoin, qu’il n’y a pas lieu, ou qu’il est impossible pour elle d’appliquer certaines de ces exigences techniques et méthodologiques prévues à l’annexe du présent règlement, elle documente de manière compréhensible son argumentation en ce sens. Lorsqu’elles exercent une supervision, les autorités nationales compétentes peuvent tenir compte du temps nécessaire aux entités concernées pour mettre en œuvre les exigences techniques et méthodologiques liées aux mesures de gestion des risques en matière de cybersécurité.
Considérant 7Guidance, tools and templates
L’ENISA ou les autorités nationales compétentes au titre de la directive (UE) 2022/2555 peuvent fournir des orientations pour aider les entités concernées à identifier, analyser et évaluer les risques aux fins de la mise en œuvre des exigences techniques et méthodologiques concernant la mise en place et le maintien d’un cadre approprié de gestion des risques. Ces orientations peuvent comprendre, en particulier, des évaluations des risques nationales et sectorielles ainsi que des évaluations des risques spécifiques à un certain type d’entité. Les orientations peuvent également comprendre des outils ou des modèles pour l’élaboration d’un cadre de gestion des risques au niveau des entités concernées. Les cadres, orientations ou autres mécanismes prévus par le droit national des États membres, ainsi que des normes européennes et internationales pertinentes peuvent également aider les entités concernées à apporter la preuve du respect du présent règlement d’exécution. En outre, l’ENISA ou les autorités nationales compétentes au titre de la directive (UE) 2022/2555 peuvent aider les entités concernées à trouver et à mettre en œuvre des solutions appropriées pour traiter les risques identifiés dans ces évaluations des risques. Ces orientations devraient être sans préjudice de l’obligation des entités concernées d’identifier et de documenter les risques pour la sécurité des réseaux et des systèmes d’information, ainsi que de l’obligation, pour les entités concernées, de mettre en œuvre les exigences techniques et méthodologiques liées aux mesures de gestion des risques de cybersécurité énoncées à l’annexe du présent règlement en fonction de leurs besoins et de leurs ressources.
Considérant 8Multi-stakeholder forum to identify best practices
Les mesures de sécurité des réseaux concernant: i) la transition vers des protocoles de communication de la dernière génération au niveau de la couche réseau, ii) le déploiement de normes modernes de communication par courrier électronique internationalement reconnues et interopérables, et iii) l’application des meilleures pratiques en matière de sécurité DNS, de sécurité du routage sur internet et d’hygiène du routage posent des difficultés particulières eu égard à l’inventaire des meilleures normes et techniques de déploiement disponibles. Afin d’atteindre dès que possible un niveau élevé commun de cybersécurité sur l’ensemble des réseaux, la Commission, avec l’aide de l’Agence de l’Union européenne pour la cybersécurité (ENISA) et en collaboration avec les autorités compétentes, l’industrie — y compris le secteur des télécommunications — et d’autres parties prenantes, devrait soutenir la mise en place d’un forum multipartite chargé d’inventorier ces meilleures normes et techniques de déploiement disponibles. Ces orientations multipartites devraient être sans préjudice de l’obligation, pour les entités concernées, de mettre en œuvre les exigences techniques et méthodologiques liées aux mesures de gestion des risques de cybersécurité énoncées à l’annexe du présent règlement.
Considérant 9Security policies
Conformément à l’article 21, paragraphe 2, point a), de la directive (UE) 2022/2555, les entités essentielles et importantes devraient être dotées de politiques relatives à l’analyse des risques ainsi que de politiques relatives à la sécurité des systèmes d’information. À cette fin, les entités concernées devraient établir une politique relative à la sécurité des réseaux et des systèmes d’information ainsi que des politiques concernant des domaines spécifiques, telles que des politiques en matière de contrôle d’accès, qui devraient être cohérentes avec la politique relative à la sécurité des réseaux et des systèmes d’information. La politique relative à la sécurité des réseaux et des systèmes d’information devrait occuper le plus haut niveau de la hiérarchie des documents définissant l’approche globale des entités concernées en matière de sécurité de leurs réseaux et systèmes d’information et elle devrait être approuvée par les organes de direction des entités concernées. Les politiques concernant des domaines spécifiques devraient être approuvées à un niveau hiérarchique approprié. La politique devrait définir des indicateurs et des mesures permettant de suivre sa mise en œuvre et l’état actuel du niveau de maturité des entités concernées en matière de sécurité des réseaux et de l’information, en particulier pour faciliter la surveillance de la mise en œuvre des mesures de gestion des risques en matière de cybersécurité par l’intermédiaire des organes de direction.
Considérant 10Definition of 'user'
Aux fins des exigences techniques et méthodologiques énoncées à l’annexe du présent règlement, le terme «utilisateur» devrait englober toutes les personnes physiques et morales qui ont accès au réseau et aux systèmes d’information de l’entité.
Considérant 11Risk management framework
Afin d’identifier et de traiter les risques qui pèsent sur la sécurité des réseaux et des systèmes d’information, les entités concernées devraient établir et maintenir un cadre approprié de gestion des risques. Les entités concernées devraient inscrire dans ce cadre l’établissement, la mise en œuvre et le suivi d’un plan de traitement des risques. Les entités concernées peuvent utiliser le plan de traitement des risques pour inventorier et hiérarchiser les options et les mesures relatives au traitement des risques. Parmi les options de traitement des risques figurent notamment la prévention, la réduction ou, dans des cas exceptionnels, l’acceptation des risques. Le choix des options de traitement des risques devrait tenir compte des résultats de l’évaluation des risques effectuée par l’entité concernée et être conforme à la politique de cette dernière en matière de sécurité des réseaux et des systèmes d’information. Afin de donner effet aux options de traitement des risques choisies, les entités concernées devraient prendre les mesures de traitement des risques appropriées.
Considérant 12Network and information system monitoring
Pour détecter les événements, les incidents évités et les incidents, les entités concernées devraient surveiller leur réseau et leurs systèmes d’information et prendre des mesures pour évaluer les événements, les incidents évités et les incidents. Ces mesures devraient permettre de détecter en temps utile les attaques réseau en se fondant sur des schémas anormaux de trafic entrant et sortant, ainsi que les attaques par déni de service.
Considérant 13Business impact analysis
Lorsque les entités concernées procèdent à une analyse de l’impact sur l’activité, elles sont encouragées à réaliser une analyse complète établissant, le cas échéant, les temps d’arrêt maximaux tolérables, les objectifs de délai de rétablissement, les objectifs de points de rétablissement et les objectifs de fourniture de services.
Considérant 14Supply chain security policy
Afin d’atténuer les risques découlant de la chaîne d’approvisionnement d’une entité concernée et des relations de cette dernière avec ses fournisseurs, les entités concernées devraient établir une politique de sécurité de la chaîne d’approvisionnement régissant leurs relations avec leurs fournisseurs et prestataires de services directs. Ces entités devraient faire figurer dans les contrats conclus avec leurs fournisseurs ou prestataires de services directs des clauses de sécurité adéquates, par exemple en exigeant, le cas échéant, des mesures de gestion des risques en matière de cybersécurité conformément à l’article 21, paragraphe 2, de la directive (UE) 2022/2555 ou en imposant d’autres exigences légales similaires.
Considérant 15Security test policy
Les entités concernées devraient effectuer régulièrement des tests de sécurité sur la base d’une politique et de procédures ad hoc afin de vérifier si les mesures de gestion des risques en matière de cybersécurité sont mises en œuvre et fonctionnent correctement. Les tests de sécurité peuvent être effectués sur des réseaux et systèmes d’information spécifiques ou sur l’entité concernée dans son ensemble et peuvent comprendre des tests automatisés ou manuels, des tests d’intrusion, des analyses de vulnérabilité, des tests dynamiques ou statiques de sécurité des applications, des tests de configuration ou des audits de sécurité. Les entités concernées peuvent effectuer des tests de sécurité sur leur réseau et leurs systèmes d’information lors de la mise en place, après des mises à niveau ou des modifications d’infrastructures ou d’applications qu’elles jugent importantes, ou après des opérations de maintenance. Les résultats des tests de sécurité devraient éclairer les politiques et procédures des entités concernées visant à évaluer l’efficacité des mesures de gestion des risques en matière de cybersécurité, ainsi que les examens indépendants de leurs politiques de sécurité des réseaux et de l’information.
Considérant 16Security patch management procedures
Afin d’éviter que l’exploitation de vulnérabilités non corrigées dans les réseaux et les systèmes d’information ne cause des perturbations et des préjudices importants, les entités concernées devraient définir et appliquer des procédures appropriées de gestion des correctifs de sécurité qui soient alignées sur leurs procédures pertinentes en matière de gestion des changements, gestion des vulnérabilités, gestion des risques et autres. Les entités concernées devraient prendre des mesures proportionnées à leurs ressources pour veiller à ce que les correctifs de sécurité n’introduisent pas de vulnérabilités ou d’instabilités supplémentaires. Si le service est inaccessible en raison de l’application de correctifs de sécurité, les entités concernées sont encouragées à en informer dûment les clients à l’avance.
Considérant 17Certified ICT products and services
Les entités concernées devraient gérer les risques découlant de l’acquisition de produits ou de services TIC auprès de fournisseurs ou de prestataires de services et devraient obtenir l’assurance que les produits ou services TIC à acquérir atteignent certains niveaux de protection en matière de cybersécurité, par exemple au moyen de certificats de cybersécurité européens et de déclarations de conformité de l’UE pour des produits ou services TIC délivrés dans le cadre d’un schéma européen de certification de cybersécurité adopté en vertu de l’article 49 du règlement (UE) 2019/881 du Parlement européen et du Conseil(2)Règlement (UE) 2019/881 du Parlement européen et du Conseil du 17 avril 2019 relatif à l’ENISA (Agence de l’Union européenne pour la cybersécurité) et à la certification de cybersécurité des technologies de l’information et des communications, et abrogeant le règlement (UE) no 526/2013 (règlement sur la cybersécurité) (JO L 151 du 7.6.2019, p. 15, ELI: http://data.europa.eu/eli/reg/2019/881/oj).. Lorsque les entités concernées fixent des exigences de sécurité à imposer aux produits TIC à acquérir, elles devraient tenir compte des exigences essentielles en matière de cybersécurité énoncées dans un règlement du Parlement européen et du Conseil concernant des exigences horizontales en matière de cybersécurité pour les produits comportant des éléments numériques.
Considérant 18Network security solutions
Afin de se protéger contre les cybermenaces et d’aider à prévenir et à endiguer les violations de données, les entités concernées devraient mettre en œuvre des solutions en matière de sécurité des réseaux. Ces solutions consistent généralement à utiliser des pare-feu pour protéger les réseaux internes des entités concernées, à limiter les connexions et les accès aux services auxquels ces connexions et accès sont absolument nécessaires, à recourir à des réseaux privés virtuels pour l’accès à distance, à soumettre les connexions des fournisseurs de services à une demande d’autorisation et à limiter ces connexions à une durée déterminée telle que la durée d’une opération de maintenance.
Considérant 19Endpoint protection
Afin de protéger les réseaux des entités concernées et leurs systèmes d’information contre les logiciels malveillants et non autorisés, ces entités devraient mettre en œuvre des contrôles qui préviennent ou détectent l’utilisation de logiciels non autorisés et devraient, le cas échéant, utiliser des logiciels de détection et de réaction. Les entités concernées devraient également envisager de mettre en œuvre des mesures visant à réduire au minimum la surface d’attaque, à réduire les vulnérabilités qui peuvent être exploitées par les auteurs d’attaques, à contrôler l’exécution des applications sur les points terminaux et à déployer des filtres de messagerie électronique et d’applications web afin de réduire l’exposition aux contenus malveillants.
Considérant 20Basic cyber hygiene and awareness training
Conformément à l’article 21, paragraphe 2, point g), de la directive (UE) 2022/2555, les États membres doivent veiller à ce que les entités essentielles et importantes appliquent des pratiques élémentaires en matière d’hygiène informatique et de formation à la cybersécurité. Parmi les pratiques élémentaires d’hygiène informatique figurent les principes «confiance zéro», les mises à jour de logiciels, la configuration des dispositifs, la segmentation des réseaux, la gestion des identités et des accès ou la sensibilisation des utilisateurs, l’organisation d’une formation pour le personnel et la sensibilisation aux cybermenaces, à l’hameçonnage ou aux techniques d’ingénierie sociale. Les pratiques d’hygiène informatique font partie des différentes exigences techniques et méthodologiques liées aux mesures de gestion des risques de cybersécurité énoncées à l’annexe du présent règlement. En ce qui concerne les pratiques élémentaires en matière d’hygiène informatique pour les utilisateurs, les entités concernées devraient envisager des pratiques telles que des politiques claires relatives aux bureaux et aux écrans, l’utilisation de moyens d’authentification multifactoriels et autres, l’utilisation sûre du courrier électronique et la navigation sur le web, la protection contre l’hameçonnage et l’ingénierie sociale ou encore les pratiques de travail à distance sécurisées.
Considérant 21Access control policy
Afin d’empêcher l’accès non autorisé à leurs actifs, les entités concernées devraient établir et mettre en œuvre une politique spécifique concernant l’accès par des personnes et par des réseaux et systèmes d’information, tels que les applications.
Considérant 22Personnel security
Afin d’éviter que les employés ne puissent abuser, par exemple, des droits d’accès au sein de l’entité concernée pour causer un préjudice et des dommages, les entités concernées devraient envisager des mesures appropriées de gestion de la sécurité du personnel et sensibiliser le personnel à ces risques. Les entités concernées devraient établir, communiquer et maintenir une procédure disciplinaire de traitement des violations de leurs politiques de sécurité des réseaux et des systèmes d’information, qui peut être intégrée dans d’autres procédures disciplinaires établies par ces entités. Les vérifications des antécédents des employés et, s’il y a lieu, des fournisseurs et des prestataires de services directs des entités concernées devraient contribuer à l’objectif de sécurité des ressources humaines dans les entités concernées et peuvent comprendre des mesures telles que des vérifications du casier judiciaire ou des fonctions professionnelles passées de la personne, selon les fonctions qu’elle occupe au sein de l’entité concernée et conformément à la politique de l’entité concernée en matière de sécurité des réseaux et des systèmes d’information.
Considérant 23Multi-factor authentication
L’authentification multifactorielle peut renforcer la cybersécurité des entités et ces dernières devraient l’envisager, en particulier lorsque les utilisateurs accèdent à des réseaux et à des systèmes d’information à distance, ou lorsqu’ils accèdent à des informations sensibles ou à des comptes privilégiés et à des comptes d’administration de systèmes. L’authentification multifactorielle peut être combinée à d’autres techniques pour exiger des facteurs supplémentaires dans des circonstances particulières, sur la base de règles et de modèles prédéfinis, tels que l’accès depuis un lieu inhabituel, à partir d’un dispositif inhabituel ou à un moment inhabituel.
Considérant 24Asset management
Les entités concernées devraient assurer la gestion et la protection des actifs ayant de la valeur pour elles en mettant en place une gestion saine des actifs qui devrait également servir de base à l’analyse des risques et à la gestion de la continuité de l’activité. Les entités concernées devraient gérer à la fois les actifs matériels et immatériels et créer un inventaire des actifs, associer à chaque actif un niveau de classification précis, assurer le traitement et la traçabilité des actifs et prendre des mesures pour les protéger tout au long de leur cycle de vie.
Considérant 25Asset classification
La gestion des actifs devrait consister à classer les actifs en fonction de leur type, de leur sensibilité, de leur niveau de risque et des exigences en matière de sécurité, et à appliquer des mesures et des contrôles appropriés pour garantir leur disponibilité, leur intégrité, leur confidentialité et leur authenticité. En classant les actifs par niveau de risque, les entités concernées devraient pouvoir appliquer des mesures et des contrôles de sécurité appropriés pour protéger les actifs, telles que le chiffrement, le contrôle d’accès, y compris le contrôle du périmètre et de l’accès physique et logique, les sauvegardes, la journalisation et le suivi, la conservation et l’élimination. Lorsqu’elles procèdent à une analyse d’impact sur l’activité, les entités concernées peuvent déterminer le niveau de classification en fonction des conséquences qu’aurait une perturbation des actifs pour les entités. Tous les membres du personnel des entités qui sont amenés à traiter des actifs doivent connaître les politiques et les instructions en la matière.
Considérant 26Granularity of asset inventory
Il convient d’adapter le niveau de détail de l’inventaire des actifs aux besoins des entités concernées. Un inventaire complet des actifs pourrait comprendre, pour chaque actif, au moins un identifiant unique, le propriétaire de l’actif, une description de l’actif, la localisation de l’actif, le type d’actif, le type et la classification des informations traitées dans l’actif, la date de la dernière mise à jour ou du dernier correctif de l’actif, le classement de l’actif dans le cadre de l’évaluation des risques et la fin de vie de l’actif. Lorsqu’elles identifient le propriétaire d’un actif, les entités concernées devraient également identifier la personne responsable de la protection de cet actif.
Considérant 27Cybersecurity governance structure
La répartition et l’organisation des rôles, des responsabilités et des pouvoirs en matière de cybersécurité devraient permettre de mettre en place une structure cohérente pour la gouvernance et la mise en œuvre de la cybersécurité au sein des entités concernées, et d’assurer une communication efficace en cas d’incident. Lors de la définition et de l’attribution des responsabilités à certains rôles, les entités concernées devraient notamment tenir compte du rôle du directeur de la sécurité de l’information, du responsable de la sécurité de l’information, du responsable de la gestion des incidents, de l’auditeur ou d’équivalents comparables. Les entités concernées peuvent attribuer des rôles et des responsabilités à des parties externes, telles que des tiers prestataires de services informatiques.
Considérant 28All-hazards approach to cybersecurity risk-management measures
Conformément à l’article 21, paragraphe 2, de la directive (UE) 2022/2555, les mesures de gestion des risques en matière de cybersécurité doivent se fonder sur une approche «tous risques» qui vise à protéger les réseaux et les systèmes d’information ainsi que leur environnement physique contre des événements tels que le vol, les incendies, les inondations, une défaillance des télécommunications ou une défaillance électrique, ou contre tout accès physique non autorisé et toute atteinte aux informations détenues par l’entité essentielle ou importante et aux installations de traitement de l’information de l’entité, ou toute interférence avec ces informations et installations, susceptibles de compromettre la disponibilité, l’authenticité, l’intégrité ou la confidentialité des données stockées, transmises ou traitées ou des services offerts par les réseaux et systèmes d’information ou accessibles par ceux-ci. Les exigences techniques et méthodologiques liées aux mesures de gestion des risques en matière de cybersécurité devraient donc également porter sur la sécurité physique et la sécurité de l’environnement des réseaux et des systèmes d’information, en incluant des mesures visant à protéger ces systèmes contre les défaillances du système, les erreurs humaines, les actes malveillants ou les phénomènes naturels. On peut citer d’autres exemples de menaces physiques et environnementales telles que les tremblements de terre, les explosions, le sabotage, la menace interne, les troubles civils, les déchets toxiques et les émissions dans l’environnement. La prévention de la perte, de la détérioration ou de la compromission de réseaux et systèmes d’information ou de l’interruption de leur fonctionnement en raison de la défaillance et de la perturbation de services d’utilité publique sous-jacents devrait contribuer à l’objectif de continuité de l’activité dans les entités concernées. En outre, la protection contre les menaces physiques et environnementales devrait contribuer à la sécurité de la maintenance des réseaux et des systèmes d’information dans les entités concernées.
Considérant 29Physical and environmental threats
Les entités devraient concevoir et mettre en œuvre des mesures de protection contre les menaces physiques et environnementales, fixer des seuils de contrôle minimaux et maximaux pour les menaces physiques et environnementales et surveiller les paramètres environnementaux. Par exemple, elles devraient envisager d’installer des systèmes permettant de détecter à un stade précoce les inondations dans les zones où se trouvent les réseaux et les systèmes d’information. En ce qui concerne le risque d’incendie, les entités concernées devraient envisager de mettre en place un compartiment coupe-feu séparé pour le centre de données, d’utiliser des matériaux résistant au feu, de recourir à des capteurs pour le contrôle de la température et de l’humidité, de raccorder le bâtiment à un système d’alarme incendie avec notification automatisée aux services locaux de lutte contre les incendies, et de faire appel à des systèmes de détection et d’extinction précoces des incendies. Les entités concernées devraient également procéder régulièrement à des exercices d’incendie et à des inspections de sécurité incendie. En outre, pour assurer l’alimentation électrique, les entités concernées devraient envisager une protection contre les surtensions et une alimentation électrique de secours correspondante, conformément aux normes applicables. Par ailleurs, étant donné que la surchauffe présente un risque pour la disponibilité des réseaux et des systèmes d’information, les entités concernées, en particulier les fournisseurs de services de centres de données, pourraient envisager des systèmes de climatisation adéquats, fonctionnant en continu et redondants.
Considérant 30Criteria for significant incidents
Le présent règlement doit préciser plus en détail les cas dans lesquels un incident devrait être considéré comme important au sens de l’article 23, paragraphe 3, de la directive (UE) 2022/2555. Les critères devraient être tels que les entités concernées soient en mesure d’évaluer si un incident est important afin de le notifier conformément à la directive (UE) 2022/2555. En outre, les critères énoncés dans le présent règlement devraient être considérés comme exhaustifs, sans préjudice de l’article 5 de la directive (UE) 2022/2555. Le présent règlement précise les cas dans lesquels un incident devrait être considéré comme important en définissant des cas horizontaux ainsi que des cas spécifiques à l’entité.
- Article 3 Incidents importants
- Article 5 Incidents importants concernant les fournisseurs de services DNS
- Article 6 Incidents importants concernant les registres de noms de domaine de premier niveau
- Article 7 Incidents importants concernant les fournisseurs de services d’informatique en nuage
- Article 8 Incidents importants concernant les fournisseurs de services de centres de données
- Article 9 Incidents importants concernant les fournisseurs de réseaux de diffusion de contenu
- Article 10 Incidents importants concernant les fournisseurs de services gérés et les fournisseurs de services de sécurité gérés
- Article 11 Incidents importants concernant les fournisseurs de places de marché en ligne
- Article 12 Incidents importants concernant les fournisseurs de moteurs de recherche en ligne
- Article 13 Incidents importants concernant les fournisseurs de plateformes de services de réseaux sociaux
- Article 14 Incidents importants concernant les fournisseurs de services de confiance
Considérant 31Notification of significant incidents
L’article 23, paragraphe 4, de la directive (UE) 2022/2555 prévoit que les entités concernées notifient les incidents importants dans les délais fixés audit article. Ces délais de notification courent à partir du moment où l’entité a connaissance de tels incidents importants. Par conséquent, l’entité concernée est tenue de notifier les incidents qui, selon son évaluation initiale, pourraient entraîner des perturbations opérationnelles graves des services ou des pertes financières pour ladite entité, ou nuire à d’autres personnes physiques ou morales en causant un dommage matériel, corporel ou moral considérable. Par conséquent, lorsqu’une entité concernée a détecté un événement suspect, ou après qu’un incident potentiel a été porté à son attention par un tiers, tel qu’un particulier, un client, une entité, une autorité, un organisme de médias ou une autre source, l’entité concernée devrait évaluer en temps opportun l’événement suspect afin de déterminer s’il constitue un incident et, dans l’affirmative, en déterminer la nature et la gravité. Il convient donc de considérer que l’entité concernée a «eu connaissance» de l’incident important lorsque, après avoir procédé à cette évaluation initiale, elle est raisonnablement certaine qu’un incident important s’est produit.
- Article 3 Incidents importants
- Article 5 Incidents importants concernant les fournisseurs de services DNS
- Article 6 Incidents importants concernant les registres de noms de domaine de premier niveau
- Article 7 Incidents importants concernant les fournisseurs de services d’informatique en nuage
- Article 8 Incidents importants concernant les fournisseurs de services de centres de données
- Article 9 Incidents importants concernant les fournisseurs de réseaux de diffusion de contenu
- Article 10 Incidents importants concernant les fournisseurs de services gérés et les fournisseurs de services de sécurité gérés
- Article 11 Incidents importants concernant les fournisseurs de places de marché en ligne
- Article 12 Incidents importants concernant les fournisseurs de moteurs de recherche en ligne
- Article 13 Incidents importants concernant les fournisseurs de plateformes de services de réseaux sociaux
- Article 14 Incidents importants concernant les fournisseurs de services de confiance
Considérant 32Identifying significant incidents
Afin d’établir si un incident est important, le cas échéant, les entités concernées devraient compter le nombre d’utilisateurs touchés par l’incident, en tenant compte des clients professionnels et des clients finaux avec lesquels elles entretiennent une relation contractuelle ainsi que des personnes physiques et morales qui sont associées à des clients professionnels. Lorsqu’une entité concernée n’est pas en mesure de calculer le nombre d’utilisateurs touchés, il y a lieu de prendre en considération, aux fins du calcul du nombre total d’utilisateurs touchés par l’incident, l’estimation du nombre maximal possible d’utilisateurs touchés effectuée par cette entité. L’importance d’un incident impliquant un service de confiance devrait être déterminée non seulement par le nombre d’utilisateurs, mais aussi par le nombre de parties utilisatrices, celles-ci pouvant être affectées au même titre par un incident important impliquant un service de confiance en ce qui concerne une perturbation opérationnelle ou un préjudice matériel ou moral. Par conséquent, les prestataires de services de confiance devraient, le cas échéant, également tenir compte du nombre de parties utilisatrices lorsqu’ils établissent si un incident est important. À cette fin, il convient d’entendre par parties utilisatrices des personnes physiques ou morales qui utilisent un service de confiance.
- Article 3 Incidents importants
- Article 5 Incidents importants concernant les fournisseurs de services DNS
- Article 6 Incidents importants concernant les registres de noms de domaine de premier niveau
- Article 7 Incidents importants concernant les fournisseurs de services d’informatique en nuage
- Article 8 Incidents importants concernant les fournisseurs de services de centres de données
- Article 9 Incidents importants concernant les fournisseurs de réseaux de diffusion de contenu
- Article 10 Incidents importants concernant les fournisseurs de services gérés et les fournisseurs de services de sécurité gérés
- Article 11 Incidents importants concernant les fournisseurs de places de marché en ligne
- Article 12 Incidents importants concernant les fournisseurs de moteurs de recherche en ligne
- Article 13 Incidents importants concernant les fournisseurs de plateformes de services de réseaux sociaux
- Article 14 Incidents importants concernant les fournisseurs de services de confiance
Considérant 33Scheduled downtime
Les opérations de maintenance entraînant une disponibilité limitée ou une indisponibilité des services ne devraient pas être considérées comme des incidents importants si la disponibilité limitée ou l’indisponibilité du service survient à la suite d’une opération de maintenance programmée. En outre, l’indisponibilité d’un service en raison d’interruptions telles que des interruptions programmées ou une indisponibilité sur la base d’un accord contractuel prédéterminé ne devrait pas être considérée comme un incident important.
- Article 3 Incidents importants
- Article 5 Incidents importants concernant les fournisseurs de services DNS
- Article 6 Incidents importants concernant les registres de noms de domaine de premier niveau
- Article 7 Incidents importants concernant les fournisseurs de services d’informatique en nuage
- Article 8 Incidents importants concernant les fournisseurs de services de centres de données
- Article 9 Incidents importants concernant les fournisseurs de réseaux de diffusion de contenu
- Article 10 Incidents importants concernant les fournisseurs de services gérés et les fournisseurs de services de sécurité gérés
- Article 11 Incidents importants concernant les fournisseurs de places de marché en ligne
- Article 12 Incidents importants concernant les fournisseurs de moteurs de recherche en ligne
- Article 13 Incidents importants concernant les fournisseurs de plateformes de services de réseaux sociaux
- Article 14 Incidents importants concernant les fournisseurs de services de confiance
Considérant 34Duration of incidents
La durée d’un incident ayant des conséquences sur la disponibilité d’un service devrait être mesurée à partir de l’interruption de la fourniture correcte de ce service jusqu’au moment du rétablissement. Lorsqu’une entité concernée n’est pas en mesure de déterminer le moment à partir duquel l’interruption a commencé, la durée de l’incident devrait être mesurée à partir du moment où l’incident a été détecté, ou de celui où l’incident a été enregistré dans les journaux du réseau, du système ou d’autres sources de données, selon l’éventualité qui intervient en premier.
- Article 3 Incidents importants
- Article 5 Incidents importants concernant les fournisseurs de services DNS
- Article 6 Incidents importants concernant les registres de noms de domaine de premier niveau
- Article 7 Incidents importants concernant les fournisseurs de services d’informatique en nuage
- Article 8 Incidents importants concernant les fournisseurs de services de centres de données
- Article 9 Incidents importants concernant les fournisseurs de réseaux de diffusion de contenu
- Article 10 Incidents importants concernant les fournisseurs de services gérés et les fournisseurs de services de sécurité gérés
- Article 11 Incidents importants concernant les fournisseurs de places de marché en ligne
- Article 12 Incidents importants concernant les fournisseurs de moteurs de recherche en ligne
- Article 13 Incidents importants concernant les fournisseurs de plateformes de services de réseaux sociaux
- Article 14 Incidents importants concernant les fournisseurs de services de confiance
Considérant 35Complete unavailability
L’indisponibilité totale d’un service devrait être mesurée à partir du moment où le service est totalement indisponible pour les utilisateurs et le moment où les activités ou opérations régulières ont retrouvé le niveau de service fourni avant l’incident. Lorsqu’une entité concernée n’est pas en mesure de déterminer quand l’indisponibilité totale d’un service a commencé, cette indisponibilité devrait être mesurée à partir du moment où elle a été détectée par cette entité.
- Article 3 Incidents importants
- Article 5 Incidents importants concernant les fournisseurs de services DNS
- Article 6 Incidents importants concernant les registres de noms de domaine de premier niveau
- Article 7 Incidents importants concernant les fournisseurs de services d’informatique en nuage
- Article 8 Incidents importants concernant les fournisseurs de services de centres de données
- Article 9 Incidents importants concernant les fournisseurs de réseaux de diffusion de contenu
- Article 10 Incidents importants concernant les fournisseurs de services gérés et les fournisseurs de services de sécurité gérés
- Article 11 Incidents importants concernant les fournisseurs de places de marché en ligne
- Article 12 Incidents importants concernant les fournisseurs de moteurs de recherche en ligne
- Article 13 Incidents importants concernant les fournisseurs de plateformes de services de réseaux sociaux
- Article 14 Incidents importants concernant les fournisseurs de services de confiance
Considérant 36Direct financial losses
Afin de déterminer les pertes financières directes résultant d’un incident, les entités concernées devraient tenir compte de toutes les pertes financières qu’elles ont subies à la suite de l’incident, telles que les coûts du remplacement ou du déplacement de logiciels, de matériel ou d’infrastructures, les frais de personnel, y compris les coûts liés au remplacement ou au déménagement du personnel, au recrutement de personnel supplémentaire, à la rémunération des heures supplémentaires et à la récupération des compétences perdues ou altérées, les frais dus au non-respect d’obligations contractuelles, les coûts de dédommagement et d’indemnisation des clients, les pertes dues aux recettes non perçues, les coûts liés à la communication interne et externe, les frais de conseil, y compris les coûts liés au conseil juridique, aux services d’investigation numérique et aux services de remédiation, et les autres coûts liés à l’incident. Toutefois, les amendes administratives, ainsi que les coûts qui sont nécessaires à la gestion quotidienne de l’activité, ne devraient pas être considérées comme des pertes financières résultant d’un incident, y compris les coûts de maintenance générale des infrastructures, des équipements, du matériel et des logiciels, la mise à jour des compétences du personnel, les coûts internes ou externes pour améliorer l’activité après l’incident, y compris les mises à niveau, les améliorations et les initiatives d’évaluation des risques, ainsi que les primes d’assurance. Les entités concernées devraient calculer le montant des pertes financières sur la base des données disponibles et avoir recours à une estimation lorsqu’il est impossible de déterminer le montant réel de ces pertes.
- Article 3 Incidents importants
- Article 5 Incidents importants concernant les fournisseurs de services DNS
- Article 6 Incidents importants concernant les registres de noms de domaine de premier niveau
- Article 7 Incidents importants concernant les fournisseurs de services d’informatique en nuage
- Article 8 Incidents importants concernant les fournisseurs de services de centres de données
- Article 9 Incidents importants concernant les fournisseurs de réseaux de diffusion de contenu
- Article 10 Incidents importants concernant les fournisseurs de services gérés et les fournisseurs de services de sécurité gérés
- Article 11 Incidents importants concernant les fournisseurs de places de marché en ligne
- Article 12 Incidents importants concernant les fournisseurs de moteurs de recherche en ligne
- Article 13 Incidents importants concernant les fournisseurs de plateformes de services de réseaux sociaux
- Article 14 Incidents importants concernant les fournisseurs de services de confiance
Considérant 37Effects on health of natural persons
Les entités concernées devraient également être tenues de signaler les incidents qui ont causé ou sont susceptibles de causer la mort de personnes physiques ou des dommages considérables à la santé de ces dernières, étant donné que ces incidents constituent des cas particulièrement graves de dommages matériels ou moraux considérables. Par exemple, un incident touchant une entité concernée pourrait entraîner l’indisponibilité de services de soins de santé ou d’urgence, ou une perte de confidentialité ou d’intégrité de données ayant une incidence sur la santé des personnes physiques. Pour déterminer si un incident a causé ou est susceptible de causer des dommages considérables à la santé d’une personne physique, les entités concernées devraient examiner si l’incident a causé ou est susceptible de causer des blessures graves et des problèmes de santé. Les entités concernées ne devraient pas être tenues de recueillir, à cette fin, des informations supplémentaires auxquelles elles n’ont pas accès.
- Article 3 Incidents importants
- Article 5 Incidents importants concernant les fournisseurs de services DNS
- Article 6 Incidents importants concernant les registres de noms de domaine de premier niveau
- Article 7 Incidents importants concernant les fournisseurs de services d’informatique en nuage
- Article 8 Incidents importants concernant les fournisseurs de services de centres de données
- Article 9 Incidents importants concernant les fournisseurs de réseaux de diffusion de contenu
- Article 10 Incidents importants concernant les fournisseurs de services gérés et les fournisseurs de services de sécurité gérés
- Article 11 Incidents importants concernant les fournisseurs de places de marché en ligne
- Article 12 Incidents importants concernant les fournisseurs de moteurs de recherche en ligne
- Article 13 Incidents importants concernant les fournisseurs de plateformes de services de réseaux sociaux
- Article 14 Incidents importants concernant les fournisseurs de services de confiance
Considérant 38Limited availability
Il y a lieu de considérer que la disponibilité est limitée en particulier lorsqu’un service fourni par une entité concernée est considérablement plus lent que la moyenne, ou lorsque toutes les fonctionnalités d’un service ne sont pas disponibles. Dans la mesure du possible, il convient d’utiliser, pour évaluer les retards dans le délai de réponse, des critères objectifs fondés sur les délais moyens de réponse des services fournis par les entités concernées. Une fonctionnalité d’un service peut être, par exemple, une fonctionnalité de discussion en ligne ou une fonctionnalité de recherche d’images.
- Article 3 Incidents importants
- Article 5 Incidents importants concernant les fournisseurs de services DNS
- Article 6 Incidents importants concernant les registres de noms de domaine de premier niveau
- Article 7 Incidents importants concernant les fournisseurs de services d’informatique en nuage
- Article 8 Incidents importants concernant les fournisseurs de services de centres de données
- Article 9 Incidents importants concernant les fournisseurs de réseaux de diffusion de contenu
- Article 10 Incidents importants concernant les fournisseurs de services gérés et les fournisseurs de services de sécurité gérés
- Article 11 Incidents importants concernant les fournisseurs de places de marché en ligne
- Article 12 Incidents importants concernant les fournisseurs de moteurs de recherche en ligne
- Article 13 Incidents importants concernant les fournisseurs de plateformes de services de réseaux sociaux
- Article 14 Incidents importants concernant les fournisseurs de services de confiance
Considérant 39Malicious access
Un accès non autorisé effectif et suspecté d’être malveillant aux réseaux et systèmes d’information d’une entité concernée devrait être considéré comme un incident important lorsque cet accès est susceptible de causer une perturbation opérationnelle grave. Par exemple, lorsqu’un acteur de cybermenace se pré-positionne dans le réseau et les systèmes d’information d’une entité concernée en vue de perturber les services à l’avenir, l’incident devrait être considéré comme important.
- Article 3 Incidents importants
- Article 5 Incidents importants concernant les fournisseurs de services DNS
- Article 6 Incidents importants concernant les registres de noms de domaine de premier niveau
- Article 7 Incidents importants concernant les fournisseurs de services d’informatique en nuage
- Article 8 Incidents importants concernant les fournisseurs de services de centres de données
- Article 9 Incidents importants concernant les fournisseurs de réseaux de diffusion de contenu
- Article 10 Incidents importants concernant les fournisseurs de services gérés et les fournisseurs de services de sécurité gérés
- Article 11 Incidents importants concernant les fournisseurs de places de marché en ligne
- Article 12 Incidents importants concernant les fournisseurs de moteurs de recherche en ligne
- Article 13 Incidents importants concernant les fournisseurs de plateformes de services de réseaux sociaux
- Article 14 Incidents importants concernant les fournisseurs de services de confiance
Considérant 40Recurring incidents
Les incidents récurrents qui sont liés par une cause originelle apparente similaire et qui, pris isolément, ne répondent pas aux critères nécessaires pour être considérés comme importants, devraient être considérés collectivement comme constituant un incident important, à condition qu’ils remplissent collectivement le critère de la perte financière et qu’ils se soient produits au moins deux fois en l’espace de six mois. Ces incidents récurrents peuvent être le signe de défaillances et de faiblesses importantes dans les procédures de gestion des risques de cybersécurité de l’entité concernée et dans leur niveau de maturité en matière de cybersécurité. En outre, de tels incidents récurrents sont susceptibles de causer des pertes financières importantes à l’entité concernée.
Considérant 41Cooperation Group and ENISA
La Commission a procédé à un échange de points de vue et a coopéré avec le groupe de coopération et l’ENISA sur le projet d’acte d’exécution conformément à l’article 21, paragraphe 5, et à l’article 23, paragraphe 11, de la directive (UE) 2022/2555.
Considérant 42European Data Protection Supervisor's opinion
Le Contrôleur européen de la protection des données a été consulté conformément à l’article 42, paragraphe 1, du règlement (UE) 2018/1725 du Parlement européen et du Conseil(3)Règlement (UE) 2018/1725 du Parlement européen et du Conseil du 23 octobre 2018 relatif à la protection des personnes physiques à l’égard du traitement des données à caractère personnel par les institutions, organes et organismes de l’Union et à la libre circulation de ces données, et abrogeant le règlement (CE) no 45/2001 et la décision no 1247/2002/CE (JO L 295 du 21.11.2018, p. 39, ELI: http://data.europa.eu/eli/reg/2018/1725/oj). et a rendu son avis le 1.
Considérant 43Opinion of the committee
Les mesures prévues par le présent règlement sont conformes à l’avis du comité institué par l’article 39 de la directive (UE) 2022/2555,
A ADOPTÉ LE PRÉSENT RÈGLEMENT:
- Article premierObjet
- Article 2Exigences techniques et méthodologiques
- Article 3Incidents importants
- Article 4Incidents récurrents
- Article 5Incidents importants concernant les fournisseurs de services DNS
- Article 6Incidents importants concernant les registres de noms de domaine de premier niveau
- Article 7Incidents importants concernant les fournisseurs de services d’informatique en nuage
- Article 8Incidents importants concernant les fournisseurs de services de centres de données
- Article 9Incidents importants concernant les fournisseurs de réseaux de diffusion de contenu
- Article 10Incidents importants concernant les fournisseurs de services gérés et les fournisseurs de services de sécurité gérés
- Article 11Incidents importants concernant les fournisseurs de places de marché en ligne
- Article 12Incidents importants concernant les fournisseurs de moteurs de recherche en ligne
- Article 13Incidents importants concernant les fournisseurs de plateformes de services de réseaux sociaux
- Article 14Incidents importants concernant les fournisseurs de services de confiance
- Article 15Abrogation
- Article 16Entrée en vigueur et application
Le présent règlement est obligatoire dans tous ses éléments et directement applicable dans tout État membre.
Fait à Bruxelles, le 17 octobre 2024.
Par la Commission
La présidente
Ursula VON DER LEYEN
- un réseau de communications électroniques au sens de l’article 2, point 1), de la directive (UE) 2018/1972;
- tout dispositif ou tout ensemble de dispositifs interconnectés ou apparentés, dont un ou plusieurs éléments assurent, en exécution d’un programme, un traitement automatisé de données numériques; ou
- les données numériques stockées, traitées, récupérées ou transmises par les éléments visés aux points a) et b) en vue de leur fonctionnement, utilisation, protection et maintenance;
- des services de résolution de noms de domaine récursifs accessibles au public destinés aux utilisateurs finaux de l’internet; ou
- des services de résolution de noms de domaine faisant autorité pour une utilisation par des tiers, à l’exception des serveurs de noms de racines;