> For the complete documentation index, see [llms.txt](https://docs.stoik.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stoik.io/help/help-center-fr/onboarding/compliance/dora.md). # DORA Depuis le 17 janvier 2025, le **Acte sur la résilience opérationnelle numérique (DORA, règlement (UE) 2022/2554)** exige des entités financières de l’UE qu’elles prouvent qu’elles peuvent résister aux incidents TIC, y répondre et s’en remettre. DORA ne vous demande pas d’acheter un outil spécifique. Elle vous demande de mettre en place des mesures **et d’en apporter la preuve**. Stoïk Protect aide sur ces deux points : ses outils couvrent plusieurs exigences techniques, et ils produisent les preuves (rapports, historique, taux d’achèvement) attendues par les auditeurs et les superviseurs. Cet article montre à quelles exigences DORA chaque outil de Stoïk Protect contribue, et ce qui reste de votre responsabilité. {% hint style="info" %} Stoïk Protect dispose d’une **NIS2** évaluation dédiée dans l’ **Compliance** onglet. Il n’y a pas encore d’évaluation DORA dans le produit. DORA et NIS2 se recoupent fortement sur les mesures techniques, et pour les entités financières DORA remplace les exigences NIS2 équivalentes (NIS2, art. 4). L’évaluation NIS2 reste donc un point de départ utile pour une analyse des écarts. {% endhint %} ## Qui est concerné par DORA ? DORA s’applique à la plupart des entités financières réglementées : banques, établissements de paiement et de monnaie électronique, entreprises d’investissement, gestionnaires d’actifs, assureurs et réassureurs, prestataires de services sur crypto-actifs, et autres. Certaines entités sont **exemptées**. La principale exemption concerne les intermédiaires d’assurance et de réassurance qui sont des microentreprises, des petites ou moyennes entreprises (art. 2(3)). Les entités plus petites entrant dans le champ d’application peuvent également appliquer un **cadre simplifié de gestion des risques TIC** (art. 16). Si vous ne savez pas si DORA s’applique à vous, demandez à votre responsable conformité ou à votre superviseur (ACPR ou AMF en France). ## Comment Stoïk Protect se rattache à DORA DORA comporte cinq piliers. Stoïk Protect contribue à quatre d’entre eux. ### 1. Gestion des risques TIC (chapitre II, articles 5 à 16) Ce pilier vous demande de connaître vos actifs, de trouver les vulnérabilités, de protéger vos systèmes, de détecter les anomalies et de former vos équipes. | Outil Stoïk Protect | Exigence DORA à laquelle il contribue | Preuves que vous pouvez présenter | | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | | **Scan Externe** | Inventaire des actifs TIC exposés à Internet (art. 8(1), 8(4)). Identification continue des vulnérabilités et des cybermenaces (art. 8(2)). Surveillance des systèmes TIC (art. 9(1)). | Rapports d’analyse datés et historique des vulnérabilités et de leurs corrections | | **Scan Active Directory** | Accès limité à ce dont chaque rôle a besoin (art. 9(4)(c)). Authentification forte (art. 9(4)(d)). Détection des comptes à privilèges, inactifs ou mal configurés. | Rapport de configuration d’AD et liste priorisée des constats avec suivi des remédiations | | **Scan Cloud** (AWS, Azure, GCP) | Sécurité et résilience des systèmes, et prévention des accès non autorisés et des fuites de données (art. 9(2), 9(3)). Détection des mauvaises configurations de votre côté du cloud, dont vous restez pleinement responsable (art. 28(1)). | Rapport d’état de sécurité cloud par environnement | | **Surveillance des identifiants** | Protection contre les accès non autorisés (art. 9(3)(b)). Détection des comptes compromis avant leur utilisation (art. 10(1)). | Liste des identifiants divulgués détectés et des mots de passe réinitialisés | | **Email Security** | Sécurité des canaux de transfert de données (art. 9(3)(a)). Réduction du risque d’accès non autorisé et de fraude (art. 9(3)(b)). | Statistiques sur les menaces bloquées | | **MDR** | Détection 24 h/24, 7 j/7 des activités anormales sur les terminaux (art. 10(1)). Ressources suffisantes pour surveiller les anomalies et les cyberattaques (art. 10(3)). Containment rapide (art. 11(2)). | Rapports d’activité, alertes traitées, temps de réponse | | **XDR** | Plusieurs couches de contrôle, seuils d’alerte et alerting automatique (art. 10(2)), sur les données VPN, pare-feu et cloud. | Règles de détection et historique des alertes | | **Formation** | Sensibilisation obligatoire à la sécurité TIC pour l’ensemble du personnel (art. 13(6)). Formation régulière de l’organe de direction (art. 5(4)). | Taux d’achèvement et certificats de formation | | **Simulation de phishing** | Programmes de sensibilisation (art. 13(6)). Apprentissage à partir des menaces observées (art. 13(1)). | Taux de clics, de soumission et de signalement par campagne, avec évolution dans le temps | ### 2. Gestion et signalement des incidents TIC (chapitre III, articles 17 à 23) | Service Stoïk | Exigence DORA à laquelle il contribue | Preuves que vous pouvez présenter | | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | **MDR / XDR** | Détection et journalisation des incidents (art. 17(2), 17(3)). La détection précoce est importante car les délais de signalement de DORA commencent à partir du moment où l’incident est classé. | Historique des alertes et des incidents | | **Bouton de signalement du phishing** | Un moyen simple pour les employés de signaler les e-mails suspects, qui alimente votre processus de détection des incidents (art. 17(3)). | E-mails signalés et traitement effectué | | **Stoïk CERT** (réponse aux incidents 24 h/24, 7 j/7, incluse avec l’assurance Stoïk) | Réponse et récupération (art. 11). Revue post-incident et analyse des causes racines (art. 13(2)). Apport technique pour les rapports d’incident majeur (art. 19(4)) : notification initiale, rapport intermédiaire et rapport final. | Rapport d’incident avec chronologie, indicateurs de compromission, cause racine et actions menées | ### 3. Tests de résilience opérationnelle numérique (chapitre IV, articles 24 à 27) DORA impose un programme de tests, revu au moins une fois par an, qui inclut explicitement **des évaluations de vulnérabilités et des analyses** (art. 25(1)). * **Scan Externe, Scan Active Directory et Scan Cloud** vous fournissent des évaluations de vulnérabilités récurrentes qui alimentent ce programme (art. 24(6), 25(1)). * **Simulations de phishing** sont une forme de test d’ingénierie sociale fondé sur des scénarios (art. 25(1)). > Les tests d’intrusion pilotés par les menaces (TLPT, art. 26 et 27) ne sont obligatoires que pour les entités financières désignées par leur superviseur. Stoïk Protect ne les fournit pas. ### 4. Risque lié aux tiers TIC (chapitre V, articles 28 à 44) Vous restez pleinement responsable de vos obligations DORA lorsque vous utilisez un fournisseur cloud (art. 28(1)). **Scan Cloud** vous aide à maîtriser la partie de ce risque qui dépend de la manière dont *vous* avez configuré votre environnement. Il ne **remplace pas** le registre des informations ni les clauses contractuelles obligatoires avec vos prestataires TIC (art. 28(3), art. 30). ### 5. Partage d’informations (article 45) Ce pilier est facultatif dans DORA. Stoïk Protect ne le couvre pas directement. ## Ce qui reste de votre responsabilité Stoïk Protect vous fournit des outils et des preuves. Votre organisation demeure responsable des éléments suivants : * **Gouvernance.** Votre organe de direction porte la responsabilité finale du risque TIC et doit approuver le cadre (art. 5(2)). * **Signalement officiel.** Vous notifiez à votre superviseur les incidents majeurs (art. 19). Le Stoïk CERT vous aide à préparer le contenu technique. * **Sauvegardes et continuité d’activité.** Vos politiques de sauvegarde, de restauration et de continuité d’activité ou de reprise après sinistre, ainsi que leurs tests (art. 11, 12). * **Registre des prestataires TIC et contrats** (art. 28(3), 30). * **Politique de chiffrement** (art. 9(4)). * **TLPT**, si votre superviseur vous a désigné (art. 26, 27). ## Pour commencer 1. Ouvrez **Stoïk Protect** et vérifiez quels outils sont déjà actifs pour votre organisation. 2. Activez les outils qui correspondent à vos écarts. Scan Externe, Scan Active Directory, Formation et simulation de phishing sont les gains les plus rapides pour les preuves DORA. 3. Complétez l’ **évaluation NIS2** dans l’ **Compliance** onglet pour obtenir une vue structurée de vos mesures techniques. 4. Exportez les rapports de chaque outil et ajoutez-les à votre documentation DORA. {% hint style="warning" %} Cet article fournit des indications générales, pas des conseils juridiques. Les références renvoient aux textes de l’UE : le règlement (UE) 2022/2554 (DORA) et ses règlements délégués (UE) 2024/1774 et (UE) 2025/301. Le champ d’application exact de chaque service dépend de votre contrat. Pour vos obligations spécifiques, demandez à votre responsable conformité ou à votre superviseur. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.stoik.io/help/help-center-fr/onboarding/compliance/dora.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.