ISO 22301 versus DORA : quelles différences ?

Le 17 janvier 2025 a marqué l’entrée en application de DORA dans l’Union européenne. Pour les établissements concernés, la question n’est donc plus de savoir s’il faut renforcer la résilience numérique, mais comment démontrer une maîtrise effective. Le débat ISO 22301 versus DORA est parfois posé comme un choix entre un référentiel de continuité d’activité et un règlement européen. C’est une lecture incomplète : les deux cadres répondent à des finalités proches, mais leur nature, leur périmètre et leurs mécanismes de preuve diffèrent profondément.

Pour les responsables PCA, RSSI, risk managers et fonctions conformité, l’enjeu consiste à articuler les deux approches sans créer de dispositifs parallèles. Une organisation déjà structurée autour de l’ISO 22301 dispose souvent d’un socle utile. Elle doit néanmoins compléter ce socle pour répondre aux obligations précises de DORA, notamment sur les risques liés aux technologies de l’information et de la communication, les tests et la gestion des prestataires tiers.

ISO 22301 versus DORA : deux cadres, deux statuts

L’ISO 22301 est une norme internationale qui définit les exigences d’un système de management de la continuité d’activité, ou SMCA. Elle fournit une méthode de gouvernance pour identifier les activités prioritaires, analyser les impacts, fixer des stratégies de continuité, formaliser des plans, exercer les dispositifs et les améliorer dans la durée. Elle est applicable à toute organisation, publique ou privée, quelle que soit sa taille ou son secteur.

DORA, pour Digital Operational Resilience Act, est un règlement européen directement applicable. Il vise les entités financières et certains prestataires tiers critiques de services TIC. Son objectif est de garantir que ces acteurs puissent prévenir, résister, répondre et se rétablir face aux incidents opérationnels et cybernétiques liés aux TIC. Il ne s’agit pas d’une bonne pratique facultative : les organisations entrant dans son champ doivent démontrer leur conformité aux autorités compétentes.

La différence première est donc juridique. Une certification ISO 22301 peut constituer un signal fort de maturité et de discipline managériale, mais elle ne vaut pas conformité automatique à DORA. À l’inverse, une démarche strictement conçue pour satisfaire DORA peut remplir les exigences réglementaires sans nécessairement constituer un système de management de la continuité complet et pérenne.

Le périmètre : continuité globale ou résilience numérique

L’ISO 22301 traite la continuité d’activité dans une logique large. Les scénarios de perturbation peuvent concerner une cyberattaque, mais également une indisponibilité de site, une rupture d’approvisionnement, une défaillance de personnel clé, un incident sanitaire ou une crise géopolitique. L’analyse d’impact sur l’activité, souvent désignée par BIA, constitue une pièce centrale : elle relie les processus critiques, les ressources nécessaires, les délais de reprise et les conséquences d’une interruption.

DORA se concentre sur la résilience opérationnelle numérique. Le règlement couvre la gouvernance des risques TIC, la gestion et la notification des incidents majeurs, les tests de résilience numérique, les échanges d’informations sur les cybermenaces et la maîtrise des risques liés aux prestataires TIC. Son périmètre est donc plus spécialisé, tout en étant particulièrement exigeant dans le secteur financier.

Cette distinction a des conséquences directes. Un PCA construit selon l’ISO 22301 pourra organiser la réponse à l’indisponibilité d’une salle de marché ou d’un centre de relation client. Pour DORA, il faudra aussi démontrer que les dépendances applicatives, les flux de données, les mécanismes de détection, les procédures de signalement et les solutions de repli informatique sont gouvernés et testés selon les attentes réglementaires.

Des convergences utiles, mais une profondeur différente

Les deux cadres partagent une même conviction : la résilience ne se réduit pas à un plan rangé dans un outil documentaire. Elle repose sur une gouvernance claire, une compréhension des activités ou services critiques, des responsabilités définies, des dispositifs de réponse réalistes et des exercices réguliers.

L’ISO 22301 demande à la direction de soutenir le système de management, de définir une politique, d’allouer les ressources nécessaires et de piloter l’amélioration continue. DORA attend également une implication forte de l’organe de direction, notamment dans la responsabilité de la stratégie de résilience opérationnelle numérique et dans la maîtrise des risques TIC.

Les écarts apparaissent dans le niveau de prescription. L’ISO 22301 indique ce qu’un SMCA doit permettre d’atteindre, tout en laissant une latitude importante sur les moyens. DORA est complété par des normes techniques de réglementation et d’exécution qui précisent davantage les attentes. La cartographie des actifs TIC, la classification des incidents, les délais de notification, les tests de pénétration avancés fondés sur les menaces ou encore les clauses contractuelles avec les prestataires font partie des sujets à traiter avec une précision supérieure.

Les tests : exercice de continuité et validation de la résilience

Dans une démarche ISO 22301, les exercices servent à vérifier que les stratégies et plans de continuité sont utilisables. Ils peuvent prendre la forme de revues de procédures, d’exercices sur table, de simulations de crise ou de tests de bascule. Leur valeur dépend moins de leur sophistication que de leur capacité à révéler des écarts réels : décisions trop lentes, dépendances oubliées, coordonnées obsolètes ou objectifs de reprise irréalistes.

DORA attend une approche de test de résilience numérique plus structurée et proportionnée au profil de risque. Les entités doivent mettre en œuvre un programme de tests couvrant les outils, systèmes et processus TIC critiques. Certaines organisations devront réaliser des tests de pénétration fondés sur les menaces, avec des modalités strictes et des exigences de suivi.

Le piège consiste à juxtaposer un calendrier PCA et un calendrier cybersécurité. Une approche plus efficace consiste à bâtir des scénarios communs. Par exemple, un exercice de rançongiciel peut évaluer simultanément la détection, l’escalade, la gestion de crise, la communication, la restauration des données, le mode dégradé métier et le retour à la normale. Cela ne dispense pas des tests techniques propres à DORA, mais améliore la cohérence globale du dispositif.

Les prestataires TIC : un point de vigilance majeur

L’externalisation est un sujet familier pour les responsables de continuité. L’ISO 22301 conduit naturellement à identifier les fournisseurs indispensables à la livraison des produits et services prioritaires, puis à intégrer leurs défaillances dans les stratégies de continuité.

DORA va plus loin sur les dépendances TIC. Les entités financières doivent gérer le risque lié aux prestataires tiers, maintenir un registre d’information, évaluer les risques de concentration et prévoir des dispositions contractuelles détaillées. Elles doivent également préparer des stratégies de sortie lorsque cela est pertinent, afin d’éviter qu’une dépendance technologique ne transforme un incident fournisseur en indisponibilité prolongée.

La continuité d’activité apporte ici une contribution concrète : elle aide à traduire un risque fournisseur en conséquences métier. Une clause contractuelle ne protège pas à elle seule un service critique. Il faut comprendre les délais acceptables d’interruption, les alternatives réellement disponibles, les données nécessaires à la reprise et les conditions de déclenchement d’une solution de repli.

Construire une articulation opérationnelle entre ISO 22301 et DORA

Le point de départ doit être une analyse de périmètre, et non la multiplication des documents. Une organisation assujettie à DORA doit identifier les obligations qui lui sont applicables selon sa catégorie, ses services et son modèle d’externalisation. Elle peut ensuite rapprocher ces obligations de ses dispositifs existants de continuité, de gestion des risques, de sécurité de l’information, de gestion de crise et de gestion des fournisseurs.

Une matrice d’exigences permet de distinguer ce qui est déjà couvert, ce qui doit être renforcé et ce qui relève d’un chantier nouveau. L’analyse d’impact ISO 22301 peut alimenter l’identification des fonctions critiques au sens de DORA. Les plans de continuité peuvent être enrichis avec les procédures de réponse aux incidents TIC. Les revues de direction et les indicateurs du SMCA peuvent intégrer les résultats des tests de résilience numérique, les incidents significatifs et les risques de concentration fournisseurs.

Cette intégration ne signifie pas que toutes les équipes doivent utiliser les mêmes outils ou porter les mêmes responsabilités. Le RSSI, le responsable PCA, les équipes IT, la conformité, les achats et les métiers conservent leurs rôles. En revanche, les hypothèses de reprise, les seuils de criticité, les chaînes d’alerte et les décisions de crise doivent être cohérents. C’est précisément à ce niveau que les dispositifs échouent ou deviennent défendables face à un contrôle.

Ce que les responsables doivent retenir

Opposer ISO 22301 et DORA conduit à une impasse. L’ISO 22301 structure une capacité durable de continuité d’activité, applicable à l’ensemble des menaces susceptibles d’interrompre les activités critiques. DORA impose aux acteurs visés une discipline spécifique de résilience numérique, assortie d’exigences de contrôle et de démonstration plus détaillées.

Pour une entité financière, l’approche la plus solide consiste à utiliser la continuité d’activité comme cadre de cohérence organisationnelle et DORA comme référentiel réglementaire de précision pour les risques TIC. La compétence des équipes est déterminante : elles doivent savoir transformer une exigence en procédure, une procédure en capacité testée, puis un résultat de test en amélioration mesurable. C’est cette capacité d’exécution, plus que l’accumulation de documents, qui permet de faire face à une perturbation réelle avec méthode et crédibilité.

Cet article est également disponible en : Anglais