DORA — the Digital Operational Resilience Act — became fully applicable on 17 January 2025 across every financial entity in the European Union. If you are a bank, an investment firm, an insurance undertaking, a payment institution, an electronic-money institution, a CCP, a CSD, a trading venue, or a critical ICT provider to any of those, you are inside the scope.
The text is dense and the supporting RTS / ITS even denser. This article is a field guide for the ICT and security leader, not the legal counsel. We assume you have read DORA at least once. We focus on what changes operationally and what your first ESMA / EBA / EIOPA review will probe.
What January 2025 actually changed
Three substantive shifts inside the security operating model:
- ICT risk became a board-level decision item with documented review at least annually. The DORA risk-management framework is not optional and not the CISO's file; the management body must approve it.
- Resilience testing graduated from "we run pentests" to a structured programme. Significant entities must perform threat-led penetration testing (TLPT) at least every three years, with scope and scenarios approved by the regulator.
- Incident reporting consolidated. The previous patchwork of EBA / ESMA / EIOPA incident-reporting templates collapses into the DORA Article 17 process, with classification thresholds and a common reporting timeline.
Article 9 — the ICT risk management framework, in practice
Article 9 demands "a sound, comprehensive and well-documented ICT risk management framework." In practice, the regulator probes for:
- A documented framework explicitly approved by the management body, with a review schedule.
- An ICT-asset inventory linked to business processes, with criticality scoring. The scoring methodology must be documented; "essential / important / non-critical" without rationale is rejected.
- A continuous identification of ICT risks, with documented risk treatment plans and residual risk acceptance.
- Detection capability tested at least annually, with documented metrics (MTTD, MTTR, false-positive rate).
- Protection and prevention measures proportionate to the risk profile, documented, and reviewed.
- Recovery objectives — RTO and RPO — documented per critical service, tested at least annually.
The single biggest gap we see in early DORA inspections: an ICT risk register that is not linked to the business-process catalogue. It is the link that makes the prioritisation defensible.
TLPT — the test that everyone is anxious about
Threat-Led Penetration Testing is the DORA Article 25 obligation that gets the most hallway conversation. The substance:
- Mandatory for "significant" financial entities — the threshold is set in the RTS and is essentially "you are systemic for the EU financial system" or you operate in a critical cluster.
- Run at least once every three years, with scope set jointly with the regulator and based on a threat-intelligence-led targeting phase.
- Methodology aligned with the European Central Bank TIBER-EU framework. If you have run a TIBER engagement, you have run a TLPT.
- Conducted by external testers approved by the regulator, with an independent threat-intelligence provider feeding the targeting phase.
- Results submitted to the regulator, with a remediation plan and timeline.
A TLPT is not a souped-up red team. It is a regulatory exercise that happens to be a red team. The deliverables, the regulator interface and the documentation expectations are different from the exercise the security team has been buying for years.
Article 17 incident reporting — the new common process
Major ICT-related incident reporting consolidates into a single Article 17 process. The classification thresholds matter:
- Number of clients affected.
- Number of transactions affected, in volume and in value.
- Reputational impact.
- Duration of the disruption.
- Geographical spread (cross-border activation triggers regulator-to-regulator notification).
- Data losses (linkage with GDPR Article 33 obligations).
You must document the classification logic in your IR policy. The regulator will read it and probe whether the thresholds were applied consistently across recent incidents.
Article 28 — third-party risk
Article 28 makes the financial entity responsible for the security of its critical ICT third parties. Two operational changes:
- A register of contractual arrangements with all ICT third parties, with the critical ones flagged. The register is provided to the regulator on request.
- Pre-contract due diligence and ongoing assessment of critical providers — the obligations cannot be discharged by accepting the provider's SOC 2 Type II report.
What the first review will look at
For the entities we have supported through their first DORA-era review:
- The DORA framework document, signed off by the management body.
- The asset and business-process linkage; the risk register that flows from it.
- The TLPT scope agreement and the test report (if scheduled).
- A sample of incidents from the past 12 months and the application of Article 17 thresholds.
- The third-party register and the most recent assessment of the top-three critical providers.
- KPIs: MTTD, MTTR, RTO/RPO actuals vs. targets, vulnerability remediation SLA adherence.
Where Sandline fits
We run TLPT exercises with TIBER-EU-aligned methodology, vulnerability programmes that produce Article 9 evidence, and IR retainers wired to Article 17 templates. We are not your law firm and we will not write your DORA framework document; we will execute the technical work and produce the evidence package the regulator wants to see.