DORA Readiness Checklist: Pillar by Pillar Checks for Financial Entities

DORA has applied since 17 January 2025, yet many financial entities still cannot show a supervisor a current register of information, a classification procedure that produces a four-hour initial notification, or evidence that systems supporting critical or important functions were tested this year. This checklist is a working template for [Organisation] to test readiness against Regulation (EU) 2022/2554 (the Digital Operational Resilience Act) pillar by pillar: ICT risk management, incident management and reporting, resilience testing, ICT third-party risk and information sharing. Where the detail lives in the Level 2 standards, the checks follow them, in particular Delegated Regulations (EU) 2024/1774, 2024/1772 and 2025/301 and Implementing Regulation (EU) 2024/2956. It is written for CISOs, heads of ICT risk, compliance officers and third-party risk teams preparing for supervisory review or an internal audit.

How to use this template

• Replace bracketed text such as [Organisation], [Competent authority], [Management body], [ICT risk function] and [Control owner] with your own terms.
• Start with section 1. Whether [Organisation] follows the full framework (Articles 5 to 15) or the simplified framework (Article 16), and whether it is a microenterprise, changes what applies in every later section.
• Mark each check Met, Partly met or Not met, link the evidence and give every gap an owner and a due date. Article numbers refer to DORA unless a Level 2 act is named.
• For the obligations themselves and how the pillars fit together, see the DORA Guide. This checklist does not repeat that explanation.
• This template is not legal advice. National competent authorities issue their own guidance and reporting channels, and EU proposals to simplify reporting may change detail: check the current text on EUR-Lex and your authority's site before each review.

1. Scope, proportionality and governance (Articles 2, 4, 5, 16)

• Every legal entity in the group is mapped to an entity type in Article 2(1), and entities that are not financial entities but provide ICT services to the group are identified as ICT third-party service providers.
• The decision on the full or simplified ICT risk management framework (Article 16(1)) and on microenterprise status is documented with its legal basis.
• The [Management body] has approved the digital operational resilience strategy and the ICT risk management framework, sets ICT risk tolerance, approves the ICT budget and receives regular reporting, as Article 5(2) requires. Decisions are minuted.
• Members of the management body have had ICT risk training to keep their knowledge current (Article 5(4)), with attendance records.
• A role to monitor ICT third-party arrangements, or a senior manager responsible for that oversight, is assigned (Article 5(3)), unless [Organisation] is a microenterprise.
• The ICT risk management function has appropriate independence under the three lines of defence model, and internal audit reviews the framework on a regular schedule.
• Critical or important functions are identified and mapped to the ICT assets, identities and third-party providers that support them. This mapping drives sections 2 to 5.

2. ICT risk management (Articles 6 to 15, RTS 2024/1774)

• A documented ICT risk management framework exists and is reviewed at least yearly and after major incidents (Article 6(5)).
• An inventory of ICT assets and information assets records owner, location, classification and dependencies, including links to ICT third-party providers (Article 8, RTS 2024/1774 Articles 4 and 5).
• Policies cover information security, encryption and cryptographic key management, ICT operations, network security, ICT project and change management, and patching, as set out in RTS 2024/1774. See the Cryptographic Key Management Policy Template.
• The identity and access management policy ensures unique identification and authentication of natural persons and systems, records assignments over the whole lifecycle, and applies least privilege and need-to-use privileged access (RTS 2024/1774 Articles 20 and 21).
• Strong authentication is enforced for remote access and privileged access, and access rights to systems supporting critical or important functions are reviewed at least every six months (RTS 2024/1774 Article 21).
• Service accounts, API keys and integration credentials are inventoried with owners, because the RTS covers systems as well as people. See the NHI Policy Template.
• Logging covers defined events including access control and identity management, with retention set by policy (RTS 2024/1774 Article 12), and anomaly detection criteria trigger incident response (Article 10).
• Business continuity and ICT response and recovery plans exist for critical or important functions, with recovery time and recovery point objectives, and are tested (Articles 11 and 12).
• Backups are taken, segregated and restored in tests, and restoring does not put the integrity of data at risk (Article 12).
• Post-incident reviews feed lessons into the framework, and the management body receives a yearly report on them (Article 13).
• A crisis communication plan covers clients, counterparts and the public (Article 14).

3. ICT-related incident management and reporting (Articles 17 to 23)

• An incident management process detects, logs, classifies, escalates and resolves ICT-related incidents, with roles and early warning indicators defined (Article 17).
• Classification applies the criteria and materiality thresholds of Delegated Regulation (EU) 2024/1772: clients, financial counterparts and transactions affected, reputational impact, data losses, critical services affected, duration and downtime, geographical spread and economic impact. An incident is major when it affects critical services and either involves successful malicious unauthorised access to network and information systems, or meets two or more other thresholds (Article 8 of that regulation).
• Recurring incidents with the same apparent root cause are aggregated, as the regulation requires, so that repeated minor incidents that are major together are caught.
• The reporting timeline is built into runbooks: initial notification within four hours of classifying an incident as major and no later than 24 hours after becoming aware of it; intermediate report within 72 hours of the initial notification; final report within one month of the latest updated intermediate report (Delegated Regulation (EU) 2025/301 Article 5). See the DORA Major ICT Incident Reporting Guide.
• Reports use the templates and data fields in Implementing Regulation (EU) 2025/302, and the submission channel to [Competent authority] has been tested.
• Clients are informed without undue delay where a major incident affects their financial interests (Article 19(3)), and a decision rule exists for voluntary notification of significant cyber threats.
• Where reporting is outsourced to a third party, [Organisation] keeps responsibility and has notified the authority as required.

4. Digital operational resilience testing (Articles 24 to 27)

• A risk-based testing programme exists and is approved, covering the test types in Article 25: vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, physical security reviews, questionnaires and scanning software solutions, source code reviews where feasible, scenario-based tests, compatibility, performance and end-to-end testing, and penetration testing.
• All ICT systems and applications supporting critical or important functions have had appropriate tests at least yearly (Article 24(6)), with results and remediation tracked to closure.
• Testers are independent, whether internal or external, and conflicts of interest are managed (Article 24(4)).
• [Organisation] knows whether its competent authority has identified it for threat-led penetration testing (TLPT). If so, TLPT is planned at least every three years on live production systems supporting critical or important functions, including outsourced ones, following Delegated Regulation (EU) 2025/1190 and the TIBER-EU approach (Article 26).
• If internal testers are used for TLPT, external testers are contracted every three tests (Article 26(8)), and tester requirements in Article 27 are met.
• ICT providers supporting critical or important functions are contractually bound to take part in TLPT.

5. ICT third-party risk (Articles 28 to 30)

• A strategy on ICT third-party risk, including a policy on ICT services supporting critical or important functions, is approved and reviewed by the management body (Article 28(2), Delegated Regulation (EU) 2024/1773).
• The register of information covers all contractual arrangements for ICT services at entity, sub-consolidated and consolidated level, in the Implementing Regulation (EU) 2024/2956 templates, including subcontractors that effectively underpin services supporting critical or important functions. Each provider is identified by LEI or EUID. See the DORA ICT Third-Party Risk and Register of Information Guide.
• The register is submitted when [Competent authority] requests it, at least yearly, and new arrangements for critical or important functions are notified in advance (Article 28(3)).
• Before contracting, [Organisation] assesses criticality of the function, concentration risk, provider due diligence and conflicts of interest (Article 28(4)).
• Every ICT contract contains the Article 30(2) terms: service description, data locations, data protection, data return on termination, service levels, incident assistance at no additional cost or at a cost set in advance, cooperation with authorities and termination rights.
• Contracts for critical or important functions add the Article 30(3) terms: full service level descriptions with performance targets, notice and reporting duties, business contingency plans that are tested, participation in TLPT, unrestricted rights of access, inspection and audit, and exit strategies with a mandatory adequate transition period.
• Subcontracting of ICT services supporting critical or important functions meets Delegated Regulation (EU) 2025/532, including due diligence on the chain and rights to object to material changes.
• Exit strategies for critical or important functions are documented, tested and realistic, with alternative providers or in-house options identified (Article 28(8)).
• Third-party access to [Organisation] systems uses individual named accounts, MFA and time-limited privilege. See the Third-Party Access Policy Template. The Snowflake breach, where stolen credentials without MFA opened customer data warehouses, shows that controls on the customer side still matter when a provider is involved.
• Dependence on providers designated as critical ICT third-party providers is known, using the ESAs' published list (first published 18 November 2025). See the DORA Critical ICT Third-Party Provider Oversight Guide.

6. Information sharing (Article 45)

• A decision has been made on joining trusted threat intelligence sharing communities, with legal review of the sharing arrangements and protection of personal and business data.
• [Competent authority] has been notified of participation in any information sharing arrangement, as Article 45(3) requires.
• Intelligence received is fed into detection rules, the testing programme and risk assessments, with a named owner.

Implementation guidance

Order of work: start with the mapping of critical or important functions to assets, identities and providers, because the register, testing scope, incident classification and contract remediation all depend on it. Next, make incident classification and the four-hour notification work in an exercise, since timing failures are visible to supervisors immediately. Then fix the register's data quality, remediate Article 30(3) contract terms for critical or important functions first and the rest at renewal, and only then mature the wider framework.

Testing your readiness: run a tabletop that takes a realistic outage of a provider supporting a critical function from detection to the final report, timing each step against the 4, 24 and 72 hour points. Run a register submission dry run through the authority's validation rules before the real deadline.

Small and large entities: an entity under the simplified framework follows Article 16 and Title III of RTS 2024/1774, which is shorter but still includes access control, so most of section 2 still applies in lighter form. A large group needs consolidated and sub-consolidated registers, a group-wide incident classification service, and coordination of TLPT across entities, including pooled tests where a provider serves several entities.

Penalties: DORA does not set a single EU fine level for financial entities. Article 50 requires Member States to lay down administrative penalties and remedial measures, which national law can extend to members of the management body. Check your national implementing law for the amounts.

Metrics to track readiness: percentage of checks Met; time from detection to classification and to initial notification in exercises; register records failing validation; contracts for critical or important functions with all Article 30(3) terms; systems supporting critical or important functions tested in the last 12 months; and privileged and non-human accounts reviewed within six months.

References: EUR-Lex: Regulation (EU) 2022/2554 (DORA) · EUR-Lex: Delegated Regulation (EU) 2024/1772 · EUR-Lex: Delegated Regulation (EU) 2025/301 · EUR-Lex: Implementing Regulation (EU) 2024/2956 · EUR-Lex: Delegated Regulation (EU) 2024/1773 · EUR-Lex: Delegated Regulation (EU) 2025/532

This template summarises obligations under Regulation (EU) 2022/2554 and its Level 2 acts and is not legal advice. Related NHI Mgmt Group resources: DORA Guide · DORA and NIS2 Overlap Mapping Guide · DORA Executive Briefing · NIS2 Readiness Checklist