DORA
ICT risk, resilience testing, and incident reporting for EU financial entities

DORA in context: a single resilience regime across EU financial services

The Digital Operational Resilience Act (Regulation EU 2022/2554) entered into force in January 2023 and has applied since 17 January 2025. It consolidates the operational resilience expectations of banks, insurers, investment firms, payment institutions, crypto-asset service providers, and their critical ICT third parties into one regulation with directly applicable rules. DORA replaces the patchwork of guidance previously issued by the European Supervisory Authorities (EBA, EIOPA, and ESMA) and is supported by a set of regulatory technical standards (RTS) and implementing technical standards (ITS) that spell out the detail.

The regulation sits across five operating pillars: ICT risk management, ICT-related incident management and reporting, digital operational resilience testing, ICT third-party risk management, and information sharing arrangements. DORA assumes proportionality, so the depth of testing, the reporting cadence, and the inclusion in TLPT scale with the size and systemic relevance of the entity, but every entity in scope owns the same five pillars. For matters DORA covers, DORA is the lex specialis for financial entities; outside those matters the wider NIS2 Directive still applies, which is why most groups end up running both frameworks against a single evidence pack.

Who is in scope, and where third parties sit

The scope is wide. DORA applies directly to financial entities and indirectly to the ICT third parties they rely on. Critical ICT third-party service providers can also be brought under direct oversight by the European Supervisory Authorities, which means cloud platforms, managed service providers, and software vendors supporting critical functions face their own assessments and audits.

Pillar 1: building an ICT risk management framework that holds up

Articles 5 to 16 set the bar for the ICT risk management framework. The supervisor expects a documented framework approved at board level, an asset register that maps systems and data to the business services they support, and a treatment plan for every identified risk. The framework is reviewed at least annually and after every major incident, with traceable updates feeding back into governance.

Pillar 2: classifying and reporting ICT-related incidents

Articles 17 to 23 require every financial entity to detect, log, classify, and report major ICT-related incidents to the competent authority. The DORA RTS on classification sets the criteria, and entities must apply them consistently with documented evidence. A well-run incident workflow links the technical detection record to the impact assessment, the supervisor reports, and the remediation backlog so the same data tells the same story across all of those audiences.

The reporting clock: initial, intermediate, and final

Once an incident is classified as major, the entity must follow the supervisor template and timeline for initial, intermediate, and final reports. A clean workflow keeps the classification, the report drafts, and the post-incident actions linked together so nothing has to be reassembled at the deadline.

For the operational side of incident management beyond DORA reporting, the incident response workflow covers triage, containment, recovery, and post-incident reporting in the same platform so the technical record and the supervisor record stay in sync.

Pillar 3: digital operational resilience testing as a programme

Articles 24 to 27 frame testing as a continuous programme rather than a single annual engagement. Vulnerability assessments, scenario tests, penetration tests, and source code reviews are all required where they are proportionate to the entity. The supervisor expects a documented test plan, defensible scoping, evidence per test, and a remediation track that closes findings on a documented timeline.

The penetration testing workflow and the vulnerability assessment workflow are designed for this kind of programme: scope, log findings against assets, track remediation against deadlines, and re-test before closure.

TLPT: threat-led penetration testing aligned to TIBER-EU

Threat-led penetration testing is the most demanding part of the DORA testing regime. In scope entities run TLPT at least every three years, on live production systems supporting critical or important functions, with bespoke threat intelligence, a controlled red team, and a joint replay with the blue team. The TIBER-EU framework provides the methodology the European Central Bank and national competent authorities use to standardise the work, and the DORA regulatory technical standards on TLPT explicitly reference TIBER-EU as the reference framework.

Tagging every TLPT finding by tactic and technique tightens the report and the replay conversation. The MITRE ATT&CK framework page covers how to tag findings end-to-end, the threat-led penetration testing workflow covers the end-to-end TLPT cycle (scoping, threat intelligence, red team, replay, joint attestation) on a single engagement record, and the red teaming workflow keeps the timeline, attack paths, and operator notes structured rather than buried in chat history.

Pillar 4: ICT third-party risk and the contractual register

Articles 28 to 44 require every financial entity to maintain a register of ICT third-party arrangements and to manage concentration risk, exit strategies, and sub-outsourcing. The register is reported to the competent authority and underpins the oversight of critical ICT third-party providers. Treat the register as a live record rather than an annual export, with assessments, incidents, and remediation linked to the provider entry they affect.

Evidence the supervisor (and your board) actually want

Resilience programmes that fail review usually fail because the artifacts are scattered across drives, ticket systems, and screenshots. Build the evidence pack as the work happens, retain raw scanner output and test reports alongside the summary, and tie every artefact back to an article, an asset, and an owner. The supervisor narrative writes itself when the underlying record is consistent.

Where SecPortal fits in the DORA workflow

SecPortal is the operating layer for the resilience programme, not a replacement for the board, the competent authority, or the testers. The platform handles scope, scans, findings, control mapping, incident records, the third-party register, and the assessor-ready output, so the work runs as a structured workflow rather than a long email thread. Compliance tracking covers DORA alongside the other frameworks the same firm has to satisfy, including ISO 27001, SOC 2, NIST 800-53, NIS2, the SWIFT Customer Security Programme for the SWIFT-related infrastructure that most in-scope financial entities also operate, and the EU Cyber Resilience Act for the products with digital elements that financial entities procure and rely on under the third-party risk regime.

DORA is a multi-year programme, not a one-off project. The first year of application focuses on the framework, the register, and the testing programme baseline. Subsequent years tighten the evidence trail, expand TLPT coverage where firms grow into scope, and deepen the integration between supplier oversight and incident management. Running the work as a managed workflow pays off most over time: historical findings, classified incidents, supplier records, and remediation timelines stay linked, so each supervisory review is a refresh rather than a rebuild. For consultants delivering DORA work to multiple clients, the security consultants workspace bundles that with branded client portals and AI report generation, so the deliverable looks as polished as the work behind it.

For programmes that want continuous detection and trend evidence between manual tests, the continuous monitoring capability and external scanning capability produce the cadence and coverage record DORA testing programmes are expected to keep.