Cheat Sheet
DORA — RoI (Register of Information)
le guide ultime pour réaliser votre registre d'information
DORA — RoI (Register of Information)
Cheat sheet — le guide ultime pour réaliser votre registre d'information
VORN°
Ce que l'autorité attend (format)
- • Modèles tabulaires standardisés (plusieurs tables, pas une seule)
- • Pour chaque colonne : type de donnée + règle de remplissage + parfois liste fermée
- • 1 cellule = 1 valeur (pas de listes, pas de texte multi-infos)
- • Si plusieurs valeurs valides → dupliquer la ligne (multi-lignes)
Résultat attendu (qualité)
- • Exhaustif — tous accords contractuels TIC inclus
- • Cohérent — mêmes identifiants entre modèles
- • Normalisé — formats ISO, listes fermées, noms stabilisés
- • Maintenable — processus de mise à jour, pas un one-shot
Règles de remplissage (R1–R4)
R1 — Identifiants : "un seul vrai ID"
Identifiant unique pour : entité, fournisseur, contrat/accord, service TIC, sous-traitant. Même ID dans tous les modèles (clé de jointure). Bon réflexe : colonne "ID interne stable" + mapping vers identifiants réglementaires.
R2 — Valeurs : zéro texte libre
Liste fermée → une valeur autorisée. Date → format ISO. Code pays → ISO alpha-2 uniquement.
R3 — Multi-valeurs = multi-lignes
Plusieurs pays / sous-traitants / services → une ligne par occurrence.
R4 — Cohérence inter-modèles
Contrôle : accord (B_02.01) → services/fonctions (B_02.02) → prestataires & chaîne/rangs (B_05.01/B_05.02) → fonctions (B_06.01) → évaluations (B_07.01) → définitions (B_99.01).
R4 — Cohérence : à vérifier en fin de remplissage
- ✓ Chaque accord (B_02.01) est détaillé dans B_02.02
- ✓ Chaque prestataire de la chaîne est présent dans B_05.01 et relié dans B_05.02
- ✓ Les fonctions sont structurées dans B_06.01 et reliables depuis B_02.02
- ✓ Les évaluations B_07.01 couvrent bien les services supportant une fonction critique/importante
- ✓ Les options "ensemble fermé" sont définies dans B_99.01
Guide opérationnel (B_01 à B_02.01)
B_01.01 — Entité tenant le registre d'informations
À quoi ça sert
Identifier qui tient et met à jour le RoI (au niveau entité / sous-consolidé / consolidé).
Comment le remplir
- Verrouiller dès le départ le niveau(x) de reporting que tu vas produire.
- Utiliser des identifiants stables et des formats normés (ex. : LEI si attendu).
Contrôles rapides
Une seule "vérité" sur l'entité déclarante : le même identifiant/nom sera réutilisé partout.
Pièges classiques
Changer la dénomination / l'identifiant au fil des onglets → casse les jointures.
B_01.02 — Liste des entités comprises dans le périmètre de consolidation
À quoi ça sert
Lister toutes les entités du groupe dans le périmètre. Si pas de groupe : seule l'entité financière.
Comment le remplir
- Considérer ce modèle comme le référentiel "entités" du RoI.
- Inclure toutes les entités pertinentes, même si certaines n'ont "pas de contrats".
Contrôles rapides
Toute entité citée ailleurs dans le RoI doit exister ici.
Pièges classiques
Oublier une entité utilisée dans B_03/B_04 → incohérences aval.
B_01.03 — Liste des succursales
À quoi ça sert
Lister les succursales des entités déclarées en B_01.02.
Comment le remplir
- Ne pas "mélanger" succursales et filiales.
- Stabiliser la manière d'identifier une succursale.
Contrôles rapides
Les succursales sont rattachables à une entité B_01.02 sans ambiguïté.
Pièges classiques
Confondre succursale / entité juridique distincte.
B_02.01 — Accords contractuels — informations générales
À quoi ça sert
Énumérer tous les accords contractuels conclus avec des prestataires tiers directs. Point clé : créer un "numéro de référence de l'accord contractuel" unique.
Comment le remplir
- 1 accord = 1 référence unique et stable. Ne pas réutiliser une référence lorsqu'un contrat est remplacé.
Contrôles rapides
Chaque référence B_02.01 réapparaît dans B_02.02 et B_05.02.
Pièges classiques
Regrouper plusieurs avenants sous une ref ; changer la ref après export (fatal).
Guide opérationnel (B_02 à B_04)
B_02.02 — Accords contractuels — informations spécifiques
À quoi ça sert
Détailler chaque accord de B_02.01 sur : (a) les services TIC inclus, (b) les fonctions soutenues, (c) autres infos (délai de préavis, droit applicable…).
Comment le remplir
- Travailler "contrat → service(s) TIC → fonction(s)".
- Si plusieurs services TIC / fonctions → appliquer la règle multi-lignes.
Contrôles rapides
Tout service TIC mentionné est traçable jusqu'au contrat (réf. B_02.01). Les fonctions réconciliables avec B_06.01.
Pièges classiques
Mettre des infos multi-valeurs dans une cellule au lieu de dupliquer les lignes.
B_02.03 — Liste des accords contractuels intra-groupe
À quoi ça sert
Relier les accords intra-groupe aux accords avec prestataires tiers hors groupe lorsque la chaîne est en partie intra-groupe.
Comment le remplir
- Utiliser les numéros de référence des accords (B_02.01) comme clé de liaison.
- Ne pas traiter ce modèle comme un "inventaire de contrats" : c'est un modèle de liaison.
Contrôles rapides
Chaque lien pointe vers des références B_02.01 existantes (zéro référence orpheline).
Pièges classiques
Oublier de modéliser l'intra-groupe alors que la chaîne l'implique → incohérence avec B_05.02.
B_03.01 — Entités qui signent les accords pour la réception (ou pour le compte)
À quoi ça sert
Identifier l'entité signataire du contrat avec le prestataire tiers direct, y compris quand elle signe pour le compte d'une autre entité utilisatrice.
Comment le remplir
- Considérer ce modèle comme le "RACI contractuel" : qui signe vs qui consomme.
- En consolidation : ne pas supposer que signataire = utilisateur.
Contrôles rapides
Pour chaque référence B_02.01, on peut retrouver l'entité signataire (et l'entité bénéficiaire si applicable).
Pièges classiques
Tout attribuer à l'entité tête de groupe alors que la signature est déléguée, ou inversement.
B_03.02 — Prestataires tiers qui signent les accords
À quoi ça sert
Lister les prestataires qui signent les accords de B_02.01 (identifiés dans B_05.01).
Comment le remplir
- Stabiliser l'identification du prestataire (même identifiant partout).
- Se reposer sur B_05.01 comme référentiel fournisseur.
Contrôles rapides
Aucun prestataire "signataire" n'est absent de B_05.01.
Pièges classiques
Doublons de prestataires (variantes de nom) → fausse perception de concentration.
B_03.03 — Entités signataires pour la fourniture de services TIC à d'autres entités du périmètre
À quoi ça sert
Identifier les entités du périmètre (B_01.02) qui signent des accords de B_02.01 pour fournir des services TIC à d'autres entités du périmètre.
Comment le remplir
Ne pas confondre avec B_03.01 : ici on est dans la logique "entité du groupe qui fournit à d'autres entités".
Contrôles rapides
Les entités citées existent en B_01.02 et sont cohérentes avec les rôles signataire/fournisseur.
Pièges classiques
Mélanger fourniture intra-groupe et fourniture par tiers direct.
B_04.01 — Entités ayant recours aux services TIC
À quoi ça sert
Lister toutes les entités qui utilisent des services TIC (entités financières du périmètre ou prestataires TIC intra-groupe).
Comment le remplir
- Traiter ce modèle comme le référentiel des "consommateurs" de services TIC.
- En niveau entité : signataire = utilisateur. En consolidation : ce n'est pas nécessairement vrai.
Contrôles rapides
Toute entité "utilisatrice" dans le RoI doit apparaître ici.
Pièges classiques
Oublier les prestataires TIC intra-groupe en tant qu'utilisateurs/relai.
Guide opérationnel (B_05 à B_99)
B_05.01 — Prestataires tiers de services TIC
À quoi ça sert
Référentiel unique des prestataires : (a) prestataires tiers directs, (b) prestataires TIC intra-groupe, (c) sous-traitants (B_05.02), (d) entreprise mère ultime.
Comment le remplir
- Définir une règle de "naming" + identifiant interne stable pour éviter les doublons.
- Mère ultime renseignée de façon cohérente (sinon analyses de concentration inexploitables).
Contrôles rapides
Tout acteur de la chaîne (rang 1, rang 2, intra-groupe) existe ici.
Pièges classiques
Créer des fournisseurs "fantômes" (ex. : marque commerciale) au lieu de l'entité qui signe réellement.
B_05.02 — Chaîne d'approvisionnement des services TIC
Règles clés
Les prestataires d'une même chaîne partagent : le même numéro de référence de l'accord contractuel (B_02.01) et le même type de service TIC. Rang 1 = prestataire tiers direct ; rang 2+ = sous-traitants.
À quoi ça sert
Relier les prestataires d'une même chaîne et les classer par rang pour chaque service TIC inclus dans chaque accord.
Comment le remplir
- Construire la chaîne par service TIC (pas juste par contrat).
- Dupliquer les lignes autant que nécessaire pour refléter les rangs (1, 2, 3…).
Contrôles rapides
Chaque ligne chaîne pointe vers : un prestataire existant en B_05.01 et une référence contrat existante en B_02.01.
Pièges classiques
Renseigner la chaîne au niveau "contrat" alors que le service B peut être sous-traité mais pas le service A.
B_06.01 — Identification des fonctions
Règle clé
Créer un identifiant unique pour chaque combinaison : LEI + activité autorisée + fonction (même fonction peut avoir plusieurs identifiants si activités différentes). Ex. : F1 / F2 pour une même fonction X selon activité A/B.
À quoi ça sert
Déclarer les fonctions des entités ayant recours aux services TIC, avec un identifiant unique : "identifiant de fonction".
Comment le remplir
- Définir une convention simple et stable pour l'identifiant (F1, F2…), cohérente sur l'ensemble du registre.
- Ne pas réutiliser un identifiant pour une autre combinaison.
Contrôles rapides
Une fonction = identifiable sans ambiguïté à partir de (LEI, activité, fonction, identifiant).
Pièges classiques
Utiliser un identifiant de fonction "global" par fonction, sans distinguer l'activité autorisée → non conforme.
B_07.01 — Évaluations des services TIC
À quoi ça sert
Recueillir des informations d'évaluation des risques des services TIC (ex. : substituabilité, date du dernier audit…), lorsque ces services soutiennent une fonction critique ou importante (ou une partie significative).
Comment le remplir
- Logique conditionnelle : ce modèle ne vise pas tous les services, mais ceux qui soutiennent une fonction critique/importante.
- Utiliser strictement les ensembles fermés quand ils existent.
Contrôles rapides
Tout service évalué ici est traçable à un service/contrat déclaré dans les modèles précédents.
Pièges classiques
Étendre l'évaluation à tous les services ou oublier les services réellement critiques.
B_99.01 — Définitions (ensembles fermés internes)
À quoi ça sert
Documenter la signification interne des valeurs utilisées dans les ensembles fermés (ex. : faible/moyenne/élevée).
Comment le remplir
- Définir tes options sans ambiguïté, de manière auditable.
- Garder la définition stable, versionnée.
Contrôles rapides
Toute option utilisée ailleurs (ex. : B_07.01) a une définition ici.
Pièges classiques
Définition trop vague → non exploitable en contrôle.
Règle d'or
Ton RoI est solide si tu peux dérouler sans rupture :
B_02.01 (réf. contrat) → B_02.02 (services/fonctions) → B_05.02 (chaîne + rangs), tous les prestataires en B_05.01, fonctions structurées via B_06.01. L'évaluation (B_07.01) s'applique aux services soutenant une fonction critique/importante, avec définitions en B_99.01.
Besoin d'accompagnement sur DORA ?
VORN° accompagne les entités dans le RoI, la gestion des risques TIC et la conformité DORA.