The Digital Operational Resilience Act is in effect across the EU since January 2025. All financial entities are subject to it. Most have written the frameworks. Fewer have built the infrastructure to evidence them under examination.
The Digital Operational Resilience Act went into effect across the EU on Jan. 17, 2025. Eighteen months on, most financial entities with significant crypto exposure have produced the governance documentation the regulation requires: ICT risk management frameworks, incident classification procedures, contingency plans. As authorities begin formal supervisory examinations, many are discovering that documentation and demonstrability are two different problems.
DORA's requirements are operational, not administrative. The regulation demands that firms prevent, detect, respond to, and recover from digital incidents, and that they can evidence each stage of that cycle to auditors and supervisors on request. A framework document describes the process. What an examiner asks for is the record of the process functioning: the alert that fired, the timestamp of first detection, the automated or manual response it triggered, and the evidence that monitoring was running continuously between incidents, not only during them.
The distinction matters because most of the security infrastructure financial entities have deployed for crypto-related operations was built for a different purpose. Incident response tools are designed to contain and investigate incidents after the fact. Audit tooling captures snapshots. Neither generates the kind of continuous, timestamped, retrievable monitoring record that DORA's traceability requirements are designed to produce.
A supervisory examination of a financial entity's DORA compliance will typically move through a series of concrete operational questions:
These questions have a common structure: they ask for the record of a specific moment, in a retrievable format, with enough context to establish that the monitoring was functioning as the framework document says it was. A firm that can produce that record for any incident in its history is evidencing DORA compliance. A firm that reconstructs the timeline from memory or from scattered logs across multiple systems is demonstrating the gap.
Onchain infrastructure falls within DORA's scope on a reasonable reading of its definitions. Smart contracts, wallet interactions, and blockchain-facing systems are ICT systems and networks under Article 3, and the protocols a firm interacts with operationally sit within that same perimeter. That means the same traceability requirements that apply to a firm's internal IT environment apply to its onchain exposure. An anomaly in a smart contract position, a governance manipulation on a protocol the firm holds exposure to, or an oracle price deviation affecting a firm's liquidity, all of these are ICT incidents that carry the same documentation expectations.
The firms best positioned for DORA examinations are those whose monitoring infrastructure generates a continuous, structured record of the onchain environment, not one that just captures incidents once they escalate. The lead-time problem is where many crypto-exposed financial entities are currently underequipped. DORA requires that firms demonstrate early detection, which means the alert log has to show the anomaly appearing before it became an incident, and the response record has to show that the firm acted on that signal rather than on the outcome.
Contingency planning under DORA carries similar evidentiary expectations. The regulation expects firms to maintain documented, tested plans for operational continuity following a digital incident. The word "tested" is doing meaningful work there. A plan that has never been exercised against a real or simulated incident is harder to evidence as operational.
The supervisory cycle for DORA is still in its early phase. Examinations are beginning, but enforcement actions remain limited. That window will not stay open indefinitely. Firms that treat DORA as a documentation project rather than an operational one will find the gap between what their frameworks describe and what their systems can demonstrate increasingly difficult to close under time pressure.
Hypernative's Transaction Guard enforces pre-execution policy governance and produces an auditable record of every approval and denial decision, with full simulation results and risk signal attribution. Address Screening provides counterparty due diligence records at the point of decision, documented in a format aligned with MiCA's requirements for defensible transaction approvals. For CASPs with exposure to DeFi protocols, Pool Toxicity Screening adds continuous monitoring of liquidity pool composition and risk drift, satisfying MiCA's expectation that indirect exposure is governed and evidenced, not assumed away.
Reach out for a demo of Hypernative’s solutions, tune into Hypernative’s blog and our social channels to keep up with the latest on cybersecurity in Web3.
Secure everything you build, run and own in Web3 with Hypernative.
Website | X (Twitter) | LinkedIn
