DORA: questions to assess your obligations

Regulation: EU 2022/2554 (Digital Operational Resilience Act) Deadline: 17.1.2025 (fully applicable) Scope: EU financial institutions (banks, insurers, investment firms, payment institutions)

DORA Article 1(2) is sector-specific EU law for financial entities also identified as essential/important under NIS2, within the equivalent obligations covered by NIS2 Article 4. It does not exempt all financial-sector suppliers from NIS2. An ICT supplier is subject to direct ESA oversight only if designated critical under Article 31; contractual requirements can affect other suppliers.

About DORA

For DORA financial entities also within NIS2, DORA is the sector-specific act under DORA Article 1(2) and NIS2 Article 4 for the corresponding duties. Determine the entity and scope; this does not give ICT suppliers a blanket exemption.

Who falls under DORA?

Category	Examples
Credit institutions	Banks, savings banks
Payment institutions	Including institutions exempted under PSD2
Electronic money institutions	Separate category under Article 2(1)(d), including exempted institutions
Investment firms	Securities dealers
Insurance undertakings	Life and non-life insurance
Reinsurance undertakings	Reinsurance companies
Institutions for occupational retirement provision (IORPs)	IORPs operating pension schemes with no more than 15 members in total are excluded (Art. 2(3)(c))
Crypto-assets	Crypto-asset service providers authorised under MiCA and issuers of asset-referenced tokens (Art. 2(1)(f))

The table is a selection of financial entities, not the complete Article 2 list. Check the exclusions in Article 2(3) and any national option under Article 2(4). ICT third-party service providers are separately covered by Article 2(1)(u); they are not financial entities under Article 2(2). Direct oversight applies after designation as critical under Article 31, subject to its conditions and exclusions.

Part E: DORA Compliance

Article 16 is limited to the entity categories expressly listed there: small and non-interconnected investment firms, specified exempt payment/credit/e-money institutions and small occupational pension institutions. Small size, low ICT complexity or low systemic importance alone does not qualify an entity. Article 4 proportionality is a separate principle; Article 16 does not create a general exemption from reporting major ICT-related incidents under Article 19.

The Article 5–15 rows describe the standard framework; Article 16 entities apply their separate framework instead. Apply the specific microenterprise adjustments in each provision; other duties, including incident reporting and general third-party risk management, are assessed separately.

The following rows are a working map; committee/SIEM choices are implementation options, not mandatory named structures/products. Apply the relevant role and the RTS alongside the Regulation.

#	Activity	Reference	Phase	Description
E1	Scope Determination	Art. 2	Preparation	Determine whether the organisation falls under DORA
E1.1	— Entity type	Art. 2(1)	Preparation	Bank, insurer, investment firm, payment institution?
E1.2	— Simplified regime?	Art. 16	Preparation	Do we qualify for the simplified regime?
E1.3	Supervisory contact	Art. 46 and sectoral law	Preparation	Identify the competent authority and applicable authorisation/reporting channel; Art. 2 does not establish a universal DORA registration
E2	GAP Analysis	Art. 4, 6	Analysis	Assessment of current state vs. DORA
E2.1	— Current state assessment	Art. 6	Analysis	Audit of current ICT risk management
E2.2	— Gap identification	Art. 6-15	Analysis	Identify gaps vs. DORA requirements
E2.3	— Remediation roadmap	Art. 6	Analysis	Remediation plan with priorities
E3	Governance Structure	Art. 5	Governance	Governance for ICT risk management
E3.1	— Board accountability	Art. 5(2)(a)	Governance	The board bears ultimate responsibility for ICT risk management
E3.2	— ICT risk management function	Art. 5(2)(c), 6(4)	Governance	Define roles and responsibilities; non-microenterprises assign an independent ICT risk control function and segregate duties
E3.3	— Security committee	Art. 5	Governance	Security committee with regular reporting
E3.4	— Management training	Art. 5(4)	Governance	Management training in ICT risks
E4	ICT Risk Management Framework	Art. 6	Framework	Comprehensive ICT risk management framework
E4.1	— ICT risk management policy	Art. 6(1)	Framework	Documented ICT risk management policy
E4.2	— ICT risk management strategy	Art. 6(8)	Framework	Digital Operational Resilience Strategy
E4.3	— Risk tolerance	Art. 6(8)(b)	Framework	Risk tolerance definition for ICT risks
E4.4	— Framework review	Art. 6(5)	Framework	Review at least annually, microenterprises periodically; also following a major incident and the other Article 6(5) triggers
E5	ICT Asset Management	Art. 8	Identification	Identification and classification of ICT assets
E5.1	— ICT asset inventory	Art. 8(1), (4)–(6)	Identification	Inventory information and ICT assets; update after major changes
E5.2	— Asset classification	Art. 8(1)	Identification	Classify by criticality; review classification and documentation at least annually
E5.3	— Business function mapping	Art. 8(1)	Identification	Map ICT-supported functions, roles and responsibilities and supporting assets
E5.4	— Dependencies mapping	Art. 8(4)–(5)	Identification	Map asset/configuration dependencies and processes dependent on ICT third parties
E6	ICT Risk Assessment	Art. 8	Risk	Regular ICT risk assessment
E6.1	— Risk identification	Art. 8(2)–(3)	Risk	Continuously identify ICT risks and review risk scenarios at least annually; non-microenterprises assess every major change
E6.2	— Risk analysis	RTS 2024/1774 Art. 3(b)	Risk	Risk assessment methodology including likelihood and impact indicators
E6.3	— Risk treatment	RTS 2024/1774 Art. 3(c)–(d)	Risk	Risk treatment measures, effectiveness monitoring and documented acceptance/review of residual risks
E6.4	— Risk reporting	Art. 5(2)(i), 13(5)	Risk	Reporting through established management channels; at least annual senior ICT management report on findings and recommendations
E7	Protection & Prevention	Art. 9, 10	Protection	Implementation of protective measures
E7.1	— ICT security policies	Art. 9(4)(a)	Protection	Information security policies
E7.2	— Network security	Art. 9(4)(b)	Protection	Network and infrastructure security proportionate to risk
E7.3	— Access control	Art. 9(4)(c)–(d); RTS 2024/1774 Art. 21	Protection	Need-based, least-privilege access control; strong authentication in the cases specified by RTS Article 21(f)
E7.4	— Encryption	RTS 2024/1774 Art. 6	Protection	Encryption policy for data at rest and in transit based on approved data classification and ICT risk assessment
E7.5	— Patch management	Art. 9(4)(f)	Protection	Patch management process
E7.6	— Data protection	Art. 9(2)–(3)	Protection	Protect data availability, authenticity, integrity and confidentiality
E8	Detection	Art. 10	Detection	Anomaly and incident detection
E8.1	— Monitoring capability	Art. 9(1), 10(3)	Detection	Continuously monitor ICT security and functioning and provide monitoring needed to detect anomalies
E8.2	— Anomaly detection	Art. 10(1)	Detection	Detection of anomalies and suspicious activities
E8.3	— SIEM implementation	Art. 10	Detection	SIEM for centralised monitoring
E9	Business Continuity	Art. 11, 12	Continuity	ICT Business Continuity Management
E9.1	— ICT BCP policy	Art. 11(1)	Continuity	ICT Business Continuity Policy
E9.2	— BIA (Business Impact Analysis)	Art. 11(5)	Continuity	Analyse the impacts of severe business disruptions
E9.3	— Recovery plans	Art. 11(3)	Continuity	ICT response and recovery plans
E9.4	— Backup strategy	Art. 12(1)	Continuity	Backup and restore strategy
E9.5	— Recovery testing	Art. 11(6)(a), 12(2)	Continuity	Test backup/restoration periodically; test continuity and response/recovery plans at least annually for systems supporting all functions and after substantive changes to critical/important-function systems
E9.6	— Crisis communication	Art. 11(2)(e), 11(7), 14	Continuity	Crisis communication; Article 11(7) crisis-management function for non-microenterprises
E10	Incident Management	Art. 17-19	Incident	ICT incident management process
E10.1	— Incident management policy	Art. 17(1); RTS 2024/1774 Art. 22(a)	Incident	ICT incident management process; documented through an incident policy in the standard framework
E10.2	— Incident classification	Art. 18; RTS 2024/1772 Art. 1–9	Incident	Classify incidents using the RTS criteria and thresholds; account for recurring incidents and the applicable exemptions
E10.3	— Incident response team	Art. 17(3)(c)	Incident	Defined roles and responsibilities for different incident types and scenarios; an IRT is an organisational option
E10.4	— Root cause analysis	Art. 17(2), 13(2)	Incident	Identify and address root causes; Article 13(2) review after a major ICT incident disrupts core activities
E11	Incident Reporting	Art. 19	Reporting	Reporting major ICT-related incidents
E11.1	— Major incident criteria	Art. 18; RTS 2024/1772 Art. 6, 8–9	Reporting	Major-incident criteria under the RTS, not a single isolated threshold
E11.2	Initial notification	Art. 19; RTS 2025/301 Art. 5(1)(a), (2)	Reporting	As early as possible, within 4h of major classification and no later than 24h after awareness; if classified after 24h, within 4h of classification
E11.3	Intermediate report	Art. 19; RTS 2025/301 Art. 5	Reporting	Within 72h after initial notification; update as required and after recovery
E11.4	Final report	Art. 19; RTS 2025/301 Art. 5	Reporting	One month after intermediate or latest updated intermediate report
E12	Resilience Testing	Art. 24, 25	Testing	Regular resilience testing
E12.1	— Testing programme	Art. 24(1)	Testing	Digital resilience testing programme for financial entities other than microenterprises
E12.2	— Vulnerability assessments	Art. 25(1); RTS 2024/1774 Art. 10(2)	Testing	Automated vulnerability scans and assessments according to classification and risk; in the standard framework, at least weekly for ICT assets supporting critical or important functions
E12.3	Appropriate resilience tests	Art. 24(6), 25	Testing	Non-microenterprises test systems supporting critical or important functions at least annually using appropriate tests; not universal annual penetration testing of every system
E12.4	— Scenario-based testing	Art. 24(2), 25(1), (3)	Testing	Scenario-based tests as an appropriate risk-based test type; account for microenterprise adjustments
E13	TLPT (Advanced Testing)	Art. 26	TLPT	Threat-Led Penetration Testing
E13.1	— TLPT scope	Art. 26(1)–(2), (8); RTS 2025/1190 Art. 2	TLPT	Check TLPT designation and authority-validated scope; microenterprises and Article 16 entities are excluded
E13.2	Tester eligibility	Art. 27; RTS 2025/1190 Art. 7	TLPT	Verify tester competence and independence, insurance, references and required evidence including certifications; account for the exceptional RTS Article 7(2) procedure
E13.3	— TLPT execution	Art. 26	TLPT	Execute TLPT
E14	Third-Party Risk	Art. 28-30	Third-Party	ICT third-party risk management
E14.1	— ICT third-party policy	Art. 28(2)	Third-Party	ICT third-party risk strategy and policy for services supporting critical or important functions; this requirement excludes microenterprises and Article 16 entities
E14.2	— Third-party register	Art. 28(3)	Third-Party	ICT third-party register
E14.3	— Due diligence	Art. 28(4)	Third-Party	Due diligence for ICT providers
E14.4	— Contractual requirements	Art. 30	Third-Party	Contractual requirements (DORA Art. 30)
E14.5	— Exit strategies	Art. 28(8)	Third-Party	Exit strategies for ICT services supporting critical or important functions
E15	Register of information	Art. 28(3)	Registry	All ICT service contractual arrangements, distinguishing support for critical/important functions; separate from ESA designation of critical providers
E15.1	Supported functions	Art. 28(3)	Register	Distinguish contracts for ICT services supporting critical or important functions; this is separate from Article 31 provider designation
E15.2	Register reporting	Art. 28(3)	Registry	Full register or parts on request, at least annual information on new arrangements; timely notice of planned critical/important-function ICT arrangements and when a function becomes critical or important
E15.3	— Registry updates	Art. 28(3)	Registry	Ongoing register updates
E16	Learning & Evolving	Art. 13	Continuous	Continuous improvement
E16.1	— Lessons learned	Art. 13(3)	Continuous	Incorporate lessons from reviews, testing and actual incidents into ongoing ICT risk assessment
E16.2	— Post-incident reviews	Art. 13(2)	Continuous	Review after a major ICT-related incident disrupts core activities
E16.3	— Threat intelligence	Art. 13	Continuous	Threat intelligence integration
E17	Communication	Art. 14	Communication	ICT communication protocols
E17.1	— Internal communication	Art. 14(2)	Communication	Internal communication during incidents
E17.2	— External communication	Art. 14(1)–(3), 19(3)	Communication	Communication plans and public/media responsibility; inform clients without undue delay of a major ICT incident affecting their financial interests
E18	Supervisory cooperation by role	Arts. 46, 50; 35–39 for critical providers	Reporting	Separate financial-entity supervision from direct oversight of designated critical ICT providers
E18.1	Financial-entity reporting	Arts. 6(5), 19, 28(3)	Reporting	Applicable framework, incident and register reports; Art. 37 is not a generic financial-entity reporting duty
E18.2	Critical-provider oversight	Arts. 35–39	Oversight	Information requests/investigations/inspections for designated critical ICT providers

Reporting time limits are subject to the specific weekend/bank-holiday rule and its exclusions in Regulation 2025/301 Article 5(4)–(6). An inability to meet a deadline must be notified without undue delay and no later than the relevant deadline, with reasons under Article 5(3); it is not an automatic extension.

DORA dates

DORA has applied since 17 January 2025. Use the current reporting schedule communicated by the competent authority. TLPT applies only to designated entities, generally at least every three years with authority-adjustable frequency.

Relationship of DORA to other regulations

Remediation priorities

Confirm the regime, management responsibility, incident-reporting capability, ICT register and critical continuity gaps first. The phases below indicate work order, not legal grace periods for duties already applicable.

Implementation phases

Sources

Content reviewed: 6 September 2026. Primary sources: DORA, Incident reporting RTS — Art. 5, NIS2 — Art. 4.