DORA Compliance Guide: What the Act Requires Now

MiCA has become a central part of the EU's regulatory framework for crypto-asset services. But it is not the only regulation that crypto-asset businesses need to consider. The Digital Operational Resilience Act (DORA) sets requirements for ICT risk management and operational resilience across the financial sector.

In this article, we will answer the basic questions about DORA and gradually move to more specific actions organisations should take when preparing for DORA compliance or a regulatory assessment.

What is DORA?

The Digital Operational Resilience Act, formally Regulation (EU) 2022/2554, is the EU regulation governing digital operational resilience in financial services. It has applied since 17 January 2025.

It requires financial entities to manage ICT-related risks, report major ICT-related incidents, test their digital operational resilience, manage ICT third-party risk, and maintain arrangements for responding to and recovering from disruptions.

The Act applies to a broad range of financial entities, including banks, investment firms, insurers, payment institutions, trading venues and crypto-asset service providers authorised under MiCA.

In simple terms, DORA was introduced to ensure financial companies can continue operating when their technology fails or is under attack.

But do not confuse DORA with MiCA. They are not equal and do not substitute each other. MiCA regulates crypto-asset services and the entities providing them. DORA establishes requirements for ICT risk management and digital operational resilience supporting regulated financial activities.

One feature of DORA is its proportionality. This means requirements are applied, taking into account the entity's size, overall risk profile, scale, complexity, and the nature and scope of its services. Smaller firms can benefit from simplified requirements in specific areas, but they still have to manage the risks created by their technology and external providers.

Who does DORA apply to?

DORA covers a broad range of financial entities, including banks, payment institutions, investment firms, insurance and reinsurance companies, investment funds and crypto-asset service providers.

Crypto-asset service providers authorised under MiCA are among the entities covered by DORA. For these businesses, DORA applies to the technology and operational processes supporting regulated activities, including custody, trading and transfers.

For a CASP, the scope extends beyond the customer-facing application.

A custody or trading service may depend on private-key infrastructure, HSMs or MPC systems, blockchain nodes, cloud environments, transaction-signing systems and monitoring tools. Those dependencies form part of the operational environment that needs to be assessed under DORA.

This is particularly relevant when a failure of a single technical component can prevent a regulated service from operating. 

What does DORA require?

DORA's main requirements can be roughly grouped into five areas:

• ICT risk management
• Incident management and reporting
• Digital operational resilience testing
• ICT third-party risk management
• Cyber-threat information sharing

Simply put, DORA requires many familiar cybersecurity and operational controls, but makes them more specific to financial-sector operations and resilience.

For example, having backups is not enough. A regulated entity needs to understand which systems support its critical or important functions, how quickly those systems need to be recovered, what happens when they become unavailable, and whether its recovery arrangements have actually been tested.

DORA also requires an ICT risk-management framework, clear management responsibilities and evidence showing that controls work in practice. That evidence can include policies, risk assessments, incident records, testing results, remediation tracking, supplier documentation and logs.

Having a policy in place is different from being able to show how it was implemented and tested.

And yes, testing is a significant part of DORA. The regulation's digital operational resilience testing programme can include vulnerability assessments, network security assessments, source-code reviews where appropriate, scenario-based tests, performance tests, end-to-end tests and penetration testing.

For some entities, there is an additional requirement: threat-led penetration testing, or TLPT.

Do DORA and MiCA overlap?

Yes. They overlap significantly, but they regulate different dimensions.

MiCA establishes the framework under which a CASP can provide crypto-asset services in the EU. DORA, on the other hand, focuses on the ICT and operational resilience behind those services.

So, obtaining MiCA authorisation does not make DORA irrelevant, and DORA does not replace MiCA.

There can be shared evidence between the two regimes. For example, custody security, key management, business continuity and certain governance arrangements may be relevant to both. But the same control does not necessarily satisfy both regimes in exactly the same way.

What does threat-led penetration testing (TLPT) mean under DORA?

We already mentioned that DORA goes beyond conventional security testing by introducing threat-led penetration testing, or TLPT, for financial entities that are identified as subject to it.

TLPT is a form of advanced resilience testing that uses threat intelligence to model realistic attacks against an organisation's critical or important functions.

How does TLPT differ from a pentest?

A pentest looks for exploitable technical vulnerabilities within a defined scope. Depending on the engagement, researchers may work in a white-box, grey-box or black-box setup and test applications, infrastructure, APIs or other systems.

TLPT goes further.

Under DORA, a TLPT must cover several or all critical or important functions, and is performed on live production systems supporting those functions. The test also considers the underlying ICT systems, processes, and technologies supporting them, including relevant outsourced ICT services.

In practice, this means the objective is not simply to produce a list of vulnerabilities. The exercise is designed around realistic threat scenarios and whether an organisation can withstand and respond to a sophisticated attack against the functions that matter most to its business.

Who is subject to threat-led penetration testing?

This is where it gets tricky.

Under DORA, TLPT is not automatically mandatory solely by virtue of belonging to a particular category of financial entity. Instead, under Article 26(8), competent authorities identify the financial entities required to perform TLPT based on factors including their impact, systemic importance, the criticality of their services, interconnectedness, business complexity, and ICT risk profile.

The RTS supplements this identification process by establishing quantitative criteria for different categories of financial entities. These include, for example, G-SII/O-SII status for credit institutions, payment-volume thresholds for payment and electronic money institutions, and market-share thresholds for trading venues. CCPs and CSDs are effectively subject to TLPT without an additional quantitative threshold.

CASPs are therefore not uniquely subject to an identification process. Like other financial entities, they are assessed under the Article 26(8) framework, with the applicable criteria determining whether they fall within the mandatory TLPT scope.

The factors relevant to that assessment include:

• Size and systemic importance
• The criticality of the services provided
• Interconnectedness with other financial entities
• Business complexity
• ICT risk profile and maturity
• The technology involved and the entity's operational dependencies

If a CASP is identified as subject to TLPT, the testing must generally be performed at least once every three years, although the competent authority can require a different frequency based on the entity's risk profile and operational circumstances.

So, potentially, a CASP can become subject to TLPT, but it should not be presented as an automatic requirement for every CASP.

What is DORA's Register of Information?

The Register of Information (RoI) is a structured record of an entity's contractual arrangements with ICT third-party service providers.

In a nutshell, an organisation needs to maintain information about who provides ICT services to the entity, what they provide, which business functions depend on those services, and how those contractual arrangements are structured. For arrangements supporting critical or important functions, the information also extends into relevant subcontracting relationships.

There is an official illustrative template on the European Banking Association website that you can use to familiarise yourself with the required structure.

But beware: it is quite easy to get your Register of Information wrong.

The 2024 ESAs dry-run exercise showed exactly that. 1,039 financial entities participated. Of the 947 registers that passed the initial integration checks and were processed, only 6.5% passed all 116 data-quality checks. Half of the remaining registers failed fewer than five checks.

A few rookie mistakes to avoid:

1. Invalid provider identifiers. Make sure the identifier used for an ICT provider is valid and matches the entity being reported.
2. Duplicate identifiers. Check that identifiers expected to be unique are actually unique.
3. Inconsistent provider information. Do not identify the same provider as “Microsoft Corporation” in one place and “Microsoft” or “Microsoft Ireland Operations Ltd” elsewhere without the relevant entity distinctions being correctly represented.
4. Broken relationships. The relationships between contracts, providers, functions and other records need to be internally consistent. If Contract A points to Provider X, the corresponding provider record needs to exist and match.
5. Missing subcontracting information. For arrangements supporting critical or important functions, relevant subcontracting relationships need to be captured rather than stopping at the first ICT provider.

The lesson is fairly simple: the information must be complete, factual, and internally consistent.

A high-level example for a digital-asset exchange’s RoI entry might look like this:

Crypto exchange → AWS → relevant subcontractors → cloud infrastructure → trading platform → order execution and custody functions

What happens if a company does not comply with DORA?

For a MiCA-authorised CASP, DORA provides the framework for administrative penalties and remedial measures, while the specific enforcement regime is implemented through national law.

There is therefore no single EU-wide DORA fine that applies to every CASP. Member States must provide for effective, proportionate, and dissuasive penalties and remedial measures, and competent authorities must determine the appropriate response under the applicable national framework. The severity of the breach, its duration, the degree of responsibility, financial strength, previous breaches, and other circumstances can be taken into account.

On 14 July 2026, the Austrian FMA fined Western Union International Bank €42,000 for repeated breaches of DORA Article 19(4) and the related incident-reporting requirements. The breaches concerned the late submission of several initial and intermediate incident reports.

How to prepare for a DORA assessment?

Unfortunately, there is no universal checklist that fits every CASP and every DORA entity.

Instead, there are foundational steps that make the assessment much more manageable.

1. Establish the DORA scope

Document exactly which legal entity is being assessed, its MiCA status, services provided, critical and important functions, ICT-supported business processes, critical ICT systems, ICT third-party supply chain and whether the entity is subject to TLPT.

For example, for a crypto exchange, you might start with flows such as:

Custody → wallet infrastructure → key management/HSM → cloud infrastructure → relevant providers and subcontractors

And:

Trading → matching engine → APIs → databases → cloud infrastructure → external providers

The point is to connect regulated services to the systems and providers that actually make those services work.

2. Build the ICT asset and dependency inventory

For each critical or important system, document:

• System owner
• Supported business function
• Environment
• Data processed
• Dependencies and interfaces
• Access model
• Provider dependencies
• Backup and recovery arrangements
• Criticality
• Known vulnerabilities
• Relevant testing
• Open findings and remediation status

You should be able to move from a regulated business function down to the systems, infrastructure and providers supporting it.

3. Test the controls internally

Prepare evidence for controls such as:

• Privileged account inventory
• MFA configuration
• Access reviews
• Joiner/mover/leaver records
• Exceptions and their approval
• Remediation of exceptions
• Backup controls
• Vulnerability management
• Logging and monitoring
• Incident response
• Change management
• Encryption
• Key management

The important word here is evidence.

A control that exists only in a policy document is much weaker than a control that can be demonstrated through configuration, records, testing results and remediation history.

4. Prepare the incident-response policy and evidence

DORA requires processes for detecting, recording, classifying, escalating and responding to ICT-related incidents, including the communication and reporting of major incidents.

For a CASP, it is rational to test scenarios such as:

• Compromised employee credentials
• Cloud-provider outage
• Ransomware
• Wallet or key compromise
• Unauthorised transaction
• API compromise
• Smart-contract issue, where relevant
• Loss of availability of custody infrastructure

For each scenario, the organisation should know who detects the incident, who makes decisions, who is notified, how the affected service is contained, how it is recovered and what evidence is retained.

5. Test business continuity and recovery

DORA requires ICT business-continuity and response and recovery plans to be tested periodically. For financial entities other than microenterprises, Article 11(6)(a) requires these plans to be tested at least annually for ICT systems supporting all functions. In addition, such testing must be carried out following any substantive change to ICT systems supporting critical or important functions.

Basically, you must know what happens when a certain system is no longer available and be able to demonstrate:

• RTO (Recovery Time Objective)
• RPO (Recovery Point Objective)
• Backup strategy
• Redundancy
• Failover
• Recovery procedures
• Dependencies that could prevent recovery
• Recovery testing
• Test results
• Remediation of findings

A documented recovery procedure that has never been tested is not strong evidence of resilience.

6. Build the DORA testing programme

DORA explicitly describes a range of assessments that can form part of the digital operational resilience testing programme, including vulnerability assessments and scans, network security assessments, source-code reviews where appropriate, scenario-based tests, performance tests, end-to-end tests and penetration testing.

If the CASP is identified as subject to TLPT, that becomes a separate advanced testing obligation, generally performed at least every three years.

7. Create a findings-remediation system

Every finding identified during assessments should have a documented remediation path.

A simple structure is:

Finding → risk → owner → severity → deadline → remediation → retest → closure evidence

This also gives management a way to see what remains open and what residual risk the organisation is accepting.

8. Prepare the ICT third-party side separately

DORA requires financial entities to maintain a Register of Information covering their contractual arrangements with ICT third-party service providers. Particular attention is needed for arrangements supporting critical or important functions.

You therefore need to know:

• Who your ICT providers are
• What services they provide
• Which business functions depend on them
• How critical those services are
• What subcontracting arrangements exist
• What risks those dependencies create
• What your exit strategy is

This is also where the Register of Information becomes useful. It should not be treated as a reporting spreadsheet that someone updates once a year. It should reflect the actual technology and third-party dependency structure of the business.

9. Get management ready

DORA explicitly requires management bodies to maintain sufficient knowledge and skills to understand and assess ICT risk.

Management should therefore be able to understand and challenge, rather than simply approve, matters such as:

• The ICT risk-management framework
• Major ICT risks
• Important ICT incidents
• Third-party ICT risk
• Testing results
• Remediation progress
• Residual risk
• Risk tolerance

For this purpose, Hacken runs DORA training for senior management to help decision-makers understand their responsibilities and the evidence they should expect from the organisation.

10. Run a mock assessment

Now you basically retrace every previous step and look for gaps.

For each critical or important function, review:

• Risk assessment
• Relevant ICT systems and dependencies
• Latest vulnerability assessment
• Penetration-test findings
• Remediation status
• Business-continuity and recovery tests
• Relevant ICT providers
• Presence and accuracy of those providers in the Register of Information
• Incident-response procedure
• Evidence that incident-response arrangements were tested
• Outstanding findings and their owners

And then do the same for every other critical or important function.