Appréciation des risques ISO 27001 prête pour l’audit pour NIS2 et DORA

Le café posé sur le bureau de Sarah était froid.

En tant que RSSI d’une fintech en forte croissance, elle connaissait la pression. L’entreprise venait de remporter un partenariat bancaire majeur, et le questionnaire de due diligence affiché à l’écran aurait dû n’être qu’une formalité. Les premières questions étaient familières : fournir la Déclaration d’applicabilité ISO/IEC 27001:2022, partager le dernier registre des risques, expliquer la méthodologie d’appréciation des risques.

Puis le questionnaire a changé de registre.

Démontrez comment votre programme de gestion des risques couvre DORA. Expliquez votre préparation à la directive NIS2, y compris la responsabilité de la direction et les mesures relatives aux risques liés à la chaîne d’approvisionnement. Fournissez les éléments probants démontrant que les fournisseurs TIC critiques sont évalués, surveillés et couverts par les plans de réponse aux incidents et de continuité d’activité.

Le lundi matin, le même sujet figurait à l’ordre du jour du comité des risques du conseil d’administration. Audit de certification ISO 27001 dans huit semaines. Pression DORA exercée par des clients du secteur financier. Questions de qualification NIS2 pour une ligne de services hébergés dans le cloud en expansion dans l’UE. Le service achats indiquait que des revues fournisseurs existaient, mais les éléments probants étaient dispersés entre des courriels, des dossiers contractuels et une feuille de calcul fournisseurs. Le service juridique précisait que la cartographie réglementaire était encore en cours. L’ingénierie affirmait que le registre des risques était presque finalisé.

Le conseil d’administration a posé la seule question qui comptait :

Pouvons-nous prouver que notre appréciation des risques et notre plan de traitement des risques sont suffisants ?

C’est le véritable problème pour les entreprises SaaS, les fintechs, les prestataires de services managés, les fournisseurs de services cloud et les plateformes numériques. Il ne s’agit pas seulement de savoir si un registre des risques existe. Il ne s’agit pas non plus de vérifier si les contrôles de l’Annexe A ont été copiés dans une feuille de calcul. La question est de savoir si l’organisation peut démontrer, sous la pression d’un audit et des clients, que son processus d’appréciation des risques ISO 27001 est répétable, fondé sur les risques, approuvé par les propriétaires des risques, lié aux actions de traitement, cartographié avec les obligations légales et réellement opérationnel.

Bien conduite, une appréciation des risques ISO 27001 et un plan de traitement des risques peuvent soutenir la certification ISO/IEC 27001:2022, les mesures de gestion des risques de cybersécurité prévues par NIS2 Article 21, les exigences DORA de gestion des risques liés aux TIC, la responsabilité au titre du GDPR, l’assurance fournisseur, la préparation aux incidents et le reporting au conseil d’administration.

Mal conduite, elle devient une feuille de calcul que les auditeurs démonteront en trente minutes.

Ce guide montre comment Clarysec construit des éléments probants d’appréciation et de traitement des risques ISO 27001 prêts pour l’audit à l’aide du Zenith Blueprint : feuille de route en 30 étapes pour l’auditeur, des politiques Clarysec et de Zenith Controls : guide de conformité croisée.

Pourquoi l’appréciation des risques ISO 27001 devient un pivot de conformité

Le paysage réglementaire européen converge autour d’un principe simple : le risque de cybersécurité doit être gouverné, documenté, testé et attribué.

ISO/IEC 27001:2022 fonctionne déjà ainsi. Les clauses 4.1 à 4.4 exigent que l’organisation comprenne son contexte, les parties intéressées, le périmètre du SMSI et les interactions entre processus avant d’apprécier les risques. Les clauses 6.1.2 et 6.1.3 exigent un processus défini d’appréciation et de traitement des risques de sécurité de l’information. Les clauses 8.2 et 8.3 exigent que l’organisation réalise les appréciations des risques et mette en œuvre le plan de traitement des risques tout en conservant les informations documentées.

NIS2 et DORA rendent cette logique fondée sur les risques plus urgente.

NIS2 Article 20 exige des organes de direction des entités essentielles et importantes qu’ils approuvent les mesures de gestion des risques de cybersécurité, en supervisent la mise en œuvre et suivent une formation à la cybersécurité. Article 21 exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées pour gérer les risques pesant sur les réseaux et les systèmes d’information. Ces mesures incluent l’analyse des risques, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, le développement sécurisé, la gestion 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 et l’authentification multifacteur ou les communications sécurisées lorsque cela est approprié.

DORA exerce une pression comparable sur les entités financières. Les Articles 5 et 6 exigent que l’organe de direction définisse, approuve, supervise et assume la responsabilité des dispositifs de gestion des risques liés aux TIC. DORA attend un cadre documenté de gestion des risques liés aux TIC intégré à la gestion globale des risques, soutenu par des politiques, procédures, protocoles, outils, l’audit interne, la remédiation, la continuité, les tests, la gestion des incidents et la gouvernance des prestataires tiers TIC.

La conclusion est pratique et incontournable : le registre des risques n’est plus une feuille de travail réservée à l’équipe technique. C’est un élément probant de gouvernance.

La Politique de gestion des risques Entreprise de Clarysec rend cette attente explicite :

Un processus formel de gestion des risques doit être maintenu conformément à ISO/IEC 27005 et ISO 31000, couvrant l’identification, l’analyse, l’évaluation, le traitement, le suivi et la communication des risques.

Extrait de la Politique de gestion des risques Entreprise, section « Exigences de gouvernance », clause de politique 5.1.

La même politique définit le résultat prêt pour l’audit :

Maintenir un registre des risques et un plan de traitement des risques centralisés et versionnés, reflétant le statut actuel des risques, la couverture des contrôles et l’avancement des mesures d’atténuation.

Extrait de la Politique de gestion des risques Entreprise, section « Objectifs », clause de politique 3.3.

Cette formule, « statut actuel des risques, couverture des contrôles et avancement des mesures d’atténuation », marque la différence entre un dossier de conformité statique et un programme de gestion des risques défendable.

Commencer par le périmètre, les obligations et les critères de risque

De nombreuses appréciations des risques ISO 27001 fragiles commencent par une liste de contrôles. C’est l’ordre inverse de ce qui est attendu.

ISO 27001 exige que l’organisation détermine le contexte, les exigences des parties intéressées, le périmètre du SMSI, les responsabilités de leadership et la planification des risques avant de sélectionner les contrôles. ISO/IEC 27005:2022 renforce cette approche en recommandant aux organisations d’identifier les exigences de base des parties intéressées avant d’apprécier les risques. Ces exigences peuvent provenir des normes ISO, des réglementations sectorielles, des lois nationales, des contrats clients, des politiques internes, des activités de traitement antérieures et des obligations fournisseurs.

Pour une entreprise SaaS ou une fintech orientée vers l’UE, le processus de gestion des risques doit commencer par un inventaire de conformité et des obligations.

Pour les PME, la Politique de conformité juridique et réglementaire - PME de Clarysec fixe le point de départ :

Le DG doit maintenir un registre de conformité simple et structuré listant :

Extrait de la Politique de conformité juridique et réglementaire PME, section « Exigences de gouvernance », clause de politique 5.1.1.

Ce registre simple fait le lien entre conformité et gestion des risques. S’il indique que le GDPR s’applique parce que des données à caractère personnel de l’UE sont traitées, que NIS2 peut s’appliquer parce que l’organisation fournit des services numériques ou managés, ou que DORA est pertinent du fait de clients du secteur financier, ces obligations doivent influer sur les critères de risque et les priorités de traitement.

Le Zenith Blueprint est explicite sur ce point dans la phase Gestion des risques, étape 10, « Définir les critères de risque et la matrice d’impact » :

Tenez également compte des exigences légales et réglementaires dans vos critères d’acceptation. Certains risques peuvent être inacceptables indépendamment de leur vraisemblance en raison d’exigences légales.

Extrait du Zenith Blueprint, phase Gestion des risques, étape 10.

Il donne également une règle pratique pour les ateliers :

« Tout risque susceptible d’entraîner une non-conformité aux lois applicables (GDPR, etc.) est inacceptable et doit être atténué. »

Extrait du Zenith Blueprint, phase Gestion des risques, étape 10.

Pour la fintech de Sarah, cela modifie le modèle de cotation. Une vulnérabilité d’API fournisseur peut présenter une faible vraisemblance, mais si son exploitation pouvait déclencher un incident majeur lié aux TIC au sens de DORA, un incident significatif NIS2, une évaluation de violation GDPR, un manquement à un SLA client ou une escalade au niveau du conseil d’administration, l’impact est élevé ou critique. L’exposition de conformité devient partie intégrante de la logique de risque, et non une feuille de calcul distincte.

Construire un registre des risques que les auditeurs peuvent tester

Les auditeurs ne demandent pas seulement quels sont vos principaux risques. Ils testent si votre méthode est définie, répétable, traçable et appliquée.

Ils poseront les questions suivantes :

• Comment avez-vous identifié ces risques ?
• Quels actifs, services, fournisseurs, types de données et processus étaient dans le périmètre ?
• Quels critères ont été utilisés pour la vraisemblance et l’impact ?
• Qui est propriétaire de chaque risque ?
• Quels contrôles existants réduisent le risque ?
• Pourquoi cette décision de traitement a-t-elle été retenue ?
• Où se trouvent les éléments probants démontrant que le traitement a été réalisé ?
• Qui a approuvé le risque résiduel ?
• Quand le risque sera-t-il réévalué ?

La Politique de gestion des risques - PME de Clarysec décrit l’entrée minimale de risque prête pour l’audit :

Chaque entrée de risque doit inclure : la description, la vraisemblance, l’impact, le score, le propriétaire et le plan de traitement des risques.

Extrait de la Politique de gestion des risques PME, section « Exigences de gouvernance », clause de politique 5.1.2.

Pour les programmes d’entreprise, le Zenith Blueprint, phase Gestion des risques, étape 11, « Construire et documenter le registre des risques », étend cette structure. Il recommande des colonnes telles que l’identifiant du risque, l’actif, la menace, la vulnérabilité, la description du risque, la vraisemblance, l’impact, le niveau de risque, les contrôles actuels, le propriétaire du risque, la décision de traitement, le plan de traitement des risques ou les contrôles, et le statut.

Une entrée de risque robuste ressemble à ceci :

C’est matériellement différent de « risque tiers, élevé, atténuer ». La version prête pour l’audit relie l’actif, la menace, la vulnérabilité, la conséquence, les contrôles actuels, le propriétaire, la réglementation, les éléments probants et la gouvernance.

Transformer le traitement des risques en plan de preuve

Un plan de traitement des risques doit répondre à quatre questions opérationnelles :

1. Que ferons-nous ?
2. Qui en est responsable ?
3. Quand cela sera-t-il fait ?
4. Comment prouverons-nous que le risque a été réduit ?

ISO/IEC 27001:2022 Clause 6.1.3 exige que l’organisation sélectionne des options de traitement, détermine les contrôles nécessaires, les compare à l’Annexe A pour éviter les omissions, produise une Déclaration d’applicabilité, formule un plan de traitement des risques et obtienne l’approbation du propriétaire du risque pour le plan et les risques résiduels. La clause 8.3 exige ensuite la mise en œuvre du plan de traitement des risques et la conservation d’informations documentées sur les résultats.

La Politique de gestion des risques Entreprise rend cela opérationnel :

Le responsable des risques doit veiller à ce que les traitements soient réalistes, assortis d’échéances et cartographiés avec les contrôles de l’Annexe A ISO/IEC 27001.

Extrait de la Politique de gestion des risques Entreprise, section « Exigences de mise en œuvre de la politique », clause de politique 6.4.2.

La politique PME précise également que l’acceptation n’est pas un raccourci :

Accepter : justifier pourquoi aucune action supplémentaire n’est requise et enregistrer le risque résiduel.

Extrait de la Politique de gestion des risques PME, section « Exigences de mise en œuvre de la politique », clause de politique 6.1.1.

L’acceptation doit être justifiée au regard des critères, approuvée par le propriétaire compétent et surveillée. Dans le cadre de NIS2 et de DORA, un risque résiduel non approuvé peut devenir une défaillance de gouvernance.

Un plan de traitement complet doit contenir les champs suivants :

Pour le risque R-042 de Sarah, le plan de traitement devient une liste d’actions de conformité croisée.

Ce plan est puissant parce qu’il crée une ligne directe entre un scénario de risque, les contrôles ISO 27001, les obligations NIS2, les articles DORA, les propriétaires et les éléments probants.

Faire travailler davantage la Déclaration d’applicabilité

La Déclaration d’applicabilité est souvent traitée comme un livrable de certification. Elle doit être davantage que cela.

ISO/IEC 27001:2022 Clause 6.1.3 exige que la SoA inclue les contrôles nécessaires, la justification de leur inclusion, le statut de mise en œuvre et la justification des exclusions. Les lignes directrices ISO/IEC 27005:2022 renforcent la nécessité de comparer les contrôles sélectionnés avec l’Annexe A ISO/IEC 27001 afin d’éviter les omissions.

Dans un programme prêt pour l’audit, la SoA devient le pont entre le traitement des risques et les éléments probants de conformité croisée. Si un plan de traitement exige la MFA, la journalisation, la surveillance des fournisseurs, la restauration des sauvegardes, le développement sécurisé, l’escalade des incidents ou la planification de sortie cloud, la SoA doit montrer que les contrôles pertinents de l’Annexe A sont inclus, justifiés, mis en œuvre ou planifiés, et étayés par des éléments probants.

Cela permet également d’éviter une défaillance d’audit fréquente : le registre des risques dit une chose, le plan de traitement en dit une autre, et la SoA reste muette. Lorsque ces livrables divergent, les auditeurs perdent rapidement confiance.

Cartographier le traitement des risques ISO 27001 avec NIS2, DORA et GDPR

ISO 27001 ne remplace ni NIS2, ni DORA, ni GDPR. Elle fournit un mécanisme structuré pour produire des éléments probants à leur appui.

L’essentiel consiste à intégrer la cartographie au processus de gestion des risques au lieu de l’ajouter après coup.

Cette cartographie est particulièrement importante lorsque les réglementations se chevauchent. DORA constitue le régime sectoriel de résilience TIC applicable à de nombreuses entités financières, tandis que NIS2 peut rester directement pertinente pour certains prestataires, pour la coordination ou pour des entités hors du champ de DORA. Une fintech peut devoir utiliser DORA comme cadre principal de résilience TIC, tandis qu’un prestataire de services managés qui soutient cette fintech peut être directement soumis à des obligations NIS2.

Le registre des risques doit être capable de montrer les deux côtés de cette dépendance.

Utiliser Zenith Controls comme boussole de conformité croisée

Clarysec utilise Zenith Controls comme guide de conformité croisée afin d’éviter la défaillance courante où les contrôles ISO, les articles réglementaires et les questions d’audit vivent dans des univers séparés. Il ne crée pas un cadre de contrôle distinct. Il cartographie les domaines de contrôle ISO/IEC 27001:2022 et ISO/IEC 27002:2022 avec d’autres normes, attentes d’audit et perspectives de conformité.

Pour l’appréciation et le traitement des risques ISO 27001, les références suivantes sont particulièrement importantes :

La leçon de conformité croisée est simple. Si les obligations légales ne figurent pas dans la méthode d’appréciation des risques, votre cotation est incomplète. Si la cotation est incomplète, les priorités de traitement peuvent être erronées. Si les priorités sont erronées, la SoA et le reporting au conseil d’administration deviennent peu fiables.

Le Zenith Blueprint exprime le même point dans la phase Gestion des risques, étape 14, « Politiques de traitement des risques et références réglementaires croisées ». Il recommande aux organisations de créer une table de cartographie recensant les principales exigences réglementaires de sécurité et les contrôles ou politiques correspondants dans le SMSI. Ce n’est pas obligatoire pour la certification ISO 27001, mais c’est très utile pour démontrer que la sécurité est gérée dans un contexte légal et contractuel.

Ce que demanderont différents auditeurs

Un auditeur de certification, un évaluateur orienté NIS2, un client orienté DORA, un évaluateur GDPR, un évaluateur NIST ou un praticien COBIT peut examiner les mêmes éléments probants, mais poser des questions différentes.

C’est pourquoi l’architecture des éléments probants est déterminante. La même entrée de risque doit être traçable depuis l’objectif métier jusqu’à l’actif, la menace, la vulnérabilité, le contrôle, le propriétaire, le déclencheur réglementaire, l’action de traitement, le résultat de test et la décision de direction.

Les politiques Clarysec sont conçues pour soutenir cette architecture. La Politique de gestion des risques Entreprise indique dans la section « Normes et référentiels de référence » :

Article 5 : impose un cadre documenté de gestion des risques liés aux TIC, entièrement couvert par la structure de cette politique, y compris la cartographie SoA et les KRI.

Cela transforme la politique d’un document statique en élément probant d’audit montrant que la gouvernance des risques TIC a été conçue intentionnellement avec DORA à l’esprit.

Constats courants qui fragilisent les programmes de gestion des risques

Lorsque Clarysec examine les éléments probants d’appréciation et de traitement des risques ISO 27001, les mêmes constats reviennent régulièrement.

Premièrement, les critères de risque ignorent l’impact légal, réglementaire, contractuel, fournisseur et vie privée. Cela produit une cotation faible. Une violation de données à caractère personnel ou une défaillance d’un fournisseur critique peut être classée moyenne parce que sa vraisemblance est faible, alors que l’impact GDPR, NIS2, DORA ou client devrait la rendre élevée ou critique.

Deuxièmement, les propriétaires du risque sont génériques. « IT » n’est pas un propriétaire du risque. Un propriétaire du risque doit être un rôle ou une personne responsable des décisions de traitement, du budget, du calendrier et du risque résiduel.

Troisièmement, les plans de traitement ne sont pas assortis d’échéances. « Améliorer la surveillance » n’est pas un plan. « Déployer des alertes de session à privilèges dans le SIEM pour les comptes administrateur de production d’ici le 30 juin, sous la responsabilité du Responsable SOC, testé par une connexion administrateur simulée, avec éléments probants d’alerte joints » est un plan.

Quatrièmement, la SoA est déconnectée du traitement. Si le plan de traitement exige la surveillance des fournisseurs, les tests de sauvegarde, l’escalade des incidents, la MFA ou la journalisation, la SoA doit refléter les contrôles pertinents et leur statut de mise en œuvre.

Cinquièmement, le risque résiduel n’est pas approuvé. ISO 27001 exige l’approbation, par le propriétaire du risque, du plan de traitement des risques et des risques résiduels. NIS2 et DORA rendent cela encore plus important parce que la responsabilité de la direction y est explicite.

Sixièmement, le risque fournisseur est traité comme une formalité achats. Au titre de NIS2 Article 21(2)(d) et des DORA Articles 28 et 30, les risques fournisseurs et les risques liés aux prestataires tiers TIC doivent faire partie de la gestion des risques, et non d’un questionnaire annuel stocké isolément.

Septièmement, il n’existe aucun élément probant de l’efficacité. ISO 27001 Clause 6.1.1 exige que l’efficacité des actions planifiées soit évaluée. NIS2 inclut l’évaluation de l’efficacité dans Article 21(2)(f). DORA attend des tests et de la remédiation. Un contrôle qui existe mais qui n’est jamais testé constitue un élément probant faible.

La Politique de gestion des risques - PME fixe clairement l’attente :

Le Directeur général et le Coordinateur des risques doivent veiller à ce que les activités de gestion des risques soient prêtes pour l’audit. Le registre des risques et les actions associées sont soumis à l’audit interne et externe.

Extrait de la Politique de gestion des risques PME, section « Application et conformité », clause de politique 8.2.1.

Reporting au conseil d’administration sans noyer les dirigeants

NIS2, DORA et ISO 27001 convergent toutes vers la responsabilité de la direction, mais les conseils d’administration n’ont pas besoin de chaque ligne de risque. Ils ont besoin d’un reporting utile à la décision.

Un bon dossier de risques pour le conseil d’administration doit présenter :

• Les risques élevés et critiques par domaine
• Les actions de traitement en retard
• Les risques réglementaires impliquant NIS2, DORA, GDPR ou des contrats
• Les risques fournisseurs affectant des services critiques ou importants
• Les tendances des incidents et quasi-accidents
• Les risques résiduels en attente d’acceptation
• Les résultats des tests d’efficacité des contrôles
• Les changements matériels de périmètre, de fournisseurs, de technologie ou de droit
• Les constats d’audit interne et les actions correctives

Clarysec recommande généralement des revues opérationnelles mensuelles des risques et des revues de direction trimestrielles. Les revues mensuelles se concentrent sur la réalisation des traitements. Les revues trimestrielles se concentrent sur l’acceptation, le financement, la priorisation, l’exposition réglementaire et les décisions stratégiques de risque.

Ce rythme soutient également l’amélioration continue. Les appréciations des risques doivent être mises à jour lorsque des incidents surviennent, que des vulnérabilités apparaissent, que de nouveaux actifs sont introduits, que la technologie évolue, que les fournisseurs changent, que les lois changent, que les obligations clients évoluent ou que l’appétence au risque change.

Le parcours de mise en œuvre Clarysec

Un programme de gestion des risques unifié évite les feuilles de calcul ISO, NIS2, DORA, GDPR et d’assurance client déconnectées. Le parcours pratique est le suivant :

1. Confirmer le périmètre du SMSI, les services, les actifs, les fournisseurs, les juridictions et les obligations clients.
2. Construire ou mettre à jour le registre de conformité en utilisant, le cas échéant, la Politique de conformité juridique et réglementaire - PME.
3. Définir la méthodologie de risque, les critères d’acceptation, les échelles de vraisemblance, les échelles d’impact et les règles d’impact réglementaire.
4. Construire le registre des risques à l’aide de la phase Gestion des risques du Zenith Blueprint et de l’approche Clarysec de construction du registre des risques et de la SoA.
5. Identifier les risques fondés sur les actifs et les scénarios, y compris les scénarios fournisseurs, cloud, vie privée, continuité, incidents, vulnérabilités, développement sécurisé et accès.
6. Coter les risques à l’aide de critères incluant les impacts légaux, réglementaires, contractuels, opérationnels, vie privée, fournisseurs et financiers.
7. Sélectionner les options de traitement : atténuer, éviter, transférer ou accepter.
8. Cartographier les contrôles nécessaires avec l’Annexe A ISO/IEC 27001:2022 et les lignes directrices ISO/IEC 27002:2022.
9. Créer ou mettre à jour la Déclaration d’applicabilité.
10. Cartographier les traitements avec NIS2 Article 21, la gestion des risques TIC et les attentes relatives aux prestataires tiers de DORA, la responsabilité GDPR et les obligations contractuelles clients.
11. Collecter les éléments probants, valider l’efficacité des contrôles et obtenir l’approbation des risques résiduels.
12. Préparer un dossier d’audit organisé par risque, contrôle, réglementation et livrable justificatif.
13. Alimenter la revue de direction, l’audit interne, les actions correctives et l’amélioration continue avec les résultats.

Ce n’est pas de la documentation pour elle-même. C’est le système d’exploitation d’une gouvernance cyber défendable.

Construire un dossier de traitement des risques prêt pour l’audit

L’histoire de Sarah se termine bien parce qu’elle a cessé de traiter ISO 27001, NIS2 et DORA comme des projets de conformité séparés. Elle a utilisé l’appréciation des risques ISO 27001 comme moteur central, intégré les obligations réglementaires dans les critères de risque, cartographié les actions de traitement avec l’Annexe A et les exigences de l’UE, et collecté des éléments probants compréhensibles par les clients, les auditeurs et le conseil d’administration.

Votre organisation peut faire de même.

Utilisez Zenith Blueprint : feuille de route en 30 étapes pour l’auditeur pour définir les critères de risque, construire le registre des risques, créer le plan de traitement des risques et croiser les exigences réglementaires.

Utilisez Zenith Controls : guide de conformité croisée pour relier les domaines de contrôle de l’Annexe A ISO/IEC 27001:2022 aux perspectives de gouvernance, de conformité juridique, d’assurance et d’audit.

Utilisez la Politique de gestion des risques, la Politique de gestion des risques - PME et la Politique de conformité juridique et réglementaire - PME de Clarysec pour standardiser la propriété, les registres, les décisions de traitement et les éléments probants prêts pour l’audit.

L’étape pratique la plus rapide consiste à prendre vos dix principaux risques et à les tester au regard de cinq questions :

1. L’impact réglementaire est-il visible ?
2. Le plan de traitement est-il assorti d’échéances et attribué à un propriétaire ?
3. Chaque traitement est-il cartographié avec l’Annexe A et la SoA ?
4. La pertinence NIS2, DORA, GDPR ou client est-elle documentée lorsqu’elle s’applique ?
5. Existe-t-il des éléments probants montrant que le contrôle fonctionne ?

Si la réponse est non, Clarysec peut vous aider à transformer votre registre des risques en un programme de traitement des risques défendable, couvrant la conformité croisée, auquel les auditeurs, les autorités de régulation, les clients et les conseils d’administration peuvent faire confiance.