DORA for CASPs: why being small doesn’t get you the simplified framework

Most crypto founders discover DORA somewhere in the middle of a MiCA application, assume it is a cybersecurity policy they can write in an afternoon, and then assume that because they are a ten-person company it barely applies. Two of those three assumptions are wrong, and the third one is wrong in an expensive way. Here is what DORA actually asks of a crypto-asset service provider — and the drafting trap that catches small CASPs specifically.

You are a financial entity. That is not a figure of speech.

DORA – Regulation (EU) 2022/2554 – has applied since 17 January 2025, and its scope provision does not treat crypto as a special case. Article 2(1)(f) puts crypto-asset service providers authorised under MiCA and issuers of asset-referenced tokens in the same list as banks, payment institutions, and investment firms. Article 2(2) then calls everything on that list, collectively, “financial entities”.

So the operational-resilience regime that applies to a bank applies to you. Not an adapted version of it. The same regulation.

The instinctive response from a small CASP is that surely there is a proportionality escape hatch for a company with eleven employees and one product. There is a proportionality principle (art. 4), and there is a microenterprise concept (art. 3(60)) – and both do less than founders expect. This is where the trap is.

The article 16 trap

DORA contains a genuinely lighter regime: the simplified ICT risk management framework in article 16. Entities that qualify for it are excused from articles 5–15 altogether and instead run a proportionate framework specified in Delegated Regulation (EU) 2024/1774.

It is a real relief, and it is not available to you.

Article 16(1) lists the entity types that get it: small and non-interconnected investment firms, exempted payment institutions and e-money institutions, certain small IORPs, and a handful of others. CASPs are not on that list. The list is closed, and no amount of being small puts you on it.

The consequence is precise and counterintuitive:

A four-person payment institution with an exemption gets article 16. A four-person CASP does not. Same headcount, different regime — because the legislator wrote a list and crypto was not on it.

So what does microenterprise status actually get you?

A short and unglamorous list. As a microenterprise CASP you are relieved of:

• the dedicated ICT third-party monitoring role – art. 5(3) applies expressly to “financial entities, other than microenterprises”, so you need not create a specific function or designate senior management to monitor ICT third-party arrangements (you must still manage that risk under arts. 28–30);
• the crisis management function for activating ICT business continuity plans (art. 11(6));
• regular internal audits of the ICT risk management framework, and periodic risk analyses of legacy systems – you run them when the audit plan or risk profile justifies it, rather than on a fixed cycle;
• notifying the competent authority of changes made following post-incident reviews, and estimating aggregated annual costs and losses from major incidents;
• the baseline digital operational resilience testing programme in art. 24, which applies to financial entities “other than microenterprises”.

Everything else stands: the governance framework, identification and classification of assets, protection, detection, response and recovery, backup, learning, secure development, incident classification and reporting, and the full ICT third-party regime.

And proportionality (art. 4) is not the escape hatch it is often taken for. It lets you scale the depth of controls to your size and risk profile – but it requires you to document and justify each simplification, article by article. Supervisors do not sanction a lean setup; they sanction the absence of the analysis that explains why the setup is lean. An undocumented “we’re small, so we did less” is the failure mode.

The management body is personally on the hook

Article 5(2) is the provision that changes conversations in board meetings. The management body must “define, approve, oversee and be responsible for the implementation of all arrangements related to the ICT risk management framework”, and bears ultimate responsibility for ICT risk. It approves the digital operational resilience strategy and the ICT risk tolerance, the business continuity and recovery plans, the ICT audit plan, the ICT budget, and the third-party ICT policy.

Article 5(4) goes further: members of the management body must maintain sufficient knowledge and skills on ICT risk, through regular training proportionate to the risk being managed. Read alongside the sanctioning regime in arts. 50–52 – which expressly permits Member States to introduce criminal penalties for serious breaches – this is a personal-accountability provision, not a delegation provision. “The CTO handles that” is not an answer a board can give.

Incident reporting: the clock is short

For major ICT-related incidents (classified under the criteria in Delegated Regulation (EU) 2024/1772 – clients affected, downtime, data losses, geographic spread, economic impact), the reporting cascade is:

Report	Deadline
Initial notification	within 4 hours of classifying the incident as major, and no later than 24 hours from becoming aware of it
Intermediate report	within 72 hours of the initial notification
Final report	within one month of incident closure, with root-cause analysis and full impact figures

Four hours is not a timeline you improvise on the day. It means the classification criteria are pre-mapped, the template is pre-filled to the extent it can be, and someone knows – at 3am, during an outage – who decides that this incident is “major” and who files. That decision tree is the deliverable, not the policy document that describes it.

Third-party risk: the register and the contracts

This is where most CASP files are thin, because it is the part that reaches outside the company.

The register of information (art. 28). You maintain a register of all contractual arrangements for ICT services, and submit it to your competent authority at least annually. Per the ITS templates, it captures each provider, the services and their criticality, where the service is performed and where data is processed, the subcontracting chain, start and end dates, exit strategies, and which arrangements support critical or important functions. For a CASP running on cloud infrastructure, a custody technology vendor, a chain-analytics provider, and a KYC vendor, the register is not a formality – it is a map of your actual dependency structure, and most firms have never drawn it.

The contracts (art. 30). Article 30(2) sets mandatory terms for every ICT contract: description of services, subcontracting conditions, the locations of service provision and data processing with advance notice of changes, data availability and integrity safeguards, service levels with consequences, incident assistance, cooperation with authorities, and termination rights with notice.

Article 30(3) then adds, for ICT services supporting critical or important functions: quantitative service-level targets, notice and reporting obligations for developments affecting the provider, contingency planning and testing, unrestricted rights of access, inspection and audit for you and for the competent authority, cooperation in TLPT where applicable, and exit-strategy support.

Read that list against the standard terms of service of a large cloud provider or a custody-tech vendor, and the gap is obvious. Those clauses are not in the box. Getting them requires either negotiation or, where the counterparty will not move, a documented assessment of the residual risk and an exit strategy that is real. The contracts you sign this year are the contracts your supervisor will read.

TLPT (arts. 26–27) – threat-led penetration testing, on a three-year cycle, aligned with TIBER-EU – applies only to entities designated by their competent authority as significant. Most CASPs will not be designated. Large CASPs providing custody, trading, or payment infrastructure across several Member States are a different conversation.

DORA and the MiCA application file

MiCA article 62 does not mention DORA. It requires, among other things, a programme of operations, the organisational structure, internal control mechanisms, and policies and procedures to identify, manage and mitigate ICT and operational risks, plus safeguarding and outsourcing arrangements.

In practice the two documents are the same document. National authorities reviewing applications in 2025–2026 expect ICT governance and resilience consistent with DORA, and the national application forms already demand ICT systems descriptions, security policies, incident management, backup and recovery, and ICT outsourcing. Full DORA compliance is not a formal precondition of MiCA authorisation – the two regimes are legally independent – but an authorised CASP becomes a DORA financial entity on day one, and a file that shows a credible DORA-aligned framework moves through review materially faster than one that treats ICT as an annex.

The practical implication: build the DORA framework as the ICT section of the MiCA file, not afterwards. Doing it twice is the expensive path, and doing it afterwards is how a CASP ends up authorised and non-compliant in the same quarter.

One overlap worth naming: any AI system you run – transaction monitoring, market surveillance, a customer-facing assistant – is an ICT asset inside DORA’s scope, and the AI Act layers AI-specific controls on top of it rather than replacing them. Same vendors, same register, one framework. That boundary is covered separately.

Poland: your DORA supervisor is not KNF

A wrinkle specific to the Polish market, and one that surprises people.

Poland still has no operational CASP procedure. The Crypto-Asset Market Act was vetoed three times – most recently on 11 June 2026 – and the MiCA transitional period expired on 1 July 2026. So a business serving Polish clients is authorised in another Member State and passports in under art. 65 of MiCA.

Now ask who supervises its DORA compliance. Article 46(d) of DORA designates, for CASPs and ART issuers, the competent authority designated under MiCA – which means the home-state authority. A CASP authorised in Cyprus, Estonia, or Lithuania and passporting into Poland reports its major ICT incidents to its home-state NCA and files its register of information there. KNF, having no MiCA CASP mandate, is not your DORA supervisor for that entity.

We serve Polish clients, so we deal with KNF — the wrong regulator, discovered during an incident, which is the worst possible moment.

A recurring assumption in Polish CASP files

This matters operationally. It determines which authority you notify within four hours at 3am, in which language, and on whose template. Firms that assume “we serve Polish clients, so we deal with KNF” have the wrong regulator in their incident-response playbook – and they find out during an incident, which is the worst possible moment to discover it.

The full picture of the Polish legislative gap and the passporting route is on the crypto licensing hub.

What I would actually do first

If you are a CASP – authorised, applying, or planning to – the sequence that works:

• Confirm your regime. You are a financial entity under art. 2(1)(f). You are not an art. 16 entity, whatever your headcount. Settle that before anyone starts writing policies against the wrong template.
• Draw the dependency map. The art. 28 register, done honestly, including the subcontracting chains. It will tell you which functions are critical or important, and that classification drives everything downstream.
• Read your vendor contracts against art. 30(2) and (3). Make the gap list. Decide, per vendor, whether you negotiate, accept and document, or exit.
• Build the incident decision tree. Who classifies, who files, on what template, within four hours.
• Put it in the board’s hands. Art. 5(2) means the management body approves the strategy and owns the risk – and art. 5(4) means they need the training to do it credibly.
• Fold it into the MiCA file. One framework, one document set, one review.

None of this is exotic. It is unglamorous, it takes longer than founders budget for, and it is the part of a CASP file that regulators read closely because it is the part that most applicants copy from somewhere else.