DORA compliance checklist for financial entities: what to have

What a DORA compliance checklist for financial entities must cover

A regulator, client or board now expects DORA evidence, and the first thing to know is that DORA sets no certificate. No auditor can certify an entity as DORA compliant, so compliance means having the required policies, registers, tests and contract terms in place and being able to show them to the competent authority on request. The checklist is therefore an evidence plan: for each obligation, which document or record exists, who approved it, when it was last reviewed and where a supervisor would find it. The core documents include the ICT risk management framework and digital operational resilience strategy (Article 6), the information security policy (Article 9(4)(a)), business continuity and recovery plans (Article 11), backup policies (Article 12), crisis communication plans (Article 14), the incident management process (Article 17), the testing programme (Article 24) and the third-party risk strategy, register of information and exit plans (Article 28).

The exact list depends on the type of financial entity, its size and whether it runs critical or important functions. A microenterprise or an entity using the simplified regime carries a lighter set of obligations, and only some entities must run threat-led penetration testing. Confirm your scope against the Regulation and the technical standards before you build the list, because a checklist copied from a larger bank will create work that a supervisor does not expect and miss obligations that apply to you. Recurring items matter as much as one-off documents. Article 6(5), Article 8 and Article 24(6) name activities that must happen at least yearly, and the delegated regulations set shorter cycles for some controls, such as six-monthly access reviews for systems supporting critical or important functions under Article 21 of Delegated Regulation (EU) 2024/1774.

Ownership is the point to settle first. The organization owns every control, approves its policies through the management body and signs off its own risk decisions. An implementation partner can prepare systems, draft documentation, configure logging and evidence collection and help run tests, but it cannot approve the checklist or attest to it. The competent authority alone judges compliance. Ask any partner to name in writing which items they will prepare, which the entity must approve and which the entity must keep current, and check that each contract clause for ICT providers traces to Article 30(2). Confirm the detailed cost and effort of this work with your advisers and with the supervisor's guidance rather than relying on estimates in this checklist.

Which policies and plans DORA requires

The ICT risk management framework and digital operational resilience strategy sit at the top of the document set. Article 6 asks the financial entity to have a framework that covers identification, protection, detection, response and recovery, and to set a resilience strategy that states how the framework supports the business. Article 9(4)(a) names an information security policy as one of the documents the framework must produce. Delegated Regulation (EU) 2024/1774 Article 2 requires the ICT security policies to be embedded in the framework, aligned with the strategy's information security objectives, and to state the date the management body formally approved them. The management body approves the framework and strategy, and an undated or unapproved policy is weak evidence.

Framework and strategy: a single document that links business objectives, ICT risk tolerance and the security objectives the policies implement.
Information security policy: the top-level policy, with the approval date and the approving body written on its face.
Approval record: minutes or a signed resolution showing the management body reviewed and approved these documents.
Operational evidence: access reviews, change records or risk register entries that show the policy is applied.
Annual review: proof that the framework was reviewed and the review reported to the management body.

Check that every security policy cites its approval date and that the framework names the owner of each policy.

Which registers and inventories to keep current

DORA checklists tend to list documents, but supervisors test whether the underlying records agree with each other. The cards below cover the registers and inventories that feed one another, from the ICT service inventory up to the register of information.

ICT service and provider inventory

This is the starting record: every ICT service the entity uses, the provider behind it, the systems it touches and the entity that contracts for it. Include self-hosted open-source platforms and any hosting provider the entity relies on, since a self-hosted product still needs an owner, a support route and a contract or internal arrangement that is recorded. Check that every contractual arrangement in the procurement system appears here and that no provider is listed without a named business owner.

Register of information on ICT contracts

Article 28(3) requires entities to maintain and update a register of information covering all contractual arrangements for ICT services provided by third parties, at entity level and at sub-consolidated and consolidated levels. The register must distinguish arrangements that support critical or important functions. Check that each record links back to the service inventory and that contract changes trigger an update. The templates and reporting cycle are covered in the register of information guide.

Critical or important function classification

The classification of functions and assets must be reviewed at least once a year under DORA Article 8(1). This review decides which ICT services support critical or important functions, which in turn sets the contract clauses, testing frequency and register flags that apply. Check that the classification records the reasoning for each function, that business owners sign it off, and that a change in a function, such as a new payment channel, triggers a reassessment.

Asset inventory tied to functions

Systems, data stores and network components need to be mapped to the functions they support, because classification decisions and testing scope depend on that mapping. Legacy systems also need their own risk assessment at least yearly under Article 8(7). Check that each asset has an owner, a function reference and a status, and that retired or unsupported systems are flagged rather than silently dropped from the inventory.

Residual risk inventory and acceptances

Delegated Regulation (EU) 2024/1774 Article 3(d) requires residual risks to be identified, roles to be assigned for accepting risks above tolerance, and an inventory of accepted residual risks with justifications. That inventory must be reviewed at least once a year. Check that each acceptance names the accepting role, states the justification and an expiry or review date, and that risks above tolerance do not appear as accepted without the right approval.

Consistency checks across records

Supervisors often find gaps where two records disagree, such as a contract in the register with no matching service, or a critical function with no mapped systems. Run a reconciliation across the service inventory, the register, the function classification and the residual risk inventory before each annual review. Record who performed the reconciliation, what discrepancies were found and how each was closed. This reconciliation is the evidence that the records are maintained rather than produced once.

Which reviews and tests must run every year

This sequence moves from the governance review of the framework down to the technical testing of critical systems, so each yearly cycle refreshes the documents that drive the tests and leaves evidence a supervisor can request. Read it as an annual calendar in which earlier outputs feed later steps.

Review the ICT risk management framework
The management body and the ICT risk function review the ICT risk management framework at least once a year, as Article 6(5) of DORA requires. The review should check whether the framework still fits the entity's risk profile, its digital operational resilience strategy and recent incidents, tests and third-party changes. Output: a dated review report, approved by the management body, that lists the changes made and the reasons for them. Confirm internally who owns the report and where it is stored.
Refresh the classification of functions, assets and risk scenarios
Article 8(1) and 8(2) require the entity to review, at least yearly, its classification of ICT-supported business functions and information assets, and its risk scenarios. Business owners confirm which functions are critical or important, and the ICT team confirms which systems and dependencies support them. Output: an updated function and asset inventory and a risk scenario register with a sign-off record. These outputs feed the testing scope in the later steps.
Assess legacy systems and their risk
Article 8(7) requires a yearly assessment of the risk posed by legacy ICT systems. The team identifies systems that are no longer supported by vendors, lack security updates or depend on outdated components, then records the compensating controls and replacement plans for each. Output: a legacy system risk assessment with named owners and dated actions. Any accepted residual risk from this review should be added to the inventory required under the residual risk rules in Delegated Regulation (EU) 2024/1774.
Test continuity and recovery plans
Article 11(6) requires testing of ICT business continuity plans and response and recovery plans at least yearly, including scenarios such as cyber incidents and loss of key suppliers. The test should use the business functions and dependencies confirmed in the classification review. Output: a test plan, a record of what was exercised, the gaps found and remediation tickets with owners. Ask the team to show that recovery objectives were measured during the exercise, not assumed.
Report senior ICT staff findings to the management body
Article 13(5) requires senior ICT staff to report at least yearly to the management body on ICT risk and the state of the resilience programme. The report should draw on the framework review, the legacy assessment and the continuity test results, and it should state open risks, decisions needed and resource gaps. Output: a minuted presentation or report, with the management body's recorded discussion. Supervisors commonly ask for these minutes, so keep them with the framework review report.
Test systems supporting critical or important functions
Article 24(6) requires that systems and applications supporting critical or important functions be tested at least yearly, in line with the testing programme. The scope comes from the classification review, and the test types are chosen under the testing programme, which may include vulnerability assessments, scenario-based tests and penetration tests. Output: a test report per system, with findings classified by severity, remediation owners and retest evidence. Confirm with your testers whether any threat-led testing obligation applies to the entity, since that is a separate regime.
Apply the shorter cycles in Delegated Regulation 2024/1774
Delegated Regulation (EU) 2024/1774 sets more frequent controls for systems that support critical or important functions. Automated vulnerability scanning of those assets must run weekly under Article 10, firewall rule checks must run at least every six months under Article 13, and access rights reviews must run at least every six months under Article 21. Output: a control calendar with scan logs, firewall review records and access review sign-offs for each period. These shorter cycles are the most frequent evidence requests in practice, so set up the calendar and its records before the annual cycle begins.

Incident reporting deadlines to build into the runbook

The runbook needs a major incident clock that starts the moment an entity becomes aware of an ICT incident, and the classification step has to finish fast enough that the first notification still lands on time. Under Delegated Regulation (EU) 2025/301, Article 5, the initial notification is due within 4 hours of classifying the incident as major and no later than 24 hours after becoming aware of it. The intermediate report follows within 72 hours of the initial notification, and the final report is due no later than one month after the latest intermediate report. Because the 4-hour limit runs from classification, a slow or undocumented classification decision pushes the first report toward the 24-hour outer limit, so the runbook should name who classifies, how fast that person must decide, and what evidence supports the decision.

Build the clock into the incident management process itself. Assign owners for the initial, intermediate and final reports, store the timestamps for awareness, classification and each submission, and rehearse the sequence with the incident response and communications teams using a tabletop exercise. Check the templates, channels and field-level instructions in the operational instructions published by the EBA and in the incident reporting guide on the EUR-Lex text of Implementing Regulation (EU) 2025/302 before you finalize the runbook, because these documents are the ones your competent authority will expect you to follow. Confirm with your authority which submission channel it uses and whether any national procedure adds steps.

Plan for change as well. The Commission's Digital Omnibus proposal (2025/0360(COD)) would route major incident reports through a single entry point under NIS2, and as of the latest check the procedure is still awaiting committee decision. Keep the reporting contacts and submission steps in a separate, versioned annex so that a change in entry point affects one document rather than the whole runbook, and review that annex each time the procedure moves.

Contract clauses every ICT agreement needs

Article 30(2) of DORA lists clauses that every contract for ICT services must contain, whether or not the service supports a critical or important function. The cards below walk through that clause set in plain terms, with the check to run against each executed contract.

Clear service descriptions

The contract must describe the ICT services provided, including which functions they support and what the provider does and does not do. Vague wording such as "managed platform support" makes it hard to classify the arrangement, fill in the register of information, or judge whether a subcontractor sits inside the agreed scope. Check that the service description matches the systems and activities your team actually relies on, and that any change in service scope is made by written amendment.

Service and data locations

The agreement must state where the contracted services are performed and where data is stored and processed, including backup and support locations. Supervisors and your own exit planning both depend on knowing these locations. Confirm that the contract names countries or regions, that you are notified before a change, and that the locations in the contract match the locations the provider reports in its due diligence file.

Data protection and return

The contract must set out how the provider protects data and how data is returned or deleted when the agreement ends. Ask for the specific return format, the timeline for return, and the deletion confirmation the provider will give. Check that these terms are written into the executed contract and that they can be carried out in practice, because exit plans tested under Article 28(8) rely on them.

Incident assistance at agreed cost

The provider must assist you when an ICT incident affects the service, either at no additional cost or at a cost fixed in advance. Your reporting clock for major incidents is short, so the contract should commit the provider to timely information, named contacts and cooperation during the incident. Check whether the cost terms are stated in the signed contract, not left to a later price list.

Cooperation with competent authorities

The contract must oblige the provider to cooperate with your competent authority and any other authority relevant to the arrangement. This covers requests for information, access for inspections and the provider's own responses to supervisors. Confirm that the wording reaches the provider's sub-contractors where they are needed to answer a request, and that the clause is not limited to what the provider chooses to share.

Termination rights and awareness training

The contract must give you termination rights in the circumstances DORA specifies, and it must require the provider to take part in your security awareness and digital operational resilience training where appropriate under Article 13(6). Check that termination triggers and notice periods are written out, and that training obligations name who must attend and how often. Where the service supports a critical or important function, the contract guide covers the further requirements that apply on top of this clause set.

Training records that show compulsory modules were completed

Article 13(6) of DORA makes ICT security awareness programmes and digital operational resilience training compulsory for all employees and senior management, so the first record a supervisor will ask for is proof that every one of those people completed the modules. Build a training register that lists each person in scope, their role, the modules assigned, the completion date and the version of the material they received. Pull the population from the HR system and reconcile it against the identity directory once a quarter, because joiners, movers and leavers are where gaps usually appear. Keep the completion data in a form you can export, not only as screenshots from a learning platform.

Supervisors will also test content and governance, not just attendance. Keep the course outlines, slide decks or e-learning scripts, and a dated record of who approved each version. Show that senior management and the members of the management body attended the digital operational resilience sessions, with the date and the topics covered, since the management body must understand and approve the ICT risk management framework. Where the entity relies on an ICT provider's staff who have access to its systems, Article 30(2)(i) makes participation in security awareness training a contract term where appropriate, so record which provider personnel were trained and under which clause.

Confirm the details with your own HR and learning teams before you assume the records exist. Ask whether the learning system can report completion by role, by legal entity and by date, whether contractors are enrolled at all, and how long completion data is retained under your records policy. Ask the provider managing your platform whether the training records can be stored alongside the access reviews and change logs they already produce. Agree the format of the register in writing before the first assessment, because a register that cannot be filtered by role will take far longer to produce when a supervisor asks.

DORA checklist questions buyers ask before hiring help

Is a DORA compliance checklist a certificate?

No. DORA sets no certification scheme, so no auditor can certify an entity as DORA compliant, and a checklist is a working tool, not evidence of a certificate. Competent authorities supervise compliance using their powers under Article 50 and look at documents, registers, test records and decisions the entity can produce on request. The only attestation an authority issues under the Regulation is the one confirming that a threat-led penetration test met the requirements (Article 26(7)). Treat the checklist as a map of what your supervisor may ask to see, and keep the evidence behind each line current. Any implementation partner can prepare that evidence, but the management body remains accountable for it.

How much work does a DORA checklist imply for my firm?

The volume depends on a few variables that you can establish before asking for a quote. The main drivers are the type of financial entity under Article 2(1), its size and the proportionality options that apply to it, the number of ICT third-party service providers and contracts, and how many of your functions are critical or important. Each of these changes how many policies you must write, how many contracts must be reviewed against the Article 30(2) clauses, and how many yearly activities must be run. Ask any partner to break its estimate down by these drivers, and to state which items it treats as one-time work and which recur each year. An illustrative example: a payment institution with a few outsourced SaaS tools will carry a smaller workload than a bank with cloud-hosted core systems and many providers.

Can a small firm meet DORA requirements in-house?

Yes, a small firm can often do much of the work in-house, because DORA applies the proportionality principle of Article 4 and microenterprises and smaller entities can use the simplified regime. Before you start, confirm that DORA applies to you and which obligations change for your entity type, since the simplified regime and the member state options differ from one kind of entity to another. Then decide which parts you can own with existing staff, such as the register of information and yearly reviews, and which need specialist help, such as technical testing or contract negotiation with large providers. Confirm the applicable rules with your national competent authority or your legal adviser, as the answer depends on your licence and status.

What does DORA work need from our compliance and IT teams?

The work needs named owners on both sides. The compliance team typically owns the policy set, the register of information, contract reviews against the Article 30(2) clauses, and the evidence trail that shows management body approval. The IT and security teams own the technical controls in the ICT risk management framework, the asset and configuration records, backup and continuity testing, vulnerability scanning and access reviews at the frequencies set by Delegated Regulation (EU) 2024/1774. Both teams should agree on who keeps the incident management process and who runs the yearly testing programme. Expect the engagement to need time from system owners for interviews and walkthroughs, so ask any partner for a written list of the people and access it will require.

What does an implementation partner prepare, and what does the entity sign off?

A partner can prepare systems, controls and evidence, but it does not issue audit reports, attestations or certifications, and it cannot approve policies on your behalf. In a typical fixed-scope engagement, DeployOpen would plan, implement, document and test self-hosted open-source platforms inside your own infrastructure, prepare the policies, registers and test records, and hand over an evidence pack in an agreed format. The entity signs off on its risk appetite, residual risk acceptance, policy approval by the management body, contract decisions and any regulatory submission. Independent review, where you choose to obtain it, comes from a qualified external assessor. Agree this split in writing in the scope document before work starts.

Which DORA checklist items are one-time work and which recur?

Setup work is largely one-time: writing the ICT risk management framework, drafting the policies, building the initial register of information, mapping critical or important functions, and reviewing existing contracts. Recurring work includes the yearly activities that DORA requires, such as the framework review, review of the classification of functions and assets, review of risk scenarios, testing of continuity and recovery plans, and testing of systems supporting critical or important functions. Some items recur at higher frequencies under Delegated Regulation (EU) 2024/1774, such as access rights reviews and firewall rule checks at least every six months for those systems. Ask any partner whether its quote covers the first year only or includes ongoing support under a retainer, and what that support costs.

How should we compare quotes for a DORA checklist engagement?

Compare quotes against the same written scope rather than against headline figures. Ask every provider to list its deliverables, the entity types and ICT providers it has assumed, the systems and documents in scope, the number of working sessions, and the items that the entity must complete itself. DeployOpen works on fixed-scope engagements with scope, deliverables and timelines agreed in writing before work starts, and it does not publish a price list, so a quote follows from that written scope. Check whether the proposal covers testing, reporting to your own supervisor, or support after handover, and whether any of those are separate retainers.

Who owns each item and who can prepare it

The management body owns the checklist's top layer. It approves the ICT risk management framework, the information security policy and the other policies DORA requires, and it carries the accountability for them. Compliance and risk functions own the registers and recurring reviews: the register of information, the residual risk inventory and its annual review, the framework review, and the record of which activities were carried out each year. IT and security own the technical evidence, such as vulnerability scan outputs, access rights reviews, backup restore tests and continuity test records. Procurement and legal own the contract clauses that Article 30(2) requires in every ICT services agreement. Before work starts, confirm this split in writing, because a gap between these owners is where most checklists stall.

An implementation partner such as DeployOpen can help prepare systems, documents and evidence for the items above, within a scope agreed in writing before work begins. In practice that can mean configuring logging and access reviews on self-hosted platforms, drafting policy templates for the management body to adopt, or assembling the evidence folder an assessor will ask for. The partner does not replace the entity's own accountability. The management body still decides, signs off and owns the outcome, and the entity must confirm which items it will hand over and which it will keep in-house. Ask any partner to state those boundaries in the scope document, not in a sales conversation.

Only the competent authority supervises DORA compliance, using the powers set out in Article 50 of the Regulation. No auditor can certify an entity as DORA compliant, and DeployOpen does not issue reports, attestations or certificates or guarantee a supervisory outcome. If the entity commissions an independent auditor or assessor to examine a specific area, that party issues its own report, which belongs to the entity and is only one input to supervision. Treat any firm that offers a DORA certificate as a warning sign. Confirm with your competent authority which evidence it expects and how it wants the checklist items presented.

How DeployOpen prepares DORA evidence for your team

DeployOpen works on the DORA compliance checklist as a fixed-scope implementation engagement inside your own infrastructure. We prepare the systems, controls and documents the checklist calls for, while your management body owns the policies, approvals and decisions, and independent assessors judge the result.

How we scope

Written scope fixes which entities, systems and ICT services the checklist items cover before work starts.
We map existing policies, registers and inventories against the checklist items your scope includes.
Scope, deliverables and timelines are agreed in writing, and a quote follows from that written scope.
We confirm with you which supervisor, entity type and proportionality options apply to your organization.

How we build

We configure self-hosted open-source platforms in your cloud accounts, data centers or air-gapped networks.
We set up logging, backup, access review and vulnerability scanning so the recurring activities produce records.
We draft the policy and plan documents for your management body to review, amend and formally approve.
We build the register of information and asset inventory structures from data your teams supply and verify.

How we hand over

Each deliverable comes with documentation covering configuration, owners, review cycles and where evidence is stored.
We prepare evidence packs that show what each checklist item required and how your systems met it.
Your staff receive knowledge transfer so they can run reviews, tests and reporting after the engagement ends.
We do not issue reports or certificates; your independent auditor or assessor reviews the evidence you hold.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work closes.
Retainers can cover annual reviews of frameworks, risk scenarios and access rights as the checklist requires.
Security testing of applications, APIs, infrastructure and AI systems can run alongside the compliance work.
We confirm with your team which contract clauses and ICT provider evidence need follow-up before each review cycle.

DORA compliance checklist for financial entities