Depuis le 17 janvier 2025, toute entité financière soumise à DORA doit tenir un registre d'information sur ses prestataires TIC. Ce registre doit suivre le template B_02.02 défini par le Règlement d'exécution (UE) 2024/2956 — 32 colonnes obligatoires, dans un ordre précis, avec un contenu défini au niveau réglementaire européen.
La plupart des RCSI que nous rencontrons ont démarré leur registre sur Excel avec 8 à 12 colonnes. C'est insuffisant. L'ACPR peut demander ce registre à tout moment dans le cadre d'un contrôle DORA. Un registre incomplet expose l'entité à une mise en demeure.
Le template B_02.02 comporte 32 colonnes obligatoires. Un registre à 10 ou 15 colonnes ne satisfait pas aux exigences du Règlement (UE) 2024/2956, même si les données sont correctes.
Contexte réglementaire
L'obligation de registre est posée par l'Art. 28(3) du Règlement DORA (UE) 2022/2554 :
"Les entités financières tiennent et mettent à jour un registre d'information en rapport avec tous les accords contractuels conclus avec des prestataires tiers de services TIC."
Le contenu exact de ce registre est précisé par le Règlement d'exécution (UE) 2024/2956 (ITS — Implementing Technical Standards), adopté par la Commission européenne le 13 décembre 2024, entré en vigueur le 2 janvier 2025. L'Annexe II de ce règlement définit le template B_02.02 avec ses 32 colonnes.
Les 32 colonnes du template B_02.02
Voici le détail exhaustif des 32 colonnes obligatoires, dans l'ordre exact imposé par l'ITS :
| # | Référence ITS | Intitulé de la colonne | Contenu attendu |
|---|---|---|---|
| 01 | B_02.02.0010 | Identifiant interne arrangement | Identifiant unique attribué par l'entité financière à l'accord contractuel. Format libre mais stable dans le temps. |
| 02 | B_02.02.0020 | Nom du prestataire TIC | Dénomination sociale complète du prestataire tiers de services TIC. |
| 03 | B_02.02.0030 | Code LEI du prestataire | Identifiant d'entité juridique (Legal Entity Identifier) — 20 caractères alphanumériques. Obligatoire si le prestataire dispose d'un LEI. |
| 04 | B_02.02.0040 | Pays du siège social | Code ISO 3166-1 alpha-2 du pays où est enregistré le prestataire (ex : FR, DE, US, IE). |
| 05 | B_02.02.0050 | Type d'entité prestataire | Nature juridique du prestataire : fournisseur cloud, éditeur logiciel, intégrateur, sous-traitant de données, etc. |
| 06 | B_02.02.0060 | Type de service TIC | Catégorie du service fourni : Cloud IaaS/PaaS/SaaS, hébergement, réseau, cybersécurité, paiement, données, communication. |
| 07 | B_02.02.0070 | Description du service TIC | Description libre mais précise du périmètre fonctionnel du service fourni par le prestataire. |
| 08 | B_02.02.0080 | Fonction critique ou importante (CIF) | Oui/Non — Ce prestataire supporte-t-il une fonction critique ou importante au sens de l'Art. 28(2) DORA ? |
| 09 | B_02.02.0090 | Classification CIF | Niveau de criticité : CRITIQUE / IMPORTANTE / NORMALE. Résulte de l'analyse menée par l'entité selon les critères Art. 28. |
| 10 | B_02.02.0100 | Justification classification CIF | Texte libre justifiant la classification retenue. Doit référencer les critères Art. 28(2) appliqués. |
| 11 | B_02.02.0110 | Date de début du contrat | Date d'entrée en vigueur de l'accord contractuel. Format ISO 8601 (AAAA-MM-JJ). |
| 12 | B_02.02.0120 | Date de fin du contrat | Date d'expiration prévue. Format ISO 8601. Peut être indéfinie pour les contrats à durée indéterminée. |
| 13 | B_02.02.0130 | Préavis de résiliation (jours) | Délai de préavis contractuel en jours calendaires. Exigence Art. 30(2)(g) DORA. |
| 14 | B_02.02.0140 | Droit applicable | Droit national régissant le contrat. Code ISO 3166-1 alpha-2 (ex : FR pour droit français). |
| 15 | B_02.02.0150 | Pays d'exécution du service | Pays où le service est effectivement exécuté (datacenter, équipes opérationnelles). Peut différer du siège. |
| 16 | B_02.02.0160 | Localisation des données | Pays où les données de l'entité financière sont stockées et traitées. Critique pour la conformité RGPD et DORA. |
| 17 | B_02.02.0170 | Plan de sortie disponible | Oui/Non — L'entité dispose-t-elle d'un plan de sortie documenté pour ce prestataire ? Exigence Art. 28(8) DORA. |
| 18 | B_02.02.0180 | Droit d'audit accordé | Oui/Non — Le contrat prévoit-il un droit d'audit de l'entité financière chez le prestataire ? Art. 30(2)(f) DORA. |
| 19 | B_02.02.0190 | Fréquence d'audit | Fréquence contractuelle des audits : Annuel, Bisannuel, Ad hoc, Sur demande. |
| 20 | B_02.02.0200 | Sous-traitance permise | Oui/Non — Le prestataire est-il autorisé à sous-traiter tout ou partie du service ? Déclenche les obligations RTS JC 2024/53. |
| 21 | B_02.02.0210 | Plan de continuité d'activité (BCP) | Oui/Non — Le prestataire dispose-t-il d'un plan de continuité documenté couvrant ce service ? Art. 30(3)(a) DORA. |
| 22 | B_02.02.0220 | Plan de reprise d'activité (DRP) | Oui/Non — Existence d'un plan de reprise après sinistre couvrant spécifiquement ce service TIC. |
| 23 | B_02.02.0230 | RTO — Objectif de temps de reprise (heures) | Recovery Time Objective contractuel en heures. Temps maximum acceptable d'interruption du service. |
| 24 | B_02.02.0240 | RPO — Objectif de point de reprise (heures) | Recovery Point Objective contractuel en heures. Perte de données maximale acceptable en cas d'incident. |
| 25 | B_02.02.0250 | Score de risque | Score de risque interne attribué par l'entité financière à ce prestataire. Méthodologie propre à l'entité. |
| 26 | B_02.02.0260 | Statut de l'enregistrement | Statut du registre : Validé / Brouillon / En révision / Archivé. |
| 27 | B_02.02.0270 | Date de dernière évaluation | Date de la dernière revue de cet enregistrement par le RCSI ou l'équipe conformité. |
| 28 | B_02.02.0280 | Responsable interne | Nom ou rôle du responsable interne de la relation avec ce prestataire (RCSI, Risk Manager, DSI). |
| 29 | B_02.02.0290 | Niveau de criticité brut | Niveau de criticité avant application des critères de pondération : High / Medium / Low. |
| 30 | B_02.02.0300 | Confiance de la classification (%) | Niveau de confiance dans la classification CIF retenue. Pertinent en cas de classification automatisée ou assistée. |
| 31 | B_02.02.0310 | Date de création de l'enregistrement | Date de création de la ligne dans le registre. Format ISO 8601. Traçabilité obligatoire. |
| 32 | B_02.02.0320 | Date de mise à jour | Date de la dernière modification de cet enregistrement. Mise à jour automatique recommandée. |
Les 5 colonnes les plus souvent oubliées
Dans notre expérience, 5 colonnes sont systématiquement absentes des registres construits sans outil dédié :
1. Justification CIF (colonne 10)
La classification Critique/Importante/Normale ne suffit pas — l'ITS exige une justification textuelle référençant les critères Art. 28(2) appliqués. Sans cette justification, la classification n'est pas défendable lors d'un contrôle.
2. RTO et RPO contractuels (colonnes 23-24)
Ces valeurs doivent être les valeurs contractuelles — pas des estimations internes. Si votre contrat avec AWS ou Salesforce ne précise pas de RTO/RPO, c'est une non-conformité Art. 30(3) à corriger lors du prochain renouvellement.
3. Plan de sortie (colonne 17)
L'Art. 28(8) DORA impose un plan de sortie documenté pour chaque prestataire CIF. Ce plan doit prévoir les conditions, les délais, et les alternatives. La plupart des entités n'en ont pas.
4. Sous-traitance permise (colonne 20)
Cette colonne déclenche des obligations supplémentaires au titre du RTS JC 2024/53 sur la sous-traitance. Si le prestataire sous-traite une fonction CIF, l'entité doit avoir une visibilité sur les sous-traitants et leurs propres clauses contractuelles.
5. Confiance de la classification (colonne 30)
Colonne souvent ignorée mais importante en cas de classification assistée par IA. Elle documente la fiabilité de la classification et renforce l'auditabilité du processus.
L'ACPR a publié en 2025 ses premières orientations de contrôle DORA. La complétude du registre B_02.02 est explicitement mentionnée comme point de contrôle prioritaire pour les entités mid-market (EME, PSP, PSAN, SGP).
Comment automatiser la tenue de ce registre
Tenir manuellement un registre à 32 colonnes pour 20 à 50 prestataires représente une charge significative. Les points de friction principaux sont :
La classification CIF — elle nécessite une analyse structurée qui prend 30 à 60 minutes par prestataire si elle est faite manuellement.
La mise à jour continue — DORA impose une mise à jour du registre à chaque modification significative d'un arrangement contractuel. Sans processus automatisé, les registres deviennent rapidement obsolètes.
Les alertes non-conformité — identifier automatiquement les prestataires CIF sans BCP, sans droit d'audit, ou sans plan de sortie documenté nécessite des règles de gestion systématiques.
C'est exactement ce que fait l'Agent 3 REGISTRE 28 de CUSTOR 28 : classification CIF automatique, tenue du registre 32 colonnes, alertes sur les clauses manquantes, export XLSX conforme ITS B_02.02 et PDF Art. 30 pour l'ACPR.
Références réglementaires
- Règlement (UE) 2022/2554 — DORA — Art. 28 à 30 (Registre prestataires TIC)
- Règlement d'exécution (UE) 2024/2956 — ITS Template B_02.02 (32 colonnes)
- RTS JC 2024/53 — Sous-traitance ICT pour fonctions CIF
- Orientations ACPR 2025 — Contrôle DORA entités mid-market