Préparation au règlement de l’UE sur la cybersolidarité avec ISO 27001

L’incident de 03:17 qui transforme la coopération européenne en sujet d’audit

À 03:17 un mardi matin, Maria, RSSI d’InnovateCloud, fixe un écran saturé d’alertes. Son entreprise est un fournisseur SaaS européen de taille intermédiaire qui sert des clients du secteur logistique en Allemagne, en France et en Pologne. La première alerte ressemble à un accès à privilèges suspect dans un tenant de production. Dix minutes plus tard, le prestataire de services de sécurité managés signale une activité similaire affectant deux autres clients. À 04:00, le SOC observe des appels d’API provenant d’une infrastructure précédemment associée à une phase de préparation de rançongiciel.

InnovateCloud n’était pas la cible initiale. Un fournisseur d’infrastructure critique semble se trouver dans le périmètre d’impact. Mais les conséquences relèvent désormais de la responsabilité de Maria.

Un client affecté est une banque allemande qui demande des réponses au titre de DORA. Un autre est un fournisseur critique du secteur de l’énergie déjà classé selon les règles nationales issues de NIS2. L’environnement peut contenir des données à caractère personnel, mais l’exfiltration n’est pas encore confirmée. L’équipe de sécurité veut confiner la menace immédiatement. Le service juridique veut savoir si le délai de 24 heures pour l’alerte précoce NIS2 a commencé à courir. Le responsable de la protection des données demande si une notification de violation au titre de GDPR est envisageable. Le conseil d’administration veut savoir si l’interruption pourrait se propager dans plusieurs États membres.

En 2026, ce n’est plus seulement une crise interne.

Le règlement de l’UE sur la cybersolidarité modifie la réalité opérationnelle des incidents cyber de grande ampleur et transfrontaliers. Il introduit des mécanismes de détection, de préparation et de réponse au niveau de l’UE, notamment le système européen d’alerte en matière de cybersécurité, le mécanisme d’urgence en matière de cybersécurité et la réserve de cybersécurité de l’UE. Même si une organisation ne demande jamais directement l’aide de la réserve, ses éléments de preuve, contacts auprès des autorités, contrats fournisseurs, chronologies d’incident et communications clients peuvent entrer dans une chaîne de réponse européenne plus large.

L’écart apparaît rapidement. Beaucoup d’organisations disposent d’outils, de tickets et de politiques, mais pas d’éléments de preuve capables de résister à l’examen réglementaire. Elles peuvent dire « nous avons contacté le régulateur », sans pouvoir démontrer qui était autorisé, quel seuil a déclenché le contact, ce qui a été communiqué, si les journaux ont été préservés, si un fournisseur était contractuellement tenu d’assister l’organisation, ou si un rapport final peut être reconstitué à partir des décisions prises au moment des faits.

La réponse n’est pas un autre dossier isolé « règlement sur la cybersolidarité ». La réponse est un système de management de la sécurité de l’information (SMSI) ISO/IEC 27001:2022 qui produit les éléments de preuve une seule fois et les réutilise pour répondre aux attentes de NIS2, DORA, GDPR, NIST CSF 2.0 et COBIT 2019.

Ces éléments de preuve se construisent avant l’incident.

Pourquoi le règlement de l’UE sur la cybersolidarité élève le niveau d’exigence probatoire

Le règlement sur la cybersolidarité vise la détection cyber, la préparation et la réponse aux crises au niveau de l’UE. Son effet pratique pour les RSSI, les auditeurs et les responsables conformité est clair : la coordination d’incidents de grande ampleur exige des éléments de preuve plus rapides, plus propres, plus cohérents et plus faciles à partager avec des parties prenantes de confiance.

Lorsqu’un impact transfrontalier est possible, une organisation peut devoir coordonner ses actions avec les CSIRT nationaux, les autorités compétentes, les régulateurs sectoriels, les autorités de contrôle de la protection des données, les superviseurs financiers, les autorités répressives compétentes, les clients, les sous-traitants, les fournisseurs et les intervenants externes en gestion des incidents. La réserve de cybersécurité de l’UE ajoute une autre dimension, car des prestataires privés préqualifiés peuvent soutenir la préparation, la réponse et le rétablissement. La gouvernance des fournisseurs, l’autorité juridique, le traitement des données et la préservation des éléments de preuve deviennent donc encore plus critiques.

Les entités privées sont au cœur de cette réalité. Les fournisseurs cloud, centres de données, prestataires de services managés, prestataires de services de sécurité managés, opérateurs d’infrastructure numérique, fintechs et plateformes SaaS détiennent souvent la télémétrie, les journaux, les données d’impact client et les faits techniques dont les autorités ont besoin pour comprendre un incident majeur.

NIS2 va déjà dans ce sens. Elle s’applique à de nombreuses entités moyennes et grandes dans les secteurs des annexes I et II qui fournissent des services ou exercent des activités dans l’UE. Elle couvre aussi certaines entités indépendamment de leur taille, notamment les prestataires de services de confiance, les prestataires de services DNS, les registres de noms de domaine de premier niveau et les prestataires de services d’enregistrement de noms de domaine. L’annexe I inclut les infrastructures numériques telles que les services d’informatique en nuage, les services de centres de données, les réseaux de diffusion de contenu, les fournisseurs DNS, les prestataires de services de confiance et les registres TLD. Elle inclut également la gestion de services TIC B2B, notamment les prestataires de services managés et les prestataires de services de sécurité managés. L’annexe II inclut des fournisseurs numériques tels que les places de marché en ligne, les moteurs de recherche en ligne et les plateformes de services de réseaux sociaux.

DORA ajoute une deuxième couche pour le secteur financier. Depuis le 17 janvier 2025, il s’applique à un large éventail d’entités financières, notamment les établissements de crédit, les établissements de paiement, les établissements de monnaie électronique, les entreprises d’investissement, les prestataires de services sur crypto-actifs, les plateformes de négociation, les entreprises d’assurance et de réassurance, les agences de notation de crédit, les prestataires de services de financement participatif et d’autres acteurs. Il crée également des attentes importantes à l’égard des fournisseurs tiers de services TIC, car les entités financières restent responsables des services TIC externalisés.

Un incident touchant une fintech en 2026 peut donc être coordonné via les canaux de supervision DORA, tandis que le fournisseur SaaS ou le MSSP qui soutient cette fintech peut relever de NIS2. Un même événement technique peut créer des obligations de notification, des attentes probatoires et des obligations contractuelles différentes selon les acteurs.

ISO/IEC 27001:2022 donne aux organisations le système d’exploitation nécessaire pour gérer cette complexité. Les clauses 4.1 à 4.4 imposent à l’organisation de définir le SMSI dans son contexte métier, d’identifier les parties intéressées et leurs exigences légales, réglementaires et contractuelles, de définir les limites et dépendances, et d’établir le système de management. Les clauses 5.1 à 5.3 rendent la direction responsable de la politique, des ressources, de l’intégration et de l’attribution des rôles. Les clauses 6.1.1 à 6.1.3 exigent une appréciation des risques répétable, un traitement des risques et une déclaration d’applicabilité (SoA). La clause 8.1 exige une maîtrise opérationnelle, y compris la maîtrise des processus, produits et services fournis par des tiers.

C’est le cœur de la préparation au règlement sur la cybersolidarité : prouver que la réponse à la crise est gérée, testée et auditable, et non improvisée.

Le modèle probatoire de Clarysec : un incident, plusieurs obligations

Un incident transfrontalier n’attend pas que les équipes juridiques le qualifient. Les éléments de preuve doivent être capturés dès la première alerte, puis orientés vers les bons circuits de notification et de coordination.

L’approche de Clarysec relie trois actifs :

1. Zenith Blueprint : feuille de route en 30 étapes pour auditeur Zenith Blueprint, qui transforme la mise en œuvre d’ISO/IEC 27001:2022 en un parcours séquencé compatible avec les exigences d’audit.
2. Zenith Controls : guide de conformité croisée Zenith Controls, qui cartographie les contrôles ISO/IEC 27002:2022 avec les contrôles associés, les attributs, les capacités opérationnelles, les domaines de sécurité et les attentes probatoires inter-référentiels.
3. Les modèles de politiques Clarysec pour la réponse aux incidents, la collecte des éléments de preuve, la sécurité des fournisseurs, la journalisation, la surveillance et la continuité d’activité, adaptés aux environnements d’entreprise et de PME.

Dans Zenith Blueprint, phase Controls in Action, l’étape 22 traite le contrôle ISO/IEC 27002:2022 5.5, Contact avec les autorités. Elle indique :

Le contrôle 5.5 garantit qu’une organisation est prête à interagir avec les autorités externes lorsque cela est nécessaire, non pas de manière réactive ou dans la panique, mais au moyen de canaux prédéfinis, structurés et bien compris.

La même section pose la question à laquelle chaque RSSI doit répondre avant la crise :

si votre organisation était ciblée par une cyberattaque, impliquée dans une violation de données ou faisait l’objet d’une enquête, qui appellerait les autorités ? Comment saurait-on quoi dire ? Dans quelles conditions un tel contact serait-il déclenché ?

Il ne s’agit pas de paperasse administrative. Dans un environnement régi par le règlement sur la cybersolidarité, c’est la différence entre une alerte précoce maîtrisée et des messages contradictoires entre juridictions.

Zenith Controls traite le contrôle ISO/IEC 27002:2022 5.5, Contact avec les autorités, comme un contrôle préventif et correctif, lié à la confidentialité, à l’intégrité et à la disponibilité, et aligné sur les concepts Identifier, Protéger, Répondre et Rétablir. Il relie 5.5 à la planification et à la préparation de la gestion des incidents, au signalement des événements, au renseignement sur les menaces, aux groupes d’intérêt spécialisés et à la réponse aux incidents.

Le même guide traite le contrôle ISO/IEC 27002:2022 5.24, Planification et préparation de la gestion des incidents de sécurité de l’information, comme un contrôle correctif lié à Répondre et Rétablir. Ses liens avec l’évaluation des événements, la réponse aux incidents, les retours d’expérience, la journalisation, la surveillance, la sécurité pendant une perturbation et la continuité montrent ce que les auditeurs testent souvent : le plan relie-t-il détection, classification, escalade, éléments de preuve, rétablissement et apprentissage ?

Pour le traitement des éléments de preuve, le contrôle ISO/IEC 27002:2022 5.28, Collecte des éléments de preuve, est particulièrement important. Zenith Controls le relie à la réponse aux incidents, à la journalisation, à la surveillance et au signalement des événements. Dans un incident transfrontalier grave, c’est à ce niveau que l’investigation technique devient défendable.

Cartographier la préparation au règlement sur la cybersolidarité avec les éléments de preuve ISO 27001

Le règlement de l’UE sur la cybersolidarité crée un environnement de préparation et de coordination. ISO/IEC 27001:2022 fournit le moteur probatoire. NIS2, DORA et GDPR définissent de nombreuses attentes spécifiques en matière de notification, de gouvernance et de protection.

Ce qui est absent est notable : aucun silo de conformité séparé. Les mêmes éléments de preuve qui soutiennent la certification ISO/IEC 27001:2022 peuvent soutenir la responsabilité de la direction au titre de NIS2, la gestion des risques liés aux TIC de DORA, la responsabilité en matière de sécurité au titre de GDPR, les résultats de communication du NIST CSF et les attentes d’assurance de COBIT 2019.

NIS2 : le délai de notification commence avec la prise de connaissance

NIS2 est centrale pour la préparation 2026, car elle définit un workflow de signalement des incidents par étapes.

L’Article 23 impose aux entités essentielles et importantes de notifier sans retard injustifié à leur CSIRT ou à l’autorité compétente les incidents significatifs affectant la fourniture des services. L’alerte précoce doit être soumise sans retard injustifié et au plus tard 24 heures après la prise de connaissance de l’incident significatif. Elle doit indiquer, le cas échéant, si des actes malveillants ou illicites sont suspectés et si un impact transfrontalier est possible.

Une notification d’incident suit sans retard injustifié et au plus tard 72 heures après la prise de connaissance, en mettant à jour l’alerte précoce et en fournissant une première évaluation de la gravité, de l’impact et des indicateurs de compromission disponibles. Un rapport final est dû dans le mois suivant la notification d’incident, avec la gravité, l’impact, le type de menace probable ou la cause racine, les mesures d’atténuation et l’impact transfrontalier.

C’est pourquoi la réponse aux incidents ne peut pas commencer par un document vierge.

La Politique de réponse aux incidents d’entreprise Politique de réponse aux incidents indique :

NIS2 Article 23 (notification dans les 24 heures suivant la prise de connaissance de l’incident)

La Politique de réponse aux incidents - PME Politique de réponse aux incidents - PME transpose la même logique de délai dans une gouvernance pratique :

« Les délais de réponse, y compris la restauration des données et les obligations de notification, doivent être documentés et alignés sur les exigences légales, telles que l’exigence GDPR de notification d’une violation de données à caractère personnel dans un délai de 72 heures. »

Extrait de la Politique de réponse aux incidents - PME, section « Exigences de gouvernance », clause 5.3.2.

Elle intègre également l’évaluation multi-régimes dans le processus d’incident :

« Lorsque des données clients sont concernées, le directeur général doit évaluer les obligations légales de notification selon l’applicabilité de GDPR, NIS2 ou DORA. »

Extrait de la Politique de réponse aux incidents - PME, section « Traitement des risques et exceptions », clause 7.4.1.

Dans un scénario relevant du règlement sur la cybersolidarité, la mention « un impact transfrontalier est possible » devient opérationnellement importante. L’alerte précoce peut ne pas contenir tous les faits, mais l’organisation doit pouvoir démontrer pourquoi elle soupçonnait, ou ne soupçonnait pas, un impact transfrontalier sur la base des éléments de preuve disponibles.

L’enregistrement d’incident doit consigner :

• Le moment où l’organisation a pris connaissance de l’événement.
• La personne qui a déclaré l’événement comme incident potentiel.
• Les services, pays, clients ou secteurs potentiellement affectés.
• L’existence d’un soupçon d’activité malveillante ou illicite.
• Les indicateurs de compromission disponibles.
• Le circuit de contact utilisé auprès des autorités.
• La nécessité ou non de communications clients.
• Les éléments de preuve préservés avant toute remédiation majeure.

Le meilleur moment pour concevoir ces champs est avant 03:17.

DORA : lorsque le client est régulé mais que le fournisseur détient les journaux

DORA modifie la discussion avec les fournisseurs. Les entités financières doivent gérer le risque lié aux tiers TIC dans le cadre de leur cadre de gestion des risques liés aux TIC. L’externalisation de services TIC ne transfère pas la responsabilité réglementaire hors de l’entité financière.

DORA exige des stratégies de gestion du risque lié aux tiers TIC, des registres des contrats de services TIC, des diligences raisonnables, la planification des audits et inspections, des droits de résiliation et des stratégies de sortie testées pour les services TIC critiques ou importants. L’Article 30 exige une clarté contractuelle, notamment les descriptions de services, les lieux, le traitement des données, la confidentialité, l’intégrité, la disponibilité, les niveaux de service, l’assistance lors d’incidents TIC, la coopération avec les autorités et les droits de résiliation. Des conditions plus strictes s’appliquent aux fonctions critiques ou importantes.

Revenons à l’incident de Maria. La banque allemande est réglementée au titre de DORA. InnovateCloud fournit des services SaaS. Le MSSP détecte une activité suspecte. Le fournisseur d’infrastructure cloud détient une partie des journaux d’audit clés. Un sous-traitant exploite une partie de la chaîne de télémétrie. La banque reste responsable, mais elle ne peut pas qualifier et notifier correctement l’incident sans les éléments de preuve du fournisseur.

Clarysec traite ce point au moyen de la classification des fournisseurs et des éléments de preuve contractuels. La Politique de sécurité des tiers et des fournisseurs d’entreprise Politique de sécurité des tiers et des fournisseurs exige :

Les contrats avec les fournisseurs doivent inclure :

La Politique de sécurité des tiers et des fournisseurs - PME Politique de sécurité des tiers et des fournisseurs - PME applique la même logique de conformité dans un modèle opérationnel allégé :

Les contrats doivent inclure des clauses obligatoires couvrant :

La valeur se trouve dans le calendrier d’exécution derrière ces mots : obligations de notification d’incident, accès aux journaux, droits d’audit, confidentialité, localisation des données, contrôles des sous-traitants, coopération avec les autorités, support de rétablissement et obligations de sortie.

Dans Zenith Blueprint, phase Controls in Action, l’étape 23 donne la voie de mise en œuvre :

Établissez une liste complète des fournisseurs et prestataires de services actuels (5.19), puis classez-les selon leur accès aux systèmes, aux données ou à la maîtrise opérationnelle. Pour chaque fournisseur classifié, vérifiez que les exigences de sécurité sont clairement intégrées aux contrats (5.20), y compris la confidentialité, l’accès, le signalement des incidents et les obligations de conformité.

Elle poursuit avec le risque en aval :

Pour chaque fournisseur critique, identifiez s’il utilise des sous-traitants ultérieurs susceptibles d’accéder à vos données ou systèmes. Documentez la manière dont vos exigences de sécurité de l’information sont répercutées à ces parties, soit par les clauses contractuelles de votre fournisseur, soit par vos propres clauses directes.

C’est aussi de la préparation à la réserve de cybersécurité. Si un prestataire externe de réponse intervient dans votre environnement pendant une urgence, vous devez connaître la base légale, le périmètre d’accès, les règles relatives aux éléments de preuve, les obligations de traitement des données, le circuit de coordination avec les autorités et les conditions de sortie. DORA rend cela explicite pour les entités financières. NIS2 le rend pertinent pour les entités essentielles et importantes. ISO/IEC 27001:2022 le rend auditable.

GDPR : la question de la violation au sein de la crise cyber

Tout incident de cybersécurité n’est pas une violation de données à caractère personnel, mais tout incident sérieux doit être évalué sous cet angle.

GDPR s’applique aux traitements effectués dans le cadre d’un établissement dans l’UE, ainsi qu’aux responsables du traitement ou sous-traitants non établis dans l’UE qui offrent des biens ou services à des personnes dans l’UE ou suivent leur comportement dans l’UE. Il définit les données à caractère personnel, le traitement, le responsable du traitement, le sous-traitant et la violation de données à caractère personnel. Ses principes incluent l’intégrité, la confidentialité et la responsabilité, ce qui signifie que les responsables du traitement doivent être en mesure de démontrer la conformité.

Pendant l’incident de 03:17, l’équipe de Maria doit se demander :

• Des données à caractère personnel ont-elles été consultées, divulguées, modifiées, perdues ou détruites ?
• InnovateCloud est-elle responsable du traitement, sous-traitant, ou les deux, pour les données affectées ?
• Des catégories particulières de données à caractère personnel sont-elles concernées ?
• Quels clients ou quelles personnes sont affectés ?
• Les journaux sont-ils suffisants pour évaluer le périmètre ?
• Les obligations de notification au titre de GDPR s’exécutent-elles en parallèle des obligations NIS2 ou DORA ?

C’est pourquoi la coordination relative à la protection des données doit faire partie de l’escalade de l’incident, et non d’une revue juridique tardive après reconstruction des systèmes et rotation des journaux.

La Politique de journalisation et de surveillance - PME Politique de journalisation et de surveillance - PME indique :

Les alertes de priorité élevée doivent être escaladées vers le directeur général et le coordinateur protection des données dans un délai de 24 heures

Cette clause est simple, mais elle résout un schéma de défaillance réel. Les responsables de la protection des données ont besoin d’éléments de preuve tant qu’ils sont suffisamment frais pour déterminer si une violation de données à caractère personnel s’est produite et si les personnes concernées sont exposées à un risque.

Constituer un dossier probatoire de 24 heures pour incident transfrontalier

Un exercice de préparation pratique doit simuler les premières 24 heures d’un incident transfrontalier. L’objectif n’est pas de sur-notifier. L’objectif est de démontrer que l’organisation peut assembler les faits, prendre des décisions défendables et maintenir des communications cohérentes.

Scénario

Votre MSSP détecte un accès à privilèges suspect provenant d’une région inhabituelle contre votre tenant de production. La même infrastructure source apparaît dans des alertes affectant deux clients dans deux États membres. L’un des clients est une entité financière. L’environnement affecté contient des données à caractère personnel, mais l’exfiltration n’est pas confirmée.

Étape 1 : ouvrir l’enregistrement d’incident

Créez le ticket d’incident avec les champs de classification approuvés. Incluez l’heure de prise de connaissance, la source de détection, les actifs affectés, les services affectés, les pays potentiellement concernés, l’activité malveillante suspectée, la gravité initiale et le responsable d’incident.

Reliez cet élément aux contrôles ISO/IEC 27002:2022 5.24, 5.25 et 5.26, ainsi qu’aux contrôles de l’annexe A ISO/IEC 27001:2022 A.5.24, A.5.25 et A.5.26.

Étape 2 : déclencher le workflow de décision relatif aux autorités

Utilisez la matrice de contact des autorités exigée par l’étape 22 de Zenith Blueprint. Identifiez les autorités susceptibles d’être pertinentes : CSIRT national, autorité de contrôle de la protection des données, régulateur financier, autorités répressives compétentes et régulateur sectoriel.

Consignez la décision et sa justification. Si aucune alerte précoce NIS2 n’est émise, documentez pourquoi. Si un impact transfrontalier est possible, consignez les éléments de preuve qui étayent cette conclusion.

Étape 3 : préserver les éléments de preuve avant toute remédiation majeure

La Politique de collecte des éléments de preuve et d’investigation forensique d’entreprise Politique de collecte des éléments de preuve et d’investigation forensique indique :

Tous les éléments de preuve collectés doivent être identifiés de manière unique, étiquetés et stockés dans un référentiel sécurisé avec :

La Politique de collecte des éléments de preuve et d’investigation forensique - PME Politique de collecte des éléments de preuve et d’investigation forensique - PME applique la même discipline sous une forme plus simple :

« Chaque élément de preuve numérique doit être consigné avec : »

Extrait de la Politique de collecte des éléments de preuve et d’investigation forensique - PME, section « Exigences de gouvernance », clause 5.2.1.

Pour l’exercice sur table, collectez des exemples d’entrées probatoires : export d’alerte SIEM, journaux du fournisseur d’identité, enregistrements de sessions à privilèges, instantané de terminal, journaux de pare-feu, journaux d’audit cloud, notes d’impact client et approbations de communication.

Étape 4 : activer l’assistance des fournisseurs

Consultez le registre des fournisseurs. Identifiez le MSSP, le fournisseur cloud et les sous-traitants critiques. Confirmez les clauses d’assistance en cas d’incident, les contacts d’escalade, les durées de conservation des journaux, le format des éléments de preuve et les obligations de coopération avec les autorités.

Cela soutient directement les exigences de DORA relatives au risque lié aux tiers TIC et les attentes de NIS2 en matière de sécurité de la chaîne d’approvisionnement.

Étape 5 : rédiger trois communications

Rédigez trois communications à partir de la même base factuelle :

Étape 6 : clôturer avec les retours d’expérience

Mettez à jour le registre des risques, la déclaration d’applicabilité (SoA), le registre des fournisseurs et le plan de réponse aux incidents. Si l’exercice révèle des journaux manquants, des contacts autorités imprécis ou des clauses fournisseurs faibles, ouvrez des actions correctives.

Dans Zenith Blueprint, phase Controls in Action, l’étape 23 demande aux organisations de valider les capacités de gestion d’incident comme suit :

Sélectionnez un événement récent ou conduisez un exercice sur table pour valider votre plan. Capturez et consignez toutes les décisions, tous les rôles et toutes les communications (5.26), puis mettez à jour le plan avec les retours d’expérience (5.27). Confirmez que les procédures sont en place pour préserver les éléments de preuve forensiques (5.28), y compris les instantanés de journaux, les sauvegardes et l’isolement sécurisé des systèmes affectés.

Ce paragraphe constitue un ordre du jour d’exercice compatible avec les exigences d’audit.

Journalisation : la différence entre coordination et spéculation

La coordination d’un incident transfrontalier échoue lorsque tout le monde a une opinion et personne n’a d’horodatage.

Dans Zenith Blueprint, phase Controls in Action, l’étape 19 l’exprime clairement :

La journalisation est le système circulatoire de tout environnement informatique sécurisé. Sans elle, les incidents restent invisibles, la responsabilité s’estompe, et les relations de cause à effet disparaissent.

Elle poursuit :

Au fond, la journalisation concerne la traçabilité. Lorsqu’un problème survient, qu’il s’agisse d’une tentative de connexion échouée, de la suppression de fichiers critiques ou d’un script non autorisé exécuté sur un serveur, les journaux fournissent le fil forensique qui aide à démêler ce qui s’est réellement passé.

Pour NIS2, les journaux étayent la notification d’incident à 72 heures avec la gravité initiale, l’impact et les indicateurs de compromission. Pour DORA, les journaux soutiennent la classification des incidents majeurs liés aux TIC, l’analyse de la cause racine, l’impact opérationnel et la responsabilité des tiers. Pour GDPR, les journaux soutiennent l’évaluation visant à déterminer si des données à caractère personnel ont été consultées ou divulguées. Dans un contexte de règlement sur la cybersolidarité, les journaux permettent une connaissance partagée de la situation sans contraindre les intervenants à s’appuyer sur des spéculations.

Si la réponse à l’une de ces questions est « pas certain », le sujet doit figurer dans le plan de traitement des risques.

Continuité d’activité et opérations de crise sécurisées

La discussion sur le règlement sur la cybersolidarité se concentre naturellement sur la réponse aux incidents, mais la résilience consiste aussi à maintenir les services critiques en sécurité pendant une perturbation.

L’Article 21 de NIS2 exige une approche tous risques couvrant la gestion des incidents, la continuité d’activité, la gestion des sauvegardes, la reprise après sinistre, la gestion de crise, la sécurité de la chaîne d’approvisionnement, le traitement des vulnérabilités, l’évaluation de l’efficacité, l’hygiène cyber, la cryptographie, la sécurité RH, le contrôle d’accès, la gestion des actifs, l’authentification multifacteur, les communications sécurisées et, le cas échéant, les communications d’urgence sécurisées.

DORA exige de manière similaire la gouvernance, la gestion des risques liés aux TIC, la gestion des incidents, les tests de résilience, la gestion du risque lié aux tiers, la continuité et le rétablissement. Les entités plus petites peuvent bénéficier d’exigences simplifiées, mais elles ont toujours besoin d’une gestion documentée des risques liés aux TIC, d’une surveillance, de systèmes résilients, d’une gestion des incidents, de l’identification des dépendances vis-à-vis de tiers, de sauvegardes, de restauration, de tests, de retour d’expérience post-incident et de formation.

La Politique de continuité d’activité et de reprise après sinistre d’entreprise Politique de continuité d’activité et de reprise après sinistre part d’une exigence simple :

Les plans doivent couvrir :

Derrière cette formule se trouvent les éléments de preuve de continuité attendus par les auditeurs : priorités de rétablissement, objectifs de temps de rétablissement, objectifs de point de reprise, calendriers de sauvegarde, tests de restauration, rôles de crise, communications de secours, dépendances fournisseurs et actions d’amélioration après exercice.

Les contrôles ISO/IEC 27002:2022 5.29 et 5.30 sont centraux ici. Le contrôle 5.29 traite de la sécurité de l’information pendant une perturbation. Le contrôle 5.30 traite de la préparation des TIC à la continuité d’activité. Dans Zenith Controls, la planification des incidents au titre de 5.24 est liée à la sécurité pendant une perturbation et à la planification plus large de la continuité. C’est particulièrement pertinent lorsque les canaux normaux sont indisponibles, que les systèmes d’identité sont dégradés ou que les équipes de crise doivent coordonner leurs actions avec les autorités au moyen de communications d’urgence sécurisées.

Carte de conformité croisée : NIS2, DORA, GDPR, NIST CSF 2.0 et COBIT 2019

Un RSSI n’a pas besoin de cinq programmes d’incident séparés. Il lui faut un modèle probatoire unique observable selon cinq angles.

La méthode des profils actuel et cible du NIST CSF 2.0 est particulièrement utile pour les organisations qui ne sont pas encore assez matures pour une plateforme GRC pleinement intégrée. Elle encourage les organisations à définir le périmètre d’un profil, à rassembler des entrées telles que les politiques, les priorités de risque de l’organisation, les analyses d’impact sur l’activité, les exigences, les normes, les procédures, les mesures de protection et les rôles, puis à analyser les écarts et à créer un plan d’action priorisé. Cela ressemble fortement à un sprint pratique de préparation au règlement sur la cybersolidarité : éléments de preuve actuels, obligations cibles, plan d’écarts, responsables, dates et piste d’audit.

Les auditeurs COBIT 2019 et de type ISACA demandent généralement si les objectifs de gouvernance sont attribués, mesurés et surveillés. Ils ne se satisferont pas de « le SOC s’en occupe ». Ils demanderont comment les organes de direction approuvent les mesures de risque, comment la performance est rapportée, comment le risque lié aux tiers est gouverné, comment les exceptions sont acceptées et comment les actions correctives sont suivies.

Comment les auditeurs testeront le même incident

Le même incident de 03:17 produit différentes questions d’audit selon le mandat de l’évaluateur.

Un auditeur ISO/IEC 27001:2022 commencera par le SMSI. Il demandera si le processus d’incident est dans le périmètre, si les exigences des parties intéressées incluent NIS2, DORA, GDPR et les contrats, si l’appréciation des risques a considéré les scénarios transfrontaliers et fournisseurs, si les contrôles de l’annexe A ont été sélectionnés dans la déclaration d’applicabilité (SoA), et si les enregistrements opérationnels prouvent que le processus a été suivi.

Une autorité ou un évaluateur axé sur NIS2 se concentrera sur la responsabilité de la direction, les mesures de gestion des risques de l’Article 21 et le signalement de l’Article 23. Il pourra demander quand l’organisation a pris connaissance de l’incident, pourquoi l’incident était ou n’était pas significatif, comment l’impact transfrontalier a été évalué, si les clients ont été informés et si des mesures correctives ont été prises sans retard injustifié.

Un superviseur DORA ou une équipe d’audit interne demandera si l’incident a affecté des fonctions critiques ou importantes, si les fournisseurs tiers de services TIC ont soutenu la réponse, si l’entité financière a conservé sa responsabilité, si le registre d’informations était exact, si l’incident a été classifié correctement et si les retours d’expérience ont alimenté les tests de résilience et la supervision des fournisseurs.

Un auditeur GDPR ou une autorité de contrôle de la protection des données demandera si l’organisation disposait d’éléments de preuve suffisants pour déterminer si des données à caractère personnel ont été compromises, si les rôles de responsable du traitement et de sous-traitant étaient clairs, si les personnes concernées étaient exposées à un risque, si les contrôles de confidentialité et d’intégrité étaient appropriés, et si les enregistrements de responsabilité ont été maintenus.

Un évaluateur NIST CSF 2.0 traduira l’événement en résultats Gouverner, Identifier, Protéger, Détecter, Répondre et Rétablir. Il recherchera les attentes des parties prenantes, les obligations légales, l’appétence au risque, la gouvernance des fournisseurs, la journalisation, la surveillance, l’exécution de la réponse, les communications et la validation de la reprise.

Un auditeur COBIT 2019 ou ISACA se concentrera sur l’efficacité de la gouvernance et du système de management : propriété, droits de décision, indicateurs, acceptation du risque, performance des processus, assurance et amélioration continue.

C’est là que Zenith Controls sert de boussole de conformité croisée. Il ne renomme pas les contrôles officiels et ne crée pas de cadre de contrôle parallèle. Il montre comment les contrôles ISO/IEC 27002:2022 tels que 5.5, 5.24 et 5.28 se relient aux capacités opérationnelles, aux contrôles associés et aux éléments de preuve pertinents pour l’audit.

Ce que les RSSI doivent faire dès maintenant pour être prêts en 2026

Si vous préparez votre organisation à la réalité opérationnelle du règlement de l’UE sur la cybersolidarité, commencez par les éléments de preuve, pas par les slogans.

Premièrement, mettez à jour le contexte de votre SMSI et l’analyse des parties intéressées. Identifiez si votre organisation, vos clients ou vos fournisseurs relèvent de NIS2, DORA ou GDPR. Incluez l’empreinte par État membre, la classification sectorielle, les clients critiques, les dépendances aux services TIC et les contacts auprès des autorités.

Deuxièmement, organisez un exercice sur table d’incident transfrontalier. Utilisez un scénario incluant un fournisseur, plus d’un État membre, une possible exposition de données à caractère personnel et un client financier régulé. Encadrez les premières 24 heures dans un temps limité.

Troisièmement, revoyez les contrats fournisseurs. Confirmez les obligations de notification, l’accès aux journaux, le support forensique, la coopération avec les autorités, la répercussion aux sous-traitants, la localisation des données, les droits d’audit, le support de continuité et les droits de résiliation.

Quatrièmement, testez la collecte des éléments de preuve. Exportez des journaux, préservez des instantanés, étiquetez les éléments de preuve, consignez la chaîne de conservation et validez l’accès au référentiel. Si votre politique indique que les éléments de preuve sont identifiés de manière unique et stockés de façon sécurisée, démontrez-le.

Cinquièmement, alignez les communications d’incident. Votre alerte précoce NIS2, votre escalade DORA, votre évaluation de violation GDPR et votre notification client ne doivent pas se contredire. Elles peuvent avoir des finalités juridiques différentes, mais elles doivent provenir de la même base factuelle.

Sixièmement, associez le conseil d’administration à l’exercice. NIS2 et DORA renforcent tous deux la responsabilité de la direction. Les clauses de leadership ISO/IEC 27001:2022 rendent cela auditable. Un conseil qui n’a jamais vu un délai de notification cyber de 24 heures n’est pas prêt pour une crise transfrontalière.

Prochaines étapes avec Clarysec

L’avenir de la cybersécurité dans l’UE repose sur la collaboration et la confiance démontrée. Les organisations qui traitent NIS2 et DORA comme des listes de contrôle isolées seront en difficulté lors d’incidents transfrontaliers. Celles qui construisent des systèmes opérationnels ISO/IEC 27001:2022 étayés par des éléments de preuve pourront répondre avec assurance aux régulateurs, clients, auditeurs et intervenants de crise.

Clarysec aide les RSSI, les responsables conformité, les auditeurs et les dirigeants à transformer la réglementation cyber de l’UE en éléments de preuve opérationnels compatibles avec les exigences d’audit grâce à :

• Zenith Blueprint : feuille de route en 30 étapes pour auditeur, pour une mise en œuvre structurée d’ISO/IEC 27001:2022 et un séquencement d’audit.
• Zenith Controls : guide de conformité croisée, pour cartographier les contrôles d’incident, d’autorité, de fournisseur, d’éléments de preuve, de journalisation et de continuité entre référentiels.
• Les modèles de politiques Clarysec, notamment la Politique de réponse aux incidents, la Politique de collecte des éléments de preuve et d’investigation forensique, la Politique de sécurité des tiers et des fournisseurs, la Politique de continuité d’activité et de reprise après sinistre, ainsi que les versions PME lorsque la proportionnalité est déterminante.

Le meilleur moment pour se préparer à la coordination d’un incident transfrontalier est avant l’alerte de 03:17. Le deuxième meilleur moment est aujourd’hui.

Commencez par une revue de préparation Clarysec, téléchargez le toolkit de politiques pertinent, ou demandez une démonstration de la manière dont Zenith Blueprint et Zenith Controls peuvent aider votre SMSI à produire les éléments de preuve qu’exigera la cyberrésilience en 2026.