Gouvernance des paiements de rançon pour NIS2 et DORA

Il est 3 h 17 du matin, un jour de semaine en 2026. Maria, RSSI d’une plateforme fintech en forte croissance, est appelée en cellule de crise par un message de son analyste SOC principal : chiffrement massif confirmé, services critiques indisponibles et groupe de rançongiciel affirmant avoir exfiltré 2 To de données clients.

Le directeur général rejoint l’appel en premier. Le service juridique suit. Puis la protection des données, la finance, la communication, l’assureur cyber, un prestataire d’analyse forensique et l’équipe d’exploitation cloud. Un portail du dark web affiche un compte à rebours de 48 heures et une demande en cryptomonnaie à sept chiffres.

Le directeur général pose la question que tout RSSI redoute.

« Pouvons-nous payer, et qui est habilité à décider ? »

La mauvaise réponse consiste à traiter la situation comme un problème de négociation. La bonne réponse consiste à la traiter comme un problème de gouvernance.

En 2026, la gouvernance des décisions de paiement de rançon n’est plus un choix de crise privé et technique. Elle peut être examinée par les autorités de régulation, les auditeurs, les assureurs, les clients, les autorités répressives compétentes, les actionnaires et le conseil d’administration. Une décision de paiement recoupe l’exposition aux sanctions, l’évaluation d’une violation de données à caractère personnel, les conditions d’assurance cyber, les obligations contractuelles, les communications de crise, la préservation des éléments de preuve, la notification progressive au titre de NIS2, la classification des incidents DORA, la notification GDPR et l’amélioration post-incident.

C’est pourquoi Clarysec recommande à ses clients d’intégrer la gouvernance des décisions de paiement de rançon dans le SMSI avant l’incident. ISO/IEC 27001:2022 fournit la structure du système de management. Les contrôles ISO/IEC 27002:2022 fournissent le modèle opérationnel. Zenith Blueprint : feuille de route en 30 étapes pour auditeurs et Zenith Controls : le guide de correspondance de conformité aident à transformer cette structure en éléments probants pratiques et exploitables en audit.

Un playbook rançongiciel qui se limite à dire « notifier le juridique » ne suffit pas. L’organisation doit savoir qui peut autoriser une négociation, comment le contrôle des sanctions est réalisé, quand l’assureur doit donner son accord, comment la classification GDPR, NIS2 et DORA est documentée, et comment les éléments de preuve sont protégés pendant que les équipes de rétablissement travaillent sous pression.

Pourquoi les décisions ad hoc de paiement de rançon échouent

Une décision de paiement de rançon est souvent décrite comme binaire : payer ou ne pas payer. En réalité, la décision comporte au moins six niveaux :

1. L’événement est-il confirmé, contenu et correctement classifié ?
2. Des données à caractère personnel, des données réglementées ou la fourniture d’un service critique sont-elles affectées ?
3. L’organisation est-elle juridiquement autorisée à communiquer ou à réaliser une transaction avec l’acteur de menace ?
4. L’assurance cyber impose-t-elle une notification préalable, des fournisseurs approuvés, un consentement ou des éléments de preuve spécifiques ?
5. Le paiement réduirait-il l’impact métier, ou augmenterait-il le risque juridique, financier et réputationnel ?
6. Qui détient l’autorité de décision, et comment cette décision est-elle enregistrée ?

Pendant un incident en cours, des équipes non coordonnées tirent souvent dans des directions différentes. Le directeur financier peut considérer la rançon comme une dépense métier face à une indisponibilité croissante. Le juridique voit les sanctions, la criminalité financière et l’exposition réglementaire. Le DPO évalue si des données chiffrées ou exfiltrées constituent une violation de données à caractère personnel notifiable. La conformité surveille les délais de notification NIS2 et DORA. Le RSSI tente de préserver les éléments de preuve tout en rétablissant les services. Le directeur général veut une recommandation avant l’expiration du compte à rebours de l’attaquant.

Sans processus décisionnel formel, la voix la plus forte dans la cellule de crise peut devenir le modèle de gouvernance. C’est précisément la situation que la réglementation moderne en cybersécurité cherche à éviter.

NIS2 fait de la cybersécurité une responsabilité de la direction. Article 20 traite de la gouvernance et de la responsabilité des organes de direction, tandis qu’Article 21 impose des mesures de gestion des risques couvrant la gestion des incidents, la continuité d’activité, la gestion des sauvegardes, la gestion de crise, la sécurité de la chaîne d’approvisionnement, le contrôle d’accès, la gestion des actifs, l’authentification multifacteur et l’évaluation de l’efficacité. Article 23 crée une notification par étapes pour les incidents significatifs, comprenant une alerte précoce sous 24 heures, une notification sous 72 heures et, le cas échéant, un rapport final dans un délai d’un mois.

Pour les entités financières, DORA constitue le référentiel sectoriel de résilience opérationnelle. Article 5 attribue à l’organe de direction la responsabilité de la gestion des risques liés aux TIC. Articles 17, 18 et 19 traitent de la gestion, de la classification et de la notification des incidents majeurs liés aux TIC. DORA impose également des capacités de réponse et de rétablissement, de sauvegarde et de restauration, d’apprentissage post-incident, de tests et de gestion des risques liés aux prestataires tiers de TIC.

GDPR ajoute une évaluation distincte mais partiellement recoupée. Si un rançongiciel entraîne la destruction, la perte, l’altération, la divulgation non autorisée de données à caractère personnel ou l’accès non autorisé à celles-ci, de manière accidentelle ou illicite, le responsable du traitement doit déterminer si une violation de données à caractère personnel est survenue. Si une notification est requise, le délai auprès de l’autorité de contrôle est généralement de 72 heures à compter de la prise de connaissance. En cas de risque élevé pour les personnes, une communication aux personnes concernées peut également être nécessaire.

La conclusion est simple : la question de la rançon ne doit pas être posée pour la première fois dans la cellule de crise.

Les contrôles ISO 27001:2022 qui ancrent la gouvernance des paiements

Un SMSI ISO/IEC 27001:2022 n’est pas une liste de contrôle pour auditeurs. C’est un système de management destiné à prendre des décisions fondées sur les risques. La gouvernance des paiements de rançon relève de ce système, car elle combine appréciation des risques, traitement des risques, rôles, obligations légales, réponse aux incidents, continuité, gestion des fournisseurs et amélioration continue.

Les contrôles les plus pertinents de l’Annexe A d’ISO 27001:2022 forment une chaîne de contrôle cohérente.

Dans Zenith Controls, la section relative à A.5.24, Planification et préparation de la gestion des incidents de sécurité de l’information, classe le contrôle comme correctif, lié à la confidentialité, à l’intégrité et à la disponibilité, et aligné sur les concepts Respond et Recover. Elle relie également A.5.24 à l’évaluation des événements A.5.25, aux enseignements tirés des incidents A.5.27, à la journalisation A.8.15, à la surveillance A.8.16, à la sécurité pendant les perturbations A.5.29, à la continuité et au contact avec les autorités.

C’est important, car la gouvernance des paiements de rançon est une chaîne. Si vous ne pouvez pas détecter et classifier l’événement, vous ne pouvez pas décider. Si vous ne pouvez pas préserver les éléments de preuve, vous ne pouvez pas défendre la décision. Si les obligations légales ne sont pas cartographiées, la négociation ou le paiement peut être illicite. Si les options de rétablissement ne sont pas testées, les dirigeants peuvent être poussés vers une décision fondée sur la peur plutôt que sur les faits.

Zenith Controls énonce clairement la relation entre préparation et prise de décision :

« 5.25 est le point de décision qui détermine quand un événement franchit le seuil pour devenir un incident de sécurité, déclenchant les actions décrites en 5.26. Une évaluation rapide et exacte des événements garantit que la réponse aux incidents n’est ni retardée ni mal orientée. »

Le même guide relie A.5.31, Exigences légales, statutaires, réglementaires et contractuelles, à la vie privée, à la conservation des enregistrements, à la revue indépendante et à la conformité aux politiques internes. Pour les rançongiciels, A.5.31 est l’endroit où le contrôle des sanctions, les obligations d’assurance, l’échange avec les autorités répressives compétentes, les contrats clients, les obligations de protection des données et les notifications réglementaires sectorielles sont consolidés dans un registre de conformité unique.

Le modèle Clarysec de gouvernance des paiements de rançon en cinq portes

Le modèle Clarysec distingue la gouvernance des décisions de paiement de rançon en cinq portes. L’objectif n’est pas de faciliter le paiement. Il est de rendre toute décision, y compris le refus de payer, fondée sur des éléments de preuve, revue juridiquement, autorisée et vérifiable en audit.

Ce modèle utilise la logique de traitement des risques d’ISO 27001. Un paiement de rançon n’est pas un contrôle de sécurité. C’est, au mieux, une option de crise envisagée dans un contexte de traitement des risques et de rétablissement. Avant un incident, l’organisation devrait déjà avoir déterminé comment les risques liés aux rançongiciels sont traités : les atténuer par des contrôles, transférer une partie de l’exposition financière par l’assurance, éviter des dépendances héritées inacceptables, ou accepter explicitement le risque résiduel lorsque cela est justifié.

Dans la phase de gestion des risques, étape 13, Planification du traitement des risques et Déclaration d’applicabilité, Zenith Blueprint demande aux organisations de déterminer les options de traitement pour chaque risque et de les documenter dans le registre des risques. Il rappelle que le transfert, par exemple via l’assurance cyber, ne supprime pas la nécessité de contrôles, car le transfert traite souvent l’impact financier plutôt que la vraisemblance. Il précise également :

« L’acceptation doit être explicite et approuvée par la direction, en particulier pour tout risque moyen. Les risques élevés sont rarement acceptés, sauf s’ils sont réellement inévitables et validés au plus haut niveau. »

Cette phrase s’applique directement à la gouvernance des paiements de rançon. Si le conseil d’administration est invité à accepter le risque résiduel lié au refus de paiement, ou le risque juridique et réputationnel lié à l’autorisation d’une négociation, l’acceptation doit être explicite, enregistrée et approuvée par l’autorité compétente.

La Politique de gestion des risques de Clarysec renforce le même principe :

« Les décisions de traitement des risques doivent être alignées sur les options prédéfinies »
Extrait de la clause 5.5.

Une décision relative à une rançon n’est donc pas un raccourci contournant la gestion des risques. Elle doit être traitée comme une décision formelle et documentée de traitement des risques, sous une autorité définie.

Autorité politique : qui peut décider sous pression ?

De nombreux échecs liés aux rançongiciels sont des échecs de gouvernance déguisés en défaillances techniques. Quelqu’un contacte l’attaquant en dehors du canal approuvé. Quelqu’un promet un paiement avant l’approbation de l’assureur. Quelqu’un restaure des systèmes et écrase des éléments de preuve forensiques. Quelqu’un informe les clients trop tôt, trop tard, ou avec des faits inexacts.

Les politiques Clarysec sont conçues pour supprimer cette ambiguïté.

Pour les PME, la Politique relative aux rôles et responsabilités de gouvernance - PME donne une règle simple :

« Toutes les décisions de sécurité significatives, exceptions et escalades doivent être enregistrées et traçables. »
Extrait de la section « Exigences de gouvernance », clause de politique 5.5.

La Politique de réponse aux incidents - PME attribue l’autorité d’escalade :

« Le directeur général (DG) est responsable de l’autorisation de toutes les décisions d’escalade d’incident, notifications réglementaires et communications externes. »
Extrait de la section « Exigences de gouvernance », clause de politique 5.1.1.

Elle relie également les incidents touchant des données clients aux obligations réglementaires :

« Lorsque des données clients sont concernées, le directeur général doit évaluer les obligations légales de notification en fonction de l’applicabilité de GDPR, NIS2 ou DORA. »
Extrait de la section « Traitement des risques et exceptions », clause de politique 7.4.1.

Pour les organisations de plus grande taille, la Politique relative aux rôles et responsabilités de gouvernance impose une escalade immédiate lorsqu’une exposition juridique ou des violations de données notifiables peuvent exister :

« Escalade juridique et réglementaire : les incidents impliquant une exposition juridique potentielle ou des violations de données notifiables doivent être escaladés immédiatement au responsable juridique et conformité et à la direction générale. »
Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.4.3.

La Politique de réponse aux incidents d’entreprise définit l’autorité exécutive pendant les incidents graves. La clause 4.6.1 indique que le rôle de l’équipe de direction générale est de :

« Prendre les décisions stratégiques pendant les incidents de gravité élevée, y compris l’approbation des notifications et des communications publiques. »

Dans un contexte de rançongiciel, Clarysec considère la discussion sur le paiement, l’autorisation de négociation, la notification aux clients, la déclaration réglementaire et la communication publique comme des décisions stratégiques, et non comme des actions techniques.

Il en découle une règle de gouvernance pratique : le RSSI peut recommander, l’équipe de gestion des incidents peut évaluer, le juridique peut conseiller, la finance peut valider les mécanismes de paiement, l’assureur peut consentir ou refuser la couverture, mais la direction générale ou le conseil d’administration doit assumer la décision selon l’autorité prédéfinie.

Escalade sécurisée au regard des sanctions avant toute négociation

Un processus rançongiciel sécurisé au regard des sanctions commence par une interdiction : aucun employé, contractant, fournisseur, intermédiaire, négociateur ou intervenant en gestion des incidents ne peut négocier, promettre, faciliter ou transférer une valeur à un acteur de menace sans revue juridique approuvée.

Le point de contrôle juridique doit intervenir avant tout échange actif avec l’attaquant, et non après l’apparition d’une adresse de portefeuille. Le processus doit inclure :

• L’implication d’un conseil juridique avant toute communication allant au-delà de la capture passive des éléments de preuve.
• L’identification de l’acteur de menace à l’aide d’éléments forensiques, de renseignement et d’informations des autorités répressives compétentes lorsque disponibles.
• Le contrôle des sanctions et des parties restreintes pour les noms de groupes, alias, adresses de portefeuille, infrastructures, intermédiaires et canaux de paiement.
• La prise en compte et l’enregistrement d’une consultation des autorités répressives compétentes.
• La notification de l’assureur cyber conformément aux conditions de la police avant la désignation de fournisseurs ou l’ouverture de négociations.
• L’implication du DPO ou du responsable de la protection des données si des données à caractère personnel peuvent être concernées.
• La confirmation, par le directeur financier ou le responsable financier, des contrôles de paiement, de la séparation des tâches, des contrôles antifraude et des exigences d’approbation par le conseil d’administration.
• L’enregistrement de la décision exécutive avec les alternatives envisagées, notamment la restauration, le confinement, la suspension de service, la communication client et le refus de payer.
• La préservation des éléments de preuve relatifs aux communications de l’attaquant, indicateurs, détails de portefeuille, réunions de décision, approbations et avis externes.

Pour les rançongiciels, le registre juridique doit inclure au minimum les sources d’obligations suivantes.

Les organisations doivent également définir qui peut suspendre la décision de paiement. Le juridique, la conformité, le DPO, le conseil spécialisé en sanctions ou le conseil d’administration doivent disposer d’une autorité explicite pour mettre en pause la négociation ou le paiement si le contrôle est incomplet, si les éléments de preuve sont peu fiables, si les conditions de l’assureur ne sont pas remplies, ou si l’action peut violer la loi ou un contrat.

Préservation des éléments de preuve : ne détruisez pas la preuve en rétablissant le service

Les équipes confrontées à un rançongiciel se précipitent naturellement pour rétablir les opérations. Mais si la restauration détruit les journaux, instantanés, demandes de rançon, échantillons de logiciels malveillants, images mémoire ou messages de l’attaquant, l’organisation peut perdre la capacité de prouver ce qui s’est passé.

Dans la phase Contrôles en action, étape 23, Contrôles organisationnels, Zenith Blueprint demande aux organisations de valider et tester les capacités de gestion des incidents en définissant les événements de sécurité notifiables, en documentant la prise de décision et en préservant les éléments de preuve forensiques. Il demande aux équipes de :

« Capturer et journaliser toutes les décisions, rôles et communications (5.26), et mettre à jour le plan avec les enseignements tirés (5.27). Confirmer que des 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 impactés. »

La même étape explique A.5.28 dans un langage que tout conseil d’administration peut comprendre :

« ce que vous pouvez prouver compte autant que ce qui s’est réellement produit »

La Politique de collecte des éléments de preuve et d’investigation forensique d’entreprise de Clarysec rappelle que les éléments de preuve doivent rester traçables :

« Un journal de chaîne de conservation doit accompagner tout élément de preuve physique ou numérique depuis son acquisition jusqu’à son archivage ou son transfert, et doit documenter : »
Extrait de la section « Exigences de gouvernance », clause de politique 5.6.

Pour les PME, la Politique de collecte des éléments de preuve et d’investigation forensique - PME est volontairement pratique :

« Une copie forensique ou un export doit toujours être créé ; l’élément de preuve original ne doit jamais être modifié directement. »
Extrait de la section « Exigences de mise en œuvre de la politique », clause de politique 6.1.1.

Elle impose également une consultation juridique lorsqu’un impact potentiel sur les ressources humaines, le juridique ou les clients peut exister :

« Si l’incident implique un impact potentiel sur les ressources humaines (RH), le juridique ou les clients, le DG doit consulter un conseil juridique avant de procéder à l’application de la politique ou à l’escalade. »
Extrait de la section « Exigences de gouvernance », clause de politique 5.4.2.

Un dossier pratique d’éléments de preuve doit être ouvert pendant la porte 2. Créez un dossier d’éléments de preuve d’incident à accès restreint. Exportez les chronologies SIEM, les détections EDR, les journaux d’audit cloud, les journaux de connexion du fournisseur d’identité, l’état des tâches de sauvegarde, les demandes de rançon, captures d’écran, messages de l’attaquant, adresses de portefeuille, échantillons de fichiers, références d’avis juridiques, correspondance avec l’assureur et décisions de réunion. Désignez un dépositaire. Enregistrez les valeurs de hachage lorsque c’est approprié. Ne laissez pas les administrateurs nettoyer les systèmes impactés avant l’acquisition forensique, sauf si la sécurité des personnes, la protection d’un service critique ou un confinement approuvé par la direction générale l’exige.

Une seule feuille de classification pour NIS2, DORA et GDPR

Un incident de rançongiciel peut déclencher plusieurs délais. Le défi ne consiste pas seulement à connaître les échéances. Il consiste à savoir quand l’organisation a pris connaissance de l’incident, ce qu’elle savait à ce moment-là et comment les décisions de classification ont été prises.

NIS2 Article 23 impose aux entités essentielles et importantes de notifier sans retard injustifié au CSIRT ou à l’autorité compétente les incidents significatifs. Le caractère significatif est lié à une perturbation opérationnelle grave, à une perte financière ou à des dommages matériels ou immatériels considérables pour autrui. Le modèle par étapes comprend une alerte précoce sous 24 heures, une notification sous 72 heures, des mises à jour intermédiaires si elles sont demandées et, le cas échéant, un rapport final dans un délai d’un mois à compter de la notification de l’incident.

DORA impose aux entités financières de définir et de mettre en œuvre la gestion des incidents liés aux TIC, d’enregistrer les incidents et les cybermenaces significatives, de classifier les incidents selon des critères tels que les clients affectés, la durée, l’étendue géographique, la perte de données, la criticité et l’impact économique, et de notifier les incidents majeurs liés aux TIC aux autorités compétentes au moyen de rapports initiaux, intermédiaires et finaux.

GDPR pose une question différente mais recoupée : l’incident a-t-il causé une violation de données à caractère personnel ? Si oui, est-il susceptible d’entraîner un risque pour les personnes ? Si le seuil de notification est atteint, la notification à l’autorité de contrôle doit être évaluée au regard du délai de 72 heures. En cas de risque élevé, une communication aux personnes peut également être nécessaire.

Clarysec recommande d’exploiter une feuille unique de classification des incidents de rançongiciel, avec des sections distinctes pour chaque régime.

Cette approche s’inscrit dans les clauses ISO 27001 relatives à l’appréciation des risques, au traitement des risques et aux informations documentées. Elle s’aligne également sur NIST CSF 2.0. La fonction GOVERN du NIST CSF 2.0 attend des organisations qu’elles comprennent les parties prenantes, les obligations légales et réglementaires, l’appétence au risque, les rôles, la politique, la supervision et les risques liés aux tiers. Ses résultats en matière de détection, de réponse et de rétablissement soutiennent la déclaration d’incident, l’analyse, la coordination de la réponse, la notification des parties prenantes, l’exécution du rétablissement et la validation de la restauration.

Pour les entités financières, DORA peut constituer le régime sectoriel de cybersécurité applicable aux obligations NIS2 qui se recoupent, mais cela ne supprime pas la nécessité de comprendre l’applicabilité de NIS2 aux entités du groupe, aux prestataires TIC, aux services managés ou aux dépendances cloud. La réponse pratique n’est pas de maintenir des playbooks séparés. Elle consiste à exploiter un modèle unique d’éléments de preuve SMSI cartographié avec toutes les obligations pertinentes.

L’assurance cyber et la coordination fournisseurs sont des contrôles de gouvernance

L’assurance cyber peut être utile, mais elle ne constitue pas une stratégie rançongiciel. C’est un mécanisme de transfert du risque assorti de conditions. Pendant un événement de rançongiciel, l’assureur peut exiger une notification immédiate, le recours à des cabinets référencés, une approbation préalable de la négociation, la préservation des éléments de preuve, la preuve d’un échec de sauvegarde, la preuve de contrôles raisonnables et une revue juridique avant toute considération de paiement.

DORA fait du risque lié aux prestataires tiers de TIC un domaine de conformité à part entière. NIS2 Article 21 impose également la sécurité de la chaîne d’approvisionnement et la prise en compte des vulnérabilités et pratiques de cybersécurité des fournisseurs. ISO 27001 soutient la même logique au moyen de contrôles fournisseurs et cloud, notamment A.5.19 à A.5.23, ainsi que des contrôles relatifs aux incidents, à la continuité et aux exigences légales.

Zenith Controls relie la préparation aux incidents aux partenaires externes, notamment les cabinets forensiques, le juridique, les relations publiques et le contact avec les autorités. Du point de vue de l’audit, l’absence de partenaires externes pré-identifiés peut être considérée comme une lacune de préparation, car elle peut retarder la réponse pendant un incident réel.

Pour la gouvernance des paiements de rançon, Clarysec recommande de pré-négocier :

• Un contrat de rétention forensique ou des conditions de réponse rapide.
• La disponibilité d’un conseil juridique externe pour la violation, les sanctions et la stratégie de confidentialité juridique.
• Le circuit de notification de l’assureur cyber et la liste des fournisseurs approuvés.
• Le circuit d’escalade du fournisseur cloud pour les instantanés, les journaux, l’isolement et le rétablissement.
• Les procédures de collaboration en incident avec le MSSP ou le MDR.
• Le processus de revue des relations publiques et des communications de crise.
• Les contrôles d’approbation bancaire ou financière pour tout paiement exceptionnel.
• Le protocole de contact avec les autorités répressives compétentes.

Cela se cartographie correctement avec les résultats de la chaîne d’approvisionnement du NIST CSF 2.0, notamment les rôles et responsabilités des fournisseurs, la diligence raisonnable, les exigences contractuelles de cybersécurité, la coordination des incidents fournisseurs et les activités postérieures à la résiliation.

Un playbook pratique d’escalade des paiements de rançon

Les cinq portes peuvent être traduites en playbook opérationnel. Chaque étape doit être documentée, attribuée et exercée.

L’objectif n’est pas de garantir une décision confortable. Il peut ne pas y avoir de décision confortable. L’objectif est de garantir que la décision est autorisée, fondée sur des éléments de preuve, éclairée juridiquement et défendable.

L’exercice sur table de 90 minutes qui prouve la préparation

La façon la plus simple de tester la gouvernance des paiements de rançon n’est pas un red team technique. C’est un exercice sur table décisionnel.

Utilisez Zenith Blueprint, phase Contrôles en action, étape 23, pour valider la capacité de gestion des incidents. Sélectionnez un scénario de rançongiciel et exécutez un exercice chronométré. L’objectif n’est pas de décider à l’avance que l’organisation paierait ou ne paierait jamais. L’objectif est de prouver que l’organisation peut parvenir à une décision gouvernée.

Scénario : une base de données clients hébergée dans le cloud est chiffrée, l’attaquant affirme avoir exfiltré des données, des sauvegardes existent mais leur intégrité n’a pas encore été testée, l’assureur n’a pas été notifié, et l’attaquant fournit une adresse de portefeuille avec une échéance de 48 heures.

Liste de contrôle de l’exercice :

• Déclarer l’incident et désigner le responsable de la coordination de l’incident.
• Ouvrir le journal de décision rançongiciel.
• Classifier l’événement selon les critères A.5.25.
• Identifier les actifs et services métier affectés.
• Déterminer si des données à caractère personnel sont concernées.
• Déclencher les workflows d’évaluation GDPR, NIS2, DORA et contractuels.
• Notifier le juridique, le DPO, la direction générale, l’assureur et le prestataire forensique.
• Préserver les éléments de preuve avant les actions de rétablissement destructrices.
• Vérifier l’intégrité des sauvegardes et les options de restauration.
• Réaliser le contrôle des sanctions avant toute négociation.
• Enregistrer si la consultation des autorités répressives compétentes est requise.
• Rédiger les déclarations d’attente destinées aux clients et aux autorités de régulation.
• Présenter les options de décision à l’autorité exécutive.
• Enregistrer la décision, la justification, les désaccords, les approbations et les prochaines actions.
• Planifier la revue post-incident et les actions d’amélioration des contrôles.

La sortie doit être un dossier complet d’éléments de preuve : liste de présence, chronologie, feuille de classification, journal de décision, projets de communication, actions juridiques, actions assureur, constats sur les sauvegardes et enseignements tirés. Ce dossier a une forte valeur en audit, car il montre que la gouvernance fonctionne avant une crise réelle.

Comment les auditeurs et les autorités de régulation testeront le processus

Des auditeurs issus de différents contextes examineront le même processus rançongiciel sous des angles différents.

Zenith Controls fournit une méthodologie d’audit détaillée pour A.5.24, A.5.25 et A.5.31. Pour A.5.24, les auditeurs examinent le plan de réponse aux incidents, les classifications de gravité, les rôles, les listes de contacts, les instructions de notification réglementaire, les exercices et les arrangements avec les partenaires externes. Pour A.5.25, ils vérifient si des critères de classification des événements existent, si les enregistrements de traitement des alertes montrent les décisions d’investigation et d’escalade, si le SIEM et le renseignement sur les menaces sont utilisés, et si le DPO ou les équipes juridiques sont impliqués lorsque des données à caractère personnel peuvent être affectées. Pour A.5.31, les auditeurs recherchent les registres juridiques, la cartographie de conformité, les éléments probants de revue, la couverture d’audit interne et le reporting à la direction générale.

Le risque d’audit ne tient pas seulement au fait qu’une organisation ait payé ou refusé de payer. Le risque d’audit tient au fait que personne ne puisse prouver comment la décision a été prise.

De l’extorsion à l’amélioration des contrôles

La gouvernance des rançongiciels ne s’arrête pas lorsque les systèmes sont restaurés. ISO 27001 exige l’amélioration continue. A.5.27, Enseignements tirés des incidents de sécurité de l’information, est central dans cette attente. DORA exige une analyse de la cause racine et des contrôles supplémentaires. Le rapport final NIS2 attend des mesures d’atténuation et la cause racine probable lorsque cela est applicable. La responsabilité au titre de GDPR exige la documentation des décisions et des mesures de protection.

Toute revue post-incident liée à un rançongiciel doit répondre aux questions suivantes :

• Les délais de notification ont-ils été correctement identifiés ?
• L’autorité de décision a-t-elle fonctionné comme prévu ?
• La revue juridique et le contrôle des sanctions sont-ils intervenus suffisamment tôt ?
• La coordination avec l’assureur a-t-elle aidé ou retardé la réponse ?
• Les sauvegardes étaient-elles complètes, séparées, restaurables et testées ?
• Les journaux étaient-ils suffisants pour évaluer l’accès et l’exfiltration ?
• Les fournisseurs ont-ils répondu conformément au contrat ?
• Les communications clients étaient-elles exactes et opportunes ?
• Les dirigeants ont-ils reçu les bonnes informations au bon moment ?
• Quels contrôles, politiques, contrats ou formations doivent évoluer ?

Ces réponses doivent mettre à jour le registre des risques, la Déclaration d’applicabilité, le plan de réponse aux incidents, la stratégie de sauvegarde, les contrats fournisseurs, le plan de communication et le programme de formation.

Dans la phase Fondations et leadership du SMSI, étape 5, Zenith Blueprint met l’accent sur la planification des communications externes, notamment l’identification des clients, autorités de régulation, partenaires et du public, la détermination de ce qui doit être communiqué et à quel moment, et la définition des personnes autorisées à communiquer. Pour les rançongiciels, cette étape devient le pont entre la réponse technique et la préservation de la confiance.

Construire l’enregistrement de décision avant la demande de rançon

Le meilleur moment pour gouverner une décision relative à une rançon est avant que l’attaquant ne fixe l’échéance.

Si votre playbook rançongiciel ne définit pas l’autorité de décision, la revue juridique, le contrôle des sanctions, l’approbation de l’assureur, la préservation des éléments de preuve, la classification NIS2 et DORA, l’évaluation de violation GDPR et la documentation au niveau du conseil d’administration, l’organisation présente une lacune de gouvernance qui attend une crise.

Clarysec aide les organisations à intégrer cette capacité dans le SMSI à l’aide de :

• Zenith Blueprint : feuille de route en 30 étapes pour auditeurs pour la mise en œuvre progressive d’ISO 27001, le traitement des risques, la planification de la communication et la validation des capacités de gestion des incidents.
• Zenith Controls : le guide de correspondance de conformité pour cartographier les contrôles ISO 27001 avec NIS2, DORA, GDPR, NIST CSF, COBIT 2019, ISO/IEC 27035, ISO/IEC 27701, ISO/IEC 27005 et les éléments probants d’audit.
• Les politiques Clarysec pour entreprises et PME, notamment la Politique de réponse aux incidents, la Politique de réponse aux incidents - PME, la Politique de collecte des éléments de preuve et d’investigation forensique, la Politique de collecte des éléments de preuve et d’investigation forensique - PME, la Politique relative aux rôles et responsabilités de gouvernance, la Politique relative aux rôles et responsabilités de gouvernance - PME et la Politique de gestion des risques.
• Des modèles pratiques d’exercices sur table rançongiciel, journaux de décision, matrices d’escalade juridique, dossiers d’éléments de preuve et feuilles de notification de conformité croisée.

N’attendez pas l’appel de 3 h du matin pour découvrir qui peut décider. Passez votre plan de réponse aux incidents au regard des cinq portes de Clarysec, exécutez un exercice sur table de 90 minutes consacré au paiement de rançon et construisez un enregistrement de décision sécurisé au regard des sanctions, prêt pour audit, capable de résister à l’examen des autorités de régulation, des assureurs et de votre propre conseil d’administration.