Registre d’informations DORA : guide ISO 27001

Il est 09 h 15 un mardi. Sarah, RSSI d’une fintech en forte croissance, participe à une évaluation de préparation avec son responsable conformité, son conseil juridique, son responsable achats et son architecte cloud. Le consultant externe joue le rôle d’un superviseur DORA.

« Merci pour la présentation », dit-il. « Veuillez fournir votre registre d’informations, tel que requis par DORA Article 28, incluant les accords contractuels TIC qui soutiennent des fonctions critiques ou importantes, la visibilité sur la sous-traitance, la propriété des actifs et les éléments probants démontrant que le registre est tenu dans le cadre de votre gestion des risques liés aux TIC. »

La première réponse paraît assurée : « Nous avons une liste de fournisseurs. »

Puis les questions commencent.

Quels fournisseurs soutiennent l’autorisation des paiements ? Quels contrats incluent des droits d’audit, une assistance en cas d’incident, des engagements sur la localisation des données, des droits de résiliation et une assistance à la sortie ? Quelles plateformes SaaS traitent des données à caractère personnel de clients ? Quels services cloud soutiennent des fonctions critiques ou importantes ? Quels sous-traitants se trouvent derrière le prestataire de services de sécurité managés ? Quel propriétaire d’actif interne a approuvé la dépendance ? Quels risques du plan de traitement des risques ISO/IEC 27001:2022 sont liés à ces prestataires ? Quelles entrées de la Déclaration d’applicabilité (SoA) justifient les contrôles ?

À 10 h 30, l’équipe a ouvert quatre feuilles de calcul, un export de CMDB, un dossier SharePoint de contrats PDF, une liste des sous-traitants de traitement de données, un rapport de facturation cloud et un outil de suivi SaaS tenu manuellement. Aucun de ces éléments ne concorde.

C’est le défi opérationnel du registre d’informations DORA en 2026. La mise en œuvre de DORA est passée de « nous avons besoin d’une feuille de route » à « montrez-moi les éléments probants ». Pour les entités financières, les prestataires tiers de services TIC, les RSSI, les auditeurs internes et les équipes conformité, le registre n’est plus un modèle administratif. Il constitue le tissu conjonctif entre les contrats TIC, le risque fournisseur, les chaînes de sous-traitance, les services cloud, les actifs TIC, les fonctions critiques, la gouvernance et les éléments probants ISO/IEC 27001:2022.

L’approche de Clarysec est simple : ne construisez pas le registre d’informations DORA comme un livrable de conformité isolé. Construisez-le comme une couche vivante d’éléments probants au sein de votre SMSI, soutenue par la gestion des actifs, la sécurité des fournisseurs, la gouvernance des usages cloud, la cartographie des obligations juridiques et réglementaires, les métadonnées d’audit et la traçabilité du traitement des risques.

Le Zenith Controls: The Cross-Compliance Guide de Clarysec Zenith Controls identifie trois contrôles d’ancrage de l’Annexe A d’ISO/IEC 27001:2022 comme particulièrement pertinents pour ce sujet : A.5.9, inventaire des informations et autres actifs associés ; A.5.19, sécurité de l’information dans les relations avec les fournisseurs ; et A.5.20, prise en compte de la sécurité de l’information dans les accords fournisseurs. Ces contrôles ne sont pas de la paperasse supplémentaire. Ils constituent l’ossature opérationnelle permettant de prouver que le registre est complet, attribué, à jour et auditable.

Ce que DORA attend du registre d’informations

DORA s’applique depuis le 17 janvier 2025 et établit, pour le secteur financier, un corpus de règles de résilience TIC couvrant la gestion des risques liés aux TIC, la notification des incidents, les tests de résilience, les risques liés aux tiers, les accords contractuels, la supervision des prestataires tiers critiques de services TIC et l’application par les autorités de supervision. Pour les entités financières également identifiées dans le cadre de la transposition nationale de NIS2, DORA constitue l’acte juridique sectoriel de l’Union applicable aux exigences correspondantes de gestion des risques de cybersécurité et de notification des incidents.

L’obligation de registre s’inscrit dans la discipline de gestion des risques liés aux prestataires tiers de services TIC prévue par DORA. DORA Article 28 impose aux entités financières de gérer le risque lié aux tiers TIC dans le cadre de la gestion des risques liés aux TIC, de rester pleinement responsables de la conformité même lorsqu’elles recourent à des prestataires TIC, de tenir un registre d’informations des accords contractuels de services TIC et de distinguer les accords qui soutiennent des fonctions critiques ou importantes.

DORA Article 29 ajoute des considérations relatives au risque de concentration et à la sous-traitance. Cela inclut la substituabilité, les dépendances multiples à l’égard d’un même prestataire ou de prestataires liés, la sous-traitance dans des pays tiers, les contraintes d’insolvabilité, la restauration des données, la conformité en matière de protection des données et les chaînes de sous-traitance longues ou complexes.

DORA Article 30 définit ensuite la substance contractuelle que les auditeurs s’attendront à voir. Elle inclut les descriptions de services, les conditions de sous-traitance, les lieux de traitement des données, les engagements en matière de protection des données, les obligations d’accès et de rétablissement, les niveaux de service, l’assistance en cas d’incident, la coopération avec les autorités, les droits de résiliation, la participation aux formations, les droits d’audit et les stratégies de sortie pour les accords soutenant des fonctions critiques ou importantes.

Un registre d’informations DORA mature doit répondre à quatre questions pratiques.

Un registre faible est une feuille de calcul mise à jour une fois par an par les achats. Un registre solide est un jeu de données gouverné qui relie le portefeuille fournisseurs, l’inventaire des actifs, le registre cloud, le référentiel contractuel, les registres de protection des données, les plans de continuité d’activité (PCA), les procédures de réponse à incident, le registre des risques et les éléments probants ISO/IEC 27001:2022.

Pourquoi ISO 27001 est la voie la plus rapide vers un registre DORA défendable

ISO/IEC 27001:2022 fournit aux organisations la structure de système de management qui manque souvent aux éléments probants DORA. Les clauses 4.1 à 4.4 exigent que l’organisation définisse le contexte, les parties intéressées, les obligations légales, réglementaires et contractuelles, le périmètre, les interfaces et les dépendances. C’est précisément là que DORA doit s’intégrer au SMSI, car le registre dépend de la connaissance des services financiers, des prestataires TIC, des clients, des autorités, des plateformes cloud et des processus externalisés inclus dans le périmètre.

Les clauses 5.1 à 5.3 exigent le leadership, l’alignement des politiques, les ressources, les responsabilités et le reporting à la direction. C’est essentiel, car DORA Article 5 place la responsabilité sur l’organe de direction, qui doit définir, approuver, superviser et rester responsable de la gestion des risques liés aux TIC, y compris des politiques relatives aux prestataires tiers de services TIC et des canaux de reporting.

Les clauses 6.1.1 à 6.1.3 sont l’endroit où le registre devient fondé sur les risques. ISO/IEC 27001:2022 exige un processus répétable d’appréciation des risques, des propriétaires du risque, une analyse de la vraisemblance et des conséquences, le traitement des risques, la sélection des contrôles, une Déclaration d’applicabilité (SoA) et l’approbation du risque résiduel par le propriétaire du risque. Un registre DORA non lié au traitement des risques devient une liste statique. Un registre lié à des scénarios de risque, à des contrôles et à des propriétaires devient un élément probant d’audit.

Les clauses 8.1 à 8.3 transforment ensuite la planification en opérations maîtrisées. Elles soutiennent les informations documentées, la planification et le contrôle opérationnels, le contrôle des changements, le contrôle des processus fournis par des tiers, les réévaluations planifiées des risques, la mise en œuvre des traitements et la conservation des éléments probants. C’est critique en 2026, car les superviseurs ne demandent pas seulement si un registre existait à un instant donné. Ils demandent si les nouveaux contrats, les services modifiés, les nouveaux sous-traitants, les migrations cloud et les événements de sortie sont capturés dans le cycle de gouvernance.

La couche des contrôles de l’Annexe A renforce le même point. Les relations avec les fournisseurs, les accords fournisseurs, le risque lié à la chaîne d’approvisionnement TIC, la surveillance des services fournisseurs, l’acquisition et la sortie de services cloud, la gestion des incidents, la continuité d’activité, les obligations légales et réglementaires, la vie privée, les sauvegardes, la journalisation, la surveillance, la cryptographie et la gestion des vulnérabilités contribuent toutes à la qualité du registre.

Le Zenith Blueprint: An Auditor’s 30-Step Roadmap de Clarysec Zenith Blueprint explique le socle des actifs dans la phase Controls in Action, étape 22 :

Dans sa forme la plus stratégique, un inventaire des actifs sert de système nerveux central de votre SMSI. Il indique comment les accès sont provisionnés (8.2), où le chiffrement doit être appliqué (8.24), quels systèmes nécessitent une sauvegarde (8.13), quels journaux sont collectés (8.15), et même comment les politiques de classification et de conservation sont appliquées (5.10, 8.10).

Cette citation résume le point pratique. Vous ne pouvez pas tenir un registre d’informations DORA fiable si l’inventaire des actifs sous-jacent n’est pas fiable. Si votre registre mentionne « SaaS de core banking », mais que votre inventaire des actifs ne montre pas les interfaces de programmation (API), les comptes de service, les jeux de données, les sources de journaux, les clés de chiffrement, les dépendances de sauvegarde et les propriétaires, le registre est incomplet du point de vue de l’audit.

Le modèle de données Clarysec : un registre, plusieurs vues d’éléments probants

Un registre d’informations DORA ne doit pas remplacer votre registre des fournisseurs, votre registre des actifs ou votre registre cloud. Il doit les relier. Clarysec conçoit généralement le registre comme une couche maîtresse d’éléments probants avec des relations contrôlées vers les enregistrements SMSI existants.

Le modèle minimal viable comprend sept objets liés.

Cette structure permet à un seul registre de répondre à plusieurs demandes d’éléments probants. Un superviseur DORA peut consulter les accords contractuels soutenant des fonctions critiques ou importantes. Un auditeur ISO peut tracer les contrôles fournisseurs jusqu’aux références de l’Annexe A et au traitement des risques. Un réviseur GDPR peut voir les sous-traitants de traitement, les catégories de données, les localisations et les engagements en matière de protection des données. Un évaluateur orienté NIST peut examiner la gouvernance de la chaîne d’approvisionnement, la criticité des fournisseurs, les exigences contractuelles et la surveillance du cycle de vie.

Le registre devient plus que « qui sont nos fournisseurs ? ». Il devient un graphe de dépendances.

Fondations de politique qui rendent le registre auditable

Le corpus de politiques de Clarysec donne au registre un cadre opérationnel. Pour les PME, la Third-Party and Supplier Security Policy-sme Politique de sécurité des tiers et des fournisseurs - PME commence par une exigence claire de registre :

Un registre des fournisseurs doit être tenu et mis à jour par le référent administratif ou achats. Il doit inclure :

La même politique PME établit que les contrats doivent contenir des obligations de sécurité définies :

Les contrats doivent inclure des clauses obligatoires couvrant :

Même si les clauses citées introduisent, dans la politique elle-même, des listes de champs et des catégories de clauses obligatoires, le message de mise en œuvre est direct : la gouvernance des fournisseurs doit être documentée, attribuée et imposée contractuellement.

Pour les environnements d’entreprise, la Politique de gestion des risques de dépendance vis-à-vis des fournisseurs de Clarysec Politique de gestion des risques de dépendance vis-à-vis des fournisseurs est encore plus proche des attentes de supervision DORA :

Registre des dépendances fournisseurs : le VMO doit tenir un registre à jour de tous les fournisseurs critiques, incluant des informations telles que les services/produits fournis ; le caractère de fournisseur unique ou non ; les fournisseurs alternatifs disponibles ou la substituabilité ; les conditions contractuelles en vigueur ; et une évaluation de l’impact si le fournisseur venait à défaillir ou à être compromis. Le registre doit clairement identifier les fournisseurs générant une forte dépendance, par exemple ceux pour lesquels aucune alternative rapide n’existe.

Cela se cartographie directement avec DORA Article 29 sur le risque de concentration et de substituabilité. Si un fournisseur est unique, soutient une fonction critique, opère dans un pays tiers, utilise une longue chaîne de sous-traitance et ne dispose d’aucun parcours de sortie testé, le registre ne doit pas masquer ce risque dans une note en texte libre. Il doit le signaler, attribuer un propriétaire et le relier au traitement des risques.

La Politique de sécurité des tiers et des fournisseurs d’entreprise de Clarysec Politique de sécurité des tiers et des fournisseurs rend le champ d’application explicite :

Elle couvre à la fois les fournisseurs directs et, le cas échéant, leurs sous-traitants, et inclut les logiciels tiers, l’infrastructure, le support et les services managés.

Cette phrase correspond à une lacune DORA fréquente. De nombreuses organisations recensent les prestataires TIC directs, mais ne documentent pas les sous-traitants, les sous-traitants ultérieurs, les outils de services managés, les plateformes de support ou les logiciels tiers intégrés à un service.

Les éléments probants contractuels comptent également. La même politique d’entreprise inclut :

Droits d’audit, d’inspection et de demande d’éléments probants de sécurité

Cette formule doit apparaître dans votre liste de contrôle de revue contractuelle. Si un contrat avec un prestataire TIC critique ne comporte pas de droits d’audit ou de demande d’éléments probants, le registre doit marquer une action de remédiation.

Les éléments probants relatifs aux actifs sont tout aussi importants. La Politique de gestion des actifs PME de Clarysec Politique de gestion des actifs - PME indique :

Le responsable informatique doit tenir un inventaire des actifs structuré comprenant, au minimum, les champs suivants :

La Politique de gestion des actifs d’entreprise Politique de gestion des actifs précise de manière similaire :

L’inventaire des actifs doit contenir, au minimum :

Le registre n’a pas besoin de dupliquer chaque champ d’actif, mais il doit référencer l’inventaire des actifs. Si un SaaS de surveillance des paiements soutient la détection de fraude, le registre DORA doit renvoyer à l’actif applicatif, à l’actif jeu de données, aux comptes de service, aux intégrations API, aux sources de journaux et au propriétaire métier.

Les services cloud méritent une vue dédiée. La Politique d’utilisation du cloud PME de Clarysec Politique d’utilisation du cloud - PME exige :

Un registre des services cloud doit être tenu par le prestataire informatique ou le DG. Il doit consigner :

C’est particulièrement utile pour détecter l’informatique fantôme. Un registre DORA qui exclut les services cloud achetés en dehors des achats échouera au test pratique d’exhaustivité.

Enfin, la Politique de conformité juridique et réglementaire de Clarysec Politique de conformité juridique et réglementaire transforme la conformité croisée en exigence du SMSI :

Toutes les obligations légales et réglementaires doivent être cartographiées avec des politiques, des contrôles et des propriétaires spécifiques au sein du système de management de la sécurité de l’information (SMSI).

C’est le pont entre le registre DORA et les éléments probants ISO 27001. Le registre ne doit pas seulement montrer les fournisseurs. Il doit montrer quelles politiques, quels contrôles et quels propriétaires satisfont à l’obligation réglementaire.

Cartographier les exigences DORA avec ISO 27001 et les éléments probants Clarysec

Le tableau ci-dessous combine les attentes clés relatives au registre avec les contrôles de l’Annexe A d’ISO/IEC 27001:2022 et les livrables justificatifs Clarysec pratiques.

Cette cartographie est le point où le registre cesse d’être une feuille de calcul et devient un modèle d’éléments probants. Chaque ligne doit avoir un propriétaire du contrat, un propriétaire fournisseur, un responsable de service, un propriétaire métier et un responsable conformité. Chaque relation critique doit disposer d’un enregistrement de risque, d’une liste de contrôle des clauses contractuelles, d’un lien vers les actifs et d’une cadence de surveillance.

Exemple pratique : cartographier un contrat TIC avec des éléments probants ISO 27001

Imaginons qu’une entité financière utilise une plateforme cloud d’analytique de fraude. Le service ingère des métadonnées de transaction, prend en charge la notation de fraude en temps réel, s’intègre à la plateforme de paiement, stocke des identifiants clients pseudonymisés, utilise un sous-traitant d’hébergement cloud et fournit une assistance managée depuis un lieu approuvé dans un pays tiers.

Une ligne de registre faible indique : « Fournisseur : FraudCloud. Service : analytique de fraude. Contrat signé. Critique : oui. »

Une ligne de registre de niveau supervision est très différente.

L’équipe conformité peut alors produire un dossier d’éléments probants cohérent. Le registre des fournisseurs prouve que le prestataire existe et a un propriétaire. L’inventaire des actifs prouve que les systèmes internes, interfaces de programmation (API), jeux de données et journaux sont connus. La liste de contrôle contractuelle prouve que les clauses DORA obligatoires ont été revues. L’appréciation des risques prouve que la concentration, la sous-traitance, la protection des données et la résilience opérationnelle ont été prises en compte. La Déclaration d’applicabilité (SoA) montre quels contrôles ont été sélectionnés. La revue de surveillance prouve que l’accord n’est pas oublié après l’intégration.

Le Zenith Blueprint, phase Risk Management, étape 13, recommande exactement ce type de traçabilité :

Référencer les réglementations de manière croisée : si certains contrôles sont mis en œuvre spécifiquement pour se conformer à GDPR, NIS2 ou DORA, vous pouvez le noter soit dans le registre des risques, dans le cadre de la justification de l’impact du risque, soit dans les notes de la SoA.

C’est ainsi que le registre DORA devient un élément probant ISO 27001 plutôt qu’une bureaucratie parallèle.

La chaîne fournisseurs et sous-traitants est l’endroit où la qualité du registre échoue

Les plus grandes défaillances de registre ne sont pas dues à des fournisseurs principaux manquants. Elles sont causées par des chaînes de dépendances cachées.

Un prestataire de sécurité managée peut utiliser une plateforme SIEM, un agent de télémétrie terminal, un système de tickets et une équipe offshore de triage. Un processeur de paiement peut dépendre de l’hébergement cloud, de services d’identité, de bases de données de fraude et de connectivité de règlement. Un fournisseur SaaS peut s’appuyer sur plusieurs sous-traitants ultérieurs pour l’analytique, la messagerie, l’observabilité, le support client et les sauvegardes.

DORA Article 29 impose de porter l’attention sur le risque de concentration et de sous-traitance. NIS2 Article 21 exige également la sécurité de la chaîne d’approvisionnement pour les fournisseurs directs et les prestataires de services, et attend des entités qu’elles prennent en compte les vulnérabilités propres à chaque fournisseur direct, la qualité globale des produits, les pratiques de cybersécurité des fournisseurs et les procédures de développement sécurisé. Pour les entités financières couvertes par DORA, DORA constitue le corpus sectoriel de règles pour les exigences NIS2 qui se recoupent en matière de gestion des risques de cybersécurité et de notification des incidents, mais la logique de chaîne d’approvisionnement est alignée.

Le Zenith Blueprint de Clarysec, phase Controls in Action, étape 23, donne une instruction pratique :

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

C’est là que de nombreuses organisations doivent engager une remédiation en 2026. Les contrats signés avant la préparation à DORA peuvent ne pas inclure la transparence sur les sous-traitants, les droits d’accès aux éléments probants d’audit, la coopération avec les autorités, l’assistance en cas d’incident, l’assistance à la sortie ou les engagements de localisation. Le registre doit donc inclure un statut de remédiation contractuelle, par exemple : complet, lacune acceptée, renégociation en cours ou option de sortie requise.

Conformité croisée : DORA, NIS2, GDPR et NIST ont besoin de la même vérité sur les dépendances

Un registre d’informations DORA bien conçu soutient davantage que DORA.

NIS2 Article 20 fait de la cybersécurité une responsabilité de l’organe de direction par l’approbation, la supervision et la formation. Article 21 exige l’analyse des risques, les politiques, la gestion des incidents, la continuité, la sécurité de la chaîne d’approvisionnement, l’acquisition et la maintenance sécurisées, 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 lorsque cela est approprié. Ces domaines recoupent fortement ISO/IEC 27001:2022 et le modèle d’éléments probants du registre.

GDPR ajoute la responsabilité en matière de protection des données. Son champ territorial peut s’appliquer aux organisations de l’UE et hors UE qui traitent des données à caractère personnel dans le contexte d’établissements situés dans l’UE, offrent des biens ou services à des personnes dans l’UE, ou surveillent leur comportement. Les définitions GDPR du responsable du traitement, du sous-traitant, du traitement, de la pseudonymisation et de la violation de données à caractère personnel sont directement pertinentes pour la cartographie des fournisseurs TIC. Si le registre DORA identifie les prestataires TIC et les sous-traitants mais n’identifie pas les rôles de traitement des données à caractère personnel, les catégories de données, les localisations et les mesures de protection, il ne soutiendra pas les éléments probants GDPR.

NIST CSF 2.0 fournit une autre grille utile. Sa fonction GOVERN exige que les organisations comprennent leur mission, les attentes des parties prenantes, les dépendances, les exigences légales et contractuelles, les services dont d’autres dépendent et les services dont l’organisation dépend. Ses résultats GV.SC relatifs à la chaîne d’approvisionnement appellent un programme de gestion des risques liés à la chaîne d’approvisionnement, des rôles fournisseurs définis, l’intégration dans la gestion des risques de l’organisation, la criticité des fournisseurs, les exigences contractuelles, les diligences préalables, la surveillance du cycle de vie, la coordination des incidents et la planification post-relation.

Une vue pratique de conformité croisée ressemble à ceci.

L’objectif n’est pas de créer cinq chantiers de conformité. L’objectif est de créer un modèle unique d’éléments probants pouvant être filtré pour chaque référentiel.

À travers le regard de l’auditeur

Un superviseur DORA se concentrera sur l’exhaustivité, les fonctions critiques ou importantes, les accords contractuels, la sous-traitance, le risque de concentration, la gouvernance, le reporting et la tenue effective du registre. Il peut demander un échantillon de prestataires critiques et s’attendre à voir les clauses contractuelles, les appréciations des risques, les stratégies de sortie, les conditions d’assistance en cas d’incident et les éléments probants de supervision par la direction.

Un auditeur ISO/IEC 27001:2022 partira du périmètre du SMSI, des parties intéressées, des obligations réglementaires, de l’appréciation des risques, de la Déclaration d’applicabilité (SoA), du contrôle opérationnel et des informations documentées. Il testera si les relations avec les fournisseurs et les inventaires d’actifs sont tenus, si les processus fournis par des tiers sont contrôlés, si les changements déclenchent une réévaluation et si les éléments probants soutiennent la mise en œuvre déclarée des contrôles.

Un évaluateur NIST CSF 2.0 demandera souvent les profils actuels et cibles, les attentes de gouvernance, la cartographie des dépendances, la criticité des fournisseurs, l’intégration contractuelle, la surveillance du cycle de vie et les actions d’amélioration priorisées.

Un auditeur orienté COBIT 2019 examinera généralement la propriété de gouvernance, la responsabilité des processus, les droits de décision, la surveillance de la performance, le reporting des risques et l’assurance. Il demandera si le registre est intégré à la gouvernance d’entreprise, et non simplement tenu par la conformité.

Zenith Controls aide à traduire ces perspectives en ancrant le sujet dans les contrôles A.5.9, A.5.19 et A.5.20 de l’Annexe A d’ISO/IEC 27001:2022, puis en utilisant l’interprétation de conformité croisée pour relier les actifs, les relations avec les fournisseurs et les accords fournisseurs aux attentes réglementaires, de gouvernance et d’audit. C’est la différence entre « nous avons un registre » et « nous pouvons défendre le registre ».

La Politique d’audit et de surveillance de la conformité PME de Clarysec Politique d’audit et de surveillance de la conformité - PME traite également de la qualité des éléments probants :

Les métadonnées, par exemple qui les a collectées, quand et à partir de quel système, doivent être documentées.

Cette exigence est modeste mais puissante. Dans une demande d’éléments probants en 2026, une feuille de calcul sans métadonnées de collecte est faible. Un export de registre indiquant le système source, la date d’extraction, le propriétaire responsable, le statut d’approbation et la cadence de revue est plus solide.

Constats fréquents relatifs au registre d’informations DORA en 2026

Les constats les plus fréquents sont pratiques.

Premièrement, l’incomplétude du registre. Les services cloud, les outils de support, les plateformes de surveillance, les outils de développement, les systèmes de tickets et les plateformes d’analytique de données sont souvent absents parce qu’ils n’ont pas été classés comme services TIC par les achats.

Deuxièmement, une logique de criticité faible. Certaines équipes classent les fournisseurs comme critiques en fonction des dépenses, et non de l’impact métier. DORA s’intéresse au fait que le service TIC soutienne ou non une fonction critique ou importante.

Troisièmement, des lacunes dans les éléments probants contractuels. Les anciens accords fournisseurs manquent souvent de clauses adaptées à DORA concernant les droits d’audit, l’assistance en cas d’incident, la sous-traitance, la coopération avec les autorités, les lieux de service, la restitution des données, la résiliation et l’assistance à la sortie.

Quatrièmement, un lien insuffisant avec les actifs. Les registres listent les fournisseurs mais ne les relient pas aux applications, jeux de données, interfaces de programmation (API), identités, journaux, infrastructures ou services métier. Cela rend l’analyse d’impact difficile lors des incidents et des défaillances de fournisseurs.

Cinquièmement, l’opacité des sous-traitants. L’organisation connaît le prestataire principal, mais ne peut pas expliquer quels sous-traitants ultérieurs ou prestataires techniques soutiennent le service.

Sixièmement, l’absence de déclencheurs de changement. Un prestataire ajoute un nouveau sous-traitant ultérieur, change de région d’hébergement, migre son architecture ou modifie l’accès d’assistance, mais personne ne met à jour le registre ni ne réévalue le risque.

Septièmement, l’absence de cadence probante. Aucune fréquence n’est définie pour la revue fournisseur, la revue contractuelle, la validation des actifs, la réconciliation du registre cloud ou le reporting à la direction.

Ces problèmes peuvent être résolus, mais uniquement si le registre dispose de propriétaires et de flux de travail.

Un plan d’amélioration pratique sur 30 jours

Commencez par le champ d’application. Identifiez toutes les fonctions métier susceptibles d’être critiques ou importantes au titre de DORA. Pour chaque fonction, listez les services TIC dont elle dépend. Ne commencez pas par les dépenses d’achats. Commencez par la dépendance opérationnelle.

Réconciliez les sources de données principales : registre des fournisseurs, référentiel contractuel, inventaire des actifs et registre des services cloud. Ajoutez les enregistrements de sous-traitants de traitement de données et les dépendances de réponse aux incidents lorsque cela est pertinent. L’objectif n’est pas la perfection dès le premier jour. L’objectif est un socle de registre unique où les inconnues sont clairement signalées.

Classez les fournisseurs et les services selon des critères tels que la fonction soutenue, la sensibilité des données, la substituabilité opérationnelle, la concentration, la sous-traitance, les localisations, l’impact d’un incident, le délai de rétablissement et la pertinence réglementaire.

Passez en revue les contrats de chaque accord TIC critique ou important. Vérifiez si le contrat inclut les descriptions de services, les conditions de sous-traitance, les localisations, les engagements en matière de protection des données, l’accès et le rétablissement, les niveaux de service, l’assistance en cas d’incident, les droits d’audit, la coopération avec les autorités, la résiliation, la participation aux formations et l’assistance à la sortie.

Cartographiez les éléments probants ISO pour chaque accord critique. Reliez-les aux enregistrements d’actifs, aux entrées d’appréciation des risques, aux contrôles SoA, aux diligences préalables fournisseur, aux revues de surveillance, aux plans de continuité, aux procédures de réponse à incident et aux éléments probants de stratégie de sortie.

Attribuez une cadence. Les prestataires critiques peuvent nécessiter une revue trimestrielle, une assurance annuelle, une revue contractuelle avant renouvellement et une réévaluation immédiate en cas de changement significatif. Les prestataires non critiques peuvent être revus annuellement ou lors d’événements déclencheurs.

Utilisez cette liste de contrôle pour transformer le registre en processus opérationnel :

• Créer un propriétaire du registre DORA et un propriétaire suppléant.
• Lier chaque ligne du registre à un identifiant de contrat et à un propriétaire fournisseur.
• Lier chaque service TIC critique ou important à une fonction métier et à des enregistrements d’actifs.
• Ajouter des champs relatifs aux sous-traitants et aux sous-traitants ultérieurs, même s’ils sont initialement marqués comme inconnus.
• Ajouter le statut des clauses contractuelles pour les termes critiques DORA.
• Ajouter les références de risque et de SoA ISO/IEC 27001:2022.
• Ajouter les champs de rôle GDPR, données à caractère personnel et localisation lorsque cela s’applique.
• Ajouter la cadence de revue et les métadonnées de dernière revue.
• Créer des règles d’escalade pour les clauses manquantes, les sous-traitants inconnus et les risques de concentration élevés.
• Rapporter à la direction les indicateurs de qualité du registre.

C’est ici que la méthode de mise en œuvre en 30 étapes de Clarysec, son corpus de politiques et Zenith Controls travaillent ensemble. Le Zenith Blueprint fournit le chemin de mise en œuvre, depuis le traitement des risques et la traçabilité SoA à l’étape 13 jusqu’à l’inventaire des actifs à l’étape 22 et les contrôles fournisseurs à l’étape 23. Les politiques définissent qui doit tenir les registres, quels éléments probants contractuels et d’actifs doivent exister et comment les métadonnées de conformité sont capturées. Zenith Controls fournit la boussole de conformité croisée pour cartographier les mêmes éléments probants avec les attentes d’audit DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST et COBIT 2019.

Transformez le registre en éléments probants avant que le superviseur ne les demande

Si votre registre d’informations DORA est encore une feuille de calcul déconnectée des contrats, des actifs, des fournisseurs, des sous-traitants et des éléments probants ISO 27001, 2026 est l’année où il faut le corriger.

Commencez par utiliser le Zenith Blueprint Zenith Blueprint pour relier le traitement des risques, l’inventaire des actifs et la gouvernance des fournisseurs. Utilisez Zenith Controls Zenith Controls pour cartographier les contrôles A.5.9, A.5.19 et A.5.20 de l’Annexe A d’ISO/IEC 27001:2022 avec les éléments probants de conformité croisée. Puis mettez les exigences en œuvre opérationnelle au moyen des politiques Clarysec relatives aux fournisseurs, aux actifs, au cloud, à la conformité juridique et à la surveillance d’audit, notamment Politique de sécurité des tiers et des fournisseurs - PME, Politique de gestion des risques de dépendance vis-à-vis des fournisseurs, Politique de sécurité des tiers et des fournisseurs, Politique de gestion des actifs - PME, Politique de gestion des actifs, Politique d’utilisation du cloud - PME, Politique de conformité juridique et réglementaire et Politique d’audit et de surveillance de la conformité - PME.

Le meilleur moment pour corriger la qualité du registre est avant une demande d’une autorité, un audit interne, une interruption de service fournisseur ou un renouvellement contractuel. Le deuxième meilleur moment est maintenant. Téléchargez les politiques Clarysec pertinentes, cartographiez votre registre actuel avec le modèle d’éléments probants ci-dessus et planifiez une évaluation du registre DORA afin de transformer des données fournisseurs dispersées en éléments probants de niveau supervision.