DORA Compliance Requirements: What Financial Entities and Crypto-Asset Service Providers Must Demonstrate

DORA Is Not Forthcoming. It Is In Force.

The Digital Operational Resilience Act (DORA) entered application on 17 January 2025. It applies to over 22,000 financial entities and ICT third-party service providers operating within the EU. Security is no longer a matter of what is responsible. It is a matter of what is legally required.

DORA applies to banks, investment firms, insurance companies, and payment institutions. It also explicitly includes crypto-asset service providers. If your organisation operates anywhere in this space within EU jurisdiction, the obligation is not coming. It arrived. The question now is whether your programme generates the documented evidence regulators expect to see, or whether it does not.

This post sets out what DORA requires across its five pillars, who must comply, what the penalties for non-compliance are, and where most organisations, particularly those at the intersection of traditional finance and on-chain infrastructure, fall short on evidence.

What DORA Is

DORA is Regulation (EU) 2022/2554, introduced by the European Parliament and Council to harmonise ICT risk management and digital operational resilience requirements across the EU financial sector. Before DORA, each EU member state applied disparate, often generic regulations covering ICT risk. DORA eliminates that fragmentation. It establishes a single, consistent supervisory framework across all categories of in-scope entity, with uniform requirements for risk management, incident reporting, resilience testing, third-party oversight, and information sharing.

The regulation is administered by the three European Supervisory Authorities: the European Banking Authority (EBA), the European Securities and Markets Authority (ESMA), and the European Insurance and Occupational Pensions Authority (EIOPA). These bodies publish regulatory technical standards, issue guidance, and conduct oversight of critical ICT third-party providers designated under DORA's union-wide oversight framework.

DORA is not aspirational. It is enforceable, with penalties at the entity and individual level for non-compliance.

Who Must Comply With DORA

Article 2 of DORA specifies 21 categories of in-scope entity. These include:

• Credit institutions (banks)
• Payment institutions, including those exempted under PSD2
• Electronic money institutions
• Investment firms
• Crypto-asset service providers (CASPs) under MiCA
• Central securities depositories and central counterparties
• Trading venues and trade repositories
• Alternative investment fund managers and management companies
• Insurance and reinsurance undertakings
• Insurance intermediaries
• Institutions for occupational retirement provision
• Credit rating agencies
• Crowdfunding service providers
• ICT third-party service providers (where designated as critical by the ESAs)

The scope is deliberately broad. Crypto-asset service providers are explicitly captured. So are cloud service providers, data analytics firms, software vendors, and managed service providers where they serve in-scope financial entities and are designated as critical ICT third-party providers. A US-based or UK-based organisation serving EU financial entities is not automatically outside scope. DORA's extraterritorial reach, similar in logic to GDPR, means that where ICT services are provided to in-scope EU entities, the contractual obligations DORA imposes flow through to those providers regardless of where they are headquartered.

For blockchain-native organisations, the CASP designation matters most. Any entity operating a virtual asset exchange, custody platform, lending service, or advisory operation within the EU under a MiCA licence is an in-scope entity under DORA. The two frameworks are deliberately complementary. MiCA provides the market conduct and financial authorisation framework. DORA provides the operational resilience and ICT security requirements that sit beneath it.

Who Is Exempt

DORA explicitly exempts a small number of categories. These include managers of alternative investment funds below the de minimis thresholds in the AIFMD, small insurance and reinsurance undertakings below Solvency II thresholds, occupational retirement provision institutions with fewer than 15 members, and certain micro and small enterprise insurance intermediaries. Member states may extend exemptions within defined parameters.

If your organisation is in any doubt about whether it is in scope, the starting assumption should be that it is. The exemptions are narrow and specific. They are not a general escape route for smaller or newer entities in the financial or digital asset sector.

The Five Pillars of DORA

Pillar 1: ICT Risk Management

DORA requires in-scope entities to maintain a comprehensive, documented ICT risk management framework. This is not a reference to a generic IT security policy. The framework must identify and classify critical and important functions supported by ICT systems; continuously monitor all sources of ICT risk; establish protection and prevention measures aligned to that monitoring; set up prompt detection capabilities for anomalous activity; and put in place business continuity policies and disaster recovery plans, including annual testing of those plans.

Governance is a hard requirement. Entities must appoint responsible roles with defined reporting lines into senior management. Leadership is expected to have active oversight of the ICT risk management framework, not delegated passive awareness. Board-level sign-off on risk appetite thresholds is a regulatory expectation, not a matter of internal discretion.

The practical gap for most organisations is between what they believe their risk management framework covers and what is actually documented. DORA regulators review evidence. A framework that exists in practice but not in writing, or that is documented at a level of generality that does not reflect the actual operational environment, is insufficient. The mapping of dependencies, including third-party ICT dependencies supporting critical functions, must be specific and current.

Pillar 2: ICT-Related Incident Management, Classification and Reporting

DORA mandates a structured, tiered approach to managing and reporting ICT-related incidents. Entities must define classification criteria for what constitutes a major incident based on severity indicators including service disruption, data loss, client impact, and financial harm. Once an incident is classified as major, reporting to the competent authority is mandatory and structured across three phases:

• Initial notification: Submitted within four hours of the entity becoming aware that an incident is major (and no later than 24 hours after first detection of the incident)
• Intermediate report: A more detailed update within 72 hours of the initial notification
• Final report: A comprehensive incident report, including root cause analysis and corrective actions, within one month of the initial notification

These timelines are not aspirational targets. They are regulatory requirements. Entities that do not have real-time detection, pre-defined escalation paths, and practiced reporting workflows will struggle to meet them under actual incident conditions. Regulators do not grant informal extensions because internal processes were not ready.

For organisations operating on-chain infrastructure, the incident classification challenge has an added dimension. On-chain events, including protocol exploits, bridge drains, and governance attacks, may not trigger conventional IT monitoring alerts. The classification framework must be capable of capturing on-chain events within the definition of ICT-related incidents where they affect the entity's digital operations. Most generic incident management frameworks were not built with this in mind.

Pillar 3: Digital Operational Resilience Testing

DORA does not just require plans. It requires proof that those plans work under pressure. All in-scope entities must conduct regular resilience testing of their ICT systems. DORA specifies two distinct tiers:

Basic testing applies to all in-scope entities and includes vulnerability assessments, source code reviews, network security assessments, gap analyses, and scenario-based testing. These must be conducted on a regular basis and must cover all supporting ICT systems, not only production-facing infrastructure.

Threat-Led Penetration Testing (TLPT) is required for entities identified by competent authorities as significant, based on their systemic importance, risk profile, and operational complexity. TLPT must be conducted at least every three years. It is materially different from conventional penetration testing. A TLPT exercise simulates a realistic adversarial attack against live production systems, using threat intelligence specific to the entity's profile and threat landscape. The test must be scoped and executed by certified, independent external testers. The resulting report must be submitted to the competent authority in a standardised format.

The regulatory technical standards for TLPT under DORA reference the TIBER-EU framework. Entities subject to TLPT should treat it as a significant, resource-intensive exercise that requires planning, threat intelligence inputs, and independent external execution. A standard annual penetration test conducted against a scoped subset of non-production systems does not satisfy the TLPT requirement.

Pillar 4: ICT Third-Party Risk Management

Outsourcing ICT functions does not transfer the regulatory responsibility for managing the risks those functions carry. DORA is explicit on this. Entities must treat third-party ICT risk as a first-order operational risk, not an administrative onboarding item.

The practical requirements under this pillar include:

• Pre-contract due diligence on ICT service providers, covering security posture, resilience capabilities, regulatory alignment, and subcontracting arrangements
• Contractual provisions mandating that providers cooperate with resilience testing, provide unrestricted access rights during audits and inspections, and include breach notification obligations
• An up-to-date, comprehensive register of all ICT third-party arrangements, including subcontractors, classified by criticality
• Continuous monitoring of vendor performance and risk against defined indicators, not periodic point-in-time reviews
• Exit and continuity plans ensuring that if a vendor fails or must be replaced, critical functions can continue without material disruption

For DeFi-native and blockchain-native entities, this pillar creates obligations they may not have considered. Node infrastructure providers, RPC providers, oracle networks, bridge operators, and custody technology providers are all ICT third parties for the purposes of DORA. If they support critical or important functions, they fall within scope of the third-party risk management requirements. The contractual and monitoring obligations apply regardless of whether those providers are themselves regulated entities.

Pillar 5: Information Sharing

The fifth pillar encourages in-scope entities to participate in threat intelligence sharing arrangements with other financial entities. This is the only pillar that is not strictly mandatory, but it is explicitly promoted by the regulation as a mechanism for building sector-wide resilience. Entities that participate in formal information-sharing groups, such as ISACs focused on financial services, benefit from earlier visibility into emerging threat vectors and attack patterns.

Participation must be governed. Entities sharing threat intelligence must comply with GDPR, define what categories of information may be shared and with whom, and maintain oversight of redaction and transmission practices. Information sharing without governance is not what DORA contemplates.

The Penalties for Non-Compliance

DORA establishes that member states must ensure their competent authorities have the power to impose administrative sanctions and remedial measures. The specific penalty levels are set at member state level, but DORA provides the framework:

• For in-scope financial entities: penalties of up to 2% of total annual worldwide turnover, or up to 1% of average daily worldwide turnover for each day of continuing infringement. Individual executives in non-compliant entities may face personal penalties of up to EUR 1,000,000.
• For critical ICT third-party providers: periodic penalty payments of up to 1% of average daily worldwide turnover for each day of non-compliance with oversight measures, for a period of up to six months.

Beyond financial penalties, DORA authorises competent authorities to issue public reprimands identifying the entity and the nature of the violation, impose temporary operational restrictions, and, in serious cases, require the suspension or cessation of specific services. Senior executives can face personal liability.

The reputational dimension is separate from the financial penalty. A public reprimand under DORA, published by a competent authority, is a material event for any regulated entity. For institutional counterparties and investors conducting due diligence, regulatory standing is a standard screening criterion. Non-compliance is not an abstract risk. It is a business risk.

Why Documentation Is the Specific Failure Point

A significant proportion of DORA readiness assessments reveal organisations that have invested in the underlying security programme but have not built the evidence trail regulators require to verify it. The ICT risk management framework exists, but it has not been mapped to DORA's specific classification and governance requirements. The incident response process works, but it has not been tested against realistic scenarios and the testing record has not been retained. The penetration test was conducted, but the report scope did not cover all critical systems and was not structured for regulatory submission.

DORA regulators review documentation, not intentions. The gap between what an organisation believes about its own security posture and what it can demonstrate to a regulator is where most compliance failures originate. This gap is particularly common in two types of organisation. The first is traditional financial institutions entering on-chain infrastructure, which typically have governance structures and policy frameworks but lack documentation of how those frameworks have been tested against on-chain-specific threat models. The second is blockchain-native entities pursuing CASP licensing, which typically have strong technical security practices but have not built the governance layer, documented evidence trails, or regulatory-grade reporting that DORA requires.

Where Blockchain-Native Entities Specifically Fall Short

Crypto-asset service providers approaching DORA compliance for the first time tend to encounter three specific gaps.

The first is the ICT risk management framework at governance level. Smart contract audits and on-chain monitoring are not the same as a documented ICT risk management framework with board-level ownership, defined risk appetite thresholds, and a continuously maintained dependency map of critical functions. Most blockchain-native entities have invested heavily in the former and not at all in the latter.

The second is the incident management timeline. A 24-hour initial detection-to-classification requirement and a four-hour competent authority notification window demand real-time alerting, practiced escalation procedures, and pre-approved reporting templates. On-chain events move faster than traditional IT incidents. An exploit that begins with a single test transaction and completes within a single block leaves no recovery window between detection and loss. If the incident response process has not been designed and tested for this pace, the DORA reporting timeline will not be met.

The third is third-party risk management for on-chain dependencies. A CASP using a third-party oracle, bridge, or custody technology provider has an ICT third-party arrangement within the meaning of DORA. The due diligence, contractual, and monitoring obligations apply. This is not a theoretical concern. Oracle manipulation was the root cause of multiple nine-figure losses in 2024 and 2025. DORA's third-party risk management pillar exists precisely because regulators understand that ICT risk does not stop at the entity's own perimeter.

How a Security Review Generates the Evidence DORA Requires

DORA compliance is not a one-time certification. It is an ongoing programme with annual, quarterly, and event-driven components. What distinguishes a compliant programme from a non-compliant one is not primarily the quality of the underlying security controls. It is whether those controls are documented, tested, and evidenced in a form regulators can assess.

A structured security review generates that evidence. A smart contract and infrastructure audit, scoped to cover all critical functions and conducted by an independent third party, satisfies DORA's annual assessment requirement under the resilience testing pillar. A threat-led penetration test, scoped and executed to the TIBER-EU standard, satisfies the TLPT requirement for entities designated as significant. An operational security review covering key management architecture, access control design, and incident response procedures produces the documented evidence required to support the ICT risk management framework. Each of these reviews must produce a report structured for regulatory submission, not only internal findings.

The distinction matters. A security review that produces actionable internal findings but does not document scope, methodology, evidence base, and remediation status in a format regulators recognise is operationally useful but regulatorily insufficient. The evidence trail and the security programme are both required.

What We Provide

Security4Web3 works at the intersection of institutional-grade cybersecurity and on-chain infrastructure. For organisations operating under DORA, that combination is directly relevant. DORA applies to entities operating in both environments simultaneously, and the security review programme required to satisfy it must cover both.

For DORA compliance specifically, our work covers:

• ICT risk management framework review and documentation mapping your existing controls to DORA's specific requirements, identifying gaps, and building the evidenced documentation trail regulators expect
• Smart contract and on-chain infrastructure audit scoped to cover all critical and important functions, conducted independently, and structured for regulatory submission
• Threat-led penetration testing of production environments against realistic threat actor profiles specific to your entity type and operational footprint
• Incident response design and testing building the classification framework, escalation procedures, reporting templates, and competent authority notification workflows required to meet DORA's incident reporting timelines
• Third-party ICT risk assessment covering on-chain dependencies including oracle networks, bridge infrastructure, custody technology, and RPC providers that support critical functions
• Operational security review documenting key management architecture, multisig governance, access control design, and wallet custody procedures to the standard required for DORA's ICT risk management framework

Our reports are written for regulatory audiences. They are structured to satisfy competent authority review, with scope, methodology, evidence, findings, and remediation status documented in the format regulators expect. Where your compliance team needs to respond to a regulator's request for evidence of a specific DORA requirement, our report should be the document you provide.

Where to Start

If your organisation is in scope under DORA and has not yet conducted a formal gap analysis against the regulation's five pillars, that is the starting point. A gap analysis identifies what your existing programme covers, where the documentation is insufficient, and what work is required to close the gap. It produces a prioritised remediation plan and a realistic view of how your evidence trail compares to what DORA regulators will assess.

For organisations that have already conducted a gap analysis and are working through implementation, the next priority is typically the ICT risk management framework documentation and the resilience testing programme, since these generate the evidence base for almost every other DORA requirement.

For CASPs and blockchain-native entities approaching DORA compliance for the first time alongside their MiCA authorisation process, the security programme DORA requires and the security programme MiCA requires overlap significantly. A single, well-scoped review programme can address both, provided the documentation is structured to satisfy both frameworks. Starting that process early creates significantly less pressure than attempting to build both evidence trails simultaneously under a regulatory deadline.