Does DORA apply to us? Entities in scope

Does DORA apply to us? Start with the 20 entity types in Article 2

A customer, contract or regulator now asks whether DORA applies to your organization. Start with Article 2(1), which lists 20 types of financial entity, points (a) to (t), and has applied since 17 January 2025. If your licence or activity matches one of those types, DORA applies to you directly, because it is a regulation that needs no national transposition. The list covers banking, payment, markets, insurance, fund management, pension, credit rating, benchmark, crowdfunding and securitisation activities, along with crypto-asset service providers. Read the text of the points themselves, since the wording of your licence category matters more than the name of your business.

The answer then depends on four checks. First, confirm your licence type against the Article 2(1) points. Second, check the exclusions in Article 2(3), which cover, among others, small alternative investment fund managers, small insurers and occupational pension schemes with 15 or fewer members. Third, ask whether your home member state has used the option in Article 2(4) to exclude certain credit institutions located in its territory, and confirm this with your competent authority. Fourth, test whether you qualify as a microenterprise under Article 3(60), because that status relaxes several obligations and may move you into the simplified framework in Article 16. Record each check in writing, since the same answer will be needed for supervisors and auditors.

DeployOpen can help you prepare systems and evidence for this scoping work, but it does not decide scope. Your competent authority supervises DORA compliance and makes the final call on how your entity is classified, and only an independent auditor issues any report on your controls. Ask any implementation partner to put in writing which systems, documents and records it will prepare, and which decisions remain with your management body and your authority. Any engagement should begin with an agreed scope, so that the boundaries of the scoping review are clear before work starts.

Which financial entity types DORA covers and how to check them

This table groups the 20 financial entity types in Article 2(1), plus ICT third-party providers, by the authorisation or registration that places an entity in scope. Run the check column against your own licence, registration or exemption before assuming you are in or out. Scope turns on your regulated status first, then on any exclusions or size tests.

Entity group	Article 2(1) types	Check against your authorisation
Credit institutions	Credit institutions	Confirm your banking licence. Check whether the ECB supervises you as a significant institution.
Payments and e-money	Payment institutions, electronic money institutions, account information service providers	Confirm your PSD2 or E-Money Directive authorisation. If an exemption applies, check the simplified regime in Article 16.
Investment and market infrastructure	Investment firms, trading venues, central securities depositories, central counterparties, trade repositories	Confirm your investment or market infrastructure authorisation. Microenterprise relief does not apply to trading venues, CCPs, CSDs or trade repositories.
Crypto-assets	Crypto-asset service providers, issuers of asset-referenced tokens	Confirm your authorisation to provide crypto-asset services or to issue asset-referenced tokens.
Funds and data reporting	Alternative investment fund managers, management companies, data reporting service providers	Confirm your AIFM or management company authorisation. Small AIFMs under AIFMD Article 3(2) are excluded, so verify your size.
Insurance	Insurance and reinsurance undertakings, insurance intermediaries	Confirm your Solvency II authorisation. Small insurers and micro, small or medium intermediaries are excluded, so check both tests.
Occupational pensions	Institutions for occupational retirement provision	Count your scheme members. Schemes with no more than 15 members in total are excluded under Article 2(3).
Ratings, benchmarks, crowdfunding and securitisation	Credit rating agencies, administrators of critical benchmarks, crowdfunding service providers, securitisation repositories	Confirm the registration or authorisation for your activity with your competent authority.
Member state exclusions and ICT providers	CRD entities in opted-out member states (Article 2(4)); ICT third-party service providers (Article 2(1)(u))	Check whether your state has excluded you. If you are an ICT provider, obligations arrive through customer contracts.

Exclusions and member state options that change the answer

Article 2(3) of DORA excludes certain small alternative investment fund managers that fall under the small-manager carve-out in Article 3(2) of the AIFMD. The exclusion depends on the AIFMD test, not on a general notion of small size, so the fund manager must first establish whether it meets that test and whether its national authority treats it as within the carve-out.

Start from the AIFMD test: Check the manager's assets under management and its leverage and redemption profile against the AIFMD carve-out criteria, not against DORA's own thresholds.
Confirm the category: A manager that is excluded from AIFMD authorization may still be an entity in scope under other points of Article 2(1), so classify it separately.
Watch for changes: Assets under management can grow past the threshold, which removes the exclusion for future periods.
Document the basis: Keep the analysis and the authority's view on file for supervisors.
Note the dependency: Any fund services outsourced to third parties still bring those providers into DORA's contract rules.

Confirm with your national competent authority whether the exclusion applies to your specific structure before you omit DORA controls.

How microenterprise and simplified regime status changes the obligations

Smaller and specially licensed financial entities can carry lighter DORA duties, but only after they confirm which category they fall into. The four cards below set out the size test, the relaxed governance duties, the simplified ICT framework and the duties that still apply to exempted entities.

Microenterprise size test

Under Article 3(60), a microenterprise is a financial entity with fewer than 10 employees and an annual turnover and/or balance sheet total of no more than EUR 2 million. Trading venues, central counterparties, trade repositories and central securities depositories are excluded from this category even if they are small. Both the headcount and the financial limits must be checked against the entity's most recent figures, and the group context should be reviewed before concluding that status applies.

Relaxed internal audit duties

Several obligations are relaxed for microenterprises, including the internal audit and independent control function requirements in Article 6. The entity still needs a documented control framework and must still show that someone reviews its ICT risk management. Confirm with the competent authority how it expects a microenterprise to evidence independent review, because the relaxation changes who performs the work, not whether the work is needed.

Simplified ICT risk framework

Article 16(1) places small and non-interconnected investment firms, exempted payment and electronic money institutions, certain exempted credit institutions and small occupational pension institutions under a simplified ICT risk management framework instead of Articles 5 to 15. Eligibility depends on the licence and the entity type, not only on size. Entities should confirm in writing which category their authorisation places them in before adopting the simplified framework.

Duties that still apply

Exempted entities are not free of DORA. Payment and electronic money institutions exempted under PSD2 and the E-Money Directive remain within Article 2(1)(b) and (d), and their ICT providers' contracts, incident handling and testing expectations still need to be managed. Ask the authority which chapters continue to apply and document the exemption basis, since supervisors will request it during review.

Which entities must run threat-led penetration testing

Threat-led penetration testing applies only to entities that their competent authority identifies under Article 26(8) of DORA, not to every financial entity in scope. Being in scope under Article 2 is necessary but does not by itself oblige an entity to run TLPT. The authority makes the identification decision, so the first practical step is to ask your supervisor directly whether you have been identified and, if so, on what basis. Do not assume your size or sector settles the question in either direction.

The default categories in Article 2(2) of Delegated Regulation (EU) 2025/1190 are a useful starting point for that conversation. They name G-SII and O-SII banks, central securities depositories, central counterparties, and payment institutions whose annual payment transactions exceed EUR 150 billion in each of the two preceding years. Work out now whether your own figures sit near that threshold, because the test applies to the two preceding years and a change in volume can move you into scope. Also keep in mind that the authority can identify entities beyond these defaults, so the list is not a complete boundary. Ask for the identification decision in writing, including the date it takes effect and the reasons it cites.

If you are identified, confirm early whether a TIBER-EU test can be used to meet the DORA requirement, and what the authority will need to see to accept it, such as the scope, the threat intelligence used and the closure documentation. Confirm this with the authority and with the testing provider in writing before procurement begins, since the testing framework and its deliverables shape the timeline and the contracts you sign. Entities that are not identified do not need to run TLPT, but they still carry basic testing obligations under Chapter IV, so the identification decision does not remove the need for a testing programme.

How ICT providers are caught through contracts and oversight

Article 2(1)(u) names ICT third-party service providers, but it does not put most of them directly under DORA's supervision. Their obligations arrive mainly through the contracts that financial entities must sign under Article 30. The financial entity owns the third-party risk duties, so the practical question for a provider is usually what its customer's contract requires it to accept, not whether DORA applies to it as a standalone legal subject. Direct oversight by the European Supervisory Authorities follows only if the provider is designated critical under the oversight framework in Articles 31 to 44. Until that designation happens, the ESAs do not supervise the provider itself.

For a SaaS or self-hosted platform vendor, this means the vendor is usually reached through its customer's contract. A bank, payment institution or insurer that runs an open-source platform in its own cloud account will typically treat the software supplier, any hosting provider and any managed service partner as ICT third parties in its register and due diligence. As a check, the reader should list each supplier that touches a function, map which contract covers it, and confirm whether that contract contains the Article 30 clauses. Where the platform is installed and operated by an implementation partner, the partner's scope of work, access rights and subcontractors should be reviewed in the same way, because the financial entity will be asked to evidence them.

The ESAs also considered whether statutory auditors and audit firms should be brought into DORA's scope. In report JC 2025 85, issued on 4 December 2025 in response to the Commission under Article 58(3), they concluded that this is not warranted at this stage. Readers who advise audit firms should therefore not assume a DORA obligation for them today. Readers should still confirm the current position with their competent authority, because the Commission's review under Article 58(1), due by 17 January 2028, remains open.

What to do in the next 30 days to confirm scope

This sequence turns the question of whether DORA applies into a documented scope decision that the management body can sign and that a competent authority could later review. Each step produces a specific record, so the conclusion rests on evidence rather than on memory or assumption.

Pull the authorisation or registration record
Start by collecting the licence, authorisation, registration or exemption notice that defines what the entity is legally allowed to do, such as a credit institution licence, a payment institution authorisation, or an exemption under PSD2 or the E-Money Directive. Compare the wording with the 20 entity types in Article 2(1) of DORA. The output is a dated file of these documents, held by the compliance lead, that shows the legal basis on which the entity sits within or outside the Regulation.
Map the sectoral regime and supervisor
Identify the sectoral directive or regulation that governs the entity and the national competent authority that supervises it under Article 46. Where the entity is a significant credit institution, confirm whether the ECB is the supervisor under the Single Supervisory Mechanism. The output is a one-page register entry naming the regime, the supervisor and the contact route, which the compliance team should confirm against the supervisor's own published list.
Check exclusions and member state options
Test the entity against the exclusions in Article 2(3), including small alternative investment fund managers, small insurers, small occupational pension schemes and micro insurance intermediaries. Then check whether the home member state has used the option in Article 2(4) to exclude certain Capital Requirements Directive entities. Where the answer depends on national law, record the question for the authority. The output is an exclusion analysis that cites the article relied on for each conclusion.
Collect headcount and turnover for microenterprise tests
Gather the employee count and the annual turnover and balance sheet total for the last financial year, then compare them with the microenterprise definition in Article 3(60). Remember that trading venues, central counterparties, trade repositories and central securities depositories cannot qualify. The finance function should confirm the figures, and the output is a signed data sheet showing the thresholds and the result. Where the entity sits close to a threshold, record the trend and the approach to monitoring it.
Check the simplified regime and TLPT identification
Determine whether the entity falls under the simplified ICT risk management framework in Article 16(1), and whether it could be identified for threat-led penetration testing under Article 26(8). For the TLPT question, compare the entity against the default categories in Delegated Regulation (EU) 2025/1190, Article 2(2), and ask the competent authority whether any identification decision has been made. The output is a short memo listing which obligations are relaxed and which apply in full.
Request written decisions from the competent authority
Where scope depends on an Article 2(4) national choice, an identification decision or an uncertain sectoral classification, send a written query to the competent authority and keep the reply. Ask for confirmation of the entity's status rather than assuming it. The output is a correspondence file containing each question, each answer and the date received, which the management body can refer to in the scope memo.
List ICT services supporting critical or important functions
Inventory the ICT services the entity uses, including cloud, hosting, software-as-a-service, intra-group and self-hosted open-source platforms run in the entity's own environment. Mark those that support critical or important functions, and note which providers are ICT third-party service providers under Article 2(1)(u). The output is a draft list linked to the register of information, which shows where contract and oversight obligations are likely to arise.
Sign the scope memo with the management body
Bring the evidence from the previous steps together in a scope memo that states which entity types apply, which exclusions or options were relied on, which regime applies, whether microenterprise or simplified rules apply, whether TLPT is a possibility, and which ICT services are in scope. The management body reviews and signs it, and the memo is filed with the open questions and their status. The output is a signed, dated scope memo that becomes the starting point for the gap analysis.

What to ask an implementation partner before scoping work

Before agreeing a fixed scope for DORA readiness work, check how a partner handles applicability, documentation, roles and overlap with other regimes. The answers show whether the engagement will produce evidence your competent authority can review, or a document set that assumes an answer nobody has confirmed.

Confirmation of applicability without legal advice

Ask whether the partner will confirm which of the 20 types of financial entity in Article 2(1) you fall into, and whether they will say so in writing as technical input only. A reliable partner will walk through the exclusions in Article 2(3), any member state option under Article 2(4), and the microenterprise and simplified regime tests, then tell you to take the legal conclusion to counsel or your competent authority. Ask for the applicability memo to name who reviewed it and what it does not cover.

Documented scope decision

Ask how the partner records the reasoning behind the scope decision: which entity type, which legal entities in the group, which ICT systems and which ICT providers were considered in or out. The record should list the facts relied on, such as headcount and turnover for the microenterprise test, and name the people at your organization who approved it. Without this record, a later supervisory question about why a service was left out has no answer.

Separation of preparation and independent assessment

Confirm in writing that the partner prepares systems, policies, registers and evidence, while your management body owns the controls and only an independent auditor or your competent authority reviews or attests to them. Ask which deliverables the partner will not sign, and who will sign the register of information and the management body approvals. This keeps the readiness work from being presented as an assurance opinion it cannot give.

Handling of NIS2 overlap

Financial entities identified as essential or important under NIS2 fall under DORA as the sector-specific act for Article 4 of NIS2, so DORA's ICT risk and reporting rules replace NIS2's for those obligations. Ask how the partner maps which requirements remain under NIS2 and which move to DORA, and whether they keep that mapping current with the Digital Omnibus proposal COM(2025) 837 under review. Ask for the mapping to be a written deliverable with a named reviewer.

Written scope and deliverables before work starts

Ask for the scope, deliverables, acceptance criteria and timeline to be agreed in writing before any work begins, with each deliverable named and its evidence location stated. Check whether exclusions are listed, such as ICT providers, legacy systems or group entities, and who decides on changes. A partner should also state that the work will not guarantee a supervisory outcome, since that depends on your entity and on the authority that reviews it.

Common questions about whether DORA applies

Does DORA apply to a non-EU firm serving EU clients?

DORA applies to a non-EU firm only when it is an entity of one of the 20 types listed in Article 2(1) and it operates in the EU, typically through an authorized EU entity or branch. Scope follows the regulated activity and the legal entity that holds the authorization, not the location of the parent company or the data center. A firm that serves EU clients from outside the EU without an EU authorization should get written advice from counsel or its national competent authority on whether it is caught. Ask counsel to map each EU entity against the Article 2(1) categories and to confirm which national authority supervises it.

Can we be exempt from DORA because we are small?

Size alone does not remove an entity from DORA, but it can change the obligations. Some small entities are excluded under Article 2(3), including small alternative investment fund managers, small insurers and occupational pension institutions with no more than 15 members. Others remain in scope but move to the simplified ICT risk management framework of Article 16, and microenterprises get relaxed obligations, including those on internal audit and the independent control function in Article 6. Member states may also exclude certain credit institutions under Article 2(4). Confirm your category and any national exclusion with your competent authority before relying on one.

Does a microenterprise still need DORA policies?

Yes, in most cases a microenterprise in scope still needs an ICT risk management framework, an incident process and contracts that meet DORA's requirements, although several obligations are reduced. Under Article 3(60), a microenterprise has fewer than 10 employees and turnover or balance sheet total of no more than EUR 2 million, and it is excluded from trading venues, central counterparties, trade repositories and central securities depositories. The reduction is in depth and formality, not in whether ICT risk is managed. Document a proportionate framework, record the reasoning for each relaxed item, and keep evidence that the framework is reviewed.

Who decides whether an entity must run threat-led penetration testing?

The competent authority decides. Under Article 26(8), threat-led penetration testing (TLPT) applies only to entities that the authority identifies, so an entity cannot select itself. Delegated Regulation (EU) 2025/1190 sets default categories in Article 2(2), including G-SII and O-SII banks, central securities depositories, central counterparties, and payment institutions above EUR 150 billion of annual payment transactions in each of the two preceding years. Entities outside those categories should expect their authority to assess them, and should confirm that assessment in writing. Other entities still need the basic testing required by Chapter IV.

Does DORA apply directly to our ICT vendor?

DORA reaches an ICT provider mainly through the contracts that financial entities must sign under Article 30, not as a direct licensing regime. Article 2(1)(u) lists ICT third-party service providers within scope, but most duties arrive as contract clauses, audit rights, subcontracting conditions and incident assistance that your customers will require. A provider designated as critical is overseen directly by the European Supervisory Authorities under Articles 31 to 44. Vendors should ask their financial customers which clauses they must impose and which register identifiers they need, and should confirm the designation status with the customers themselves.

How much effort is the scoping work, and what must we provide?

Scoping is usually a bounded piece of work, but its size depends on how many legal entities, regulated activities and ICT services you have. The main inputs are your authorization status for each entity, your category under Article 2(1), any member state exclusion, your NIS2 status if applicable, and an inventory of ICT services and providers. Expect the effort to grow with the number of entities and the number of third-party relationships to classify. Ask any scoping partner for a written scope listing the entities, documents reviewed, decisions to be recorded and the deliverables, and confirm that the final determination stays with your organization and its authority.

Which primary sources to read to confirm your scope

Start with Article 2 of Regulation (EU) 2022/2554 on EUR-Lex. Article 2(1) lists the 20 types of financial entity in points (a) to (t), and point (u) names ICT third-party service providers. Read the exclusions in Article 2(3) against your own licence or authorisation, then read Article 2(4) and (5) for the member state option to exclude certain credit institutions located in its territory. Write down the exact point of Article 2(1) that matches each legal entity in your group, because the same group can contain several types of financial entity with different obligations.

For resilience testing scope, read Commission Delegated Regulation (EU) 2025/1190 on EUR-Lex. Its Article 2(2) sets default categories for threat-led penetration testing, including G-SII and O-SII banks, central securities depositories, central counterparties, and payment institutions above the transaction threshold in the RTS. Being in a default category does not replace the formal identification by your competent authority under Article 26(8), so treat the default as a likely outcome to plan for, not a confirmed obligation. Check how the thresholds were measured for the two preceding years, because the measurement period determines whether you are caught.

Then read Joint ESAs Report JC 2025 85, which the ESAs published under Article 58(3). It records their view that bringing statutory auditors and audit firms into DORA's scope is not warranted at this stage, which matters if your firm or a client relies on audit services. Member state options, national exclusions, and the identification of entities for TLPT are decisions made nationally, so confirm each one in writing with your local competent authority before you finalise scope. Keep the authority's reply in your scope file as evidence for the next supervisory review.

How DeployOpen works on this

Once you know which DORA category your entity or provider falls into, DeployOpen turns that answer into a written scope covering the systems, ICT services and contracts involved. We then prepare the platforms, records and evidence that support the position you document, while the organization keeps ownership of its own determinations.

How we scope

We confirm the entity type, any Article 2 exclusion or member state option, and whether microenterprise or simplified regime rules apply.
We list the ICT services and self-hosted platforms in use, so each one is assessed against the same criteria.
We agree the scope, deliverables and timelines in writing before any work starts, with no prices in the scope itself.

How we build

We map each ICT service to the DORA obligations it triggers, such as the register of information, contract clauses or TLPT eligibility.
We set up the open-source platforms that produce logs, inventories and records your scope determination depends on, inside your own infrastructure.
We test the configured platforms and document the results so the reasoning behind your scope decision can be reviewed.

How we hand over

You receive the written scope determination, the ICT service inventory and the evidence set that supports it.
We document the platforms, configurations and operating procedures so your own teams can maintain them after handover.
Your management body and compliance function review and approve the determination, since the organization owns its conclusions.

How we support

Ongoing support, upgrades and continuous testing are available as retainers when your entity or provider scope changes.
We can refresh the inventory and evidence when the Commission review due in 2028 or the pending Digital Omnibus change affects your position.
Assessments of your scope and any formal confirmation come from your competent authority or an independent auditor, not from DeployOpen.

Does DORA apply to us