"Le board est responsable." Trois mots qui changent tout. L'article 5 de DORA ne laisse aucune ambiguïté : l'organe de direction de l'entité financière porte la responsabilité ultime de la gestion du risque ICT. Pas le RSSI. Pas le DSI. Pas le CRO. Le board.
Ce n'est pas une responsabilité théorique. C'est une responsabilité qui se traduit par des obligations concrètes de définition, d'approbation, de supervision et de formation. Un administrateur qui vote la stratégie ICT sans la comprendre s'expose — personnellement et collectivement.
Ce que l'article 5 impose au comité de direction
L'article 5 de DORA est explicite. L'organe de direction doit :
| Obligation | Détail | Implications pratiques |
|---|---|---|
| Définir | Cadre de gestion des risques ICT, tolérance au risque, stratégie de résilience | Le board fixe le cap, pas la DSI |
| Approuver | Politiques ICT, plans de continuité, stratégie de tests, budget sécurité | Validation formelle avec PV de décision |
| Superviser | Mise en œuvre du cadre, résultats des tests, état de conformité | Reporting régulier au board, indicateurs de suivi |
| Allouer | Ressources humaines et financières suffisantes | Budget sécurité sanctuarisé, recrutements |
| Se former | Acquérir et maintenir des connaissances suffisantes en risque ICT | Formations régulières, sessions de sensibilisation |
Le changement de paradigme
Avant DORA, dans beaucoup d'établissements, le risque ICT était de facto délégué à la DSI ou au RSSI. Le board recevait un reporting annuel — souvent un slide avec des feux tricolores — et validait le budget sans vrai débat. La cybersécurité était un sujet technique, pas stratégique.
DORA inverse cette logique. Le risque ICT devient un risque d'entreprise gouverné au plus haut niveau, au même titre que le risque de crédit ou le risque de marché. Un administrateur de banque qui ne comprend pas la posture cyber de son établissement manque à ses obligations de la même manière qu'un administrateur qui ne comprend pas le ratio de solvabilité.
Un RSSI d'une banque coopérative me décrivait le changement : "Avant, je présentais au board une fois par an. Maintenant, c'est chaque trimestre, avec un rapport détaillé. Et les questions sont pointues — ils ont été formés, ils comprennent les enjeux. Ça change tout dans l'allocation des budgets."
La formation des administrateurs — obligation implicite
L'article 5(4) de DORA impose que les membres de l'organe de direction maintiennent des connaissances et compétences suffisantes pour comprendre et évaluer les risques ICT et leur impact sur l'entité. Ce n'est pas optionnel — c'est une obligation réglementaire.
Quel niveau de compétence ?
DORA n'exige pas que chaque administrateur soit un expert en cybersécurité. Mais le collectif du board doit être capable de :
Comprendre le profil de risque ICT de l'entité. Évaluer l'adéquation des ressources allouées à la sécurité. Questionner la pertinence des choix technologiques majeurs (migration cloud, externalisation, choix de prestataires critiques). Interpréter les résultats des tests de résilience. Prendre des décisions éclairées en situation de crise cyber.
Modalités de formation
| Format | Fréquence | Public |
|---|---|---|
| Session de sensibilisation cyber | Annuelle | Tout le board |
| Briefing sur le paysage de menaces | Semestriel | Tout le board |
| Formation approfondie DORA | À l'entrée en fonction + annuelle | Membre référent ICT |
| Exercice de crise tabletop | Annuel | Direction + board |
| Visite du SOC | Ponctuelle | Comité des risques |
NIS2 va encore plus loin en imposant explicitement la formation des organes de direction (article 20(2)). Les entités financières soumises aux deux textes ont doublement intérêt à investir dans la montée en compétence de leur board.
Le reporting ICT au board — quel contenu, quelle fréquence
Les indicateurs essentiels
Le reporting au board doit être synthétique mais substantiel. Fini les dashboards de feux verts sans signification. Voici les indicateurs que les régulateurs s'attendent à voir dans le reporting ICT au board :
| Catégorie | Indicateurs |
|---|---|
| Posture de risque | Nombre de vulnérabilités critiques ouvertes, délai moyen de remédiation, couverture des scans |
| Incidents | Nombre d'incidents ICT (majeurs et significatifs), temps de détection, temps de résolution |
| Tests | Résultats des derniers tests de résilience, écarts RTO/RPO cible vs réel |
| Tiers ICT | Nombre de prestataires critiques, état de conformité des contrats, risques de concentration |
| Conformité | État d'avancement de la conformité DORA, écarts restants, plan de remédiation |
| Budget | Dépenses sécurité vs budget, ratio investissement/dette technique |
La fréquence de reporting
DORA ne fixe pas de fréquence précise mais l'obligation de supervision continue implique un reporting régulier. Les bonnes pratiques du marché :
Trimestriel minimum pour le comité des risques. Semestriel pour le conseil d'administration complet. Ad hoc en cas d'incident majeur ou de changement significatif du profil de risque.
Le comité des risques ICT — une bonne pratique qui s'impose
De plus en plus d'établissements créent un sous-comité dédié au risque ICT au sein du comité des risques du board. Ce sous-comité se réunit plus fréquemment (mensuel ou bimensuel), avec une composition mixte : administrateurs, RSSI, DSI, directeur des risques, directeur conformité.
Ce n'est pas une obligation DORA explicite, mais c'est devenu une quasi-nécessité pour les entités de taille significative. Le volume d'informations à traiter et les décisions à prendre sont trop importants pour être gérés uniquement lors des conseils d'administration trimestriels.
La responsabilité personnelle des administrateurs
DORA ne prévoit pas explicitement de sanctions personnelles contre les membres du board. Mais la responsabilité est clairement établie dans le texte, et les droits nationaux peuvent prévoir des conséquences personnelles en cas de manquement caractérisé.
En France, la responsabilité des dirigeants d'établissements financiers est encadrée par le Code monétaire et financier. Un manquement grave aux obligations de gouvernance DORA pourrait constituer une faute de gestion engageant la responsabilité personnelle des dirigeants. L'ACPR peut également prononcer des interdictions d'exercer.
Au-delà du risque juridique, le risque réputationnel est réel. Un administrateur associé à un incident cyber majeur qui révèle des défaillances de gouvernance — absence de supervision, budget insuffisant, tests non réalisés — porte une responsabilité qui ne s'efface pas facilement.
Gouvernance ICT dans les différentes structures
Banques systémiques
Board avec comité des risques ICT dédié, RSSI rattaché au CRO ou directement au CEO, reporting mensuel, participation aux exercices de crise. C'est le modèle le plus mature et celui que les régulateurs attendent des établissements significatifs.
Banques coopératives et mutuelles
Défi spécifique : administrateurs souvent bénévoles, issus du terrain, pas formés au numérique. La formation est cruciale. Certains réseaux mutuels ont mis en place des programmes de certification interne pour leurs administrateurs.
Fintech et petites entités
La gouvernance peut être simplifiée (article 16) mais la responsabilité du dirigeant reste. Un CEO de fintech qui est aussi le décideur ICT de facto doit documenter ses décisions et les rationales associées.
FAQ — Gouvernance ICT DORA
Un administrateur peut-il déléguer sa responsabilité ICT au RSSI ?
Non. DORA est explicite — la responsabilité est portée par l'organe de direction. Le RSSI est un exécutant et un rapporteur, pas le porteur de la responsabilité. La délégation opérationnelle est nécessaire mais ne transfère pas la responsabilité de gouvernance.
Faut-il un administrateur spécialisé en ICT ?
DORA n'impose pas formellement un "administrateur expert ICT" mais les guidelines de gouvernance des AES recommandent que le board dispose collectivement de compétences suffisantes. Avoir au moins un membre avec une expertise technologique ou cyber est une bonne pratique fortement encouragée.
Le board doit-il être informé en temps réel des incidents ?
Pas en temps réel au sens strict, mais dans des délais compatibles avec la prise de décision. Un incident majeur doit être remonté au président du board et au président du comité des risques dans les heures qui suivent la classification. Le board complet est informé ensuite, avec un rapport détaillé.
La gouvernance ICT sous DORA n'est pas un exercice cosmétique — c'est un changement profond dans la manière dont le risque numérique est piloté dans les institutions financières. Les boards qui s'emparent réellement du sujet protègent leur entité mieux que n'importe quelle solution technique. Parce qu'un board qui comprend le risque cyber alloue les bons budgets, pose les bonnes questions et prend les bonnes décisions — avant la crise, pas après. Pour le cadre complet, consultez notre guide DORA.