DORA — Résilience opérationnelle numérique

Oui si vous êtes : banque, assurance, réassurance, entreprise d'investissement, PSF, gestionnaire d'OPC, établissement de paiement, établissement de monnaie électronique, fonds de pension, prestataire de services sur cryptoactifs, administrateur d'indices de référence, agence de notation de crédit, ou prestataire TIC critique désigné par les ESA. Les seuils de taille activent la proportionnalité mais pas l'exemption.

NIS2 est une directive (transposée en droit belge), secteur-agnostique, applicable à 18 secteurs dont la finance. DORA est un règlement (applicable directement), spécifique au secteur financier, plus détaillé et plus contraignant sur la résilience opérationnelle. Pour une banque soumise aux deux, DORA prévaut (lex specialis). En pratique, on implémente les deux dans un cadre unifié.

Ordre de grandeur sur 18-24 mois : Petit PSF / fintech (< 50 personnes) : 150-350 K€. PME financière (50-250 personnes) : 400-800 K€. Grand acteur (banque, assurance, > 250 personnes) : 1-3 M€. Ces budgets couvrent l'audit, la gouvernance, la supply chain, les tests, l'outillage GRC, et la formation. Les TLPT viennent en sus : 150 à 600 K€ par campagne.

TLPT = Threat-Led Penetration Testing (DORA art. 26-27). Test d'intrusion avancé de 4 à 12 semaines basé sur une threat intelligence spécifique à votre institution. Les seuils ESA désignent les institutions éligibles (grandes banques, grandes assurances, certains prestataires critiques). Le cadre TIBER-BE pilote ces tests en Belgique, en coordination avec la BNB. Fréquence minimale : tous les 3 ans.

Non, la responsabilité finale reste chez l'entité financière. Vous pouvez sous-traiter certaines fonctions opérationnelles (MSSP, vCISO, audit) mais la gouvernance DORA doit être portée en interne au niveau board et COMEX. Le régulateur veut voir des dirigeants qui maîtrisent le sujet, pas des prestataires qui répondent pour eux.

Les hyperscalers (AWS, Azure, Google Cloud) peuvent être désignés par les ESA comme "Critical Third-Party Providers" et tomber sous supervision directe européenne. Côté client : vous devez (1) avoir un registre précis des services utilisés, (2) évaluer la concentration (part de l'IT sur un seul provider), (3) avoir un exit plan crédible et testé, (4) des clauses contractuelles DORA-compliant.

DORA s'ajoute aux exigences prudentielles existantes (Bâle III, Solvabilité II, CRR/CRD, MiFID II, etc.). La BNB et la FSMA intègrent DORA dans leur programme de contrôle global. L'approche recommandée : bâtir un framework GRC unifié qui couvre DORA + prudentiel + NIS2 + RGPD, plutôt que d'empiler des systèmes en silos.

La BNB et la FSMA envoient généralement (1) un questionnaire détaillé sur les 5 piliers, (2) une demande de documents ciblés (registre prestataires, politique TIC, rapports tests), (3) si nécessaire, une inspection sur site avec interviews. Délai de réponse typique : 2 à 4 semaines. Anticiper = préparer un dossier type qu'on peut livrer rapidement.

Les contrôles s'intensifient en 2026 sur des points précis : qualité et exhaustivité du registre des prestataires TIC (art. 28) et de sa transmission, clauses contractuelles de l'art. 30, preuve de l'implication du board (procès-verbaux, formation, art. 5), alignement des procédures d'incident sur les seuils des RTS (art. 17 à 19), réalité des tests de résilience (art. 24 à 26), et crédibilité des exit plans cloud. Le fil conducteur : des preuves opérationnelles, pas des politiques sur papier.