DORA applies to investment firms. If your firm holds a MiFID II licence — whether you are an investment manager, broker-dealer, wealth manager, trading firm, or multi-family office with a regulated entity — you are in scope for EU Regulation 2022/2554, which has been enforceable since 17 January 2025.
Most DORA commentary focuses on large banks and insurers. Investment firms, including those operating at scale with complex technology infrastructure, have received comparatively little sector-specific guidance. This guide fills that gap.
Are Investment Firms in Scope for DORA?
Yes. DORA Article 2(1)(b) explicitly includes investment firms as defined in Article 4(1)(1) of Directive 2014/65/EU (MiFID II). The regulation applies regardless of whether your investment firm is a small Class 3 firm under IFR/IFD or a large systemic entity approaching bank-equivalent scale.
There is a proportionality mechanism in Article 4 that allows NCAs to calibrate how intensively certain requirements apply based on size and risk profile. But the core obligations — ICT governance, incident reporting, third-party oversight, and the Register of Information — apply to all in-scope investment firms.
The relevant supervisor for DORA enforcement is the same NCA that supervises your MiFID II authorisation, typically the national financial markets regulator. In most EU jurisdictions this will be the securities regulator: AMF in France, BaFin in Germany, AFM in the Netherlands, FI in Sweden, and so on. At EU level, ESMA has a coordinating role particularly in relation to significant investment firms and CTPPs.
What DORA Requires from Investment Firms
Pillar 1: ICT Governance
Article 5 places ICT risk management responsibility squarely on the management body. For investment firms, that means the board of directors or equivalent governing body — not the CTO or CISO acting alone. The management body must approve the ICT risk strategy and be able to demonstrate active engagement with ICT risk.
For many investment firms, particularly smaller and mid-sized managers, this represents a meaningful governance change. ICT risk has often been treated as an operational matter handled below board level. DORA requires it to be a board-level agenda item with documented decisions and oversight.
Practically, you need:
- A board-approved ICT risk strategy (or equivalent management body resolution)
- A documented ICT risk appetite statement
- A named function or senior individual responsible for ICT risk management
- Evidence of board-level ICT risk discussions in meeting minutes
- Relevant training completed by the management body and ICT staff
Pillar 2: ICT Risk Management
Investment firms operate a range of ICT systems depending on their business model: order management systems (OMS), execution management systems (EMS), portfolio management systems (PMS), risk analytics platforms, data feeds, algorithmic trading infrastructure, client reporting systems, and custodian/prime broker connectivity.
DORA's starting point is Article 8: a comprehensive register of ICT assets and the business processes they support. You need to identify which of your functions qualify as Critical or Important Functions (CIFs) under DORA's definition — functions whose disruption would materially affect your ability to operate or would harm clients.
For most investment firms, portfolio management, order execution, and client reporting are likely CIFs. Trade settlement connectivity and risk management systems often qualify too. The CIF identification exercise needs management body approval and forms the basis for everything downstream: risk assessments, business continuity planning, recovery targets, and testing scope.
Article 11 requires business continuity plans with defined recovery time objectives (RTOs) and recovery point objectives (RPOs) for each CIF. Critically, those targets need to be tested — not just documented. If your BCP states you can recover your OMS within 4 hours, that claim should be supported by actual restoration test results.
Pillar 3: ICT Incident Management and Reporting
DORA's incident reporting requirements are operationally demanding and apply to investment firms in the same way they apply to banks. Article 19 sets out a three-stage reporting timeline for major ICT incidents:
- Initial notification to your NCA: within 4 hours of classifying the incident as major (and no later than 24 hours after first becoming aware)
- Interim report: within 72 hours of the initial notification
- Final report: within one month of the interim report
What makes an incident 'major' is defined in Article 18 and supporting RTS. The criteria include the number of clients affected, duration of service disruption, financial losses, reputational impact, and geographical spread. An extended outage of your OMS during trading hours, preventing client orders from being placed or executed, could trigger multiple thresholds simultaneously.
For trading firms and market makers, an ICT failure during volatile market conditions is particularly high-risk from a DORA reporting perspective. You need a classification process and reporting templates in place before an incident occurs — the 4-hour clock starts running when you first classify the incident as major, not when you finish your incident report.
Assign clear ownership: who has authority to declare a major incident, who is responsible for filing each of the three reports, and what templates and contact details for your NCA are maintained and accessible during an incident.
Pillar 4: Digital Resilience Testing
All investment firms must conduct digital resilience testing under Articles 24-27. For most investment firms this means:
- Annual vulnerability assessments across systems supporting CIFs
- Penetration testing on critical systems at least annually
- Remediation of identified vulnerabilities tracked to closure
- Test results reported to the management body and used to update the ICT risk framework
Threat-led penetration testing (TLPT) is required every three years for entities that are classified as significant under Article 24(1). Most investment firms will not be in scope for TLPT unless they are large, systemically important, or explicitly designated by their NCA. Check your NCA's published guidance or seek confirmation if you are uncertain.
One important point: test results that sit in a report without triggering updates to your risk assessments or continuity plans do not satisfy DORA. Article 27 explicitly requires findings to feed back into the ICT risk management framework.
Pillar 5: Third-Party ICT Risk Management
This is one of the most operationally intensive areas for investment firms, because the industry is heavily dependent on third-party ICT services. Bloomberg and Refinitiv/LSEG for data, custodians for settlement connectivity, prime brokers for financing and execution, SaaS providers for OMS/EMS/PMS platforms, cloud infrastructure for compute and storage — these are all ICT third-party arrangements in scope for DORA.
The Register of Information (RoI) is the most concrete near-term deliverable. EBA ITS 2024/2956 specifies the required format in detail — every ICT third-party arrangement must be documented with a standardised set of fields. The first submission deadline was 30 April 2025. If your firm has not yet submitted or submitted an incomplete RoI, this is your most urgent compliance gap.
Contractual requirements under Article 30 are also likely to require a systematic review of provider agreements. Contracts predating DORA will frequently be missing required clauses: audit rights, service level commitments with specific metrics, data location provisions, provisions for regulatory access, and termination and exit rights. Agreements with providers supporting CIFs need to be updated as a priority — which in practice means negotiating with Bloomberg, your custodian, your prime broker, and your OMS provider.
Exit plans are required for each provider supporting a CIF. For investment firms, this is not a straightforward exercise — the market for some specialist services (particularly data) is concentrated, and genuine alternatives may be limited. The exit plan needs to address this honestly, including the timeline and cost of migration, rather than describing an exit that is not operationally realistic.
How DORA Interacts with Existing MiFID II Requirements
MiFID II already imposes operational resilience requirements on investment firms, including requirements around business continuity, outsourcing governance, and incident management. DORA layers additional specificity onto those existing obligations.
In several areas there is meaningful overlap. MiFID II outsourcing requirements (Article 16(5) and Articles 30-31 of the MiFID II Delegated Regulation) already require due diligence, contractual protections, and monitoring of outsourced functions. DORA's Article 30 requirements are more prescriptive, but the underlying governance approach should be consistent.
The key practical difference is that DORA introduces a Register of Information with a standardised format, a specific submission requirement to your NCA, and an annual review obligation. MiFID II's outsourcing register requirements did not previously require submission to the regulator in a standardised format. This is a new administrative obligation even for firms with mature outsourcing governance frameworks.
Where the two regimes diverge most sharply is in incident reporting. MiFID II did not include the specific 4-hour/72-hour/one-month reporting timeline that DORA introduces. Investment firms that had informal incident reporting practices will need to formalise them to meet DORA's requirements.
Practical Priorities for Investment Firm Compliance Teams
If you are building or reviewing your DORA compliance programme, work through these in order:
1. Register of Information. If you have not submitted your RoI in the EBA ITS 2024/2956 format, this is the most visible gap. Complete and submit it. If you submitted an incomplete version, review and update it. 2. CIF identification. Everything downstream depends on knowing which functions are Critical or Important. Document them, get management body approval, and make sure the CIF list reflects your actual business rather than a generic template. 3. Incident classification and reporting process. Build and test your classification policy against the Article 18 criteria. Prepare three-stage report templates. Assign escalation ownership. Test the process before you need it. 4. Third-party contract review. Audit your key ICT provider contracts against the Article 30 checklist. Prioritise providers that support CIFs. Engage your legal team and providers early — contract renegotiations with major data or infrastructure vendors take time. 5. Management body governance. Ensure your board or equivalent has formally approved your ICT risk strategy. Document ICT risk as a standing board agenda item. Check that relevant training for the board and ICT staff has been completed.For a structured overview of all five pillars, the DORA compliance checklist sets out specific items to verify across each requirement. The free DORA gap analysis will score your readiness in about three minutes with a pillar-by-pillar breakdown. For the third-party risk management obligations specifically, the DORA third-party risk guide covers the Register of Information, Article 30 contracts, and exit planning in detail.