DORA sounds like a regulation for banks. But it affects your fund administrator, and that means it affects you. Here is what matters.
The Digital Operational Resilience Act became enforceable across the EU in January 2025. If you are a fund manager reading this and thinking "that is a banking regulation, it does not affect me," you are partially right and importantly wrong.
DORA may not apply directly to your fund. But it almost certainly applies to your fund administrator, your custodian, and other critical service providers in your operational chain. When your administrator's compliance becomes your problem, you need to understand what they should be doing.
What DORA is
DORA is an EU regulation that establishes uniform requirements for the security of network and information systems supporting the business processes of financial entities. In plain language: it requires financial institutions to have robust IT systems, to be able to withstand cyber incidents, and to manage their dependence on third-party technology providers.
The regulation covers five main areas:
ICT risk management frameworks
ICT-related incident reporting
Digital operational resilience testing
Third-party risk management for ICT service providers
Information sharing arrangements
Who it applies to
DORA applies directly to a broad range of financial entities including banks, insurance companies, investment firms, fund managers, and, critically, their ICT third-party service providers. If your fund administrator processes investor data, manages financial records, or operates technology platforms on behalf of regulated funds, they are in scope.
For many emerging managers, the direct application of DORA to their fund depends on their regulatory status and jurisdiction. A sub-threshold AIFM may have reduced obligations. But even if your fund is not directly in scope, your administrator is, and their compliance posture directly affects your operational resilience.
What DORA requires
ICT risk management. A comprehensive framework for identifying, protecting against, detecting, responding to, and recovering from ICT-related incidents. This means documented policies, designated responsibility, regular risk assessments, and tested response procedures.
Incident reporting. Major ICT-related incidents must be reported to the relevant competent authority. This creates accountability and ensures that systemic risks are visible to regulators.
Resilience testing. Regular testing of ICT systems, including, for significant entities, threat-led penetration testing (TLPT). This goes beyond basic vulnerability scanning to simulate real-world attack scenarios.
Third-party risk management. Financial entities must assess and manage the risks arising from their dependence on ICT service providers. This includes contractual arrangements, exit strategies, and concentration risk monitoring.
Technical standards and third-party oversight
The core principles of DORA are straightforward, but the implementation is guided by detailed Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) developed by the European Supervisory Authorities (ESAs). These standards cover everything from the content of incident reports to the specifics of contractual arrangements with ICT providers [1]. For fund managers, this means your administrator's compliance requires adhering to a complex and evolving set of technical requirements. DORA now subjects "critical" ICT third-party providers (CTPPs) to direct supervision by the ESAs. This brings major technology suppliers under the direct scrutiny of financial regulators for the first time [2].
Why smaller funds should care
The concern for smaller fund managers is not direct regulatory compliance but operational exposure. If your fund administrator suffers a cyber incident that disrupts their ability to process capital calls, produce reports, or maintain investor records, that is your problem. Your LPs do not care whether the failure was at your end or your administrator's end. They care that their capital call was late or their report was wrong.
How your administrator's compliance becomes your own
DORA's focus on third-party risk management means your fund administrator will impose stricter contractual obligations on their own suppliers. This creates a ripple effect throughout the financial technology supply chain. Expect changes in service level agreements, increased costs, and more due diligence requirements on fund managers. Your administrator may need to demonstrate a viable exit strategy if a critical technology provider fails, and they may pass on some of the costs of this additional resilience to their clients. DORA changes the lines of responsibility between fund managers, administrators, and technology providers [3].
The DORA conversation gets bogged down in whether it applies to you. The real story is the ripple. Once your administrator is on the hook, your contract changes, your fees move, and your exit options narrow. Worry less about the rulebook and more about what your administrator just signed with their cloud provider.
What to ask your fund administrator
Five questions that will tell you a lot about your administrator's DORA readiness.
Do you have a documented ICT risk management framework?
What is your incident response procedure and what are your recovery time objectives?
When was your last penetration test and what were the findings?
How do you manage your own third-party ICT providers?
What certifications do you hold (ISO 27001, SOC 2)?
How we handle this
We built Infra One's infrastructure with operational resilience as a design principle, not a compliance afterthought.
Encrypted data at rest and in transit
Multi-factor authentication
Regular penetration testing
Documented incident response procedures
A risk management framework aligned with DORA's requirements
Because our platform is built on modern cloud infrastructure, we can implement and demonstrate security controls that legacy systems struggle to match.
