Does DORA apply to our AIFM or UCITS management company?
DORA applies to alternative investment fund managers and UCITS management companies through the amended AIFMD and UCITS rules: Directive (EU) 2022/2556 replaces Article 18 of the AIFMD so that an AIFM's electronic data processing and network systems must comply with DORA, and it requires UCITS management companies' systems to be set up and operated in accordance with DORA. The one carve-out you are most likely to test is the small AIFM exclusion in Article 2(3), which removes small alternative investment fund managers under Article 3(2) of the AIFMD from scope. Whether your firm qualifies is a question of your authorization status and thresholds under the AIFMD, so confirm it against your current authorization file and your competent authority's position before you tell an investor or depositary that DORA does not reach you.
The answer is not the same for every manager. Article 4(1) requires Chapter II (ICT risk management) to be applied in line with proportionality, taking into account size, overall risk profile, and the nature, scale and complexity of the services and activities you run. In practice, a manager that delegates portfolio management, runs a small range of funds with a simple service model, or relies mostly on one hosted fund administration platform will normally have a lighter set of obligations than a multi-strategy manager operating its own trading and reporting infrastructure. Proportionality changes how much you must do and how deep the documentation goes. It does not switch the regulation off for a manager that is in scope, and your organization owns its controls, so the decision about how far proportionality reaches belongs to the board and its risk function.
Full application and proportionate application differ in the evidence an assessor or competent authority will ask for. Ask your compliance lead to record, in writing, which DORA obligations apply in full, which are applied proportionately, and why. Then check how that position fits the register of information under Article 28(3), which covers every ICT contractual arrangement and flags those that support critical or important functions. An implementation partner such as DeployOpen can prepare systems, controls and evidence for that position, but it does not judge whether your scope or proportionality choice is correct. That judgment sits with your competent authority, and any independent audit you commission is issued by the auditor, not by DeployOpen.
Which fund manager entities fall inside DORA scope
DORA reaches fund managers through two routes: Article 2(1) lists alternative investment fund managers as a type of financial entity, and Directive (EU) 2022/2556 amends the AIFMD and UCITS rules so that the ICT systems of these managers must meet DORA. Each card covers one entity type or check that determines whether a given manager is in scope.
AIFMs in general
Alternative investment fund managers fall within the Article 2(1) list of financial entities, so the DORA obligations apply to their electronic data processing and network systems as a whole. Scope is decided by the AIFM's authorization status, not by the size of the fund range it runs alone. Confirm that your authorization covers the activities you actually perform, including delegated portfolio or risk management, because those arrangements determine which ICT services you must govern under Chapter V.
UCITS management companies
Directive (EU) 2022/2556 requires UCITS management companies to set up and operate their electronic data processing and network systems in accordance with DORA. This brings UCITS managers into the regime through the sectoral directive rather than through the Article 2(1) list. Map your ICT estate, including the systems that run fund accounting, order routing and investor reporting, against DORA's requirements, and check how the UCITS amendment interacts with your management company's authorization.
Small AIFMs under the AIFMD exemption
Article 2(3) of DORA excludes small alternative investment fund managers as defined in Article 3(2) of the AIFMD. A manager that qualifies for this exemption is outside DORA's scope on the basis of its size and authorization regime. Because the exemption depends on the thresholds and conditions in the AIFMD, do not assume that a manager is small simply because its fund is small. Recheck the position whenever assets under management, fund count or authorization changes.
Confirm status with the national authority
A manager that believes it is excluded should confirm that position with its national competent authority, not rely on its own reading alone. The authority that supervises your authorization is the one to ask, and the answer should be recorded in your compliance file with the date and the basis for it. Ask for the confirmation in writing before you rely on the exclusion for planning or budgeting, since it determines whether a register of information and the full ICT risk framework are needed.
Neighboring entities in group structures
Article 2(1) lists the other financial entity types, including management companies, data reporting service providers, insurers and crowdfunding providers. Group structures often place several of these under one roof, and a fund manager may share ICT systems with a management company or insurer in the same group. Check each entity against the list, because a single shared platform can bring a neighboring entity into scope and change the obligations that apply to the whole group.
What the AIFMD and UCITS amendments change
The amendments mean that the electronic data processing and network systems a fund manager runs are now subject to DORA's ICT requirements in their own right. For alternative investment fund managers, Article 3 of Directive (EU) 2022/2556 replaces Article 18 of the AIFMD so that these systems must comply with DORA. For UCITS management companies, Article 1 of the same directive requires their systems to be set up and operated in accordance with DORA. In practice, the question shifts from whether the manager has a general operational risk process to whether the systems behind the funds (portfolio management, order and trade processing, risk reporting, investor administration, and the network connecting them) can be shown to meet DORA's ICT risk management and third-party rules. The core obligation is the same for both fund types, even though each reaches it through a different legal text.
Practically, a manager should start by listing every system that processes fund data or connects to a market, administrator, depositary or cloud provider, then mapping each one to the DORA component that governs it. Confirm with your national competent authority how it expects the AIFMD and UCITS amendments to be evidenced, since supervisory practice and reporting expectations can differ across member states. Ask whether any system you rely on is operated by a delegate or group entity, because those arrangements feed into the register of information and the third-party rules that follow from it. Where a manager uses self-hosted open-source platforms, the systems are still the manager's responsibility under the amended provisions, so the documentation of configuration, change control and ownership must sit with the manager.
Because the amendments attach DORA to the systems rather than to a separate fund-level filing, the work is largely internal and recurring. Budget for the inventory, the gap review against DORA's ICT risk management framework, and the upkeep of that evidence as systems change. Any external help should be scoped in writing to prepare systems, configurations and records, while the manager keeps ownership of its controls. Only an independent assessor or the competent authority can confirm compliance.
Building the register of information step by step
This sequence turns the contractual estate of an AIFM or UCITS management company into a register of information under Article 28(3) that is complete, flagged for critical or important functions, consolidated across entity and group levels, and ready for submission in the format set by Implementing Regulation (EU) 2024/2956.
Confirm the entity scope and reporting levels
Start by confirming which legal entities the register must cover: the AIFM or UCITS management company itself, any sub-consolidated or consolidated group level that applies, and whether the entity falls under the small AIFM exclusion, which removes it from DORA altogether. The compliance lead and legal counsel should record the decision in writing. The output is a scope memo that names each entity and level, so the inventory has a defined boundary before any data is collected.
Inventory every contractual arrangement for ICT services
Collect every contract, order form, licence, framework agreement and intra-group arrangement under which an ICT third-party service provider supplies ICT services. Include cloud hosting, SaaS, managed service providers, data services and support contracts for self-hosted open-source components where a third party provides maintenance, hosting or support. Procurement, IT operations and the business owners of each system should jointly sign off the list. The output is a raw contract inventory with a named owner for each line.
Map each arrangement to the ICT services it supports
For each contract, identify the specific ICT service, the system or process it supports, the provider and any subcontractors that the provider relies on. Self-hosted open-source platforms deserve the same treatment when a third party supplies consulting, integration, hosting or support, because that third party is an ICT provider for register purposes. The output is a service-level map that links every contract to a system and a provider, with gaps logged for follow-up.
Flag arrangements supporting critical or important functions
Assess each mapped arrangement against the entity's own criteria for critical or important functions, documented in its ICT risk and third-party policies, and mark those that support them. The flag matters because Article 28(3) requires the register to distinguish these arrangements. The risk function and the management body should review the flagged list and minute their approval. The output is a classified inventory in which each arrangement carries a critical or important flag and a documented rationale.
Populate the register fields required by the implementing regulation
Enter each arrangement into the register using the structure and data fields set by Implementing Regulation (EU) 2024/2956, which specifies the information the register must hold. Check the current ESAs FAQ on reporting of registers of information before finalizing the template, since it clarifies how fields are completed. The output is a populated register at entity level, with a data quality check that confirms every mandatory field has a value or a documented reason for its absence.
Consolidate the register across entity and group levels
Where a group reporting level applies, combine entity registers into sub-consolidated or consolidated views, removing duplicate provider records and reconciling inconsistent classifications between entities. Confirm with the group compliance function which level is submitted to the competent authority. The output is a consolidated register and a reconciliation log that explains every change made between the entity and group versions.
Validate and approve the register before submission
Run a second-line or internal audit review of the register against the contract inventory, testing a sample of entries back to the signed contract and confirming the critical or important flags. Ask the management body or its delegated committee to approve the register, and record that approval. Confirm the submission format and channel with the competent authority, since the ESAs FAQ and the implementing regulation govern the format. The output is an approved, version-controlled register with a validation record.
Maintain and update the register over time
Establish a change process that updates the register whenever an ICT contract is signed, renewed, materially changed or terminated, and whenever a critical or important classification changes. Assign an owner and link the process to procurement and onboarding so changes are not missed. The output is a documented maintenance procedure and an update log, which evidences that the register stays current between submissions.
What DORA readiness costs and who gets paid
This table sets out each cost component of DORA readiness for an AIFM or UCITS management company, who is paid for it, whether it is one-time or recurring, and what drives it up. No prices are published here, and every figure comes from a written, scoped quote. Use the table to build your own cost model and to ask each provider the right questions.
| Cost component | Who is paid or who carries it | One-time or recurring | Main cost drivers |
|---|---|---|---|
| Internal staff time for the ICT risk framework and register | Your own staff (ICT, risk, compliance, operations) | Both: one-time build, then recurring upkeep | Number of ICT services in use, state of existing asset and contract records, number of delegated functions |
| Register of information build and maintenance | Your staff, with optional support from an implementation partner | Recurring, with a one-time build | Count of ICT third-party contracts, subcontracting chains, and how many support critical or important functions |
| External implementation partner for systems and evidence | Implementation partner, paid under a written fixed scope | One-time for the initial scope, with optional recurring retainers | Number of self-hosted platforms in scope, integration complexity, hardening and documentation depth |
| Legal and governance support | External counsel or consultants for contracts, policies and board materials | Mostly one-time, with periodic review | Volume of existing outsourcing agreements, AIFMD and UCITS amendments to reflect, management body approval cycles |
| Tooling and licences | Software vendors and cloud or hosting providers | Recurring subscriptions, plus any one-time setup | Logging and monitoring volume, number of users, whether tools are open source or commercial |
| Testing and assurance support | Security testing providers and independent assessors where you engage them | Recurring testing cycle, with one-time initial testing | Scope of testing, depth of ICT provider involvement, remediation volume |
| Competent authority supervision | National competent authority for your entity type, under its own fee rules | Recurring if a fee applies | Set by the authority, not published here. Confirm the applicable fee and reporting obligations with your regulator |
| Independent audit or review | Your internal audit function or an external auditor you appoint | Recurring, usually annual | Entity size, internal audit scope, number of ICT systems reviewed |
Who owns DORA controls and who prepares the evidence
Under DORA, the AIFM or UCITS management company remains responsible for its digital operational resilience. The management body approves the ICT risk management framework, carries final accountability for it, and takes the decisions that cannot be delegated away: risk appetite, the critical or important function classification, which ICT third-party arrangements to enter, and how major incidents are handled and reported. Staff who run systems day to day still answer to these decisions.
- Management body sign-off: approves the ICT risk framework, the digital resilience strategy and the policies that support them, and records that approval.
- Register of information decisions: determines which contractual arrangements fall within scope and which support critical or important functions, then confirms the entries.
- Incident decisions: classifies incidents, decides on major incident reporting and owns communications with the competent authority.
- Third-party oversight: runs due diligence, monitors providers, and keeps exit plans current.
- Proportionality choices: documents how size, risk profile and complexity shaped the controls that apply.
Before engaging any outside firm, confirm which of these decisions your internal governance records as owned by named individuals.
An implementation partner such as DeployOpen works inside your environment to prepare the systems, documents and data that your controls depend on. The work is scoped in writing before it starts. The partner configures self-hosted open-source platforms in your own cloud accounts, data centers or air-gapped networks, then produces drafts and extracts for your team to review, amend and approve. It does not take over the decisions listed in the other tab, and it does not issue any DORA report or certificate.
- Systems preparation: configures logging, access controls, backups and monitoring on platforms you operate, so that the controls produce evidence.
- Documentation drafts: prepares draft policies, procedures and runbooks for management body review.
- Register data: assembles register of information fields from contract and system records for your validation.
- Evidence collection: exports logs, configuration baselines and test records in a form your team and assessor can review.
- Open-source configuration: installs and hardens the platforms you select, and documents the configuration.
Ask the partner to list every artifact it will hand over and name the internal owner who approves each one.
Supervision of DORA sits with the national competent authority designated for your entity type under Article 46, and the authority uses the supervisory powers in Article 50. An independent assessor may test your controls for your own assurance or to support a contractual request, but neither the authority nor the assessor produces a DORA certificate. DORA contains no certification scheme. The only authority-issued attestation it provides for is the confirmation that a threat-led penetration test met the requirements, which applies only where a test falls under that regime.
- Supervision: the authority reviews your framework, register and incident reports and may request information or take remedial action.
- Testing and inspection: the authority or an assessor examines evidence against the regulation and its technical standards.
- Independence boundary: an assessor cannot design or operate the controls it tests without losing its independence.
- No DORA certificate: any document presented as a DORA certificate should be questioned before it is relied on.
- Threat-led testing: attestation applies only to qualifying TLPT, not to general readiness work.
Confirm with your competent authority which evidence it expects and how it prefers to receive the register and incident information.
Questions fund managers ask about DORA scope and effort
Is a small AIFM excluded from DORA?
A small alternative investment fund manager can fall outside DORA, but only if it meets the small AIFM test in Article 3(2) of the AIFMD and is listed in the exclusions of Article 2(3) of DORA. The exclusion is not automatic from size alone, and it is not a reason to skip the check. Confirm it in three steps: confirm your AIFM status and the thresholds under the AIFMD with your national competent authority or legal counsel, confirm that your fund management activity falls under the exclusion, and record the reasoning in a dated memo signed by the management body. Re-run the check whenever assets under management, leverage or fund strategy change, because a fund manager can move in or out of the exclusion over time. You can read the scope wording directly in Regulation (EU) 2022/2554, Article 2.
Does a UCITS management company have the same DORA work as an AIFM?
The core obligations are largely the same, but the legal route differs. DORA reaches UCITS management companies through Directive (EU) 2022/2556, whose Article 1 requires their electronic data processing and network systems to be set up and operated in accordance with DORA. AIFMs are reached through Article 3 of the same directive, which replaces Article 18 of the AIFMD. In practice, both types of manager need an ICT risk management framework, incident management and reporting processes, resilience testing appropriate to their size, and a register of information covering ICT third-party arrangements. Confirm with your competent authority how the UCITS and AIFM perimeters apply to a manager that runs both, and whether any relief under the proportionality principle in Article 4 applies to your activities.
How long does DORA readiness take for a fund manager?
No readiness duration has been established for this page, and any figure quoted without a source would be guesswork. The time depends on what you start from. The main drivers are how complete your existing ICT risk framework and asset inventory are, how many ICT third-party contracts must be reviewed and re-papered, whether your register of information already exists in a usable form, how many systems you run in-house versus through a provider, and how quickly the management body can review and approve the documents. Fund managers that rely heavily on outsourced fund administration and cloud services often spend most of the effort on contract and register work rather than on technical controls. Ask any implementation partner for a written, scoped plan with milestones before committing, and ask your competent authority which reporting dates apply to you.
Can our team handle DORA readiness in-house?
Many fund managers can run the governance and documentation side internally, but the technical evidence work usually needs specialist capacity. In-house staff are well placed to own the policies, the risk assessment, the asset inventory and the management body reporting, since they know the business and the funds. Gaps tend to appear in the technical areas: logging and monitoring, vulnerability and patch management, backup and recovery testing, and the evidence that a resilience test was actually run and acted upon. A useful test is whether one named person can show, for each control, where the evidence lives and when it was last produced. If not, you can keep ownership in-house while bringing in outside help for the systems and evidence. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms in your own infrastructure and prepares evidence for assessment, but it does not issue audit reports or certifications.
What does DORA expect from the management body of a fund manager?
The management body carries responsibility for the ICT risk framework, and it cannot delegate that accountability to IT or to a vendor. In practice it must approve the ICT risk management framework and the resilience strategy, approve and review the policies, oversee the ICT third-party arrangements and the register of information, and keep sufficient knowledge of ICT risk to challenge management. Members should receive regular reporting on incidents, testing results and open remediation items, and the minutes should show real discussion rather than a single sign-off. Plan for training so that board members understand the framework they approve. Confirm with your competent authority which specific board approvals are expected for your entity type and how frequently they must be refreshed.
Is there a DORA certificate for fund managers?
No. DORA sets no certification scheme, so there is no DORA certificate that a fund manager can obtain. Competent authorities supervise compliance using the supervisory powers in Article 50, which include requesting information, conducting investigations and inspections, and requiring remedial measures. The only authority-issued attestation the Regulation provides for relates to threat-led penetration testing under Article 26(7), and it applies only to entities that fall within the TLPT regime. Be wary of anyone offering a DORA certificate. For assurance you can offer clients or regulators, independent auditors and certification bodies can examine your controls against other frameworks, but none of them issue DORA compliance certificates. Ask your competent authority how it expects you to demonstrate compliance.
Where fund manager DORA projects stall
Most fund manager DORA projects do not fail on the big design decisions. They stall on the basics: an incomplete inventory, a delegated assumption nobody tested, register data that drifts from contracts, and governance documents without a clear management body sign-off. Each card below names one gap and the fix that closes it.
Incomplete ICT asset inventory
The ICT asset inventory is often built from internal systems and misses what sits with shared service providers: the fund administrator's portfolio and NAV platform, the depositary's reporting feeds, the hosted document store and the SaaS tools used by the investment team. Those assets still support the fund manager's operations and must be recorded. Fix it by walking each provider's service description with the provider, listing the systems and data flows behind every function, and assigning an owner to each item before the inventory is treated as complete.
Assuming a delegated administrator covers it
Many managers assume that because the fund administrator runs accounting and investor servicing, the administrator also carries the DORA obligations. The manager remains the financial entity and remains accountable for its own electronic data processing and network systems, including the third-party arrangements it chooses. Fix it by writing down which ICT functions the administrator performs, which remain with the manager, and what evidence the manager receives to test the administrator's controls at least once a year.
Register data that does not match contracts
The register of information must reflect each contractual arrangement for ICT services, distinguishing those that support critical or important functions. Problems arise when the register lists a provider name, service or contract date that differs from the signed agreement, or when a subcontractor is missing. Fix it by reconciling every register line against the executed contract and the current service schedule, and by setting a recurring review so that renewals, amendments and new subcontractors reach the register on time.
Documents lacking management body approval
Policies, the ICT risk management framework and the resilience strategy need documented approval by the management body, and the file should show who approved what and when. Teams often circulate drafts from the operations or compliance function and treat them as final. Fix it by logging each document with its version, owner, approval date and the minutes or resolution that approved it, and by making sure the management body reviews the material at the cadence its own governance requires.
How DeployOpen prepares your fund manager's systems and evidence
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so your ICT systems and evidence can be prepared for DORA scrutiny. We prepare systems, controls and evidence for assessment; the fund manager owns its controls, and only independent auditors or competent authorities issue reports or conclusions.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We confirm which of your ICT systems fall under DORA and whether AIFMD or UCITS obligations apply to each.
- We agree which ICT services and third-party arrangements feed your register of information before any build begins.
How we build
- We implement and configure self-hosted open-source platforms within your cloud accounts, data centers or air-gapped networks.
- We harden systems, document configurations and align logging, access and backup settings with your ICT risk framework.
- We run security and resilience testing on the systems we build and record findings for your remediation tracking.
How we hand over
- You receive documented configurations, runbooks, test results and evidence packs mapped to your DORA requirements.
- We walk your security, compliance and operations teams through each deliverable so they can operate and maintain the systems.
- Your management body and independent auditors can review the evidence directly, with no reliance on DeployOpen to vouch for it.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, agreed separately from the original scope.
- We help you update the register of information and evidence as ICT services, providers and platform versions change.
- We confirm with your competent authority, auditor or legal counsel any interpretation of DORA or the AIFMD and UCITS amendments.
