Does DORA apply to my company?

Most company owners and CEOs I speak to about DORA open by explaining why it does not reach them. It might be a software firm that sells into a couple of banks, or a small payment company sure it sits under the size where anyone cares. They are usually wrong, and they are usually uncomfortable when I walk them through why. DORA, the Digital Operational Resilience Act, applies to you if you are a financial entity operating in the EU, or an ICT third-party provider serving those entities. It has applied since 17 January 2025. If you are a bank, insurer, investment firm, payment or e-money institution, crypto-asset service provider, or a technology company supplying any of them, you are very likely in scope. Two tests decide it, and I put them to work in almost every one of those conversations.

Who does DORA apply to?

Two groups. Financial entities authorised or operating in the EU, and the ICT third-party providers that serve them. The two tests below tell you which of them is you, or whether both are.

Test 1: are you a "financial entity"?

DORA does not leave this to interpretation. It lists the financial entities it covers: credit institutions, payment institutions, e-money institutions, investment firms, crypto-asset service providers, insurance and reinsurance undertakings, and several more. If your firm holds an EU financial licence or authorisation, start from the assumption that you are in scope, and go looking for a specific exemption rather than hoping one applies to you.

Definition

Financial entity (DORA)

One of the categories of firm DORA lists directly, credit institutions, payment and e-money institutions, investment firms, crypto-asset service providers, and insurance and reinsurance undertakings among them. Holding an EU financial licence generally means you are a financial entity under DORA unless a specific exemption applies.

Article 2(1) names 20 types of financial entity. When I go through them with company owners, I group them by sector, because that is how they recognise themselves:

Then read the exclusions in Article 2(3), because that is where most of the wishful thinking ends. Only six groups are out: small alternative investment fund managers under Article 3(2) of the AIFM Directive, insurers exempted under Article 4 of Solvency II, pension institutions whose schemes have no more than 15 members in total, persons exempted under Articles 2 and 3 of MiFID II, insurance and reinsurance intermediaries that are micro, small or medium-sized enterprises, and post office giro institutions. Member states may also exclude a few entities listed in the Capital Requirements Directive. If you are not on that list, being small does not take you out. It only makes the load lighter.

Test 2: are you an ICT third-party provider to financial entities?

If you supply ICT services to EU financial entities, cloud, software, data, or managed services, DORA reaches you through your customers' own third-party risk requirements. If a regulator designates you critical, it reaches you directly, through its own oversight. Being based outside the EU does not get you out of it: what matters is that your customer is an in-scope financial entity. The direct route is no longer theoretical, either. On 18 November 2025 the three European Supervisory Authorities designated the first 19 critical ICT third-party providers, Amazon Web Services, Google Cloud and Microsoft among them. A critical provider that ignores its Lead Overseer can be charged up to 1% of its average daily worldwide turnover, every day, for up to six months. This is the test that catches technology suppliers off guard, because they rarely thought of themselves as regulated until a banking client sent them a DORA clause to sign. If that is you, it is worth understanding how a tool ends up a regulated third party in the first place.

What DORA requires if it applies

Once either test catches you, DORA's requirements fall into five areas:

• ICT risk management, a documented framework for identifying, protecting, detecting, and recovering.
• ICT-related incident reporting, classifying and reporting major incidents to your competent authority.
• Digital operational resilience testing, regular testing, up to threat-led penetration testing for larger entities.
• ICT third-party risk management, including the specific contractual terms required under Article 30.
• Information sharing, the voluntary exchange of cyber-threat intelligence.

Smaller entities get some relief. Under Article 16, small and non-interconnected investment firms, exempted payment and e-money institutions and small pension institutions may run a simplified ICT risk-management framework instead of Articles 5 to 15. Proportionality applies across the rest of DORA too, so the weight scales with your size and complexity.

The dates and clocks that matter

The incident clock is the one that hurts in practice. Four hours is not long enough to find out who is allowed to classify an incident as major, so settle that before you need it.

How COMPLY.Reg helps

The gap I see over and over is the distance between the PDF and the day job. DORA is a long regulation, and reading it does not tell your team what to actually do on Monday. Closing that gap is much of why we built COMPLY.Reg. It uses AI to pull DORA's individual requirements out of the text, maps each one to a control, and tracks the evidence that proves the control is working, so an audit reads as a traceable record instead of a last-minute scramble. You can keep your source documents on your own systems, and your compliance data is processed in the EU, which for me is not negotiable. If you are not sure DORA is the only regime you have to worry about, start with which EU regulations apply to your company.