Decide whether the Digital Operational Resilience Act (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.
DORA has applied since 17 January 2025. Run this test in order: decide whether the organisation is a DORA , test the specific exclusions and Article 16 status, identify any information and communication technology (ICT) service relationship, and decide whether that service supports a critical or important function. Record the facts, source, owner, outcome, evidence gap, and reassessment trigger so the result can feed the ICT risk framework, third-party policy, register of information, contract remediation, and supervisory evidence.
DORA first applies by actor. Article 2 lists covered financial-entity categories 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, and securitisation repositories. It lists ICT third-party service providers separately because their role is different: financial entities carry the core operational-resilience duties, while provider relationships feed third-party controls and designated critical providers enter Union-level oversight.
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.
Sources (1)
Article 2 defines the financial entities in scope and includes ICT third-party service providers in the Regulation's scope.
this Regulation applies to the following entities
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. Article 16 places specific categories under a simplified ICT risk management framework, including small and non-interconnected investment firms, certain payment and electronic money institutions exempted under national sectoral law, certain small IORPs, and institutions exempted under Directive 2013/36/EU. This is a legal category test, not a general small-company option. Other in-scope entities apply proportionality by size, overall risk profile, and the nature, scale, and complexity of their services, activities, and operations.
Sources (2)
Article 2 lists exclusions and Article 28 applies proportionality to ICT third-party risk management.
This Regulation does not apply to
Article 1 requires the third-party policy to account for size, overall risk profile, and the nature, scale and complexity of the financial entity's services, activities, and operations.
Overall risk profile and complexity
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.
Sources (2)
Article 3 defines critical or important function, ICT services, ICT third-party risk, and ICT third-party service provider.
critical or important function
The register templates require criticality assessment, reasons for criticality, reliance, substitutability, and subcontractor supply-chain information for ICT services.
Criticality or importance assessment
For a , 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 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.
Sources (3)
Articles 28 to 30 set the core third-party risk, register, pre-contract assessment, concentration risk, and contract-provision requirements.
manage ICT third-party risk
The RTS specifies governance, lifecycle, risk assessment, due diligence, monitoring, documentation, exit, and senior-management responsibilities for ICT services supporting critical or important functions.
contractual arrangements
The RTS specifies due diligence, risk assessment, monitoring, material-change notice, objection, and termination expectations for subcontracting ICT services supporting critical or important functions.
subcontracting ICT services supporting critical or important functions
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 , 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 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 , 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 , 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.
Sources (2)
The ITS grounds the evidence fields for provider identifiers, supply chains, function criticality, reliance, substitutability, and register data quality.
register of information
The RTS shows how register data, financial-entity reliance, critical or important functions, systemic impact, subcontractor dependence, and substitutability feed critical provider designation.
designation of ICT third-party service providers as critical
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 questions tied to cited sources 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.
"digital operational resilience for the financial sector"
"this Regulation applies to the following entities"
"This Regulation does not apply to"
"critical or important function"
"manage ICT third-party risk"
"policy regarding contractual arrangements"
"Overall risk profile and complexity"
"contractual arrangements"
"standard templates for the register of information"
"Criticality or importance assessment"
"register of information"
"ICT third-party service providers as critical"
"designation of ICT third-party service providers as critical"
"subcontracting ICT services supporting critical or important functions"
How DORA critical or important functions affect ICT service mapping, third-party contracts, register-of-information records, incidents, testing, and evidence.
Track DORA dates and recurring evidence: 17 January 2025 application, incident reporting clocks, register updates, annual reporting, TLPT cadence, and critical-provider oversight milestones.
A DORA workflow for remediating ICT third-party contracts covering critical or important functions, subcontracting, audit rights, exits, register updates, and evidence.
Official source DORA guide for financial entities in scope, ICT third-party risk, contract clauses, subcontracting controls, register evidence, audit rights, exit planning, and oversight.
Official source guide to DORA ICT incident classification forms: major-incident criteria, significant cyber-threat notifications, report fields, time limits, evidence, and reclassification records.
Official source DORA workflow for starting the major-incident reporting clock, classifying ICT incidents, submitting initial, intermediate, and final reports, and preserving authority evidence.
Official source DORA guide to major ICT-related incident classification, initial notifications, intermediate and final reports, competent authority routing, and significant cyber threat notifications.
Build a DORA register of information from procurement, vendor, contract, service, function, and subcontractor data using the official register templates and validation checks.
Map DORA register fields to official templates for ICT contracts, provider chains, critical functions, dates, statuses, reporting, and evidence.
Compare binding DORA ICT third-party risk duties with the EBA outsourcing baseline for registers, critical functions, contracts, subcontracting, exit, incident reporting, and evidence.
Compare DORA's binding ICT operational resilience duties for financial entities with ISO 22301's business continuity management system requirements.
Compare EU DORA and ISO/IEC 27001 across scope, governance, incident reporting, testing, ICT third-party risk, certification, evidence, overlap, and gaps.
Compare DORA and NIS2 for financial entities, ICT providers, incident reporting, management accountability, third-party risk, supervisory routes, and reusable evidence.
Compare DORA major ICT-related incident reporting with PSD2 major operational or security payment incident reporting, including scope, triggers, report stages, recipients, and evidence.
Check DORA operating evidence against official sources for ICT risk governance, major-incident reporting, resilience testing, TLPT, third-party contracts, and the register of information.
Map DORA obligations to official sources and operating evidence for ICT risk management, incident reporting, testing, third-party risk, registers, governance, and oversight.
Concise DORA FAQ covering who is in scope, proportionality, ICT third-party contracts, register-of-information records, major ICT incident thresholds and reporting, TLPT, testing, enforcement, and evidence.
An official source DORA control baseline for ICT risk governance, asset and dependency mapping, protection, detection, response, recovery, testing, third-party risk, and evidence.
DORA guide to ICT subcontracting chains for critical or important functions: prior assessment, contract conditions, register fields, monitoring, exit rights, and evidence.
Official source guide to DORA enforcement: competent-authority powers, administrative penalties, remedial measures, publication rules, and Lead Overseer penalty payments for critical ICT third-party providers.
Field-level guide to the EU DORA register of information data model: templates B_01 to B_07, provider identifiers, contract links, subcontracting chains, critical-function assessments, dates, and export evidence.
An official source overview of the main EU DORA requirements for financial entities: governance, ICT risk management, incident reporting, resilience testing, TLPT, ICT third-party risk, register of information, oversight, proportionality, and evidence.
Classify whether DORA applies to a financial entity, ICT third-party provider, group arrangement, branch, or critical ICT service dependency.
Classify DORA covered entities, simplified-framework status, critical or important functions, ICT dependencies, evidence records, and governance approvals.
An official source DORA guide for resilience testing, TLPT eligibility, authority interaction, test evidence, remediation plans, and avoiding unsupported testing cadence.
Check how DORA TLPT authorities identify financial entities for threat-led penetration testing and what evidence supports scope, readiness, providers, and governance.
Build a DORA threat-led penetration testing runbook around authority coordination, scope validation, provider controls, active testing, closure reports, remediation, and attestation.
Build a DORA register of information from contracts, ICT services, providers, functions, subcontractors, risk assessments, audit evidence, exit plans, and export checks.
What DORA requires in ICT third-party contracts, including critical or important functions, audit and access rights, termination, exit, subcontracting, register updates, and evidence.
FAQ on DORA major ICT-related incident classification thresholds, recurring incidents, reporting triggers, and evidence inputs based on EU DORA RTS and ITS texts.
FAQ on the DORA register of information: who maintains it, which ICT third-party arrangements it covers, template fields, critical functions, reporting, data quality, and evidence.
FAQ on DORA threat-led penetration testing selection: who identifies financial entities, what criteria are used, what the TLPT authority validates, and what evidence to keep.
DORA proportionality explained from official sources: what can be scaled, simplified-framework eligibility, supporting evidence, and duties that remain mandatory.