Most regulated crypto firms in the EU can describe their obligations under MiCA and DORA in reasonable detail. Compliance officers can recite the notification deadlines, cite the relevant articles, and produce a policy document confirming that the firm understands what it must report. What a striking number of these same firms cannot do is actually produce a compliant initial notification within four hours of a real incident, because the organisational machinery to detect, classify, draft, approve and submit that notification has never been built, tested, or assigned to specific people with specific authority to act.
This is not a knowledge gap. It is an operational gap, and it is the one that gets exposed during an actual incident rather than during a desk-based compliance review. This guide sets out how to close it: the specific timelines and structures MiCA and DORA impose, and, more importantly, the internal workflow required to turn a detected incident into a submitted regulatory report before the clock runs out. For background on the substantive requirements of each framework, see our DORA compliance requirements guide and our MiCA compliance framework overview. This post assumes that grounding and focuses specifically on the reporting operation itself.
What You Are Required to Report and to Whom
Regulatory reporting for a crypto-asset service provider operating in the EU runs through two overlapping but distinct regimes, and firms need clarity on both before an incident forces the question.
MiCA reporting: authorisation-linked obligations
Under MiCA, CASP-authorised firms owe reporting obligations to the national competent authority (NCA) that granted their authorisation. This covers major incident notification, but also extends to ongoing obligations such as reporting material changes to the firm's programme of operations, governance, or risk profile. The reporting relationship is fundamentally with the NCA, not with ESMA directly, though ESMA sets the technical standards and coordinates supervisory convergence across member states.
DORA reporting: ICT resilience obligations
DORA applies a separate, parallel reporting track focused specifically on ICT-related incidents, meaning disruptions or compromises affecting information and communication technology systems, regardless of whether the incident also has a client-facing or financial dimension. DORA reporting also runs primarily through the NCA, using standardised reporting templates that ESMA, EBA and EIOPA have jointly developed to ensure consistency across the financial sector rather than treating crypto firms as a separate reporting silo.
Where the two regimes overlap
A single incident, such as a compromised administrative account that both disrupts a trading platform and originates from an ICT system failure, can trigger obligations under both frameworks at once. Firms that treat MiCA and DORA reporting as entirely separate processes, run by separate teams with no shared visibility, routinely miss this overlap and end up filing one notification while remaining unaware that a second, parallel obligation has also been triggered.
MiCA Major Incident Notification: Classification and Timelines
Article 23 of MiCA requires CASPs to notify their NCA of major incidents related to their crypto-asset services without undue delay. In practice, supervisory expectations and emerging technical standards converge on a structure that mirrors the DORA model closely: an initial notification, an intermediate report, and a final report.
Initial notification
The initial notification is expected within four hours of the incident being classified as major. This is a critical distinction that many firms get wrong: the clock starts at classification, not at first detection. An incident can sit unclassified for hours while a team investigates, and technically the notification clock has not yet started, but supervisors treat unreasonable delay in reaching a classification decision as a compliance failure in its own right. The initial notification does not need to contain a complete picture. It needs to establish that the firm is aware of a major incident, has begun its response, and will follow up with further detail.
Intermediate report
As the incident response progresses and more information becomes available, firms are expected to submit an intermediate report updating the NCA on the status of the incident, actions taken, and any change in assessed impact. There is no single universal deadline for this stage under MiCA in the way DORA specifies 72 hours, but firms should treat the DORA timeline as the practical benchmark given the convergence in supervisory expectations across both regimes.
Final report
The final report is submitted once the incident is resolved and root cause analysis is complete. It should cover what happened, why it happened, what the impact was in concrete terms, and what remediation has been or will be implemented to prevent recurrence. Supervisors read final reports closely for evidence of genuine root cause analysis rather than a superficial description of symptoms, and a weak final report can trigger follow-up supervisory engagement even after the incident itself is closed.
DORA ICT Incident Reporting: The Three-Stage Process
DORA Articles 19 and 20 set out the most detailed and prescriptive incident reporting regime affecting crypto firms operating within scope, and the timelines here are explicit rather than the "without undue delay" language MiCA uses.
Initial notification: within 4 hours of classification
Once an ICT-related incident is classified as major against DORA's defined criteria, the initial notification must reach the NCA within four hours. This uses a standardised reporting template covering the nature of the incident, systems and services affected, and the firm's initial assessment of severity.
Intermediate report: within 72 hours
The intermediate report follows within 72 hours of the initial notification, providing an updated status covering containment actions taken, any change in the assessed scope or severity of the incident, and confirmation of whether the incident is ongoing or resolved.
Final report: within one month
The final report is due within one month of the intermediate report, or in some cases from resolution of the incident depending on the finalised regulatory technical standards, and must include a full root cause analysis, the financial and operational impact incurred, and the corrective measures implemented. This report forms part of the supervisory record used to assess the firm's ongoing operational resilience posture, feeding into the same supervisory relationship that governs DORA TLPT requirements and other resilience testing obligations.
Standardised reporting templates
DORA's technical standards specify structured templates rather than free-text notifications, which means the internal reporting workflow needs to produce the specific data fields the template requires, not simply a narrative account of the incident. Firms that build their internal incident documentation around these fields from the outset avoid a scramble to reformat information under deadline pressure.
Regulators consistently find that firms which fail notifications do so not because they lacked the information, but because they had no documented workflow for turning an internal incident into a regulatory report. The gap is procedural, not informational.
From Detection to Report: Building the Internal Workflow
The four-hour classification clock is unforgiving, and it cannot be met by improvising a process during the incident itself. The workflow needs to exist, be documented, and be rehearsed before it is needed.
Step one: the alert reaches a defined recipient
Every incident starts with a detection event, whether from security logging and monitoring, a customer complaint, an internal report, or a third-party notification. That alert must route automatically to a named on-call function, not to a general inbox or a channel that may not be monitored outside business hours. Regulatory incidents do not respect office hours, and a workflow that assumes daytime staffing will fail its first genuine overnight test.
Step two: classification against pre-agreed criteria
A designated individual, typically the compliance officer or CISO, assesses the incident against documented classification criteria (covered in detail below) and makes a formal determination of whether the major incident threshold has been met. This decision, and the time it was made, must be logged immediately, since that timestamp starts the regulatory clock.
Step three: drafting the notification
A pre-built template, populated with the specific data fields the relevant regulatory template requires, should be drafted immediately following classification. This is not the moment to design a report format from scratch. The template should already exist, tested against a range of plausible incident scenarios, so that drafting is a matter of populating known fields rather than composing a document under time pressure.
Step four: internal approval
A senior sign-off, typically from the compliance officer or a named board-level individual accountable for regulatory relationships, should approve the notification before submission. This step needs a defined maximum time allocation, since the four-hour deadline includes this approval, not just the drafting.
Step five: submission and audit trail
The notification is submitted through the NCA's designated channel, and every step, from initial alert through classification, drafting, approval and submission, is logged with timestamps in a format that can be produced to the regulator on request. This audit trail is often what separates a firm that faces routine follow-up questions from one that faces a formal investigation into its reporting practices.
Incident Classification Criteria: What Triggers a Regulatory Report
Classification cannot be a subjective judgement made in the moment. DORA in particular sets out defined criteria for what constitutes a major ICT-related incident, and firms should adapt these into a documented internal threshold matrix covering both MiCA and DORA scenarios.
Number of clients or counterparties affected
An incident affecting a defined proportion or absolute number of clients, or a smaller number of critical institutional counterparties, should trigger the major incident threshold. This figure needs to be set as an actual number in the firm's internal policy, not left as an abstract concept to be judged during the incident itself.
Transaction value and financial impact
A monetary threshold, whether measured as absolute value affected or as a proportion of assets under custody or management, should be defined in advance. Firms handling institutional volumes need a threshold that reflects their actual scale, since a fixed figure appropriate for a small firm will fail to capture proportionally significant incidents at a larger one.
Reputational impact
Incidents likely to attract public, media or client attention, even where the direct financial or client impact is limited, should be weighed as a classification factor. Reputational criteria are inherently more judgement-based than the others, which is exactly why they need to be discussed and documented in advance rather than decided in the moment.
Data breach component
Any incident involving unauthorised access to or exposure of client data should be flagged as a likely trigger, both because of the direct regulatory obligations this creates and because data breaches frequently carry parallel reporting obligations under separate data protection law that need to be tracked alongside MiCA and DORA notifications.
Criticality of the affected service
An outage or compromise affecting a critical function, such as custody, settlement, or client order execution, should be classified more readily as major than an equivalent disruption to a non-critical internal system. The firm's own critical function mapping, ideally the same mapping used for business continuity and disaster recovery planning, should feed directly into this classification criterion.
Missing a Notification Deadline: Regulatory Consequences
Firms sometimes treat the notification deadline as a soft target, reasoning that a slightly late report covering a resolved incident carries limited practical risk. Supervisory practice does not support this assumption.
Direct enforcement exposure
Both MiCA and DORA give NCAs enforcement powers that extend to reporting failures independent of the underlying incident. A firm that resolves an incident cleanly but reports it late can still face enforcement action, financial penalties, or a formal remediation requirement focused specifically on its reporting function rather than its technical controls.
Escalated supervisory scrutiny
A missed or incomplete notification frequently triggers a broader supervisory review of the firm's overall compliance and risk management framework, on the reasonable basis that a firm unable to meet a defined reporting deadline may have other undocumented gaps in its control environment. What began as a single missed deadline can expand into a much wider examination.
Institutional counterparty due diligence
Institutional counterparties, custodians and banking partners increasingly ask directly about a firm's regulatory reporting history and incident notification track record during onboarding and periodic due diligence. A documented pattern of late or incomplete notifications is a specific, checkable fact that can materially affect these commercial relationships, independent of any formal regulatory penalty.
Loss of authorisation in severe cases
Persistent or serious reporting failures, particularly where they suggest a firm cannot reliably operate the governance and control functions MiCA authorisation depends on, can ultimately contribute to authorisation being reviewed, restricted or withdrawn. This is the tail-risk outcome, but it is the one that should motivate serious investment in the reporting function rather than treating it as a low-priority administrative task.
Designing the Regulatory Reporting Function
The organisations that handle regulatory reporting well treat it as a defined operational function with owners, tools and rehearsal, not as an ad hoc responsibility that falls to whoever is available when an incident occurs.
Named ownership with backup coverage
Assign a primary and backup owner for regulatory reporting, both with the authority to classify incidents and initiate the notification workflow. A single point of failure in this role, where the one person who understands the process is unreachable during an actual incident, is a common and entirely avoidable cause of missed deadlines.
Pre-built templates for every relevant regime
Maintain populated draft templates for MiCA and DORA notifications, structured around the specific data fields each regulatory technical standard requires, and review them each time the underlying technical standards are updated. Templates should be tested against realistic incident scenarios during tabletop exercises, not left untouched until the day they are actually needed.
Integration with the incident response plan
Regulatory notification cannot function as a separate process bolted onto incident response after the fact. It needs to be a defined stage within the same incident response plan that governs technical containment and remediation, with the classification decision point built explicitly into the response timeline from the outset.
Quarterly rehearsal
Run the reporting workflow through a tabletop exercise at least quarterly, using a realistic incident scenario, timing each stage from alert to submission. This is the only reliable way to discover that a template is missing a required field, an approver is unreachable at short notice, or the escalation path assumes a level of staffing the firm does not actually maintain outside business hours.
Maintaining a defensible audit trail
Every notification, whether MiCA or DORA, whether the incident was ultimately assessed as major or not, should leave a complete audit trail: when the alert was received, when classification occurred, who approved the notification, and when it was submitted. This record is the primary evidence a firm can produce to demonstrate genuine, functioning compliance rather than a policy document that has never been tested against reality.
Frequently Asked Questions
How much time do we have to notify regulators after a major incident under MiCA and DORA?
Both frameworks require an initial notification within 4 hours of the incident being classified as major, not from the moment it was first detected. Under DORA, an intermediate report follows within 72 hours and a final report within one month. MiCA follows a comparable initial, intermediate, and final report structure through the relevant competent authority.
Who decides whether an incident meets the threshold for a regulatory report?
This should be a named role within a documented workflow, typically the compliance officer or CISO acting against pre-agreed classification criteria, not an ad hoc judgement call made during the incident. The criteria should be written down and rehearsed before an incident occurs, so classification does not become the first bottleneck in the reporting clock.
What happens if we miss a MiCA or DORA notification deadline?
Consequences include enforcement action from the competent authority, financial penalties, mandatory remediation plans, increased supervisory scrutiny, and reputational damage with institutional counterparties who review incident reporting history during due diligence. A pattern of late or incomplete reporting is treated by supervisors as a governance failure in its own right, separate from the underlying incident.
Do we report to our national competent authority or to ESMA directly?
In almost all cases, the primary reporting channel is your national competent authority (NCA), the body that authorised your firm under MiCA or that supervises you under DORA. ESMA plays a coordination and standard-setting role and may receive aggregated or escalated information from NCAs, but firms should not assume a direct reporting line to ESMA replaces their NCA obligations.
Can the same incident require both a MiCA notification and a DORA notification?
Yes. An incident with both a client-facing operational impact and an ICT root cause, such as an outage caused by a compromised system that also disrupted client transactions, can trigger obligations under both frameworks simultaneously. Your reporting workflow should be built to recognise this overlap rather than treating MiCA and DORA reporting as entirely separate tracks.