Accueil
Ressources

Analyse approfondie de la conformité DORA

Analyse approfondie de la conformité DORA

1. Aperçu

Qu'est-ce que DORA

Le règlement (UE) 2022/2554, le Digital Operational Resilience Act (DORA), est le cadre unifié de l'UE en matière de risques liés aux TIC pour le secteur financier. Elle est entrée en vigueur le 16 janvier 2023 et est devenue pleinement applicable le 17 janvier 2025. DORA harmonise la gestion des risques TIC entre les entités financières opérant dans l'UE et, ce qui est essentiel pour les fournisseurs de technologies, s'étend directement aux prestataires de services tiers TIC (TPSP) dont dépendent ces entités financières. Le règlement consolidé, prenant en charge les normes techniques de réglementation (RTS), les normes techniques de mise en œuvre (ITS) et les orientations des autorités européennes de surveillance (EBA, EIOPA, ESMA), est publié sur eur-lex.europa.eu et le portail commun des AES.

À qui s’applique-t-il

DORA s'applique à vingt types d'entités financières au sens de l'article 2, paragraphe 1, y compris les établissements de crédit, les établissements de paiement, les établissements de monnaie électronique, les entreprises d'investissement, les prestataires de services sur crypto-actifs, les dépositaires centraux de titres, les contreparties centrales, les plates-formes de négociation, les référentiels centraux, les gestionnaires de fonds d'investissement alternatifs, les sociétés de gestion, les entreprises d'assurance et de réassurance, les intermédiaires d'assurance, les institutions de retraite professionnelle, les agences de notation de crédit, les administrateurs d'indices de référence critiques, les prestataires de services de financement participatif, les référentiels de titrisation et les prestataires de services d'information sur les comptes. Une exemption étroite s'applique aux microentreprises (article 16), mais la plupart des clients SaaS B2B n'en sont pas concernés.

Pourquoi il atteint la chaîne d'approvisionnement

Le titre V de DORA (articles 28 à 44) établit la gestion des risques liés aux tiers en matière de TIC comme une préoccupation réglementaire directe, et non seulement contractuelle. Les entités financières doivent appliquer le cadre de risque tiers de DORA à tous leurs TPSP TIC. L’article 28 prescrit une diligence raisonnable précontractuelle obligatoire et un contrôle continu. L'article 30 énumère les dispositions contractuelles impératives. L'article 29 régit la sous-traitance et le registre des informations. Les articles 31 à 44 établissent le régime de désignation des fournisseurs de services tiers critiques en matière de TIC (CTPP) et le cadre de surveillance du superviseur principal. L'effet pratique pour un fournisseur SaaS vendant à une banque ou un assureur est que DORA arrive via le contrat, le questionnaire de sécurité et le cycle de renouvellement.

Résultat

DORA ne produit pas de certificat. La conformité est démontrée par des programmes documentés, des dispositions contractuelles, une coopération en matière d'audit et la capacité à opérationnaliser des horloges de reporting d'incidents. Les clients des entités financières exigeront des auto-évaluations DORA ainsi que des certificats ISO 27001 et des rapports SOC 2 dans le cadre de la diligence raisonnable. Lorsqu'un TPSP est désigné comme critique (CTPP) en vertu de l'article 31, il relève de la surveillance directe de l'ESA, y compris des inspections, des recommandations et des astreintes périodiques en vertu de l'article 35, à hauteur de 1 % du chiffre d'affaires quotidien moyen mondial par jour de non-conformité.

Clarify Consult Partner soutient les programmes DORA à travers le Service de conformité DORA, généralement combiné avec ISO 27001 pour le SMSI sous-jacent et SOC 2 pour l’attestation destinée au client.

2. Portée et applicabilité

Périmètre de l'entité financière

Vingt types d'entités financières sont énumérés à l'article 2, paragraphe 1. Le champ d’application est intentionnellement large et inclut à la fois les entités bancaires traditionnelles et les marchés de capitaux ainsi que des catégories plus récentes telles que les prestataires de services sur crypto-actifs et les prestataires de services de financement participatif.

Définition du service TIC (article 3, paragraphe 21)

Les services TIC désignent les services numériques et de données fournis via des systèmes TIC à un ou plusieurs utilisateurs internes ou externes de manière continue, y compris le matériel en tant que service et les services matériels. SaaS, IaaS, PaaS, les services de sécurité gérés, les fournisseurs d'identité, les plateformes d'analyse de données, les plateformes de traitement des paiements, les outils de surveillance, les plateformes de communication et les services de conseil fournis via les TIC entrent tous dans le champ d'application.

Fonction critique ou importante

Une fonction critique ou importante est une fonction dont la perturbation nuirait sensiblement à la performance financière d'une entité financière, à ses services ou au respect des obligations réglementaires. L'entité financière classe lesquelles de ses fonctions sont critiques ou importantes. Si votre service prend en charge une fonction que l'entité considère comme critique ou importante, l'ensemble du cadre DORA s'applique à votre relation avec cette entité, et non à un sous-ensemble plus léger.

Désignation CTPP (article 31)

Les AES désignent les CTPP sur la base de critères quantitatifs, notamment l'impact systémique, la criticité des entités financières desservies par le TPSP, le recours au TPSP, la substituabilité et le risque de concentration. La première liste de CTPP désignés était attendue pour 2025. Les CTPP désignés relèvent de la surveillance directe du superviseur principal (articles 32 et suivants) avec des droits d'inspection, des recommandations et des pouvoirs de sanction.

Les sous-traitants et la chaîne

L'article 29 oblige le TPSP à tenir un registre des sous-traitants prenant en charge des fonctions critiques ou importantes, à obtenir une autorisation de sous-traitance si nécessaire et à diffuser les dispositions pertinentes pour DORA. La chaîne s'étend sur plusieurs niveaux.

3. Principes fondamentaux — Les cinq piliers

DORA est organisé en cinq piliers :

  • Gestion des risques liés aux TIC (articles 5 à 15): gouvernance, cadre de risque TIC, identification, protection et prévention, détection, réponse et rétablissement, apprentissage et évolution, communication.
  • Gestion, classification et reporting des incidents liés aux TIC (articles 17 à 23): processus incident, seuils de classification, horloges de reporting, modèles harmonisés.
  • Tests de résilience opérationnelle numérique (articles 24 à 27): programme de tests de routine, tests avancés via Threat-Led Penetration Testing (TLPT) pour les entités financières importantes.
  • Gestion des risques liés aux tiers liés aux TIC (articles 28 à 44): dispositions contractuelles, sous-traitance, registre d'informations, stratégie de sortie, désignation CTPP, régime Lead Overseer.
  • Partage d’informations (article 45): accords volontaires de partage d’informations sur les cybermenaces entre entités financières.

4. Panne du contrôle

Gestion des risques liés aux TIC (articles 5 à 15)

Article 5 — Gouvernance et organisation: l'organe de direction est responsable en dernier ressort du risque lié aux TIC ; rôles définis, formation, cadence de surveillance.
Article 6 — Cadre de gestion des risques liés aux TIC: cadre documenté couvrant les stratégies, les politiques, les procédures, les protocoles et les outils TIC. Révisé annuellement et sur les incidents majeurs.
Article 7 — Systèmes, protocoles et outils TIC: capacité appropriée, fiable, suffisante, résiliente technologiquement, équipée pour faire face aux pics de demande.
Article 8 — Identification: identifier toutes les sources de risque TIC ; classer et documenter les fonctions commerciales, les rôles, les actifs TIC, les actifs informationnels, les interdépendances et les processus.
Article 9 — Protection et prévention: sécuriser les systèmes, empêcher les accès non autorisés, sécurité des réseaux, gestion des identités, gestion des changements, gestion des correctifs, chiffrement, communications sécurisées, sécurité physique.
Article 10 — Détection: mécanismes de détection, seuils d'alerte, surveillance de l'activité des réseaux et des systèmes d'information, anomalies opérationnelles liées aux TIC.
Article 11 — Réponse et récupération: Continuité des activités TIC et plans de réponse et de reprise TIC, RTO et RPO documentés, tests.
Article 12 — Politiques de sauvegarde, procédures de restauration et de récupération: sauvegarde; site de traitement secondaire pour des fonctions critiques ou importantes ; restauration testée au moins une fois par an.
Article 13 — Apprendre et évoluer: bilans post-incidents, enseignements tirés, amélioration continue, programmes de sensibilisation.
Article 14 — Communications: plan de communication de crise à destination du personnel, des clients, des contreparties des entités financières et des autorités compétentes.

Gestion des incidents liés aux TIC (articles 17 à 23)

Article 17 — Processus de gestion des incidents: processus documenté de détection, de manipulation, de suivi.
Article 18 — Classement: critères comprenant les clients concernés, la perte de données, l'impact sur la réputation, la durée, la répartition géographique, l'impact économique et la criticité des services concernés, selon le RTS final.
Article 19 — Signalement des incidents majeurs et des cybermenaces significatives: déclaration harmonisée aux autorités compétentes. Trois notifications par RTS final : notification initiale dans les 4 heures suivant la classification mais au plus tard dans les 24 heures suivant la prise de conscience ; rapport intermédiaire dans les 72 heures ; rapport final dans un délai d'un mois.
Article 23 — Incidents liés aux TIC affectant les prestataires de services TIC tiers: Les TPSP informent les entités financières des incidents les affectant selon le calendrier de notification contractuel, généralement plus serré que le calendrier réglementaire afin que l'entité financière puisse respecter ses propres délais.

Tests de résilience opérationnelle numérique (articles 24 à 27)

Article 24 — Exigences générales: chaque entité financière met en place un programme de tests de résilience opérationnelle numérique.
Article 25 — Tests de routine: évaluations de vulnérabilités, analyses, tests basés sur des scénarios, tests de performances, tests de bout en bout, tests d'intrusion. Fréquence proportionnelle au risque. Les systèmes TIC prenant en charge des fonctions critiques ou importantes sont testés au moins une fois par an.
Article 26 — Tests avancés basés sur des tests d'intrusion basés sur des menaces (TLPT): s’applique aux entités financières importantes selon les seuils de l’article 26, paragraphe 8. TLPT tous les trois ans sur l'entité financière et sur les TPSP critiques qui soutiennent des fonctions critiques ou importantes, suivant le cadre TIBER-EU ou équivalent.

Gestion des risques liés aux tiers liés aux TIC (articles 28 à 44)

Article 28 — Principes clés pour la gestion des risques liés aux tiers en matière de TIC: due diligence précontractuelle, surveillance continue, stratégies de sortie, dispositions contractuelles conformes à l’article 30.
Article 29 — Évaluation préliminaire du risque de concentration des TIC et autres dispositions: l'entité financière prend en compte le risque de concentration lorsqu'elle conclut des accords avec des tiers en matière de TIC soutenant des fonctions critiques ou importantes ; tient un registre d'informations.
Article 30 — Dispositions contractuelles clés: clauses contractuelles obligatoires comprenant la description des services, les lieux de traitement des données et d'exécution des services, les obligations de surveillance et de reporting, les droits d'audit, les niveaux de service, les obligations de sécurité, la réponse aux incidents, la sous-traitance, les droits de résiliation et la stratégie de sortie.
Articles 31 à 44 — Cadre de surveillance du CTPP: critères de désignation, pouvoirs du Contrôleur Principal, inspections, recommandations, suivi, astreintes au titre de l'article 35.

Partage d’informations (article 45)

Accords volontaires de partage d’informations sur les cybermenaces entre entités financières. Les TPSP peuvent être invités à contribuer via des accords avec les clients.

5. Exigences minimales (non négociables) — Point de vue TPSP

Documents obligatoires

  • Cadre de gestion des risques liés aux TIC aligné sur les articles 5 à 15 de DORA
  • Registre des actifs et des informations TIC avec classification et interdépendances
  • Registre des sous-traitants prenant en charge les fonctions critiques ou importantes des clients des entités financières
  • Plan de réponse aux incidents avec seuils de classification et workflow de reporting à trois heures
  • Plan de continuité des activités et de reprise des TIC avec RTO et RPO documentés
  • Stratégie de sortie pour chaque client d'entité financière où une fonction critique ou importante est prise en charge
  • Registre d'information selon les spécifications de l'article 28
  • Modèle de contrat au titre de l’article 30 aligné sur les exigences de l’entité financière
  • Dossier de réponse au devoir de diligence de la clientèle

Processus obligatoires

  • Notification d'incident aux clients des entités financières conformément au SLA contractuel
  • Notification de changement de sous-traitance conformément à l'article 30, paragraphe 3 (au moins 30 jours pour les fonctions critiques ou importantes)
  • Support au cycle annuel de due diligence client
  • Coopération en matière d'audit pour les audits d'entités financières et les inspections des autorités compétentes
  • Tests de stratégie de sortie dans les délais

Contrôles techniques

  • Authentification forte, y compris MFA pour les accès privilégiés et clients
  • Chiffrement en transit et au repos avec cycle de vie de gestion des clés documenté
  • Segmentation du réseau et protection des limites
  • Journalisation et surveillance centralisées avec une rétention suffisante
  • Gestion des vulnérabilités et des correctifs
  • Sauvegarde et reprise après sinistre testées au moins une fois par an

6. Conseils de mise en œuvre technique

S'appuyer sur la base ISO 27001 / SOC 2

DORA s'aligne substantiellement sur les critères de l'Annexe A de la norme ISO 27001 : 2022 et sur les critères des services de confiance SOC 2. Pour un TPSP exploitant déjà un SMSI, les extensions spécifiques à DORA sont : des seuils de classification des incidents et des modèles de reporting harmonisés ; Registre des risques liés aux tiers TIC avec informations sur les sous-traitants ; tests de stratégie de sortie ; Préparation au TLPT ; Article 30 Dispositions contractuelles.

Flux de travail de classification et de reporting des incidents

  • Mettre en œuvre une logique harmonisée de classification des incidents selon le RTS final
  • Documenter le flux de travail de reporting à trois heures : notification initiale dans les 4 heures suivant la classification (au plus tard 24 heures après la prise de conscience) ; rapport intermédiaire dans les 72 heures ; rapport final dans un délai d'un mois
  • Modèles de notification client préliminaires selon l’horloge contractuelle

Stratégie de sortie

  • Document par client entité financière majeure : procédures d'extraction des données, format, calendrier, accompagnement à la transition, obligations de transfert de connaissances
  • Tester la stratégie de sortie au moins tous les deux ans ; conserver les preuves de test

Discipline de la sous-traitance

  • Tenir le registre des sous-traitants conformément à l'article 29
  • Transmettre les dispositions contractuelles pertinentes pour DORA aux sous-traitants prenant en charge les fonctions critiques ou importantes
  • Informer les clients des entités financières avant les changements de sous-traitance conformément à l'article 30, paragraphe 3.

Préparation au TLPT

  • Pour les TPSP prenant en charge des fonctions critiques ou importantes d'entités financières importantes, attendez-vous à participer au TLPT tous les trois ans.
  • TLPT suit le cadre TIBER-EU : renseignements sur les menaces, équipe rouge, équipe bleue, équipe violette, replay
  • Coordonner avec le responsable TLPT de l'entité financière et le fournisseur de tests désigné ; voir notre service de tests d'intrusion

7. Exigences en matière de politiques et de procédures

  • Politique relative au cadre de gestion des risques liés aux TIC
  • Politique et procédure de gestion des actifs TIC
  • Procédures d'identification, de protection, de détection, de réponse, de récupération et d'apprentissage
  • Plan de réponse aux incidents avec seuils de classification DORA et workflow de reporting à trois heures
  • Plan de continuité des activités TIC et de reprise après sinistre
  • Procédure de sauvegarde, de restauration et de récupération
  • Plan de communication de crise
  • Politique de gestion des risques liés aux tiers en matière de TIC
  • Registre des sous-traitants et procédure d’autorisation de sous-traitance
  • Stratégie de sortie par client d'entité financière ou modèle principal
  • Procédure de réponse à la diligence raisonnable du client
  • Accord de partage d’informations là où il a été conclu

8. Preuves d'audit et vérification — Vue TPSP

DORA ne certifie pas les TPSP. La conformité est démontrée par :

  • Cadre documenté de gestion des risques liés aux TIC avec l’approbation de l’organisme de direction
  • Registre des actifs et des informations TIC
  • Registre des sous-traitants
  • Dossiers de gestion des incidents et modèles de rapports
  • Rapports de tests de continuité des activités et de reprise après sinistre
  • Rapport de test de stratégie de sortie
  • Rapports d'évaluation des vulnérabilités, d'analyse et de tests d'intrusion
  • Modèles de contrats article 30 et accords clients signés
  • Preuve de coopération en matière d'audit client
  • Pour les CTPP uniquement : recommandations du superviseur principal et preuves de suivi

Éléments de correction courants

  • Stratégie de sortie manquante ou non testée pour les grands clients des entités financières
  • Registre des sous-traitants incomplet ou périmé
  • Contrats clients antérieurs à DORA et dispositions manquantes de l'article 30
  • Seuils de classification des incidents non alignés sur le RTS final
  • Droits d’audit non étendus aux sous-traitants
  • Le cadre de gestion des risques liés aux TIC manque de preuves de l’approbation de l’organe de direction et d’un examen annuel

9. Considérations sur le calendrier de mise en œuvre

Durée typique – TPSP

  • TPSP avec un SMSI ISO 27001 mature: 3 à 5 mois avant la préparation à DORA
  • TPSP sans SMSI: 9 à 12 mois incluant les bases ISO 27001
  • Piste de désignation CTPP: continu, avec engagement annuel du superviseur principal une fois désigné

Jalons

  • Cartographie de la clientèle et classification TPSP
  • Analyse des écarts contractuels au titre de l’article 28
  • Création d'un cadre de gestion des risques liés aux TIC
  • Flux de travail de gestion des incidents avec reporting à trois heures
  • Registre des sous-traitants et documentation sur la stratégie de sortie
  • Dossier de réponse au devoir de diligence de la clientèle
  • Cycle d’opérations vCISO pour une maintenance continue

10. Exigences continues du BAU

  • Examen annuel du cadre de risque lié aux TIC
  • Test annuel de continuité des activités et de reprise après sinistre
  • Évaluation annuelle de la vulnérabilité et test de scénarios
  • Tests d'intrusion sur la cadence basée sur le risque (une fréquence annuelle est courante)
  • TLPT tous les trois ans pour les TPSP soutenant des fonctions critiques ou importantes d'entités financières importantes
  • Répétition du workflow de reporting d'incidents
  • Actualisation du registre des sous-traitants et notification des modifications
  • Cycle de réponse en matière de due diligence client
  • Alignement sur le renouvellement des contrats conformément à l’article 30

11. Niveaux de maturité

Conformité minimale

  • Cadre de risque TIC documenté
  • Modèle de contrat article 30 dans le document client
  • Réponse aux incidents avec un flux de travail à trois heures
  • Stratégie de sortie documentée pour les meilleurs clients

Intermédiaire

  • ISO 27001 ISMS étendu avec les articulations DORA
  • Classification automatisée des incidents
  • Cycle de vie des sous-traitants géré dans la plateforme de risque fournisseur
  • Posture prête pour le TLPT

Avancé

  • Bibliothèque de preuves DORA + ISO 27001 + SOC 2 + NIS 2 intégrée
  • Surveillance de contrôle continue avec preuves en temps réel
  • Réponse automatisée en matière de due diligence client
  • Disponibilité totale au niveau CTPP même s'il n'est pas désigné

12. FAQ

Sommes-nous dans le champ d'application de DORA ?

Si vous êtes une entité financière appartenant à l’une des vingt catégories de l’article 2, paragraphe 1, oui directement. Si vous êtes un fournisseur de services TIC tiers vendant à ces entités, DORA vous contacte via le flux contractuel de l'article 30 et le cadre de gestion des risques de la chaîne d'approvisionnement que vos clients sont tenus d'appliquer.

Qu’est-ce qu’un fournisseur de services tiers TIC critiques ?

Un TPSP désigné par les AES sur la base de critères quantitatifs de l'article 31, notamment l'impact systémique, la criticité des entités desservies, la fiabilité, la substituabilité et la concentration. Les premières désignations étaient attendues à partir de 2025. Les CTPP relèvent de la surveillance directe du superviseur principal, y compris des inspections et des astreintes au titre de l'article 35.

À quelle vitesse les incidents doivent-ils être signalés ?

Pour les entités financières : première notification dans les 4 heures suivant la classification (au plus tard 24 heures après la prise de conscience) ; rapport intermédiaire dans les 72 heures ; rapport final dans un délai d'un mois. Pour les TPSP : selon l'horloge de notification contractuelle figurant dans l'accord client, généralement plus rapide que l'horloge réglementaire afin que l'entité financière puisse respecter ses propres délais.

Qu’est-ce que le TLPT et s’applique-t-il à nous ?

Les tests d'intrusion basés sur les menaces au titre de l'article 26 s'appliquent aux entités financières importantes tous les trois ans. Les TPSP soutenant les fonctions critiques ou importantes de ces entités sont concernés et doivent accepter de participer. Voir notre service de tests d'intrusion.

Quelle est l’exigence de la stratégie de sortie ?

L’article 28, paragraphe 8, exige que les entités financières disposent d’une stratégie de sortie pour chaque accord de tiers TIC soutenant des fonctions critiques ou importantes. En tant que TPSP, vous soutenez cela en documentant les procédures d'extraction de données, le format, le calendrier, l'aide à la transition et le transfert de connaissances. La stratégie est testée au moins tous les deux ans.

Quel est le rapport entre DORA et NIS 2 ?

DORA est une lex specialis pour les entités financières. L'article 1, paragraphe 2, prévoit que DORA s'applique aux incidents liés aux TIC et aux cybermenaces, nonobstant le niveau NIS 2 pour les entités financières concernées. Pour les TPSP desservant à la fois des entités financières et d’autres secteurs couverts par NIS 2, les deux cadres s’appliquent aux relations clients concernées. Voir notre Service NIS2.

Quel est le lien entre DORA et ISO 27001 ?

ISO 27001 est une norme SMSI certifiable avec un chevauchement substantiel avec la gestion des risques DORA ICT. Le fait de détenir la norme ISO 27001 réduit considérablement l'écart DORA mais n'est pas équivalent. Des extensions spécifiques à DORA sont nécessaires : classification des incidents selon le RTS final, workflow de reporting à trois heures, registre des sous-traitants, tests de stratégie de sortie, dispositions contractuelles de l'article 30.

Quel est le rapport entre DORA et SOC 2 ?

Les rapports d'attestation SOC 2 sont largement utilisés par les clients des entités financières comme preuve des contrôles opérationnels. DORA ne remplace pas SOC 2 ; les entités financières peuvent continuer à exiger un rapport SOC 2 Type 2 ainsi que des preuves spécifiques à DORA. Un rapport de type 2 couvrant la période pertinente pour DORA accélère considérablement la diligence raisonnable des clients.

Quelles sont les sanctions ?

Pour les entités financières, les sanctions sont fixées dans la législation des États membres, conformément à l'article 50. Pour les CTPP, le superviseur principal peut imposer des astreintes périodiques en vertu de l'article 35 jusqu'à un pour cent du chiffre d'affaires mondial quotidien moyen pour chaque jour de non-conformité, plafonné à six mois.

13. Résumé

DORA est le cadre de risque TIC unifié de l'UE pour le secteur financier, avec un flux explicite et détaillé vers les prestataires de services TIC tiers dont dépend le secteur. Pour un SaaS B2B ou une société de conseil vendant à des entités financières de l'UE, DORA intervient via les dispositions contractuelles de l'article 30, l'horloge de notification des incidents, la transparence de la sous-traitance, les tests de stratégie de sortie et la diligence raisonnable des clients. Le chemin vers la préparation s'appuie sur les fondements ISO 27001 ou SOC 2 et les étend avec des articulations spécifiques à DORA. Lorsque vous êtes désigné comme fournisseur de services tiers TIC critique, la surveillance par le régime de surveillance principale de l’ESA ajoute un engagement réglementaire direct.

Pour définir un engagement, réservez un appel depuis le Page du service de conformité DORA, ou parlez-nous de la combinaison de DORA avec ISO 27001, SOC 2, NIS 2, ou un complet Programme vCISO pour la conformité continue de la chaîne d’approvisionnement.

Partagez cette publication