DORA Regulation Checklist (2026 Guide)
You already know DORA is live, but the hard part is not reading the regulation. It is figuring out whether your bank or insurance company can actually prove compliance when a supervisor asks for evidence. That usually happens in a very practical moment: someone asks for the latest Register of Information, an ICT risk owner cannot trace a control decision, or a third-party arrangement turns out to be poorly classified. What looked finished in January 2025 starts to feel very unfinished in 2026.
This is where a clear dora regulation checklist helps. Not as a box-ticking exercise, but as a working review tool for compliance, risk, IT, procurement, and management. If you need a refresher on what is dora, start there first. In this article, you will get a practical checklist tailored for banks and insurers, with notes on where their operating realities often differ. DORApp was built to simplify DORA compliance for EU financial institutions through a modular approach, turning complex regulatory requirements into structured, manageable workflows with a strong focus on technically compliant reporting outputs.
Why a DORA checklist matters more in 2026
The reality is, 2025 was about getting into position. 2026 is increasingly about showing that your position is real, repeatable, and governed. Supervisors are moving beyond “do you have a policy?” and toward “show me the evidence, ownership, validation logic, and reporting trail.”
That shift affects both a dora bank checklist and a dora insurance checklist. Banks often face more layered governance and wider third-party ecosystems. Insurers often deal with complex outsourcing chains, claims systems, distribution technology, and group structures. Different operating models, same core expectation: you need to demonstrate digital operational resilience as an ongoing management practice.
If you want broader context, it helps to review the digital operational resilience act dora and a more detailed dora regulation explained article before using a checklist operationally.
From a regulatory standpoint, DORA applies from 17 January 2025 and covers 20 categories of EU financial entities. Its five pillars remain the backbone: ICT risk management, incident reporting, resilience testing, ICT third-party risk management, and information sharing. In November 2025, the ESAs designated Critical Third-Party Providers, which made third-party oversight feel much more concrete for many institutions.
The 5 pillars of DORA (and what “good” evidence looks like for each)
If you want a dora regulation checklist that holds up in 2026, it helps to translate each pillar into evidence you can actually produce quickly. Supervisors typically do not want theory. They want artifacts that show ownership, decision-making, and ongoing control.
Here is a practical way to think about the five pillars, and the types of evidence that are often expected when someone asks you to demonstrate that the pillar is operating.
1) ICT risk management: governance you can trace end-to-end
Good evidence usually looks like an owned ICT risk management framework, supporting policies and procedures, and records showing it is used in practice. That often includes risk assessments linked to real services and assets, control decisions with clear rationale, and change records showing how ICT changes feed back into risk decisions.
From a practical standpoint, the strongest evidence is typically not a single PDF. It is the trail: risk acceptance or treatment decisions, minutes or approvals, control implementation records, and follow-up actions when gaps are identified.
2) ICT-related incident reporting: repeatable classification and reporting outputs
Good evidence often includes documented classification criteria, escalation paths, incident logs, and proof that the process has been exercised. You should also be able to show how an incident moved from detection to classification to reporting, including who decided what, and when.
What many people overlook is consistency between internal incident handling and regulatory reporting. If your security team tracks one set of fields, and your compliance team reports another, gaps tend to appear right when time pressure is highest.
3) Digital operational resilience testing: a plan that matches your risk reality
Good evidence typically includes a testing strategy, a testing schedule, test plans and scoping decisions, results reports, and documented remediation tracking. Where advanced testing applies, you should still be able to show the “why” behind your choices, not just the final output.
The difference often comes down to governance: who approves test scope, how findings are prioritized, and how you prove that remediation was completed and validated.
4) ICT third-party risk management: control over dependencies, not just contracts
Good evidence usually includes a maintained Register of Information, third-party risk assessments tied to criticality, concentration risk analysis, and contractual safeguards that match DORA expectations. In most cases, supervisors also want to see that oversight is ongoing, not only done at onboarding or renewal.
Evidence here often spans multiple teams: procurement, IT, security, legal, and operational owners. If the artifacts conflict, such as different criticality classifications in different systems, that inconsistency itself can become a finding.
5) Information sharing: structured, governed, and controlled
Good evidence may be lighter than other pillars, but it still needs governance. That typically means defined rules on what can be shared, with whom, how sensitive information is handled, and who approves participation. Some organizations also keep participation records, internal guidance, and lessons learned that show sharing is managed rather than informal.
Now, when it comes to evidence quality across all five pillars, a few criteria tend to make the difference in 2026:
Consider this: supervisors may also ask for a consolidated view across a group. If your institution operates across multiple entities, the evidence often needs to be consistent across functions and across entities, even when systems or local processes differ. That does not always mean identical documentation, but it usually means a clear, defensible way to reconcile differences and still report coherently.
Your DORA regulation checklist
Think of this checklist as a management review tool. You are not only checking whether something exists. You are checking whether it is complete, current, owned, and defensible.
1. Governance and accountability are clearly assigned
You should be able to identify who owns DORA coordination, ICT risk management, incident classification, third-party oversight, resilience testing, and management reporting. Ownership should be documented, not implied. Escalation routes should also be visible.
Consider this: if a supervisor asked who approves key DORA decisions, could your institution answer in one sentence and back it with records? If not, governance may exist on paper but not in practice.
2. ICT risk management is operating, not sitting in a folder
Your institution should maintain an ICT risk framework that is actually used. That means risk identification, assessment, treatment, monitoring, and review should connect to real assets, services, dependencies, and business functions. Explore the relevant Dorapp category on DORA Fundamentals if you need a broader compliance baseline.
A mature dora regulation checklist asks whether risk decisions are traceable across teams. If your IT team updates a control or changes a provider setup, can compliance and risk see the impact?
3. Your Register of Information is complete and maintainable
This is one of the biggest pressure points. The Register of Information is a mandatory register of ICT third-party service arrangements, and the first EU-wide submission deadline was 30 April 2025. By 2026, the expectation is no longer just submission. It is sustained accuracy.
You should review whether your register includes the right entities, contracts, functions, providers, subcontracting chains, and supporting classifications. You should also check whether data can be updated without rebuilding the entire file each reporting cycle. The Register of Information category is a useful place to explore this topic in more detail.
Platforms like DORApp streamline the creation and maintenance of the Register of Information process through a structured workflow that may include importing existing data, managing records in a web interface, enriching records from public sources, validating against reporting rules, and generating compliant outputs.
4. Legal entity data and identifiers are reliable
What many people overlook is how often reporting errors come from weak master data rather than weak legal interpretation. Entity names, branches, provider records, and identifiers need to be consistent across procurement, legal, compliance, and reporting systems.
This is especially important where lei data supports legal entity consistency. If your institution operates across multiple jurisdictions or group entities, poor identifier hygiene can create validation issues and governance confusion very quickly.
5. ICT third-party risk oversight goes beyond vendor lists
Your dora bank checklist or dora insurance checklist should verify that third-party oversight covers onboarding, risk assessment, concentration analysis, subcontracting visibility, contractual safeguards, and ongoing review. Delegated Regulation (EU) 2025/532 raised the importance of deeper subcontracting risk visibility, so this area deserves close attention.
Under DORA, this means you need a living operating model for provider risk, not a spreadsheet that only gets updated before deadlines.
Using a DORA checklist to assess critical ICT third parties (vendor risk assessment mini-checklist)
Here is the thing: many institutions can list their vendors, but struggle to show how they evaluate a critical ICT third party in a repeatable way. If you want your dora regulation checklist to produce defensible evidence, a simple mini-checklist can help you standardize what “critical” oversight means in practice.
This is relevant not only for banks and insurers. It can also matter for ICT providers that support EU financial entities, since those providers are often asked to supply information, assurance artifacts, and subcontracting visibility. Regulatory frameworks and contractual expectations can vary by jurisdiction and by entity type, so it is sensible to align this with your legal and compliance teams rather than treating it as a one-size-fits-all template.
A mini-checklist you can apply to critical vendors
Think of it this way: the checklist should not live as a one-off document. It works best when it is aligned to how your institution already operates.
For most small business owners and entrepreneurs, vendor management can be simplified. In regulated financial entities, critical ICT third-party oversight is usually a cross-functional workflow. If procurement, IT, security, and legal all use different definitions and templates, it becomes hard to produce a consistent consolidated view when asked.
6. Incident reporting criteria are understood and tested
Your teams should know how ICT-related incidents are identified, escalated, classified, and reported. This includes internal coordination between IT, security, compliance, legal, and business stakeholders. If people still debate where the decision threshold sits every time an incident occurs, the process may be too fragile.
For a broader implementation view, see this article on dora implementation. It helps connect policy design with day-to-day operating processes.
What must DORA incident reports include?
Even with solid thresholds and escalation paths, teams often lose time on one question: what exactly has to be in the incident reporting package? The details can vary depending on the authority, the incident classification, and your institution type, so this is not a substitute for your regulatory interpretation. Still, a plain-English content checklist can help you avoid last-minute gaps.
In most cases, teams want the following ready in a consistent structure:
To make this work under pressure, you typically need inputs from multiple owners. That often includes the SOC or IT operations team for technical facts, service owners for business impact, communications for messaging control, legal and compliance for notification and content review, and vendor management for third-party coordination.
What many people overlook is repeatability. A practical setup often includes a report template, regular rehearsal such as tabletops, and a single owner responsible for the final submission package quality control. That does not mean one person does all the work. It means one person ensures the content is consistent, complete, and traceable across sources before it goes out.
7. Resilience testing is mapped to your risk profile
Not every institution approaches testing in the same way, but every institution should know what testing is required, how it is scheduled, who reviews outcomes, and how remediation is tracked. Your checklist should confirm that testing is not treated as a one-off technical event disconnected from governance.
8. Management and board reporting are regular and useful
A strong checklist asks whether senior stakeholders get decision-ready information. This typically includes risk trends, major incidents, provider concentrations, remediation status, and important changes in ICT dependency. If reports are too technical to support oversight, you may have activity without governance.
9. Submission readiness is repeatable
DORA reporting is not only a content problem. It is also a formatting, validation, and control problem. For Register of Information submissions, the EU-level format is XBRL, based on the DORA XBRL Data Point Model. Your institution should know how raw operational data becomes technically valid output, who signs off, and how errors are resolved.
If the timeline still feels unclear internally, review the dora implementation deadline article and the published post DORA European Commission Timeline and History (2026) for a timeline view.
Where banks and insurers usually differ
Here is the thing: the regulation is shared, but the operating patterns are not. A dora bank checklist often needs extra focus on payment infrastructure, core banking systems, wider third-party technology stacks, and sometimes more complex incident coordination across functions and jurisdictions.
A dora insurance checklist often puts more pressure on policy administration platforms, claims systems, delegated service models, distribution technology, and outsourcing relationships that may sit across underwriting, servicing, and customer operations.
What banks should usually pressure-test
What insurers should usually pressure-test
In practice, this means your checklist should reflect your operating model, not just the regulation text. The same DORA requirement may create very different evidence challenges in a retail bank versus a multinational insurer.
What proof of compliance looks like in practice
Many institutions have the right documents but still struggle with proof. That happens when evidence is scattered across email threads, spreadsheets, ticketing tools, and local folders. A policy exists, but the decision trail behind it is hard to reconstruct.
Proof of compliance usually means traceability. You should be able to show who entered or approved data, when records changed, what validation checks were applied, and how issues were resolved. That is especially true for the Register of Information and for recurring governance reviews.
With features such as modular workflows, validation support, reporting structures, and audit-oriented record handling described in DORApp documentation, compliance teams may be able to start with imperfect data and improve it through controlled review rather than waiting for a perfect file before doing anything useful.
If you want a pillar-level view of how these pieces fit together, the post DORA Pillars Explained: Complete Breakdown (2026) is a helpful companion read.
Common gaps teams discover too late
The most common issue is not that institutions ignored DORA. It is that they underestimated the operational detail needed to maintain it.
Checklist gap 1: The register exists, but no one trusts the data
This often shows up when business owners, procurement, and legal all describe the same provider differently. Reporting then becomes an exercise in reconciliation rather than governance.
Checklist gap 2: Contracts are tracked, but subcontracting is not
As subcontracting expectations deepen, institutions may need much better visibility into supply chains than they originally planned for. This can be especially difficult where relationships are managed locally.
Checklist gap 3: Incident processes are documented, but thresholds are unclear
If teams need to argue about materiality each time, your process may not be mature enough. Clear criteria, training, and rehearsal matter.
Checklist gap 4: Ownership is named, but not operationalized
A person can be listed as owner without having the workflow access, authority, or reporting support to fulfill that role. A real checklist tests operating capability, not just org charts.
Checklist gap 5: Compliance is treated as a project
DORA is now an ongoing operating requirement. Once institutions move into repeat cycles of updates, validations, testing, and evidence production, weak manual approaches start to show their limits.
How tools can support the checklist process
A checklist alone will not fix fragmented data or unclear ownership, but it can show you where the process breaks. The next question is whether your institution can maintain DORA manually, through a broader GRC environment, or with a more focused platform.
DORApp is one platform worth evaluating if you need a DORA-focused operating model rather than a generic documentation repository. Based on available Dorapp product and knowledge data, it includes dedicated DORApp modules, functions, pricing information, a help center, demo booking, and a 14-day free trial through Free Trial – 14 Days. Its documentation also describes modular support across areas such as Register of Information, third-party risk management, incident management, and governance workflows, with XBRL-oriented reporting support.
From a practical standpoint, the benefit of a purpose-built setup is not that it replaces judgment. It is that it may reduce manual translation work between source data, review steps, and submission outputs. If you want to see how DORApp approaches this, you can also Book a Demo and review whether its modular model fits your institution.
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 the purpose of a DORA regulation checklist?
A dora regulation checklist helps you translate a broad regulatory framework into a practical review process. Instead of asking whether your institution has “done DORA,” it helps you test whether governance, ICT risk management, third-party oversight, incident processes, testing, and reporting are actually working. For banks and insurers, that usually means checking ownership, data quality, evidence trails, and submission readiness. The checklist is most useful when treated as an operational control tool rather than a one-time implementation worksheet.
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. In practice, these pillars matter most when you can show evidence that each one is operating, such as owned policies and procedures, logs and records, testing plans and results, third-party oversight artifacts, and a traceable decision and remediation trail.
What are DORA regulatory requirements?
DORA regulatory requirements cover how EU financial entities manage ICT risk, handle and report ICT-related incidents, test operational resilience, control ICT third-party dependencies, and participate in information sharing under defined governance. The exact expectations can vary by entity type, size, and national supervisory approach, so most institutions treat a checklist as a way to confirm ownership, evidence quality, and repeatable operating processes rather than relying only on policy statements.
What is a regulatory compliance checklist?
A regulatory compliance checklist is a structured set of review questions used to verify that a regulatory requirement is implemented and can be evidenced. The most useful checklists go beyond “does it exist?” and test whether controls are current, owned, traceable, and consistently applied across teams. For DORA, that often includes checking data quality, version control, approvals, and the ability to produce reporting outputs without last-minute manual reconstruction.
What must DORA reports include?
What a DORA report must include can depend on the specific report type and your supervisory context, so institutions typically confirm content requirements with their compliance and legal teams. For incident-related reports, teams often prepare a consistent package covering the incident classification and rationale, a clear timeline, impacted services and systems, business and customer impact, scope across entities or geographies, known facts and root cause hypotheses, mitigation actions, recovery status, and communication and coordination steps, including third-party involvement where relevant.
Is a dora bank checklist different from a dora insurance checklist?
Yes, usually in emphasis rather than in core legal structure. Banks often need deeper review of payment systems, transaction dependencies, broader ICT ecosystems, and faster incident escalation chains. Insurers may need more focus on claims systems, policy administration platforms, servicing arrangements, and outsourcing chains. The regulation applies across both sectors, but the evidence you need and the operational pain points you encounter may differ. Your checklist should reflect your business model, provider footprint, and group structure.
What should I review first if my institution is short on time?
Start with the areas most likely to fail under scrutiny: governance ownership, the Register of Information, ICT third-party classifications, and incident escalation logic. Those are the areas where incomplete data or unclear accountability tends to show up fastest. After that, review testing, reporting, and board oversight. If you only have time for one exercise, ask each workstream owner to provide current evidence, not just policy references. That often reveals the real maturity level in a few days.
Does DORA require the Register of Information in XBRL?
For EU-level submissions, the Register of Information reporting format is XBRL, based on the DORA XBRL Data Point Model. In practice, that means your institution needs a controlled way to transform maintained operational data into technically valid reporting output. Many teams understand the business content but underestimate the formatting and validation side. That is why submission readiness should be part of your checklist. It is not enough to have the data if you cannot produce the required file structure reliably.
How often should a DORA checklist be reviewed?
In many cases, quarterly review is a sensible minimum for structured management oversight, with more frequent updates for fast-changing areas like provider onboarding, incident handling, and Register of Information maintenance. The right rhythm depends on your institution’s size, complexity, and change volume. What matters most is that the checklist is tied to actual governance cycles. If it only appears before reporting deadlines or audits, it is probably not doing enough to support ongoing resilience.
Can a spreadsheet-based process still work for DORA in 2026?
It can work in limited cases, especially for smaller institutions with lower complexity, disciplined ownership, and a narrow provider ecosystem. But as data volume, subcontracting depth, and evidence expectations increase, spreadsheets often become hard to govern. Version control, auditability, validation, and cross-team collaboration tend to get messy. The issue is not that spreadsheets are always wrong. It is that they may become fragile once your institution needs repeatable proof of compliance across multiple cycles and stakeholders.
What role does LEI data play in a DORA checklist?
LEI data may help improve the consistency and reliability of legal entity records across group structures, counterparties, and provider references. In DORA workflows, that matters because reporting quality often depends on accurate master data, not just policy interpretation. If entities are named inconsistently across legal, procurement, and compliance records, downstream validation issues are more likely. A good checklist therefore includes a review of legal entity quality, especially for institutions with cross-border operations or multiple reporting entities.
How does DORApp fit into the checklist process?
DORApp is not the regulation itself, and it should not be treated as a substitute for legal or compliance judgment. It is a platform designed to support DORA-related processes in a more structured way. Based on available Dorapp documentation, its approach includes modular workflows, Register of Information handling, reporting support, audit-oriented controls, and DORA-focused operating logic. For institutions that want a more controlled alternative to fragmented manual processes, it may be a useful option to evaluate.
What is the biggest mistake institutions make with DORA checklists?
The biggest mistake is using the checklist as a static compliance document instead of a live governance tool. Teams often mark items as complete because a policy exists or a file was submitted once. But DORA now demands ongoing operational resilience, which means ownership, updates, controls, evidence, and reporting all need to keep working over time. A useful checklist should expose weaknesses early, support escalation, and drive better cross-functional coordination rather than create false comfort.
Key Takeaways
Conclusion
If your institution is asking whether it is “done” with DORA, that is probably the wrong question. A better question is whether you can show, at any reasonable moment, that your controls, records, ownership, and reporting process still hold together under review. That is what a strong dora regulation checklist is really for.
For banks and insurers, the challenge is rarely understanding the headline requirements. It is making those requirements work across data, teams, providers, and governance cycles without losing control of the details. Start with the checklist areas that create the most operational strain, especially the Register of Information, ICT third-party oversight, and reporting traceability.
If you want a more structured way to approach that work, DORApp is worth exploring at Why DORApp or through the Dorapp blog and platform resources. You can use this checklist as a conversation starter with your compliance, risk, and IT teams, then compare whether your current setup is enough for the proof-focused phase of DORA.
About the Author
Matevž Rostaher is Co-Founder and Product Owner of DORApp. He brings deep experience in building secure and compliant ICT solutions for the financial sector and is positioned by DORApp as an expert trusted by financial institutions on complex regulatory and operational challenges. DORApp’s own webinar materials list him as CEO and Co-Founder of Skupina Novum d.o.o. and CEO and Co-Founder of FJA OdaTeam d.o.o. His articles should carry the voice of someone who understands not just compliance requirements, but the systems and delivery realities behind them.