DORA for Investment Firms: What You Actually Need in Place

DORA — the Digital Operational Resilience Act (Regulation (EU) 2022/2554) — has applied since 17 January 2025. It is not a future problem to plan for; it is a live obligation that AFM and DNB now supervise. Yet many Dutch investment firms still treat it as an IT-security project rather than the cross-firm operational-resilience regime it actually is.

This article is for COOs, compliance officers, and risk leads who need a clear picture of what DORA requires and where firms most often fall short. It is practical, not a recital of the regulation.

Who is in scope?

DORA applies to roughly 20 categories of financial entity, including investment firms, banks, fund managers, payment institutions, and crypto-asset service providers, as well as the ICT third parties that serve them. If you hold a MiFID II authorisation, you are in scope. The question is not whether DORA applies, but how proportionately it applies to a firm of your size and risk profile.

DORA does build in proportionality. A small and non-interconnected investment firm faces a lighter version of some requirements (for example, a simplified ICT risk-management framework). But proportionality is not an exemption — every in-scope firm must address all five pillars below.

The five pillars in practice

1. ICT risk management

You need a documented ICT risk-management framework: identification of critical functions and the systems supporting them, protective and detective controls, and a governance structure where the management body owns ICT risk. The board cannot delegate accountability here. Supervisors expect evidence that management actively reviews and challenges ICT risk, not a policy that sits in a drawer.

2. ICT incident management and reporting

You must classify ICT-related incidents against DORA's criteria and report major incidents to your competent authority on a defined timeline (initial, intermediate, and final notifications). The operational test is whether you can actually detect a major incident, classify it correctly under pressure, and produce the report within the window. Most firms discover the gap during a real incident, which is the worst time to find out.

3. Digital operational resilience testing

All in-scope firms run a testing programme (vulnerability assessments, scenario testing). Larger, significant firms must also perform threat-led penetration testing (TLPT) every three years. For most investment firms TLPT will not apply, but a structured, evidenced testing programme is mandatory regardless of size.

4. ICT third-party risk management

This is where firms underestimate the work. DORA requires you to manage ICT third-party risk across the full lifecycle, embed specific contractual provisions (audit rights, exit strategies, sub-outsourcing controls, incident cooperation), and maintain a register of information on all contractual arrangements for the use of ICT services. The register must be kept current and is reported to supervisors.

5. Information sharing

DORA encourages (but does not mandate) the sharing of cyber-threat intelligence between financial entities. This is the lightest pillar, but having a position on it is part of a complete framework.

What AFM and DNB expect in the Netherlands

Dutch supervisors have folded DORA into their existing supervisory dialogue. In practice that means DORA topics appear in periodic reviews and information requests, and your register of information and incident-reporting capability are the items most likely to be tested. The expectation is demonstrable control, not paperwork: can you show that ICT risk is governed, that you would detect and report a major incident in time, and that your critical providers are contractually and operationally under control?

Where firms most often fall short

1. Treating DORA as an IT project. It is a governance and operational-resilience regime. If compliance and risk are not co-owners alongside IT, you will have gaps.
2. An incomplete register of information. Missing providers, stale data, or no mapping to critical functions.
3. Contracts that pre-date DORA. Legacy ICT contracts often lack the mandatory clauses. Remediation through re-papering takes longer than expected.
4. No tested incident-reporting path. A policy that has never been rehearsed against the classification criteria and timelines.
5. Over- or under-applying proportionality. Assuming you are exempt because you are small, or building a bank-scale framework you cannot maintain.

If DORA sits across your operating model and you want a pragmatic readiness view, our advisory work focuses on exactly this kind of cross-firm implementation. It also connects to your broader investment-firm obligations under MiFID II and IFR/IFD.