> 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/onboarding/compliance/dora.md). # DORA Since 17 January 2025, the **Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554)** requires EU financial entities to prove they can withstand, respond to and recover from ICT incidents. DORA doesn't ask you to buy a specific tool. It asks you to have measures in place **and to prove it**. Stoïk Protect helps with both: its tools cover several technical requirements, and they produce the evidence (reports, history, completion rates) that auditors and supervisors expect. This article shows which DORA requirements each Stoïk Protect tool helps with, and what stays your responsibility. {% hint style="info" %} Stoïk Protect has a dedicated **NIS2** assessment in the **Compliance** tab. There is no DORA assessment in the product yet. DORA and NIS2 overlap heavily on technical measures, and for financial entities DORA replaces the equivalent NIS2 requirements (NIS2, Art. 4). So the NIS2 assessment is still a useful starting point for a gap analysis. {% endhint %} ## Who is concerned by DORA? DORA applies to most regulated financial entities: banks, payment and e-money institutions, investment firms, asset managers, insurers and reinsurers, crypto-asset service providers, and others. Some entities are **exempt**. The main exemption is for insurance and reinsurance intermediaries that are microenterprises, small or medium-sized enterprises (Art. 2(3)). Smaller entities in scope can also apply a **simplified ICT risk management framework** (Art. 16). If you're not sure whether DORA applies to you, ask your compliance officer or your supervisor (ACPR or AMF in France). ## How Stoïk Protect maps to DORA DORA has five pillars. Stoïk Protect contributes to four of them. ### 1. ICT risk management (Chapter II, Articles 5 to 16) This pillar asks you to know your assets, find vulnerabilities, protect your systems, detect anomalies and train your people. | Stoïk Protect tool | DORA requirement it helps with | Evidence you can show | | -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | | **External Scan** | Inventory of internet-exposed ICT assets (Art. 8(1), 8(4)). Ongoing identification of vulnerabilities and cyber threats (Art. 8(2)). Monitoring of ICT systems (Art. 9(1)). | Dated scan reports and a history of vulnerabilities and their fixes | | **Active Directory Scan** | Access limited to what each role needs (Art. 9(4)(c)). Strong authentication (Art. 9(4)(d)). Detection of privileged, dormant or misconfigured accounts. | AD configuration report and a prioritised list of findings with remediation tracking | | **Cloud Scan** (AWS, Azure, GCP) | Security and resilience of systems, and prevention of unauthorised access and data leaks (Art. 9(2), 9(3)). Misconfiguration detection on your side of the cloud, where you stay fully responsible (Art. 28(1)). | Cloud posture report per environment | | **Credentials monitoring** | Protection against unauthorised access (Art. 9(3)(b)). Detection of compromised accounts before they're used (Art. 10(1)). | List of leaked credentials detected and passwords rotated | | **Email Security** | Security of data transfer channels (Art. 9(3)(a)). Reduced risk of unauthorised access and fraud (Art. 9(3)(b)). | Statistics on blocked threats | | **MDR** | 24/7 detection of anomalous activity on endpoints (Art. 10(1)). Enough resources to monitor anomalies and cyberattacks (Art. 10(3)). Fast containment (Art. 11(2)). | Activity reports, alerts handled, response times | | **XDR** | Several layers of control, alert thresholds and automatic alerting (Art. 10(2)), across VPN, firewall and cloud data. | Detection rules and alert history | | **Training** | Mandatory ICT security awareness for all staff (Art. 13(6)). Regular training of the management body (Art. 5(4)). | Completion rates and course certificates | | **Phishing simulation** | Awareness programmes (Art. 13(6)). Learning from observed threats (Art. 13(1)). | Click, submission and reporting rates per campaign, with trends over time | ### 2. ICT incident management and reporting (Chapter III, Articles 17 to 23) | Stoïk service | DORA requirement it helps with | Evidence you can show | | ---------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | | **MDR / XDR** | Detecting and logging incidents (Art. 17(2), 17(3)). Early detection matters because DORA's reporting deadlines start from when the incident is classified. | Alert and incident history | | **Phishing Report button** | A simple way for employees to report suspicious emails, which feeds your incident detection process (Art. 17(3)). | Reported emails and how they were handled | | **Stoïk CERT** (24/7 incident response, included with Stoïk insurance) | Response and recovery (Art. 11). Post-incident review and root-cause analysis (Art. 13(2)). Technical input for major-incident reports (Art. 19(4)): initial notification, intermediate report and final report. | Incident report with timeline, indicators of compromise, root cause and actions taken | ### 3. Digital operational resilience testing (Chapter IV, Articles 24 to 27) DORA requires a testing programme, reviewed at least once a year, that explicitly includes **vulnerability assessments and scans** (Art. 25(1)). * **External Scan, Active Directory Scan and Cloud Scan** give you recurring vulnerability assessments that feed this programme (Art. 24(6), 25(1)). * **Phishing simulations** are a form of scenario-based social-engineering testing (Art. 25(1)). > Threat-led penetration testing (TLPT, Art. 26 and 27) is only mandatory for financial entities designated by their supervisor. Stoïk Protect doesn't provide it. ### 4. ICT third-party risk (Chapter V, Articles 28 to 44) You stay fully responsible for your DORA obligations when you use a cloud provider (Art. 28(1)). **Cloud Scan** helps you control the part of that risk that depends on how *you* configured your environment. It does **not** replace the register of information or the mandatory contract clauses with your ICT providers (Art. 28(3), Art. 30). ### 5. Information sharing (Article 45) This pillar is optional under DORA. Stoïk Protect doesn't cover it directly. ## What stays your responsibility Stoïk Protect gives you tools and evidence. Your organisation remains accountable for the following: * **Governance.** Your management body has final responsibility for ICT risk and must approve the framework (Art. 5(2)). * **Official reporting.** You notify your supervisor of major incidents (Art. 19). The Stoïk CERT helps you prepare the technical content. * **Backups and business continuity.** Your backup, restoration and business continuity or disaster recovery policies, and tests of them (Art. 11, 12). * **ICT provider register and contracts** (Art. 28(3), 30). * **Encryption policy** (Art. 9(4)). * **TLPT**, if your supervisor has designated you (Art. 26, 27). ## Getting started 1. Open **Stoïk Protect** and check which tools are already active for your organisation. 2. Activate the tools that match your gaps. External Scan, Active Directory Scan, Training and Phishing simulation are the fastest wins for DORA evidence. 3. Complete the **NIS2 assessment** in the **Compliance** tab for a structured view of your technical measures. 4. Export the reports from each tool and add them to your DORA documentation. {% hint style="warning" %} This article is general guidance, not legal advice. References are to the EU texts: Regulation (EU) 2022/2554 (DORA) and its delegated regulations (EU) 2024/1774 and (EU) 2025/301. The exact scope of each service depends on your contract. For your specific obligations, ask your compliance officer or your supervisor. {% 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/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.