Gouvernance et responsabilités

Pourquoi la gouvernance est le socle de DORA

Un cadre de gestion des risques TIC bien conçu, des tests de résilience réguliers et une cartographie précise des prestataires ne servent à rien si personne, au sommet de l'organisation, n'en porte la responsabilité formelle. C'est le pari de DORA : avant d'imposer des obligations techniques, le règlement impose une chaîne de responsabilité. L'article 5 du règlement (UE) 2022/2554 est explicite — l'organe de direction de l'entité financière assume la responsabilité finale de la gestion des risques liés aux TIC, et cette responsabilité ne peut pas être déléguée entièrement à un tiers, ni même totalement transférée au RSSI ou à la direction des systèmes d'information.

Ce principe structure tout le reste. Une politique de sécurité rédigée par la DSI et jamais présentée au conseil n'a aucune valeur au regard de DORA. Un incident majeur découvert par la presse avant le conseil d'administration constitue, en soi, une défaillance de gouvernance — indépendamment de la qualité technique de la réponse à incident.

L'accountability ne se délègue pas, mais l'exécution oui. L'organe de direction peut confier la mise en œuvre opérationnelle à un RSSI ou à un comité des risques, mais il reste responsable de l'approbation du cadre, de son suivi et des conséquences en cas de défaillance grave. En cas de contrôle, l'autorité compétente s'adresse d'abord aux administrateurs, pas au RSSI.

Ce que l'organe de direction doit approuver et suivre personnellement

DORA liste un socle d'actes que l'organe de direction ne peut pas sous-traiter :

• L'approbation, la révision et le suivi du cadre de gestion des risques liés aux TIC (article 5§2).
• L'approbation de la politique de continuité d'activité TIC et des plans de réponse et de rétablissement.
• L'approbation de la stratégie de résilience opérationnelle numérique, y compris la stratégie de tests.
• L'approbation et le réexamen périodique de la politique relative aux accords avec les prestataires tiers de services TIC.
• La définition des rôles et responsabilités pour toutes les tâches liées aux TIC.
• L'allocation et la révision périodique du budget nécessaire pour satisfaire les besoins de résilience opérationnelle numérique.

À cela s'ajoute une obligation moins visible mais tout aussi contraignante : les membres de l'organe de direction doivent maintenir, à titre individuel, une connaissance suffisante des risques TIC et de leur impact sur l'activité, et suivre une formation régulière proportionnée aux risques gérés. Un conseil d'administration qui délègue la totalité du sujet cyber à un seul administrateur « référent numérique » sans que les autres en aient une compréhension minimale ne satisfait pas à cette exigence.

Une société de gestion d'actifs de taille moyenne organise chaque trimestre un point de 45 minutes en conseil consacré exclusivement aux risques TIC : incidents significatifs et quasi-incidents, avancement du plan de remédiation des vulnérabilités critiques, statut des tests de résilience programmés, et alertes sur la dépendance à des prestataires cloud critiques. Ce rythme trimestriel, documenté dans les procès-verbaux, constitue une preuve tangible d'exercice effectif de l'accountability — c'est précisément ce que recherchent les superviseurs lors d'un contrôle sur place.

Les trois lignes de défense appliquées aux risques TIC

DORA ne réinvente pas le modèle des trois lignes de défense, déjà largement utilisé dans le secteur financier pour le risque opérationnel ; il l'étend explicitement aux risques liés aux TIC.

Première ligne — les métiers et les équipes techniques (développement, exploitation, infrastructure) qui possèdent et gèrent le risque au quotidien. Ce sont elles qui appliquent les contrôles, corrigent les vulnérabilités et exécutent les procédures de sauvegarde.

Deuxième ligne — la fonction de gestion des risques liés aux TIC, généralement pilotée par le RSSI, et la fonction conformité. Cette ligne définit le cadre, fixe les seuils d'appétence au risque, challenge les décisions de la première ligne et doit rester indépendante d'elle sur le plan hiérarchique et budgétaire.

Troisième ligne — l'audit interne, qui évalue périodiquement l'efficacité de l'ensemble du dispositif, y compris celle de la deuxième ligne elle-même.

Le piège le plus fréquent dans les structures de taille moyenne est de confondre deuxième et troisième ligne, ou de faire porter les deux rôles par la même personne. Un RSSI qui audite son propre dispositif de contrôle ne peut pas produire une assurance indépendante. Si les effectifs ne permettent pas de séparer ces fonctions en interne, DORA admet le recours à un prestataire externe pour la fonction d'audit, à condition que son indépendance soit démontrable.

Le RSSI : pivot opérationnel, pas responsable ultime

DORA n'impose pas nommément la création d'un poste de RSSI, mais dans la pratique, la fonction de gestion des risques liés aux TIC exigée par l'article 6 est presque toujours incarnée par un responsable identifié — RSSI, Chief Information Security Officer ou équivalent selon la taille de l'entité. Ses missions typiques dans le cadre DORA :

• Concevoir et tenir à jour le cadre de gestion des risques TIC, en cohérence avec la stratégie approuvée par l'organe de direction.
• Piloter l'identification et la classification des actifs informationnels et des fonctions critiques ou importantes.
• Coordonner la stratégie de tests de résilience opérationnelle numérique, y compris les tests de pénétration fondés sur la menace (TLPT) pour les entités concernées.
• Superviser le registre des prestataires tiers de services TIC et l'analyse de leur criticité.
• Assurer le lien entre la détection d'incidents et le processus de classification/notification prévu par DORA.

Documentez systématiquement l'accès direct du RSSI à l'organe de direction, sans filtre managérial intermédiaire, notamment pour les alertes critiques. Un RSSI rattaché à la DSI et devant obtenir l'aval de son supérieur hiérarchique avant de porter une alerte au conseil crée un risque de rétention d'information — c'est un point que les superviseurs examinent lors des contrôles sur la gouvernance.

Le RSSI reste toutefois un rôle d'exécution et de coordination technique. Il prépare les décisions, alerte, propose des arbitrages budgétaires — mais l'approbation finale du cadre, des politiques et des budgets reste, par construction du règlement, une prérogative de l'organe de direction. Confondre ces deux niveaux conduit à des dispositifs où la responsabilité réelle est diffuse : en cas d'incident majeur, l'autorité de contrôle constate que personne au niveau des administrateurs ne peut expliquer les arbitrages qui ont conduit à la défaillance.

Fonction conformité : contrôleur du dispositif, pas simple relais réglementaire

Dans beaucoup d'organisations, la fonction conformité intervenait jusqu'ici surtout sur les sujets LCB-FT, protection de la clientèle ou abus de marché. DORA élargit son périmètre naturel aux risques TIC, avec deux rôles précis :

1. Contrôle de conformité réglementaire — vérifier que le cadre de gestion des risques TIC, les politiques de continuité, les contrats avec les prestataires tiers et les procédures de notification d'incidents respectent effectivement les exigences du règlement et des normes techniques de réglementation (RTS) qui l'accompagnent.
2. Contribution à la deuxième ligne de défense — aux côtés du RSSI, challenger les décisions opérationnelles, notamment sur les clauses contractuelles obligatoires avec les prestataires (droits d'audit, clauses de sortie, localisation des donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire) et sur le respect des délais réglementaires de notification d'incidents majeurs aux autorités compétentes.

DORA est distinct de la directive NIS2, mais les deux textes sont complémentaires et parfois source de confusion pour les fonctions conformité qui découvrent les deux chantiers simultanément. NIS2 vise un périmètre sectoriel plus large (énergie, santé, transport, numérique, etc.) avec une logique de transposition nationale, tandis que DORA est un règlement européen directement applicable, ciblé sur le secteur financier, avec des obligations plus prescriptives sur la gestion contractuelle des prestataires TIC. Une entité financière relevant des deux textes doit s'assurer que son dispositif de gouvernance ne traite pas ces obligations en silos redondants.

En pratique, la fonction conformité doit disposer d'une compétence technique minimale pour dialoguer efficacement avec le RSSI — sans reproduire son expertise, mais sans se limiter non plus à un contrôle purement formel des cases cochées.

Culture de résilience opérationnelle : au-delà des politiques écrites

Un cadre de gouvernance parfaitement rédigé sur le papier ne produit aucun effet si la culture organisationnelle ne le porte pas. DORA emploie explicitement la notion de sensibilisation et de formation continue, pas seulement au niveau du conseil, mais pour l'ensemble du personnel exposé aux risques TIC.

Les leviers concrets les plus efficaces observés dans les entités qui ont structuré leur conformité DORA :

Après un incident de disponibilité touchant un prestataire cloud critique, une banque régionale a constaté lors du retour d'expérience que l'alerte avait mis six heures à remonter jusqu'au comité exécutif, alors que le seuil de notification réglementaire à l'autorité compétente imposait une évaluation sous quatre heures. La cause n'était pas technique mais organisationnelle : aucune procédure n'identifiait qui, en dehors des heures ouvrées, avait l'autorité pour déclencher la procédure de classification d'incident. Le correctif a porté sur la gouvernance de l'astreinte, pas sur l'outillage.

Proportionnalité pour les entités simplifiées

DORA prévoit un régime allégé pour certaines catégories d'entités — notamment les petites entreprises d'investissement non interconnectées, certains établissements de paiement de petite taille ou les petites institutions de retraite professionnelle. Ce régime simplifié réduit le formalisme documentaire attendu, mais ne dispense pas des principes de gouvernance eux-mêmes : l'organe de direction reste responsable, la séparation des lignes de défense doit exister même sous une forme allégée, et la remontée d'incidents à la direction reste obligatoire.

La proportionnalité porte sur le niveau de détail et de formalisation du dispositif, pas sur son existence. Une petite structure ne peut pas invoquer sa taille pour ne pas nommer de responsable identifié de la gestion des risques TIC, même si cette personne cumule d'autres fonctions.

Checklist d'auto-évaluation de la gouvernance

• Le conseil a-t-il formellement approuvé le cadre de gestion des risques TIC au cours des douze derniers mois ?
• Existe-t-il une trace documentée (procès-verbal) d'un point régulier consacré aux risques TIC en conseil ?
• Les administrateurs ont-ils suivi une formation sur les risques TIC proportionnée à leur exposition ?
• La fonction de gestion des risques TIC (RSSI) dispose-t-elle d'un accès direct à l'organe de direction pour les alertes critiques ?
• Les deuxième et troisième lignes de défense sont-elles portées par des personnes ou entités distinctes ?
• Le rôle de la fonction conformité sur les risques TIC est-il formalisé dans une charte ou une fiche de mission ?
• Existe-t-il une procédure documentée désignant qui, à tout moment (y compris hors heures ouvrées), peut déclencher la classification d'un incident majeur ?
• Le budget alloué à la résilience opérationnelle numérique fait-il l'objet d'une revue périodique par l'organe de direction ?

Cette liste ne remplace pas un audit formel, mais elle permet d'identifier rapidement les zones où la gouvernance reste théorique plutôt qu'effective — c'est précisément ce que les prochains chapitres, consacrés au cadre de gestion des risques et à la gestion des incidents, viendront opérationnaliser.