DORA Compliance Checklist for Luxembourg Fund Administrators

ByOfficer

Last updated: April 2026

DORA (Regulation (EU) 2022/2554) has been live since 17 January 2025. For Luxembourg fund administrators, UCITS management companies, and AIFMs, the question is no longer whether it applies to you. It does. The question is whether your implementation actually covers what the CSSF expects, or whether you have gaps disguised as compliance.

Most fund administrators I have spoken with treated DORA as a bank-focused regulation and started late. The result: register of information templates half-populated, incident reporting procedures written but untested, and ICT risk frameworks copied from group-level documents that do not reflect Luxembourg-specific operational reality. The CSSF has already issued Circulars 25/881, 25/882, and 25/883 to spell out its expectations. Those circulars are not optional reading.

This checklist breaks DORA implementation into concrete action items. It is written for the person who needs to verify that a fund administrator’s compliance programme actually works, not for the person writing a board presentation about it.

Related reading: DORA Register of Information – What Financial Entities Need to Report

Who Is in Scope: Fund Administrators Under DORA

DORA applies to “financial entities” as defined in Article 2(1). For the Luxembourg fund administration world, this includes UCITS management companies (Article 2(1)(l)), AIFMs (Article 2(1)(k)), and administrators of benchmarks. The scope catches entities that many in the industry initially assumed were too small to matter.

The common mistake is assuming that because a ManCo delegates portfolio management, it is somehow less exposed to DORA. The opposite is true. A ManCo that delegates extensively has more ICT third-party relationships to map, more contractual arrangements to document, and a wider attack surface to monitor. Delegation does not delegate away responsibility under DORA.

Article 16 provides a simplified ICT risk management framework for certain small entities: small and non-interconnected investment firms, exempted payment institutions, and exempted electronic money institutions. UCITS ManCos and AIFMs are not on that list. They must apply the full framework under Articles 5 to 15. I have seen compliance teams assume the simplified framework applies to smaller ManCos. It does not, regardless of size. The only size-based relief is for microenterprises as defined in Article 3(60), who are exempt from certain testing and governance provisions, but even they must maintain the register of information and report incidents.

Luxembourg-Specific Scope Points

Circular CSSF 25/882 addresses ICT third-party services under DORA, but the article-level scope listing of entities defined in Article 2(1)(a) to (i), (k) to (m), (p), (r) and (s) belongs to Circular CSSF 25/892, not 25/882. For fund administrators, the practical point is that CSSF has issued a package of DORA circulars that captures ManCos, AIFMs, and their ICT-related operating model, including service arrangements with transfer agents, NAV calculation providers, IT hosting companies, and data vendors.

Circular CSSF 25/883 amends the existing outsourcing circular (CSSF 22/806) to align with DORA. If your fund administrator maintained outsourcing arrangements under the old circular, those arrangements now need review against DORA’s stricter requirements for contractual provisions, exit strategies, and subcontracting chains.

Checklist 1: ICT Risk Management Framework (Articles 5-15)

DORA requires every in-scope entity to establish and maintain an ICT risk management framework. For fund administrators, this is the foundation everything else sits on. The RTS on ICT risk management (Commission Delegated Regulation (EU) 2024/1774) specifies the detailed elements.

Governance and Accountability

  • The management body (board of directors for a ManCo) has formally approved the ICT risk management framework, including the ICT risk appetite and tolerance levels (Article 5(2)).
  • A member of senior management is designated as responsible for overseeing ICT risk. This person has sufficient technical knowledge to challenge ICT decisions. In many Luxembourg ManCos, this falls to the conducting officer responsible for risk, but DORA does not accept a token appointment. The person must actively oversee.
  • The ICT risk management framework is reviewed at least annually and after major ICT incidents.
  • The management body receives regular reporting on ICT risks, including results of resilience testing and status of remediation plans.
  • Budget allocation for ICT security and digital operational resilience has been formally approved and is documented. Article 5(2)(g) specifically requires training and ICT skills development for all staff.

Where teams get this wrong: the board resolution approving the ICT risk framework often references a generic group policy. The CSSF expects entity-level documentation that reflects the specific ICT landscape of the Luxembourg entity, not a copy of what the parent bank or asset manager uses at group level.

ICT Systems and Asset Management

  • All ICT assets are identified, classified, and documented, including hardware, software, network resources, and data assets supporting critical or important functions.
  • Critical or important functions (CIFs) are explicitly identified and mapped to the ICT assets supporting them. For a fund administrator, CIFs typically include NAV calculation, transfer agency, regulatory reporting, and investor communication systems.
  • Dependencies between ICT assets are mapped, including interconnections with third-party systems.
  • Legacy systems are identified and subject to specific risk mitigation. This is relevant in Luxembourg fund administration, where some transfer agent platforms have been running on decades-old infrastructure.

ICT Security Policies and Controls

  • An ICT security policy is in place, covering access control, encryption, network security, and vulnerability management.
  • Access rights follow least-privilege principles and are reviewed at defined intervals.
  • Detection mechanisms for anomalous activities are operational, including on ICT systems supporting critical functions.
  • Patch management processes are documented, with defined timelines for applying security patches.
  • Encryption standards are documented and applied to data at rest and in transit, particularly for investor data and NAV-related information.

Business Continuity and Disaster Recovery

  • An ICT business continuity policy is in place, covering recovery time objectives (RTOs) and recovery point objectives (RPOs) for critical functions (Article 11).
  • Backup policies specify frequency, storage locations (including geographic separation), and restoration testing schedules (Article 12).
  • Business continuity plans have been tested within the last 12 months, and test results have been reported to the management body.
  • Communication plans exist for notifying clients, counterparties, and the CSSF during an ICT disruption.

The common gap: many fund administrators have business continuity plans that cover office access and staff availability but do not address ICT-specific scenarios like a ransomware attack on the NAV calculation engine or a complete loss of the transfer agent platform. DORA requires ICT-specific continuity, not just generic BCP.

Checklist 2: ICT Incident Reporting (Articles 17-23)

Incident reporting under DORA is not new for banks, but it is a new obligation for most fund administrators. The classification criteria and reporting timelines are specified in the RTS on classification of major incidents (Commission Delegated Regulation (EU) 2024/1772) and the ITS on reporting templates.

Incident Classification

  • An incident classification procedure is documented, mapping DORA’s classification criteria: number of clients affected, duration and service downtime, geographic spread, data losses, impact on critical services, and economic impact.
  • Thresholds for “major incident” classification are calibrated to the entity’s operations and checked against the RTS text in Commission Delegated Regulation (EU) 2024/1772. Do not rely on a simplified internal rule that assumes all criteria are equally weighted unless that matches the final RTS logic and documented escalation methodology.
  • Staff responsible for initial classification are trained and can apply the criteria promptly after detection. Delayed classification creates direct reporting risk even if the 4-hour clock for the initial notification runs from the point of classification.

Reporting Timelines and Channels

  • Initial notification to the CSSF must be submitted within 4 hours of classifying an incident as major, and no later than 24 hours after detection.
  • An intermediate report is due within 72 hours of the initial notification.
  • A final report is due within one month of the incident resolution.
  • Reporting templates conform to the ITS format. The templates are structured across initial, intermediate, and final submissions with specific mandatory fields at each stage.
  • Internal escalation procedures ensure that the conducting officers and board are informed before or simultaneously with the regulatory notification.

What teams get wrong here: the 4-hour clock starts from classification, not from detection. But the regulation also says classification must not be unreasonably delayed. A fund administrator that detects an incident on Friday afternoon and classifies it on Monday morning will have a problem explaining that timeline to the CSSF.

Significant Cyber Threat Reporting

  • Voluntary reporting procedures for significant cyber threats are documented, even though this reporting is not mandatory.
  • Criteria for what constitutes a “significant” cyber threat in the context of fund administration are defined internally.

Cost and Loss Estimation

Circular CSSF 25/892 applies the Joint ESA Guidelines on estimating aggregated annual costs and losses caused by major ICT-related incidents (JC 2024 34). Fund administrators must be able to estimate direct and indirect costs from ICT incidents, including operational losses, recovery costs, and any client impact.

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

Every DORA-scope entity must conduct digital operational resilience testing. The scope and intensity depend on the entity’s risk profile.

Basic Testing Requirements

  • A testing programme is documented, risk-based, and covers all critical ICT systems and applications at least annually.
  • Testing includes vulnerability assessments, network security assessments, software quality reviews, source code analysis (where applicable), and scenario-based testing.
  • Test results are reported to senior management and the management body.
  • Identified vulnerabilities from testing are prioritised and remediated within defined timelines.
  • Testing is conducted by independent parties. Internal testing is permitted under certain conditions, but conflict-of-interest safeguards must be documented.

Threat-Led Penetration Testing (TLPT)

TLPT applies only to entities identified by the competent authority based on systemic importance and ICT maturity. Most Luxembourg fund administrators will not be designated for TLPT. But do not assume this. If you are a large ManCo running significant AuM through proprietary technology, the CSSF could include you. The designation criteria include the entity’s overall risk profile and the degree to which ICT disruption could affect financial stability.

If designated, TLPT must be conducted at least every three years by external testers meeting the qualification requirements in Article 27. Internal red team resources can participate, but the external tester must lead.

Checklist 4: ICT Third-Party Risk Management (Articles 28-30)

This is where DORA hits fund administrators hardest. The typical Luxembourg fund administration chain involves multiple ICT service providers: transfer agent platforms, NAV systems, middle-office tools, cloud infrastructure, data feeds, cybersecurity services, and regulatory reporting software. Every one of these relationships needs to be assessed under DORA.

Register of Information

  • A register of information covering all contractual arrangements for ICT services is maintained in the format specified by the ITS (Commission Implementing Regulation (EU) 2024/2956). The register uses the ESA templates with specific data fields for each arrangement.
  • The register distinguishes between arrangements supporting critical or important functions and those that do not.
  • Subcontracting chains are documented. If your transfer agent platform is hosted on AWS, and your TA provider subcontracts certain processing to a third party, both layers must appear in the register.
  • The register is updated when contractual arrangements change and is submitted annually to the CSSF.
  • Article 28(3) requires reporting the number of new arrangements annually. The Joint ESAs have confirmed in Q&A 2025_7309 that, in general, this obligation is fulfilled through the annual register submission, so no second specific communication is needed, while the register must still be made available on request and firms must inform the competent authority in a timely manner about planned ICT third-party contractual arrangements supporting critical or important functions.

The biggest operational headache I have seen: identifying which vendor relationships qualify as “ICT services” under Article 3(21). A data feed provider is clearly ICT. A printing service for investor statements that runs through a cloud platform is less obvious. The EBA’s formal Q&A 2024_7290 confirms the broad Article 3(21) definition in the specific context of payment-processing and infrastructure providers, and the wider practical lesson is that firms should assess whether the service is a digital or data service provided through ICT systems on an ongoing basis. When in doubt, document the assessment carefully. Explaining a missing entry to the CSSF is worse than maintaining an extra row in the register.

Contractual Requirements

  • All ICT service contracts include the mandatory provisions specified in Article 30, including service levels, data access and recovery, audit rights, exit strategies, and termination conditions.
  • Contracts supporting critical or important functions include additional provisions: performance targets, notice periods for material changes, unrestricted audit rights, and exit plans that ensure business continuity during transition.
  • Exit strategies are documented for all arrangements supporting critical functions, specifying transition timelines, data portability, and alternative providers.
  • Contracts include provisions requiring the ICT provider to cooperate with the competent authority and resolution authority, including during on-site inspections.

Where this breaks down: many existing vendor contracts predate DORA and do not include the required provisions. Renegotiating contracts with large technology vendors (Bloomberg, SWIFT, major cloud providers) takes months, and those vendors are often reluctant to accept entity-specific DORA clauses when they serve hundreds of financial entities. Start the renegotiation process now if you have not already. Document your efforts even if the vendor pushes back. The CSSF will want to see that you tried.

Concentration Risk

  • ICT concentration risk is assessed. If five critical functions all depend on the same cloud provider, that is a concentration risk that must be documented and mitigated.
  • The entity has considered whether alternative providers exist for critical ICT services and whether a multi-provider strategy is feasible.

Checklist 5: Information Sharing (Article 45)

DORA permits (but does not require) financial entities to exchange cyber threat intelligence with other financial entities. If your fund administrator participates in information-sharing arrangements, those arrangements must meet the conditions in Article 45, including data protection safeguards.

  • If participating in an information-sharing arrangement, the arrangement is documented and approved by the management body.
  • Data protection impact assessments have been conducted where personal data may be shared.
  • If not participating, the entity has documented its rationale and assessed whether joining an arrangement would improve its threat detection capabilities.

CSSF-Specific Expectations

The CSSF has not waited for entities to figure out DORA on their own. Three circulars issued in April 2025 set out Luxembourg-specific expectations:

Circular CSSF 25/881

Amends Circular CSSF 20/750 on ICT and security risk management. Aligns the existing ICT risk management requirements with DORA. Fund administrators that were already compliant with 20/750 have a head start, but DORA adds testing requirements, incident classification thresholds, and third-party oversight obligations that 20/750 did not cover.

Circular CSSF 25/882

Covers ICT third-party services. Sets out expectations for due diligence before entering ICT service arrangements, ongoing monitoring, and the contractual provisions that must be in place. This circular applies to all in-scope financial entities, including ManCos and AIFMs.

Circular CSSF 25/883

Amends Circular CSSF 22/806 on outsourcing. Reconciles the existing outsourcing framework with DORA’s third-party risk management requirements. The key change: outsourcing arrangements involving ICT services are now governed by DORA rather than the outsourcing circular alone. The outsourcing circular continues to apply to non-ICT outsourcing.

Circular CSSF 25/892

Applies the Joint ESA Guidelines on estimating aggregated annual costs and losses from major ICT incidents. Fund administrators must implement a methodology for quantifying the financial impact of ICT disruptions. This is not a theoretical exercise. The CSSF will use this data for supervisory benchmarking.

Common Implementation Gaps for Fund Administrators

After reviewing multiple DORA implementation programmes, the same gaps keep appearing:

Gap 1: Treating DORA as an IT project. DORA is a regulatory compliance obligation. IT executes, but compliance owns the framework, legal reviews the contracts, and the board approves the governance structure. Fund administrators that delegated DORA entirely to their IT team (or worse, to their IT provider) are exposed.

Gap 2: Ignoring intra-group ICT services. A ManCo that uses its parent group’s IT infrastructure is still responsible for documenting that arrangement in the register of information and ensuring it meets DORA’s contractual requirements. Intra-group does not mean exempt. EBA Q&A 2024_7288 supports the view that financial entities providing ICT services to other financial entities can still fall within the ICT third-party service provider concept, even if they are exempt from the Oversight Framework itself. For register purposes, group structure does not remove the need to assess and record the arrangement.

Gap 3: Confusing DORA with GDPR. Both deal with data and technology, but they address different risks. DORA is about operational resilience. GDPR is about data protection. Your GDPR breach notification procedure does not satisfy DORA’s incident reporting requirement. They are separate obligations with different timelines, templates, and authorities.

Gap 4: No exit strategy for critical vendors. Article 28(8) requires exit strategies. Many fund administrators can name their critical ICT providers but cannot describe how they would transition away from any of them within a reasonable timeframe. An exit strategy that says “we would find another provider” is not an exit strategy.

Gap 5: Testing that never tests. Running a vulnerability scan once a year on the corporate network is not a resilience testing programme. DORA requires scenario-based testing that addresses ICT-specific threats to critical functions. For a fund administrator, that means testing what happens when the NAV calculation system goes down, when the transfer agent platform is compromised, or when a critical data feed stops.

Prioritised Action Items for Q2 2026

If your fund administrator is still catching up, here is what to prioritise right now:

  1. Complete the register of information. The ESA templates are available, the ITS is final, and the CSSF expects annual submission. This is the single most auditable DORA deliverable.
  2. Review all ICT service contracts against Article 30 requirements. Flag contracts that lack mandatory provisions and start renegotiation.
  3. Test your incident reporting procedure. Run a tabletop exercise simulating a major ICT incident and see whether your team can classify, escalate, and report within DORA’s timelines.
  4. Ensure the board has formally approved the ICT risk management framework. Not acknowledged. Approved. With documented evidence of their review of the framework’s substance.
  5. Map your subcontracting chains. Ask each critical ICT provider for their subcontracting arrangements. If they cannot or will not disclose, that is a finding that needs to be documented and escalated.

Related Articles

DORA Register of Information – Detailed guidance on the register’s structure, data fields, and submission requirements.

DORA ICT Incident Reporting – Classification criteria, reporting timelines, and template walkthrough for major ICT incidents.

CSSF Reporting Calendar Q2 2026 – All upcoming CSSF reporting deadlines for the quarter.

AML Reporting in Luxembourg – A parallel compliance framework that fund administrators must manage alongside DORA.

Sources and References

  • Regulation (EU) 2022/2554 (DORA) – EUR-Lex
  • Commission Delegated Regulation (EU) 2024/1774 (RTS on ICT Risk Management Framework) – EUR-Lex
  • Commission Delegated Regulation (EU) 2024/1772 (RTS on Classification of Major Incidents) – EUR-Lex
  • Commission Implementing Regulation (EU) 2024/2956 (ITS on Register of Information) – EUR-Lex
  • CSSF Circular 25/881 – ICT and security risk management – CSSF
  • CSSF Circular 25/882 – ICT third-party services under DORA – CSSF
  • CSSF Circular 25/883 – Outsourcing arrangements (DORA amendment) – CSSF
  • CSSF Circular 25/892 – ESA Guidelines on ICT incident cost estimation – CSSF
  • Joint ESA Guidelines on estimation of aggregated annual costs and losses (JC 2024 34) – EBA

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.

Similar Posts