- Primary DORA scope (Article 2) and workstreams: ICT risk management (Chapter II), incident reporting (Chapter III), testing/TLPT (Chapter IV), ICT third-party risk and register of information (Chapter V).
EU DORA Applicability Test
A practical way to decide whether DORA applies - and what layer applies.
Designed to output a scope memo you can defend in audits and supervisory discussions.
Structured answer sets in this page tree.
Cited legal and guidance references.
DORA applicability is a structured decision: you classify each legal entity, map it to Article 2 scope, decide proportionality/simplification, and identify which obligations attach (controls, reporting, testing, third-party governance). This applicability test is written for implementation teams so the output is actionable, not just legal interpretation.
Output you should produce (what "done" looks like)
At the end of this test you should have a scope memo per regulated entity and a group summary. This memo becomes the backbone for your requirements matrix, roadmap, and evidence pack.
Most teams fail by skipping this artifact and immediately building controls without tier clarity.
- Entity-by-entity scope memo: covered category mapping (Article 2) + supervisor + perimeter.
- Proportionality decision: simplified framework basis and what is scaled down.
- Workstreams and owners: ICT risk controls, incident reporting, testing/TLPT, third-party risk + register of information.
- Evidence map: where each required artifact lives (policies, procedures, logs, reports, registers).
Step 1 - Are you a covered financial entity under Article 2?
Start with legal facts: what regulated category are you, and what license/authorization do you hold?
DORA scope is defined by the covered financial entity list in Article 2.
- List your legal entities and licenses (banking, investment, payment services, insurance, market infrastructure, etc.).
- Map each entity to Article 2 categories and record the competent authority.
- If you operate in multiple Member States or have multiple authorizations, scope each entity separately and then create a consolidated group view.
Step 2 - What's your DORA implementation layer (full vs proportional/simplified)?
DORA requires applying the proportionality principle: controls and testing intensity can scale with size, complexity, and risk profile.
Document your proportionality decision as a management body artifact and review it periodically.
- Define your ICT dependency profile: critical/important functions, outsourcing model, and technology concentration.
- Decide which parts of ICT risk management/testing are simplified and why the residual risk is acceptable.
- Create an annual review cadence for proportionality (especially after major ICT or outsourcing changes).
Step 3 - Which compliance workstreams apply to you?
Once you're in scope, DORA becomes an implementation program across four main workstreams plus governance and cooperation.
Use this as your workstream inventory and owner assignment checklist.
- ICT risk management (Chapter II): governance, asset inventory/classification, protection/detection, response/recovery, business continuity and communications.
- Incident management and reporting (Chapter III): record incidents and significant cyber threats, classify, and report major incidents (initial/intermediate/final).
- Testing and TLPT (Chapter IV): annual testing programs; TLPT readiness for entities required to run threat-led penetration tests.
- ICT third-party risk + register of information (Chapter V): third-party strategy, contractual clauses, concentration risk, exit strategies, and register maintenance.
- Information sharing and cooperation: decide how you will participate in sector exercises and threat intelligence sharing.
Step 4 - Group-level obligations: register and governance layers
Some obligations, especially around ICT third-party risk, operate at entity level and also at sub-consolidated and consolidated levels.
If you have centralized vendor management, ensure entity-level supervisory requests can still be answered quickly.
- Maintain the register of information at entity level and, where relevant, sub-consolidated and consolidated levels (Article 28).
- Define how group policies map to entity controls (policy ownership vs control execution).
- Set up a supervisory response workflow: who can export register sections and incident reports on request.
Step 5 - Are you an ICT third-party provider (and could you become critical)?
Even if you're not a covered financial entity, you may be impacted as an ICT third-party provider supporting critical or important functions for in-scope entities.
Financial entities will demand contract clauses aligned to DORA RTS; critical designation adds oversight exposure.
- If you sell ICT services to financial entities: prepare for DORA-aligned contracts, audit/access rights, incident communications, and exit/portability support.
- If you are large/systemic: understand the criteria for designation as a critical ICT third-party service provider and the oversight model.
- Operational implication: treat "DORA-ready supplier" as a product capability (controls + evidence + contract positions).
Turn EU DORA Applicability Test into an operational assessment
Assessment Autopilot can take EU DORA Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents.
Start from EU DORA Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints.
Review your current process, evidence gaps, and next steps for EU DORA Applicability Test.