In December 2024, a month before DORA started applying, the European Supervisory Authorities (ESAs) published the results of a voluntary dry run of the Register of Information. Almost 1,000 financial entities took part. Of the registers analyzed, only 6.5% passed all 116 data quality checks. The exercise ran on a best-effort basis, and half of the remaining registers failed fewer than five checks, so the ESAs were cautiously optimistic. Still, the most common problem was telling: 86% of errors came down to missing mandatory information.

It's a useful lens for DORA as a whole. The rules are well understood by now. What decides how a supervisory cycle goes is whether an organization's data, processes, and evidence can keep up with them, cycle after cycle.

What is the DORA Regulation?

The DORA Regulation, formally Regulation (EU) 2022/2554, is the EU's framework for digital operational resilience in the financial sector. The EU introduced it to harmonize what had been a patchwork of national rules on information and communication technology (ICT) risk, replacing inconsistent expectations with one directly applicable regulation across all member states.

Cybersecurity alone doesn't cover it, though. DORA is about an organization's ability to withstand, respond to, and recover from ICT disruptions, which pulls governance, business continuity, and ICT risk management into a single accountability structure rather than treating them as separate concerns. Because DORA is a regulation rather than a directive, it applies directly. There's no national law to wait for, and no room for a member state to water down what it requires.

Who does the DORA Regulation apply to?

Article 2 sets DORA's scope, covering a wide range of financial entities directly, and reaching ICT third-party providers indirectly through those entities' own obligations.

Some smaller and less interconnected entities, such as small and non-interconnected investment firms, can apply a simplified ICT risk management framework under Article 16. The basics still apply, though: a documented framework, monitoring, business continuity, and awareness training.

Among ICT third-party providers, a smaller group is regulated more tightly: critical ICT third-party providers (CTPPs), designated individually by the ESAs and placed under direct EU-level oversight rather than the indirect route every other provider follows.

NIS2 covers a similarly broad range of entities across critical sectors. For financial entities, though, DORA takes precedence as the sector-specific rulebook for ICT risk management and incident reporting. ICT providers are a different case: they can fall under NIS2 in their own right while serving financial entities under DORA.

What are the 5 pillars of the DORA Regulation?

Five pillars structure everything DORA requires, and they connect to each other more than they might first appear: a weak spot in one tends to surface as a gap in another.

ICT risk management

Financial entities need a documented framework for identifying, protecting against, detecting, responding to, and recovering from ICT risk, and it has to work in practice, not only on paper. The management body carries ultimate responsibility for it. The framework also has to govern how ICT third-party risk gets identified and monitored.

ICT-related incident management and reporting

Major ICT-related incidents have to be classified against harmonized criteria and reported to the competent authority in three stages. The initial notification is due within four hours of classifying an incident as major, and no later than 24 hours after becoming aware of it. An intermediate report follows within 72 hours of the initial notification, and a final report within a month of the latest intermediate report.

Digital operational resilience testing

Financial entities have to test whether their ICT systems and resilience controls hold up in practice. For most entities, that means a regular testing program. Entities identified by their competent authority also have to run threat-led penetration testing (TLPT) at least every three years, on live production systems and based on real threat intelligence.

ICT third-party risk management

For many organizations, this is the most demanding pillar. Financial entities need contracts that include DORA-mandated clauses, covering areas such as audit rights, data location, and exit strategies, and an ongoing assessment of concentration risk across their supplier base.

At the center sits the Register of Information (RoI). Under Article 28(3), financial entities must maintain and keep up to date a register of all contractual arrangements with ICT third-party service providers, in the standardized format set out in the implementing technical standards, and make it available to their competent authority. Supervisors collect the register once a year, with a reference date of 31 December and national submission windows in the first quarter. For a closer look at what the register contains and how to keep it current, see our Register of Information page.

Information and intelligence sharing

DORA also allows financial entities to share cyber threat information and intelligence with each other, within trusted communities. Taking part is voluntary, and the aim is to help the sector respond to threats that rarely stay confined to one organization.

DORA Regulation penalties and consequences of non-compliance

Enforcement runs through national competent authorities, which supervise financial entities directly and can apply the administrative penalties and remedial measures each member state has set out. Unlike the General Data Protection Regulation (GDPR), DORA doesn't set an EU-wide maximum fine for financial entities: Article 50 leaves the amounts to national law. Enforcement isn't limited to fines, either. Supervisory measures, mandated remediation, and closer scrutiny are all part of the toolkit, and for many organizations, the reputational and operational cost of extended supervisory attention can outweigh the fine itself.

Critical ICT third-party providers sit under a separate mechanism entirely. They're overseen directly at EU level, not through a national authority. If a provider doesn't cooperate with its Lead Overseer, for example by leaving information requests unanswered, obstructing investigations or inspections, or failing to report on the remedial actions it has taken, the Lead Overseer can impose periodic penalty payments under Article 35. These are charged daily until the provider complies, for no more than six months, and can reach up to 1% of the provider's average daily worldwide turnover in the preceding business year. When setting the amount, the Lead Overseer considers how serious and long-lasting the non-compliance is, whether it was intentional or negligent, and how well the provider cooperated.

Oversight recommendations work differently. If a provider doesn't follow them, the Lead Overseer can make that public, and as a last resort, competent authorities can require financial entities to suspend or terminate their use of that provider's services.

How to implement DORA compliance in practice

Understanding the regulation and operating it day to day are different problems. This is the sequence most organizations actually need to work through:

1. Confirm DORA scope: Establish which entity category applies, and whether the simplified regime is available.

2. Identify critical and important functions: DORA's other requirements scale around this list, so getting it right early avoids rework later.

3. Map ICT assets and dependencies: Connect systems, suppliers, and business functions before trying to assess risk against any of them.

4. Assess the ICT risk management framework: Compare what's documented against what Articles 5 to 16 require.

5. Establish incident-management workflows: Build classification and reporting into a process, not a document someone opens only when something breaks.

6. Build and maintain the Register of Information: Treat it as living operational data, not an annual export exercise.

7. Establish the resilience-testing program: Scope, schedule, and evidence testing on a recurring basis, including TLPT where it applies.

8. Monitor and maintain compliance: Revisit all of the above as suppliers, systems, and supervisory expectations change.

Steps 3 and 6 tend to take the longest, largely because they depend on data scattered across procurement, IT, and business units. Formalize keeps the ICT risk framework, incident workflows, testing schedules, the third-party register, and the controls behind them in one place, alongside your ISO 27001 and NIS2 work, rather than split across spreadsheets and separate tools. The Register of Information stays current as contracts and suppliers change, instead of being rebuilt from scratch each reporting cycle.

How Formalize supports DORA compliance

Formalize is built for the part of DORA that repeats: keeping data and evidence current between cycles, instead of rebuilding them each time.

• A Register of Information that stays current. Suppliers, contracts, ICT services, and business functions stay connected, errors are flagged at entry, and the register exports in the official format. More on the Register of Information page.

• A free RoI Validator. It runs 294 checks across all 15 reports in the official format, with no registration, whether or not you use Formalize.

• Risk, incidents, and testing in one place. Each with named owners, deadlines, and evidence attached as the work happens.

• DORA alongside ISO 27001, NIS2, and GDPR, in the same system instead of separate tools.

More than 8,000 organizations across Europe already use Formalize's products.

Where can you download the DORA Regulation PDF?

For the regulation itself, EUR-Lex is the authoritative source. Secondary summaries are useful for orientation, but the text published in the Official Journal is the one that counts legally.

The regulation alone isn't the whole picture, though. The 13 RTS and ITS discussed above fill in the operational detail DORA itself doesn't specify, and supervisory guidance from the European Supervisory Authorities continues to clarify how supervisors expect the requirements to be met in practice. Implementation based on the regulation's text alone, without the supporting technical standards, tends to miss exactly the detail supervisors will ask about first.