Decide whether DORA applies by checking the entity type, ICT service relationship, critical or important function, exclusion, and evidence record.
Built for financial institutions, ICT providers, outsourcing teams, procurement, security, legal, resilience, and product owners who need a documented scope decision before assigning DORA work.
Structured answer sets in this page tree.
Cited legal and guidance references.
Use this applicability test to separate three questions that are often mixed together: whether the organisation is a DORA financial entity, whether an ICT provider relationship is relevant to that financial entity, and whether the service supports a critical or important function. The output should be a classification record that can feed the ICT risk framework, the third-party policy, the register of information, contract remediation, and supervisory evidence.
DORA first applies by actor. Article 2 lists financial entities such as credit institutions, payment institutions, account information service providers, electronic money institutions, investment firms, crypto-asset service providers and issuers of asset-referenced tokens, central securities depositories, central counterparties, trading venues, trade repositories, AIF managers, management companies, data reporting service providers, insurance and reinsurance undertakings, insurance intermediaries, institutions for occupational retirement provision, credit rating agencies, administrators of critical benchmarks, crowdfunding service providers, securitisation repositories, and ICT third-party service providers.
For a financial group, do not stop at the trading name. Record the regulated entity, branch or group entity, authorisation category, home competent authority, and the business service that uses ICT. For an ICT supplier, record whether it provides ICT services to one or more DORA financial entities, whether it is intra-group or external, and whether the service is direct or part of a subcontracting chain.
A DORA applicability test should record exclusions explicitly. Article 2 excludes certain AIF managers, certain insurance and reinsurance undertakings, pension institutions with schemes that together have no more than 15 members, persons exempted under specified MiFID II provisions, insurance and reinsurance intermediaries and ancillary insurance intermediaries that are microenterprises or SMEs, and post office giro institutions. Member States may also exclude specified credit-institution categories located in their territory.
A positive scope decision is not the same as a uniform control burden. DORA uses proportionality across ICT third-party risk, register work, and technical standards. The test should therefore classify the entity and service first, then scale evidence expectations by size, overall risk profile, and the nature, scale and complexity of services, activities, and operations.
The main operational fork is whether an ICT service supports a critical or important function. DORA defines that function as one whose disruption would materially impair financial performance, soundness or continuity of services and activities, or continued compliance with authorisation and financial-services obligations. This classification drives the register, third-party policy, contract clauses, monitoring, exit planning, and subcontractor evidence.
Use a service-by-service assessment. A cloud platform, data feed, managed security service, payment gateway, trading system, claims platform, identity system, core ledger, reporting tool, or support platform may be in a different category depending on the regulated activity it supports and the impact of disruption.
For a financial entity, DORA requires ICT third-party risk to be managed as part of the ICT risk management framework. Before entering an ICT services contract, the financial entity must assess whether the arrangement supports a critical or important function, whether supervisory conditions are met, relevant risks, due diligence on the provider, and conflicts of interest. The register of information must cover contractual arrangements for ICT services and distinguish those supporting critical or important functions.
For subcontracting, the question is not only whether a named prime vendor is acceptable. The financial entity must be able to see whether subcontractors effectively underpin ICT services supporting critical or important functions, whether the provider can identify and notify those subcontractors, whether access and inspection rights flow through, and whether material subcontracting changes can be assessed before implementation.
The result of the test should be usable without the person who made it. Store the decision as a short evidence record that states the scope conclusion, the facts reviewed, the source relied on, the controls or artifacts triggered, and the reassessment triggers. A useful record prevents two common errors: assigning DORA work to a vendor relationship that is not tied to a DORA financial entity, or missing a critical or important function because the contract was labelled as ordinary technology procurement.
The minimum evidence set should support both internal governance and supervisory review: entity classification, exclusion analysis, service mapping, criticality reasoning, provider and subcontractor identifiers, contract references, locations, data sensitivity, reliance and substitutability assessment, owner approval, and the register-of-information row or reason why no row is required.
No. The supplier analysis starts with an in-scope financial entity and an ICT service relationship. The strongest DORA third-party obligations arise where the ICT service supports a critical or important function, although the financial entity's register and ICT risk framework can still require documentation for broader ICT service arrangements.
No. Certificates and audit reports may support due diligence, but the applicability decision must still classify the financial entity, ICT service, supported function, provider relationship, subcontracting chain, and DORA source basis.
Mark the decision blocked when the team cannot identify the regulated entity category, the customer financial entity, the service recipient, the supported function, the ICT service supply chain, the contract owner, or the evidence needed to decide whether a critical or important function is supported.
Sorena can help convert the DORA applicability facts on this page into a cited classification record, third-party evidence request, register input, and reassessment workflow.
Ask source-linked questions about DORA scope, ICT third-party services, critical or important functions, register evidence, and subcontracting dependencies.
Review a DORA applicability test, provider map, evidence gap, or register-of-information workflow with Sorena.
"designation of ICT third-party service providers as critical"
"contractual arrangements"
"subcontracting ICT services supporting critical or important functions"
"register of information"
"manage ICT third-party risk"