DORA Compliance for Fund Managers: The ICT Risk Framework You Can’t Ignore

The Digital Operational Resilience Act — DORA, formally Regulation (EU) 2022/2554 — has applied since 17 January 2025. Supervisory expectations are live. Enforcement is real. And fund managers are squarely in scope.

Are Fund Managers in Scope?

Yes. Article 2(1) of DORA explicitly includes management companies (point (f), under Directive 2009/65/EC) and alternative investment fund managers (point (g), under Directive 2011/61/EU). There is no size threshold, no proportionality exemption for smaller managers, and no grace period.

The proportionality principle does appear in DORA (Article 4), allowing implementation proportionate to size and risk profile. But proportionality means "implement appropriately," not "do not implement." A boutique AIFM with three funds and twelve employees still needs a documented ICT risk management framework. The framework can be simpler than that of a global asset manager, but it must exist, be approved by the management body, and be tested.

The 5 Pillars of DORA

Pillar 1: ICT Risk Management Framework (Articles 5-16)

The management body bears ultimate responsibility for ICT risk management under Article 5(2) — this is a board responsibility, not a compliance function task. Directors who delegate ICT risk entirely to an IT department or outsourced provider are not meeting DORA's governance standard.

Fund managers must establish a documented ICT risk management policy (Article 6) covering identification, protection, detection, response, and recovery, reviewed at least annually and updated after significant ICT incidents. Article 9 specifies requirements for protection and prevention measures, including network segmentation, encryption, and access management. Article 10 requires detection mechanisms for anomalous activities.

Articles 11 and 12 require ICT business continuity and disaster recovery plans with defined RTOs and RPOs for critical functions — NAV calculation, order processing, investor reporting — tested annually. Article 13 mandates post-incident reviews and integration of lessons learned, creating a continuous improvement obligation.

Pillar 2: ICT-Related Incident Reporting (Articles 17-23)

Article 18 requires incident classification based on criteria including the number of clients affected, the duration, geographical spread, data losses, the criticality of services affected, and the economic impact. The RTS on classification provides quantitative thresholds that fund managers must map against their operations.

Major incidents must be reported to the competent authority (AFM, BaFin, CSSF, etc.) on a strict timeline: an initial notification within 4 hours of classification as major (or no later than 24 hours after detection), an intermediate report within 72 hours, and a final report within one month. These timelines demand that incident response procedures, classification criteria, escalation paths, and reporting templates are prepared before an incident occurs.

Pillar 3: Digital Operational Resilience Testing (Articles 24-27)

All in-scope entities must conduct basic testing: vulnerability assessments, penetration testing, network security reviews, scenario-based testing, and source code reviews where feasible. Threat-led penetration testing (TLPT) under Article 26 applies only to entities identified by competent authorities based on systemic importance — most fund managers will not face this requirement initially, but larger managers should prepare.

Pillar 4: ICT Third-Party Risk Management (Articles 28-44)

This pillar has the greatest operational impact. Modern fund management depends heavily on third-party ICT: portfolio management systems, order management systems, fund accounting platforms, transfer agent systems, data feeds, cloud infrastructure, and cybersecurity tools.

Article 30 mandates specific contractual provisions with ICT providers: clear SLA descriptions, data processing locations, provisions on availability and data integrity, guaranteed access and audit rights for the fund manager and its competent authority, termination rights with adequate transition periods, and the provider's obligation to cooperate during ICT incidents. Many existing vendor contracts will not meet these requirements.

Article 28(3) requires a register of all ICT third-party arrangements in the format specified by the ITS, available to supervisors upon request. Fund managers must also assess ICT concentration risk — if your portfolio management system, fund accounting, and transfer agency all run on the same cloud provider, DORA requires you to assess and manage that concentration.

Pillar 5: Information Sharing (Article 45)

DORA encourages (but does not mandate) sharing cyber threat intelligence — indicators of compromise, TTPs, cybersecurity alerts — within trusted communities such as ISACs or trade associations.

Tokenization-Specific Considerations

Smart Contracts as ICT Systems

If a fund uses smart contracts for operational functions — automated distributions, token-based redemptions, DLT-based NAV publication — those are ICT systems under DORA. They must be covered by the risk management framework, tested for vulnerabilities, and subject to business continuity planning.

Blockchain as Third-Party ICT Provider

If a fund uses a public blockchain as settlement infrastructure, is the network an "ICT third-party service provider"? The decentralised nature makes Article 30's contractual requirements practically impossible to fulfil. ESMA has not provided definitive guidance, but fund managers should document their analysis. Where third-party node operators (Alchemy, Infura) are used, those relationships fall clearly within DORA's third-party framework.

Critical RTS/ITS from the ESAs

Fund managers should review these technical standards alongside the Level 1 text: RTS on the ICT risk management framework, RTS on classification of major incidents, RTS on ICT third-party governance, ITS on the register of information (standardising the Article 28(3) format), and RTS on threat-led penetration testing methodology.

What Fund Managers Need to Do

1. ICT risk management policy — documented, board-approved, reviewed annually
2. Business continuity plan — ICT-specific scenarios, tested annually with documented results
3. Incident response procedures — pre-defined classification criteria, escalation paths, reporting templates
4. Third-party register — complete inventory of ICT providers in the ITS-prescribed format. The five-template structure and submission rules are covered in detail in our DORA register of information walk-through
5. Testing programme — risk-based annual programme covering vulnerability assessments and penetration testing
6. Contractual remediation — review existing ICT contracts against Article 30 requirements

Related DORA Guides

• DORA compliance checklist — interactive self-assessment across all five DORA pillars
• DORA vs NIS2 — which cybersecurity framework applies to your fund? Side-by-side comparison
• DORA ICT third-party register — how to build and submit the Article 28 register
• DORA incident reporting timeline — 4-hour initial notification and the three-stage reporting process
• DORA incident classification — criteria for classifying major ICT-related incidents

How financialregulations.eu Helps

Query our knowledge base for a DORA compliance checklist tailored to your firm — whether a boutique AIFM or a large UCITS management company. Argus contains the full DORA regulation, all published RTS and ITS, and relevant ESMA guidance, structured for retrieval and analysis.

---

Try financialregulations.eu — start with 5 free regulatory queries. No credit card required.

Start Analysing — Free →