What is DORA? Everything you need to know

This page covers what DORA actually requires, who it applies to, how it fits alongside other frameworks you may already know, and where firms are finding the work harder than expected. If you are specifically looking for how this plays out under CSSF and CAA supervision in Luxembourg, see our dedicated page on that: DORA in Luxembourg: what the CSSF and CAA actually expect.

What DORA actually is

DORA was adopted in 2022 and entered into force on 16 January 2023, giving affected entities a 24-month period to prepare before full applicability on 17 January 2025. Unlike a directive, it is a regulation, meaning it applies directly in every Member State without needing to be transposed into national law first. Member States still had to designate competent authorities and grant them supervisory and sanctioning powers; in Luxembourg this was done through the Law of 1 August 2024.

Who has to comply

DORA applies to financial entities and to the ICT third-party providers that serve them. In practice that covers:

• Banks and credit institutions
• Investment firms
• Payment institutions and electronic money institutions
• Insurance and reinsurance undertakings
• Investment fund managers (UCITS management companies and AIFMs)
• Crypto-asset service providers authorised under MiCA
• Central securities depositories and other entity types listed in Article 2 of the Regulation

It also reaches ICT providers who are not financial entities themselves, because the financial entities they serve have to describe those provider relationships in their own register and contracts. If you are a cloud provider, a cybersecurity firm, or an IT consultancy serving Luxembourg financial entities, DORA reaches you contractually even if you never file anything yourself.

The five pillars

The pillar that actually consumes the most time: third-party risk and the register

On paper, all five pillars carry equal weight. In practice, ICT third-party risk management is where most of the operational burden lands, because it comes with a hard annual deliverable: the Register of Information under Article 28(3). That register has to be submitted to your competent authority every year, reconciled across 101 fields and 15 ITS templates, sourced from contracts that were never written with a register in mind.

This is also where the data quality problem is well documented. In the ESAs' EU-wide dry run, fewer than 7% of nearly a thousand participating firms passed all 116 validation checks on the first attempt. That is not a Luxembourg-specific problem. It is structural to how the register works, and it is the specific problem LeDora by Letzscale is built to solve.

How DORA relates to frameworks you may already know

If your organisation already runs a mature information security program, some of DORA's requirements will look familiar. ICT risk management overlaps with practices covered by ISO 27001 and NIST-style frameworks. Incident reporting and resilience testing overlap with NIS2, the EU's broader cybersecurity directive, though DORA's ICT third-party risk requirements, and the Register of Information specifically, go further than what either of those frameworks asks for. Having an existing ISO 27001 or NIS2 program is a genuine head start on governance and incident processes. It does not produce your register for you.

Deadlines and enforcement

Full compliance has been required since 17 January 2025. DORA leaves the specific supervisory and sanctioning powers to each Member State's competent authorities. In Luxembourg, the Law of 1 August 2024 grants the CSSF its DORA supervisory and sanctioning powers, on top of its existing regime, and the CAA supervises insurance and reinsurance undertakings under its own DORA mandate. The European Supervisory Authorities began oversight activity in early 2025 and continue validation checks on register submissions each cycle.

Common challenges firms run into

• Poor visibility into subcontracting chains. You can usually name your direct provider. Naming their subcontractors, for every contract supporting a critical or important function, is harder and is the most common source of rejected fields.
• Contract data that was never structured for this. A master agreement with a dozen schedules is not one register row, and the fields the register wants (governing law, notice periods, data location) are scattered across documents that were written by lawyers, not compliance teams.
• Spreadsheet fragility. Manually re-keying contract data into a spreadsheet every year does not scale past a handful of providers, and it does not catch inconsistencies until the regulator's validation checks do.
• Rising data quality bars. Validation checks are being applied to more fields each cycle. A register that was accepted last year is not guaranteed to pass this year without changes on your side.

How LeDora helps

LeDora maps ICT contracts to the DORA register fields and builds the register data behind them, with a verbatim citation for every field it extracts. Where a field cannot be found in your documents, it is flagged as missing, not guessed at. The result is an export file that plugs into whatever system you already use to file, whether that is a spreadsheet, an adviser, or a GRC platform.