Appétence au risque lié aux TIC DORA : guide d’approbation par le conseil pour 2026

Il est 08 h 15 un mardi, et le RSSI d’une entreprise de taille intermédiaire spécialisée dans les technologies de paiement attend devant la salle du conseil, trois documents ouverts sur sa tablette.

Le premier est le registre des risques liés aux TIC. Il contient 137 lignes, des cotations en couleur et plusieurs risques élevés liés à la concentration cloud, aux accès à privilèges, à la reprise après rançongiciel, à l’exposition des données clients et à la réponse aux incidents côté fournisseur. Le deuxième est le tableau de suivi de la préparation à DORA. Il indique que l’entreprise dispose de politiques, de procédures relatives aux incidents, de registres des tiers et de plans de tests de résilience. Le troisième est le dossier destiné au conseil pour une réunion réglementaire.

Le président a une seule question, et elle n’est pas technique :

« Quel niveau de risque lié aux TIC avons-nous réellement convenu d’accepter ? »

La salle se tait, car l’entreprise dispose d’appréciations des risques, mais pas d’une appétence au risque lié aux TIC approuvée par le conseil. Elle a des cotations d’impact, mais pas de seuils de tolérance mesurables. Elle tient des réunions d’escalade, mais aucun déclencheur formel n’indique quand un risque cyber devient une décision de l’organe de direction. Elle a accepté des risques résiduels, mais certains sont justifiés comme des « décisions métier » sans lien clair avec les critères de risque, la proportionnalité de GDPR Article 32, les attentes de tolérance de DORA ou la responsabilité de la direction au titre de NIS2.

Cette lacune devient de plus en plus visible en 2026. DORA s’applique depuis le 17 janvier 2025 et impose aux entités financières de maintenir un cadre de gouvernance et de contrôle du risque lié aux TIC, incluant la responsabilité de l’organe de direction à l’égard du cadre de gestion des risques liés aux TIC, de la stratégie de résilience opérationnelle numérique et de la tolérance au risque lié aux TIC. NIS2 conduit les organes de direction à approuver les mesures de gestion des risques de cybersécurité et à en superviser la mise en œuvre. GDPR Article 32 exige des mesures techniques et organisationnelles de sécurité appropriées, fondées sur le risque. ISO/IEC 27001:2022 fournit la mécanique du système de management : contexte, parties intéressées, critères de risque, plans de traitement des risques, informations documentées et revue de direction.

Le chaînon manquant est une déclaration d’appétence et de tolérance au risque lié aux TIC qu’un conseil peut comprendre, approuver, challenger et utiliser.

Ce guide explique comment construire ce chaînon à l’aide du Zenith Blueprint: An Auditor’s 30-Step Roadmap de Clarysec, de la Risk Management Policy de Clarysec, de la Risk Management Policy-sme de Clarysec et de Zenith Controls: The Cross-Compliance Guide.

Pourquoi les registres des risques ne sont pas une appétence au risque

De nombreuses organisations confondent registre des risques et gouvernance des risques. Un registre des risques indique quels risques existent, comment ils sont cotés, qui en est propriétaire et quel traitement est prévu. Il ne répond pas automatiquement aux questions de niveau conseil que DORA, NIS2, GDPR et ISO/IEC 27001:2022 attendent des dirigeants.

Une déclaration d’appétence au risque lié aux TIC mature répond à des questions telles que :

• Quels risques liés aux TIC sont inacceptables, quel qu’en soit le coût ?
• Quelle indisponibilité opérationnelle l’organisation peut-elle tolérer pour une fonction critique ou importante ?
• Quel niveau de perte de données ou d’atteinte à l’intégrité des données sort du cadre de l’appétence ?
• Quel risque de concentration chez un tiers exige l’attention du conseil ?
• Qui peut accepter un risque résiduel lié aux TIC, et à quel niveau ?
• Quand un risque doit-il être escaladé à la direction générale ou à l’organe de direction ?
• Comment les exigences légales, réglementaires et contractuelles sont-elles intégrées aux critères de risque ?

Au titre de DORA, il ne s’agit pas d’un simple vernis de gouvernance facultatif. Article 5 impose à l’organe de direction de définir, d’approuver, de superviser et d’assumer la responsabilité du cadre de gestion des risques liés aux TIC, y compris la stratégie de résilience opérationnelle numérique et la tolérance au risque lié aux TIC. Article 6 exige un cadre documenté de gestion des risques liés aux TIC, une revue annuelle pour les entreprises autres que les microentreprises, un audit interne, la remédiation des constats d’audit critiques et une stratégie de résilience opérationnelle numérique couvrant les objectifs TIC, la tolérance au risque, la tolérance d’impact, l’architecture, les tests et la stratégie de communication relative aux incidents.

NIS2 ajoute un modèle de responsabilité parallèle. Article 20 impose aux organes de direction des entités essentielles et importantes d’approuver les mesures de gestion des risques de cybersécurité, d’en superviser la mise en œuvre et de suivre une formation. Article 21 exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées, fondées sur une approche tous risques, incluant 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é, l’efficacité des contrôles, la formation, la cryptographie, la sécurité des ressources humaines, le contrôle d’accès, la gestion des actifs et l’authentification multifacteur lorsque cela est approprié.

Pour les entités financières, DORA est traité comme un acte juridique de l’Union propre au secteur lorsque des obligations NIS2 se chevauchent. En pratique, DORA remplace généralement les exigences NIS2 de gestion des risques et de notification des incidents qui se chevauchent pour les entités financières relevant de son champ d’application, tandis que NIS2 demeure importante pour la coordination et pour les prestataires qui ne sont pas directement soumis aux obligations DORA applicables aux entités financières. Pour les fournisseurs SaaS, cloud, de services managés et de sécurité managée, NIS2 peut s’appliquer directement lorsque les conditions de champ d’application sont réunies.

C’est pourquoi l’appétence au risque lié aux TIC approuvée par le conseil n’est plus un livrable de risque financier. C’est un contrôle de gouvernance de cybersécurité.

Utiliser ISO/IEC 27001:2022 comme système d’exploitation

DORA et NIS2 indiquent aux dirigeants ce qui doit être gouverné. ISO/IEC 27001:2022 fournit aux organisations un système d’exploitation pratique pour gouverner ce périmètre.

Les Clauses 4.1 à 4.4 d’ISO/IEC 27001:2022 exigent que l’organisation définisse le contexte, les parties intéressées, les exigences, le domaine d’application du SMSI et les processus du SMSI. Ce point est essentiel, car DORA, NIS2, GDPR, les contrats, les attentes des autorités de contrôle, les clients, les fournisseurs cloud et les dispositifs d’externalisation deviennent tous des exigences qui influencent les critères de risque.

Les Clauses 5.1 à 5.3 exigent l’engagement de la direction, l’alignement des politiques, les ressources, les responsabilités et le reporting de la performance du SMSI à la direction générale. Les Clauses 6.1.1 à 6.1.3 exigent une planification fondée sur les risques, un processus documenté d’appréciation des risques, des critères d’acceptation, des critères d’appréciation cohérents, des propriétaires du risque, la comparaison avec les critères de risque, la planification du traitement, une Déclaration d’applicabilité et l’approbation du risque résiduel.

C’est le socle de la tolérance au risque lié aux TIC DORA.

Dans la phase de gestion des risques, l’étape 10 du Zenith Blueprint demande aux organisations de définir les critères de risque avant de coter les risques :

« Les critères de risque sont les règles et les points de référence que votre organisation utilise pour évaluer l’importance de chaque risque. Les établir en amont garantit que chacun parle le même langage du risque. »

La même étape rappelle que l’impact réglementaire doit être intégré aux définitions du risque :

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

Le Zenith Blueprint fournit également des orientations pratiques pour l’échelle d’impact :

« Lorsque vous définissez l’impact, il est judicieux de rattacher les niveaux à l’échelle propre à votre activité. Par exemple, “Impact financier majeur = perte > 100 k$” (à adapter à votre contexte). Tenez également compte de l’impact réglementaire : par exemple, une violation de données à caractère personnel pourrait automatiquement être “Majeure” ou “Sévère” en raison des amendes GDPR et des exigences de notification, même si la perte financière directe est incertaine. De même, si vous êtes dans le champ de NIS2 (services essentiels), un incident entraînant une interruption de service pourrait au minimum être “Majeur” en raison des implications juridiques. Intégrez ces considérations à vos définitions. »

Ces orientations évitent une erreur fréquente : coter un risque cyber comme modéré parce que la perte financière immédiate semble faible, tout en ignorant l’impact juridique, la résilience opérationnelle, les personnes concernées ou les clients.

Un modèle prêt pour le conseil doit distinguer quatre niveaux :

Cette structure rend l’appétence au risque auditable, car chaque déclaration peut être reliée aux critères de risque, aux contrôles, aux éléments de preuve et aux décisions.

Une déclaration d’appétence au risque lié aux TIC DORA prête pour le conseil

Une déclaration d’appétence au risque lié aux TIC solide doit être assez courte pour être approuvée par le conseil, assez précise pour être appliquée par la direction et assez mesurable pour être testée par les auditeurs. Elle doit éviter le jargon, sans être vague.

Une déclaration générale pratique pourrait être formulée ainsi :

« Notre entreprise présente une faible appétence pour les risques liés aux TIC susceptibles d’entraîner un préjudice significatif pour les clients, une interruption des fonctions critiques ou importantes, une divulgation ou une altération non autorisée de données réglementées, un manquement aux obligations légales ou une perte de résilience des services TIC critiques fournis par des tiers. »

Cette déclaration doit ensuite être assortie de seuils de tolérance mesurables et de déclencheurs d’escalade.

Ce tableau change la discussion. Le conseil n’approuve plus un slogan. Il approuve des limites opérationnelles pour la disponibilité, la confidentialité, l’intégrité, les fournisseurs, les vulnérabilités, la reprise et la conformité.

La Risk Management Policy de Clarysec soutient ce modèle de gouvernance. La politique d’entreprise indique :

« Approuve le cadre de gestion des risques et définit l’appétence au risque acceptable ainsi que les seuils de tolérance. »

La Clause 6.2.1 rend l’exigence de mesure explicite :

« Les risques doivent être évalués en fonction de la vraisemblance et de l’impact à l’aide d’une matrice des risques standard comportant des échelles de notation clairement définies. »

La Clause 6.3.4 crée la règle d’acceptation attendue par les auditeurs :

« Les risques acceptés sans traitement doivent être justifiés par écrit, liés à l’appétence au risque de l’organisation et approuvés au niveau approprié. »

Pour les PME, la Risk Management Policy-sme conserve le même principe de gouvernance dans un format allégé :

« Veiller à l’implication de la direction dans l’approbation de la tolérance au risque et des principaux plans de traitement des risques. »

Elle exige également l’escalade des risques élevés :

« Les risques élevés doivent être escaladés au Directeur général pour décision. »

C’est la proportionnalité en pratique. DORA Article 4 exige que les exigences soient appliquées de manière proportionnée à la taille, au profil de risque, ainsi qu’à la nature, à l’échelle et à la complexité des services. ISO/IEC 27001:2022 permet d’appliquer le même principe au moyen du périmètre, du contexte, des critères de risque et des décisions de traitement. La norme de gouvernance n’impose pas à chaque organisation la même structure de comité. Elle impose que l’appétence au risque, la tolérance, l’escalade et l’acceptation soient définies, approuvées, étayées par des éléments de preuve et utilisées.

GDPR Article 32 modifie la discussion sur les risques

GDPR Article 32 est souvent traité comme une clause de sécurité technique. En matière de gouvernance, c’est également une clause d’appétence au risque.

Article 32 exige que les responsables du traitement et les sous-traitants mettent en œuvre des mesures techniques et organisationnelles appropriées afin de garantir un niveau de sécurité adapté au risque. Cette approche fondée sur les risques tient compte de l’état de l’art, des coûts de mise en œuvre, de la nature, de la portée, du contexte et des finalités du traitement, ainsi que des risques pour les droits et libertés des personnes physiques.

Cela influence l’appétence au risque lié aux TIC de trois façons.

Premièrement, l’impact sur les données à caractère personnel ne peut pas être réduit à une perte financière. L’exposition d’une petite base de données peut avoir un coût direct limité, mais entraîner des conséquences importantes en matière de confidentialité, d’identité, de fraude, de discrimination ou d’atteinte aux droits. Lorsque des catégories particulières de données à caractère personnel sont concernées, telles que des données de santé, biométriques ou génétiques, l’appétence doit être sensiblement plus faible.

Deuxièmement, les rôles de traitement doivent être reliés à la propriété du risque. GDPR distingue les responsables du traitement et les sous-traitants. DORA distingue les entités financières et les prestataires tiers de services TIC. NIS2 distingue les entités essentielles et importantes. ISO/IEC 27001:2022 exige des propriétaires du risque. Une déclaration d’appétence mature doit identifier qui est propriétaire des décisions de risque impliquant des données à caractère personnel, un traitement externalisé, des services critiques et des dépendances transfrontalières.

Troisièmement, la proportionnalité d’Article 32 doit être visible dans la sélection des contrôles. Le chiffrement, la pseudonymisation, le contrôle d’accès, la sauvegarde, la journalisation, la surveillance, la réponse aux incidents et la résilience ne sont pas des tâches techniques isolées. Ce sont des mesures de traitement sélectionnées parce qu’un risque a dépassé l’appétence ou la tolérance.

La Risk Management Policy de Clarysec établit explicitement ce lien :

« Article 32 : impose une approche fondée sur les risques pour les mesures de sécurité, satisfaite au moyen d’évaluations des risques fondées sur l’impact et de la sélection des contrôles. »

C’est le lien opérationnel recherché par les auditeurs : exigence Article 32, appréciation des risques, cotation du risque, plan de traitement des risques, sélection des contrôles, risque résiduel et approbation.

Comment Zenith Controls soutient les éléments de preuve de conformité croisée

Une déclaration d’appétence approuvée par le conseil devient puissante lorsqu’elle est cartographiée avec les contrôles. Zenith Controls agit comme le guide de conformité croisée de Clarysec, en aidant les équipes à réutiliser les éléments de preuve entre ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF et l’assurance de type COBIT.

Trois domaines de contrôle ISO/IEC 27002:2022 sont particulièrement importants :

Il ne s’agit pas d’un simple exercice de cartographie documentaire. Cela modifie la façon dont les décisions sont prises.

Si un responsable métier demande à accepter un déploiement différé de l’authentification multifacteur pour les administrateurs, Zenith Controls aide le RSSI à montrer qu’il ne s’agit pas seulement d’une question de contrôle d’accès. La décision touche à la gouvernance des politiques, à la responsabilité de la direction, aux exigences légales et réglementaires, à la sécurité du traitement au titre de GDPR, à la gestion des risques liés aux TIC au titre de DORA, aux mesures de cybersécurité NIS2, à l’impact d’un incident et aux éléments probants d’audit.

Si une équipe produit souhaite se lancer sur un nouveau marché de l’UE avec un nouveau service cloud, le contrôle 5.31 d’ISO/IEC 27002:2022 fait entrer la revue des exigences légales et réglementaires dans le domaine d’application du SMSI. La Clause 4.2 d’ISO/IEC 27001:2022 exige l’identification des exigences des parties intéressées, y compris les obligations légales, réglementaires et contractuelles. La Clause 8.1 exige la planification et la maîtrise opérationnelles, y compris la maîtrise des processus, produits ou services fournis par des tiers et pertinents pour le SMSI.

L’objectif est un langage du risque unique, et non des dialectes de conformité séparés.

Processus d’approbation : qui décide quoi

Un RSSI peut proposer l’appétence au risque lié aux TIC, mais le conseil ou l’organe de direction doit en être propriétaire. Cette responsabilité exige un processus.

Cela s’aligne également avec NIST CSF 2.0. La fonction GOVERN, en particulier GV.RM, attend des objectifs de gestion des risques, des déclarations d’appétence et de tolérance au risque convenus, l’intégration des activités de risque dans la gestion des risques de l’organisation, des options définies de réponse au risque, des lignes de communication et des méthodes standardisées de calcul, de documentation, de catégorisation et de priorisation des risques de cybersécurité. GV.RR attend la responsabilité de la direction, les rôles, les autorités et les ressources alignés sur la stratégie de risque. GV.PO attend que les politiques soient établies, communiquées, mises en application, revues et mises à jour.

Les professionnels de l’assurance de type COBIT 19 et ISACA demanderont si l’appétence au risque est intégrée à la gouvernance d’entreprise de l’information et des technologies, et non simplement ajoutée en annexe à une politique cyber.

Construire un dossier d’appétence au risque lié aux TIC en une session de travail

Un atelier pratique sur l’appétence au risque lié aux TIC peut faire passer une organisation de registres dispersés à un dossier prêt pour le conseil et auditable.

Étape 1 : collecter les bons éléments d’entrée

Préparez le registre actuel des risques liés aux TIC, l’analyse d’impact sur l’activité, les objectifs de reprise, la liste des fonctions critiques ou importantes, l’inventaire des actifs TIC, l’inventaire des services TIC, le registre des dépendances fournisseurs et cloud, les critères de classification des incidents, l’inventaire des traitements GDPR, les DPIA lorsque pertinent, le registre des obligations légales, les politiques, la Déclaration d’applicabilité et la déclaration existante d’appétence au risque de l’organisation.

Cela s’aligne sur les Clauses 4, 6 et 8 d’ISO/IEC 27001:2022, ainsi que sur les méthodes de profils NIST CSF qui partent des priorités métier, des priorités de risque, des exigences, des mesures de protection et des rôles.

Étape 2 : définir des échelles d’impact intégrant la réglementation

À l’aide de l’étape 10 du Zenith Blueprint, définissez la vraisemblance et l’impact en langage métier. Incluez la perte financière, l’interruption opérationnelle, l’impact client, le préjudice réputationnel, l’impact légal et réglementaire, le préjudice pour les personnes concernées et l’impact sur les fonctions critiques.

Par exemple, un impact « Majeur » peut inclure une indisponibilité prolongée d’un service critique, une violation confirmée de données à caractère personnel nécessitant une notification, le non-respect d’une obligation de notification d’incident DORA ou la défaillance d’un fournisseur affectant une fonction critique ou importante.

Étape 3 : rédiger l’appétence par domaine

Ne créez pas une appétence cyber générique unique. Définissez des domaines tels que la disponibilité des services critiques, la confidentialité des données à caractère personnel, l’intégrité des données, les accès à privilèges, la dépendance TIC vis-à-vis de tiers, la concentration cloud, l’exposition aux vulnérabilités, la capacité de notification des incidents, la sauvegarde et la reprise, et le risque lié aux changements de développement sécurisé.

Pour chaque domaine, rédigez une déclaration d’appétence, un ou plusieurs seuils de tolérance et des déclencheurs d’escalade.

Étape 4 : relier le traitement à la Déclaration d’applicabilité

L’étape 13 du Zenith Blueprint demande aux organisations de choisir des options de traitement des risques : atténuer, éviter, transférer ou accepter. Elle souligne également l’approbation par la direction :

« Les décisions de traitement des risques et la SoA doivent être revues et approuvées par la direction générale. »

Pour DORA et NIS2, cela constitue un élément de preuve que l’organe de direction ou la direction délégataire a revu les risques clés, les traitements et l’exposition résiduelle acceptée. Pour GDPR, cela soutient la responsabilité en montrant pourquoi les mesures sélectionnées étaient appropriées au risque.

Étape 5 : enregistrer l’acceptation avec expiration et conditions

Chaque risque résiduel moyen ou élevé accepté doit inclure :

• Identifiant du risque et propriétaire
• Justification métier
• Référence à la déclaration d’appétence
• Seuil de tolérance affecté
• Analyse juridique et réglementaire
• Contrôles compensatoires
• Date d’expiration ou de revue
• Approbateur
• Emplacement des éléments de preuve
• Déclencheur de réouverture de la décision

La Risk Management Policy-sme indique :

« Toute décision d’accepter ou de différer le traitement d’un risque élevé ou moyen doit être documentée dans le registre des risques. Cette documentation doit inclure : »

Dans les environnements d’entreprise, cela devient un processus d’approbation et un dossier de comité des risques. Dans les organisations plus petites, il peut s’agir d’un onglet structuré du registre des risques avec validation formelle de la direction. L’objectif n’est pas la bureaucratie. L’objectif est la défendabilité.

Tolérance aux incidents : lorsque l’appétence rencontre l’horloge

L’appétence au risque devient concrète lors des incidents.

DORA Article 17 exige que les entités financières établissent un processus de gestion des incidents liés aux TIC afin de détecter, gérer et notifier les incidents, d’enregistrer tous les incidents et cybermenaces importantes, d’identifier les causes racines, d’utiliser des indicateurs d’alerte précoce, de classer les incidents selon la priorité, la gravité et la criticité du service, d’attribuer les rôles, de communiquer avec les parties prenantes, d’escalader au moins les incidents majeurs liés aux TIC à la direction générale et à l’organe de direction, et de restaurer des opérations sécurisées dans les délais appropriés.

DORA Article 18 classe les incidents selon des facteurs tels que les clients affectés, la durée, l’indisponibilité, l’étendue géographique, les pertes de données affectant la disponibilité, l’authenticité, l’intégrité ou la confidentialité, la criticité des services affectés et l’impact économique. Article 19 exige que les incidents majeurs liés aux TIC soient signalés à l’autorité compétente, les clients étant informés lorsque leurs intérêts financiers sont affectés.

NIS2 Article 23 prévoit un reporting échelonné pour les incidents significatifs, incluant une alerte précoce sans retard injustifié et, le cas échéant, dans les 24 heures, une notification d’incident sans retard injustifié et, le cas échéant, dans les 72 heures, des mises à jour intermédiaires lorsque demandées et un rapport final au plus tard un mois après la notification de l’incident. Les incidents significatifs incluent ceux qui causent une interruption opérationnelle grave, une perte financière ou un dommage matériel ou immatériel à des tiers.

La déclaration d’appétence doit définir les seuils d’escalade avant que l’incident ne survienne.

Les contrôles de l’Annexe A relatifs à la planification des incidents, à l’évaluation des événements de sécurité de l’information, à la réponse aux incidents, au retour d’expérience, à la collecte des éléments de preuve, au maintien de la sécurité de l’information pendant une perturbation et à l’aptitude TIC à la continuité d’activité soutiennent tous ces seuils. Les résultats NIST CSF dans IDENTIFY, PROTECT, DETECT, RESPOND et RECOVER soutiennent le même modèle opérationnel, notamment les sauvegardes, la surveillance, la déclaration d’incident, l’escalade, l’analyse de la cause racine, la communication avec les parties prenantes et la vérification du rétablissement.

La tolérance fournisseur et cloud que les conseils négligent souvent

DORA fait du risque lié aux tiers TIC une obligation de conformité centrale. Article 28 exige que les entités financières gèrent le risque lié aux tiers TIC dans le cadre de gestion des risques liés aux TIC, tout en restant pleinement responsables de la conformité. Il impose une stratégie de risque lié aux tiers TIC, des registres des accords contractuels portant sur les services TIC, la distinction des services soutenant des fonctions critiques ou importantes, le reporting annuel, la notification des accords planifiés, les évaluations précontractuelles, les diligences préalables, les droits d’audit et d’inspection, les droits de résiliation et des stratégies de sortie documentées.

Article 29 ajoute l’analyse du risque de concentration, incluant la non-substituabilité, les dépendances multiples envers le même prestataire ou des prestataires liés, les risques de sous-traitance, les sous-traitants de pays tiers, la conformité en matière de protection des données, l’opposabilité et les chaînes complexes de sous-traitance. Article 30 exige des droits et obligations contractuels écrits, des descriptions de services, les lieux d’exécution, les protections de sécurité, l’accès aux données et leur restitution, les niveaux de service, l’assistance en cas d’incident, la coopération avec les autorités, les droits de résiliation, des plans de continuité testés, la surveillance et les dispositifs de sortie.

Une déclaration de tolérance fournisseur approuvée par le conseil pourrait être formulée ainsi :

« Nous avons une faible appétence pour la dépendance de fonctions critiques ou importantes à un prestataire tiers de services TIC lorsque nous ne disposons pas de droits contractuels d’audit, de dispositifs de sortie testés, d’obligations de notification d’incident, d’objectifs de niveau de service, de droits de restitution des données ou de visibilité sur la sous-traitance substantielle. »

Cette phrase donne aux achats une règle pratique. Si le contrat ne respecte pas le seuil, le risque ne peut pas être accepté discrètement par l’équipe projet.

Comment les auditeurs testeront votre appétence au risque lié aux TIC

Une déclaration d’appétence solide est conçue en tenant compte de l’audit.

L’étape 28 du Zenith Blueprint, dans la phase Audit, revue et amélioration, renforce la couche de revue de direction. Elle demande aux organisations de collecter des éléments d’entrée tels que les changements des enjeux externes et internes, la performance du SMSI, les résultats d’audit, la surveillance et les mesures, les incidents, les non-conformités, les opportunités d’amélioration et les besoins en ressources. Elle précise également que la revue de direction doit conduire à des décisions et des actions, et non à de simples présentations.

Au moins une fois par an, et chaque fois que des modifications substantielles surviennent, la direction doit revoir si les seuils de tolérance restent alignés sur le modèle métier, si des incidents ont dépassé l’appétence, si les risques acceptés restent dans les limites approuvées, si de nouvelles exigences DORA, NIS2, GDPR ou contractuelles ont modifié le référentiel, si les fournisseurs restent dans les tolérances de concentration et si les KRI déclenchent une escalade en temps utile.

Si la réponse est non, la déclaration d’appétence doit changer, ou les contrôles doivent évoluer.

Schémas de défaillance fréquents dans les travaux de préparation 2026

Dans les projets DORA, NIS2, GDPR et ISO/IEC 27001:2022, les mêmes faiblesses reviennent régulièrement :

• Appétence sans seuils, lorsque le conseil approuve une déclaration mais que personne ne peut dire quand elle a été dépassée.
• Seuils sans autorité, lorsque des niveaux de gravité existent mais que les propriétaires du risque peuvent accepter des exceptions sans approbation de la direction générale.
• Risque juridique hors du modèle de notation, lorsque GDPR, DORA, NIS2 et les contrats sont listés séparément mais non intégrés aux critères d’impact.
• Tolérance fournisseur absente du dossier du conseil, alors que les dépendances TIC critiques sont connues des achats ou de l’informatique.
• Revue de direction de façade, lorsque des diapositives sont présentées mais que les décisions, actions, besoins en ressources et acceptations de risque ne sont pas documentés.
• Fragmentation des éléments probants d’audit, lorsque les politiques, registres, KRI, rapports d’incident, revues des fournisseurs et comptes rendus du conseil existent à des endroits différents sans référence croisée.

L’approche de Clarysec est conçue pour supprimer ces lacunes. Le Zenith Blueprint fournit le parcours de mise en œuvre par phases. La Risk Management Policy et la Risk Management Policy-sme fournissent des clauses de gouvernance adaptées aux environnements d’entreprise et aux PME. Zenith Controls cartographie l’ossature de contrôle entre politique de sécurité de l’information, responsabilité de la direction et exigences légales ou réglementaires, ce qui rend les éléments de preuve réutilisables entre ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF et l’assurance de type COBIT.

Transformer l’intention du conseil en gouvernance auditable du risque lié aux TIC

Si votre organisation dispose d’un registre des risques mais ne peut pas démontrer une appétence au risque lié aux TIC approuvée par le conseil, des seuils de tolérance mesurables, des déclencheurs d’escalade et des règles formelles d’acceptation, l’écart n’est pas cosmétique. Il affecte la gouvernance DORA, la responsabilité de la direction au titre de NIS2, la défendabilité de GDPR Article 32 et la préparation à l’audit ISO/IEC 27001:2022.

Une prochaine étape pratique consiste à organiser un atelier ciblé sur l’appétence au risque lié aux TIC à l’aide de la boîte à outils Clarysec :

1. Utilisez l’étape 10 de Zenith Blueprint pour définir les critères de risque et les échelles d’impact.
2. Utilisez l’étape 13 de Zenith Blueprint pour relier les options de traitement, le risque résiduel et l’approbation de la Déclaration d’applicabilité.
3. Utilisez l’étape 14 de Zenith Blueprint pour établir les références croisées avec les obligations GDPR, NIS2 et DORA.
4. Utilisez l’étape 28 de Zenith Blueprint pour intégrer l’appétence, les KRI, les risques acceptés et les décisions relatives aux ressources dans la revue de direction.
5. Appliquez la Risk Management Policy ou la Risk Management Policy-sme pour formaliser les règles d’approbation et d’acceptation.
6. Utilisez Zenith Controls pour cartographier les contrôles de gouvernance avec les éléments probants d’audit et les attentes de conformité croisée.

Clarysec peut vous aider à convertir des livrables de risque dispersés en un modèle d’appétence au risque lié aux TIC approuvé par le conseil et prêt pour les autorités de régulation, que vos équipes pourront utiliser lorsque la prochaine panne cloud, défaillance fournisseur, divulgation de vulnérabilité ou incident relatif aux données à caractère personnel mettra à l’épreuve la tolérance réelle de l’organisation.