DORA Compliance Checklist (2026 Guide)

You already know DORA is in force, but that does not always make daily execution clearer. A compliance lead asks for evidence, IT says the data lives in five places, procurement has part of the vendor inventory, and senior management wants a simple answer to one question: are we actually compliant, or just hoping we are? That is exactly where a practical dora compliance checklist becomes useful.

The challenge in 2026 is no longer just understanding the regulation. It is proving that your controls, records, governance, and reporting processes work in practice. For many financial entities, the hardest part is not reading the rules. It is translating them into an operating routine that holds up under regulatory scrutiny.

This article gives you a structured, plain-English checklist you can use to assess your current position, spot weak points, and organize next steps. If you need a broader starting point first, it helps to review what is dora before using this checklist as a working document.

DORApp was built to simplify DORA compliance for EU financial institutions through a modular approach, turning complex requirements into structured workflows and technically compliant reporting outputs. Here, the focus stays educational: what DORA requires, what a good checklist should include, and how teams typically operationalize it.

Why a checklist matters more in 2026

No such thing as “DORA certification”: what people actually mean (and how to respond)

The complete DORA compliance checklist

DORA gap assessment: a simple way to score each requirement and prioritize remediation

Your Register of Information deserves its own track

What proof of compliance looks like in practice

Common gaps teams discover too late

How to use this checklist without creating more admin

What good DORA tooling supports (without turning the checklist into a software shopping list)

Frequently Asked Questions

Key Takeaways

Conclusion

Why a checklist matters more in 2026

DORA became applicable on January 17, 2025, but 2026 is where many institutions feel the real shift. Supervisors are moving from initial readiness questions to evidence-based review. They want to see that your governance model works, your records are current, and your operational resilience processes are not just policy statements.

From a regulatory standpoint, this means your dora checklist cannot be a one-time project tracker. It needs to reflect ongoing operations across the five pillars: ICT risk management, incident reporting, digital operational resilience testing, ICT third-party risk management, and information sharing.

If you are still building your internal roadmap, this is where articles on dora implementation and the dora implementation deadline help frame the timeline behind the work.

What many teams overlook is that regulators increasingly compare information across sources. The Register of Information, incident processes, risk controls, outsourcing documentation, and internal governance records should align. If they do not, that may trigger follow-up questions even where each document looks acceptable on its own.

No such thing as “DORA certification”: what people actually mean (and how to respond)

If someone asks whether your institution has a “DORA certificate,” it can put you in a difficult position. You do not want to sound evasive, but you also do not want to confirm something that does not really exist in an official, standardized way.

In most cases, there is typically no formal “DORA certification” for companies or individuals that you can obtain once and then reuse forever. The phrase shows up anyway because it is a convenient shortcut in procurement questionnaires, client due diligence requests, and board updates. People want a simple yes or no signal, even though DORA is designed around ongoing operational resilience.

Now, when it comes to what stakeholders usually mean by “certification,” they are typically asking one of three things:

Are you in scope and actively implementing the five pillars with accountable ownership?

Can you demonstrate evidence that controls operate in practice, not just on paper?

Can you produce regulator-ready records and reporting outputs, especially around third-party oversight and the Register of Information?

Think of it this way: “proving compliance” under DORA is usually closer to being audit-ready than holding a certificate. It is your ability to show structured evidence, explain how you monitor and improve controls, and demonstrate that management oversight is real.

What “proof” typically looks like instead

Instead of a certificate, institutions usually rely on a package of artifacts and routines that can be shown to supervisors, auditors, clients, and internal governance bodies. This often includes:

approved policies and documented governance decisions, with versioning and review dates

testing plans and results, plus remediation tracking and retesting evidence

incident logs, classification rationale, post-incident reviews, and follow-up actions

third-party inventory, contract clause reviews, subcontractor visibility, and concentration risk monitoring

Register of Information exports that reconcile with your internal vendor and contract records

The difference often comes down to repeatability. If you can run the same process each quarter and produce consistent outputs, it is much easier to answer stakeholder questions confidently.

How to answer the “are we certified?” question without overcommitting

From a practical standpoint, it helps to agree on language internally before the first external questionnaire arrives. Many institutions use status phrasing such as:

“We are aligned with DORA requirements and maintaining evidence across the five pillars.”

“We are partially aligned, with remediation actions tracked and target dates approved by management.”

“We are currently implementing DORA controls, with priority focus on third-party oversight and evidence readiness.”

If you can, reference specific evidence categories rather than general statements. For example, you might point to your operating routines, your incident and testing records, and your Register of Information readiness. If you are using a structured workflow tool, you might also reference that you can produce consistent exports and maintain audit trails for changes, without implying that tooling itself creates compliance.

Here is the thing: wording can matter, especially in regulated environments and client contracts. If you are responding to external parties, it is usually smart to involve your legal and compliance teams for the exact phrasing, particularly where statements could be interpreted as guarantees.

The complete DORA compliance checklist

Here is the practical part. A useful dora compliance checklist should cover not just policy existence, but ownership, evidence, review frequency, and data quality. Think of it as an operating checklist, not a legal summary.

1. Confirm scope and entity classification

Confirm whether your organization falls within one of DORA's 20 categories of financial entities.

Document the legal entities, branches, and business functions in scope.

Map any group-level governance structure that affects DORA responsibilities.

Identify any national supervisory expectations that may affect implementation details.

2. Establish governance and accountability

Assign clear ownership across compliance, risk, IT, security, procurement, legal, and senior management.

Document management body oversight and reporting lines.

Create approval and escalation paths for DORA-related decisions.

Maintain evidence of board or senior management review where relevant.

3. Build or refresh your ICT risk management framework

Identify critical ICT assets, services, processes, and dependencies.

Maintain a risk identification and assessment methodology.

Define controls, tolerances, treatment actions, and review cycles.

Link ICT risks to business services and critical functions.

If your team still struggles with the basics, a plain-language explanation of what is ict risk can help align legal, risk, and technical stakeholders around the same terms.

4. Prepare for ICT-related incident management and reporting

Define incident classification criteria and escalation logic.

Map internal notification responsibilities and timelines.

Maintain procedures for detection, response, recovery, and post-incident review.

Check whether reporting templates and evidence logs are ready for regulator-facing use.

5. Organize resilience testing

Maintain a testing plan proportionate to your size, risk profile, and services.

Record test scope, methodology, results, remediation actions, and retesting where needed.

Ensure findings from testing feed back into risk management and control improvements.

6. Strengthen ICT third-party risk management

Maintain a complete inventory of ICT third-party service arrangements.

Identify critical or important functions supported by third parties.

Review contracts for required DORA-related clauses and operational oversight needs.

Assess subcontracting chains, especially in light of Delegated Regulation (EU) 2025/532.

Document concentration risk, exit planning, and ongoing monitoring.

7. Maintain your Register of Information

Ensure all required ICT third-party arrangements are captured.

Validate legal entity data, provider identifiers, service relationships, and dependencies.

Align register fields with reporting expectations and XBRL submission needs.

Define a refresh cycle instead of waiting for annual reporting season.

8. Prepare evidence for supervisory review

Keep audit-ready records of approvals, reviews, changes, and remediation actions.

Show how policies translate into operational workflows.

Maintain version control for key documents and data exports.

Be able to explain exceptions, gaps, and planned remediation honestly.

If you need a broader regulatory frame, resources on dora regulation explained and the digital operational resilience act dora are useful reference points.

DORA gap assessment: a simple way to score each requirement and prioritize remediation

A checklist is a strong start, but most teams quickly hit the same problem: “done” or “not done” is not detailed enough to manage risk, reporting, and dependencies. A lightweight dora gap assessment method can help you turn the checklist into something you can actually steer.

For most small compliance and risk teams, the simplest approach is to score each checklist item using a consistent status label. A practical set that works well across pillars is:

Not applicable

Fully compliant

Partially compliant

Not compliant

Once you do that, add one more field that forces clarity: “What evidence supports this status?” If the evidence is unclear, “partially compliant” is often the honest answer, even when a policy exists.

How to prioritize gaps beyond “biggest backlog first”

The reality is that not all gaps have the same operational or supervisory weight. Prioritization typically becomes much easier if you sort open items using three practical lenses:

Impact on critical services and critical or important functions: gaps here tend to create real operational exposure.

Supervisory visibility: items tied to reporting, especially around third parties and the Register of Information, are often easier for supervisors to test quickly.

Dependencies: anything blocked by third parties, subcontractors, or missing upstream data may need early attention because lead times are longer.

Consider this: some “simple” fixes can take months if they require contract changes, provider responses, or group-level approvals. That is why dependency-driven prioritization is often more realistic than pure risk scoring alone.

Turn the checklist into a living control tracker

If you want the checklist to survive beyond an initial push, keep reporting minimal and consistent. A basic structure that many institutions use is:

Owner: one accountable person per item, even if several teams contribute

Target date: when “fully compliant” is realistically expected

Remediation actions: the specific steps required, not just “update policy”

Evidence location: where the artifact lives, such as a system record, export, or controlled repository

Think of it as a control tracker rather than a project plan. If you can review it monthly, update statuses honestly, and attach evidence consistently, you are much closer to being able to answer the hardest question in 2026: not “are we compliant,” but “can we prove it quickly, and can we explain what is still in progress?”

Your Register of Information deserves its own track

Many institutions underestimate how much of the dora requirements checklist becomes visible through the Register of Information. The register is not just a vendor list. It is a structured record of ICT third-party service arrangements, and under DORA it must be maintained in a way that supports supervisory review and EU-level reporting.

The first Register of Information submission deadline was April 30, 2025. That milestone matters, but in 2026 the bigger issue is maintenance quality. Regulators may use automated tools to cross-reference ICT registers across the EU, which makes data consistency more important than ever.

In practice, this means your register work should include:

complete provider and entity records

clear mapping of services to functions and legal entities

review of subcontracting and supply chain relationships

validation before export and submission

repeatable ownership for updates throughout the year

Platforms like DORApp streamline the Register of Information process through a five-step approach: importing existing data, managing it in an intuitive interface, enriching records from public sources, validating against reporting rules, and generating export-ready outputs. That kind of workflow support may reduce manual friction, but the regulatory responsibility still stays with your institution.

For topic-specific reading, the Register of Information category is worth bookmarking.

What proof of compliance looks like in practice

Here is the thing: a dora compliance checklist is only useful if it leads to evidence. In 2026, many teams are shifting from “do we have a document?” to “can we prove this control is active, reviewed, and linked to accountable owners?”

Proof of compliance usually looks less glamorous than strategy presentations. It often means meeting minutes, approval records, issue logs, testing results, remediation tracking, contract reviews, and data exports that match each other.

What supervisors may expect to see

clear accountability for DORA obligations

up-to-date operational records rather than stale snapshots

evidence of challenge, review, and sign-off

traceability from policy to execution

documented handling of identified weaknesses

With features such as configurable workflows, audit trail visibility, data import templates, auto-enrichment, and export of DORA-compliant XBRL reports, DORApp is one example of how institutions can structure evidence generation more efficiently. The practical advantage is not that software replaces judgment. It is that teams can start working with imperfect data and improve it through controlled processes instead of waiting for a perfect spreadsheet that never arrives.

If you want a concise refresher on the framework itself, the DORA Pillars Explained: Complete Breakdown (2026) article is a useful companion read.

Common gaps teams discover too late

The reality is that most DORA programs do not fail because people ignored the regulation. They struggle because implementation was fragmented. One team owns the contract inventory, another owns ICT risk, and another owns reporting, with no reliable bridge between them.

Gap 1: The register and contract set do not match

You may have contracts that are not reflected in your Register of Information, or register entries that do not clearly point to the underlying agreement. That creates avoidable questions during review.

Gap 2: Policies exist, but workflow evidence is weak

A strong policy library is useful, but supervisors may still ask how incidents are escalated, how reviews happen, and where decisions are documented. If that evidence sits in email threads, retrieval becomes painful.

Gap 3: Subcontracting visibility is thin

This is becoming more important after the 2025 delegated regulation on subcontracting risk. Institutions often know their direct provider but have limited visibility into deeper ICT supply chains.

Gap 4: XBRL readiness starts too late

Many teams leave formatting and technical validation to the end. That is risky. XBRL submission quality usually depends on upstream data quality, structure, and consistent relationships between records.

Gap 5: Management reporting is too abstract

Senior stakeholders need concise, defensible reporting. If updates are vague, it becomes harder to prove active oversight. The DORA Fundamentals category and the article on DORA European Commission Timeline and History (2026) can help teams anchor these gaps in the broader regulatory development path.

How to use this checklist without creating more admin

A checklist should simplify execution, not add another layer of reporting theater. The best way to use a dora checklist is to turn it into a recurring review structure with named owners, evidence sources, and review dates.

A practical operating model

Assign one owner per checklist area, even if several teams contribute data.

Track evidence location, not just completion status.

Review high-risk areas monthly and broader framework items quarterly.

Use a remediation log for open issues rather than pretending everything is complete.

Reconcile register, contract, risk, and incident records on a regular cycle.

Consider this: if your current process relies on disconnected spreadsheets, manual reminders, and last-minute consolidation, the cost is not just inefficiency. It is weaker defensibility. DORApp's modular structure, including ROI, TPRM, reporting, audit trail support, and roadmap modules for broader resilience operations, reflects the reality that institutions often need to improve one process at a time rather than replace everything at once.

If you are evaluating your next step, you can explore DORApp modules at dorapp.eu, book a conversation at Book a Demo, or try the platform through the Free Trial – 14 Days page.

What good DORA tooling supports (without turning the checklist into a software shopping list)

Once your checklist becomes a living tracker, the next bottleneck is usually execution at scale. Not because people do not understand what to do, but because the data, evidence, and approvals sit across too many places.

Competitors often describe this as “DORA compliance software,” but the useful question is more specific: what workflows should tooling support so you spend less time chasing documents and more time improving controls?

Common tooling use cases teams actually need

For most institutions, the day-to-day friction shows up in a few repeatable areas:

Register of Information preparation: collecting, structuring, validating, and exporting data in a consistent format, including preparation for XBRL submissions where relevant.

Contract clause tracking: recording which arrangements include required clauses, what is missing, and what remediation is in progress.

Third-party assessment workflows: capturing due diligence inputs, reviews, follow-ups, and decisions with clear owners and timestamps.

Concentration risk monitoring: maintaining visibility into dependencies across providers and subcontracting chains, so “who relies on what” can be answered without manual consolidation.

From a practical standpoint, the best tools reduce reconciliation work. They help you align what procurement knows, what IT operates, what risk tracks, and what compliance needs to evidence.

A fit checklist for selecting tools without overbuying

If you are evaluating tooling, a simple way to stay grounded is to check whether the tool supports:

Regulator-ready outputs: exports you can actually use in supervisory conversations, not just internal dashboards.

Audit trail and versioning: the ability to show what changed, when it changed, and who approved it.

Integrations or data import: practical ways to bring in vendor inventories, contract lists, and service data without rebuilding everything manually.

Role-based ownership: clear accountability so controls do not become “everyone’s job,” which often means no one’s job.

Validation checks: especially where reporting formats and register fields must meet defined rules for completeness and consistency.

Now, when it comes to expectations, it helps to be honest internally. Software may support structure, evidence capture, and repeatable reporting, but it does not remove accountability. Your institution still needs to define scope, approve decisions, manage exceptions, and validate that the outputs reflect reality. Requirements can also vary by institution type and jurisdiction, so it is worth confirming what “good enough” looks like with your compliance and legal teams before you lock in a process.

DORApp is built around modules such as ROI, TPRM, reporting, configurable workflows, audit trail support, data import templates, and export of DORA-compliant XBRL reports, which map closely to where institutions typically feel the most operational friction. If you already have systems in place, the goal is usually not to replace everything. It is to make evidence and reporting more consistent, and to reduce the number of manual bridges between teams.

Disclaimer: The information in this article is intended for general informational and educational purposes only. It does not constitute professional technical, legal, financial, or regulatory advice. Website performance outcomes, platform capabilities, and business results will vary depending on your specific circumstances, goals, and implementation. Always evaluate tools and platforms based on your own needs and, where relevant, seek professional guidance.

Regulatory note: This article is for informational purposes only and does not constitute financial, legal, or regulatory advice. DORA compliance requirements may vary based on your institution type, size, and national regulatory framework. Content referencing regulated industries is provided for general context only and should not be interpreted as legal, regulatory, compliance, or financial advice. If you operate in a regulated sector, always consult qualified financial, legal, and compliance professionals for guidance specific to your situation.

Frequently Asked Questions

What is DORA compliance?

DORA compliance means meeting the Digital Operational Resilience Act expectations for how your institution manages ICT risk, handles ICT-related incidents, tests operational resilience, oversees ICT third parties, and participates in information sharing where applicable. In practice, it is less about a one-time readiness exercise and more about operating routines you can evidence, such as governance oversight, risk and control operation, testing results, incident logs, and consistent Register of Information maintenance.

How to prove DORA compliance?

Proving DORA compliance usually means being able to show audit-ready evidence that your controls operate in practice. That often includes approvals and meeting minutes, documented ownership and reporting lines, incident records and post-incident reviews, resilience testing plans and results with remediation tracking, third-party inventories and contract clause reviews, and Register of Information exports that reconcile with your underlying contracts and service mappings. The exact evidence set may vary by institution and supervisor, so it is typically best to align internally on what “proof” looks like before supervisory review.

Is there a DORA compliance certification (or “DORA certificate”)?

In most cases, there is typically no official, universal “DORA certificate” for companies or individuals. The term often appears in procurement and due diligence contexts as shorthand for “are you compliant and can you demonstrate it?” A practical response is to describe your current status in clear terms, for example aligned or partially aligned, and reference the evidence you maintain across the five pillars, including governance records, testing and incident artifacts, third-party oversight documentation, and Register of Information readiness. For external statements, it is usually wise to involve legal and compliance teams to confirm wording.

What are the 5 pillars of DORA regulation?

The five pillars of DORA are ICT risk management, ICT-related incident reporting, digital operational resilience testing, ICT third-party risk management, and information sharing. Many institutions also treat governance, evidence management, and the Register of Information as separate operational tracks, because that is where day-to-day execution and supervisory visibility often concentrate.

What is a DORA compliance checklist?

A DORA compliance checklist is a practical working list of the controls, records, governance tasks, and reporting obligations your institution should review to meet Digital Operational Resilience Act expectations. A good checklist goes beyond policies and asks who owns each item, what evidence exists, how often it is reviewed, and whether the data is current. It is useful because DORA covers several operational areas at once, so teams need a shared structure that legal, compliance, IT, procurement, and management can all follow.

Who should use a DORA checklist inside a financial institution?

Usually, the checklist is most useful when shared across functions. Compliance may coordinate it, but ICT risk, information security, procurement, legal, vendor management, internal audit, and senior management often contribute to different parts. That matters because DORA is not owned by one department alone. For example, the Register of Information may depend on procurement and outsourcing data, while incident reporting depends on IT and security workflows. A checklist creates one view of progress instead of several disconnected status updates.

Does DORA apply to all financial institutions in the EU?

DORA applies to 20 categories of EU financial entities, but the details of implementation may vary depending on entity type, proportionality, and national supervisory interpretation. That is why scope confirmation should be one of the first checklist items. If your institution is part of a group, cross-border structure and legal entity mapping may also affect how responsibilities and reporting are organized. If there is any uncertainty about your exact status, it is best to confirm scope with qualified legal and regulatory advisors.

What are the main pillars my DORA requirements checklist should cover?

Your dora requirements checklist should cover the five core pillars of DORA: ICT risk management, ICT-related incident reporting, digital operational resilience testing, ICT third-party risk management, and information sharing. In practice, most institutions also add governance, evidence management, and Register of Information maintenance as separate checklist tracks, because that is where execution often breaks down. Treating the regulation only as a policy exercise usually misses the operational side that supervisors increasingly want to see.

Why is the Register of Information such a big part of DORA work?

The Register of Information is a structured record of your ICT third-party service arrangements, and it is central to supervisory visibility into outsourcing and provider dependencies. It is not just an administrative list. Its quality affects reporting, third-party oversight, and your ability to explain how critical services rely on external providers. If the register is incomplete, outdated, or inconsistent with contracts and operational records, it may raise broader concerns about governance quality. That is why many institutions treat it as an ongoing operational process.

What changed in 2026 for DORA compliance programs?

In 2026, the emphasis is increasingly on proof of compliance rather than initial preparation. Supervisors may expect institutions to show that controls operate in practice, not just that framework documents exist. The 2025 designation of Critical Third-Party Providers by the ESAs and the 2025 delegated regulation on subcontracting risk also add pressure to improve third-party oversight. Many institutions are now focusing on evidence quality, recurring review cycles, and data consistency across registers, contracts, incidents, and risk records.

Do I need software to complete a DORA checklist?

Not necessarily, but manual methods often become harder to defend as complexity grows. Smaller institutions may begin with spreadsheets and shared documents, especially during early gap analysis. The challenge comes later, when updates, approvals, evidence tracking, and reporting need to stay aligned. Software may help by creating structured ownership, validation, audit trails, and repeatable exports. DORApp is one platform built specifically for this context, with modules for ROI, TPRM, reporting, and workflow support, but any approach still requires clear internal accountability.

What should I review first if my institution is behind?

Start with scope, governance ownership, the Register of Information, and ICT third-party mapping. Those areas often expose the biggest practical gaps fastest. After that, review incident classification, risk framework linkage, and evidence of management oversight. This order works because it focuses first on structural visibility, who is in scope, who owns what, and what third-party dependencies exist. Once those basics are clear, it becomes easier to strengthen testing, remediation tracking, and reporting quality without working blind.

How often should a DORA checklist be updated?

That depends on the item. Some elements, such as open remediation actions, provider changes, and incident procedures, may need frequent review. Others, such as policy frameworks or board-level summaries, may sit on quarterly or annual cycles. A practical approach is to assign review frequency by risk and operational change. The important point is that the checklist should live inside your operating rhythm. If it only appears before audits or submission deadlines, it probably will not support defensible year-round compliance.

Can DORApp guarantee DORA compliance?

No responsible platform should promise that. Compliance depends on your institution's data quality, governance, implementation decisions, and supervisory context. What a specialized platform may do is support compliance processes by structuring workflows, improving evidence capture, validating reporting data, and reducing manual effort. DORApp positions itself around technically compliant reporting outputs, modular workflows, and operational support for DORA processes, but legal and regulatory accountability remains with your institution and its responsible functions.

Key Takeaways

A strong dora compliance checklist should cover governance, ICT risk, incidents, testing, third-party oversight, and Register of Information maintenance.

In 2026, the real challenge is proving operational execution, not just showing that policies exist.

The Register of Information is a year-round data quality process, not a once-a-year reporting file.

Most gaps appear where contracts, provider records, risk ownership, and evidence trails do not align.

Tools may help structure DORA work, but accountability for compliance always stays with your institution.

Conclusion

A useful dora compliance checklist does not try to replace the regulation. It translates the regulation into work your teams can actually manage. That means clear ownership, realistic review cycles, evidence you can retrieve quickly, and records that stay aligned across functions.

If you are still treating DORA as a deadline-driven project, 2026 is a good moment to reset. The institutions that tend to feel more confident are the ones that operationalize compliance in smaller, repeatable routines rather than heroic last-minute pushes. Start with your scope, governance, Register of Information, and third-party dependencies, then build outward from there.

DORApp is one option worth exploring if you want a more structured way to manage DORA workflows, XBRL-ready reporting, and operational evidence across modules. You can learn more through the main platform at Why DORApp, or keep exploring practical guidance through Dorapp's educational content and topic pages.