DORA Gap Analysis: Assessing Compliance (2026 Guide)
You have policies, vendor inventories, incident processes, and risk registers scattered across teams. Compliance says one thing, IT says another, procurement has its own spreadsheet, and leadership wants a clear answer to a simple question: are we actually ready for DORA? That moment is where a proper dora gap analysis becomes useful. Not as a paperwork exercise, but as a practical way to compare what your institution does today against what DORA expects in day-to-day operations.
The reality is that many financial entities entered 2025 focused on initial compliance, then quickly realized 2026 is about evidence, consistency, and proof. Regulators are no longer only interested in whether you created documents. They increasingly want to see whether your ICT risk management, third-party oversight, incident workflows, and Register of Information operate in a structured, repeatable way. DORApp was built to simplify DORA compliance for EU financial institutions through a modular approach, helping teams turn complex obligations into manageable workflows and technically acceptable reporting outputs. If you are trying to assess your current state honestly, this article will help you structure that work.
What a DORA gap analysis really does
A dora gap analysis is a structured review of your current controls, records, governance, and operational practices against DORA requirements as currently defined. It helps you identify where you are compliant, where you are partially compliant, and where material gaps still exist.
If you need a broader foundation first, it helps to revisit what is dora and the wider context of the digital operational resilience act dora. A gap assessment sits between understanding the regulation and executing a practical dora implementation plan.
It is not just a compliance checklist
Think of it this way, a checklist tells you whether a document exists. A meaningful dora gap assessment asks whether the document matches actual practice, whether ownership is clear, whether evidence is retained, and whether the process would stand up under supervisory review. That distinction matters a lot more in 2026 than it did during early preparation.
It should show both design and execution gaps
Some institutions have a strong policy framework but weak execution. Others have workable operational habits but poor documentation and weak traceability. Your dora compliance gap review should capture both. From a regulatory standpoint, having good intentions or informal team knowledge may not be enough if you cannot demonstrate controlled execution, approvals, and reliable records.
DORA “certification” is not a real thing, but audit-ready work is
A common point of confusion is the idea of “DORA certification.” In practice, there is typically no formal DORA certification program you can complete once and then treat as done. Readiness is usually demonstrated through how you run governance, controls, and reporting in day-to-day operations, and through how well you can evidence those practices under supervisory or audit scrutiny. This is not legal or regulatory advice, but as a practical matter, teams often succeed or fail based on evidence quality and operational consistency rather than the existence of a single “certificate.”
Now, when it comes to being “audit-ready” for DORA work, the evidence usually has a few recurring traits. Approvals are traceable, for example committee minutes or sign-off records. Workflows are repeatable, meaning different teams can follow the same steps and reach consistent outcomes. Controls are tested in a way that can be explained later. Records are retained in a controlled way, including decision rationales and changes over time. Reporting artifacts are consistent, so the same underlying data produces the same output after validation.
Some institutions also rely on other external frameworks or certifications as supporting evidence in principle. That can be helpful context for maturity, but it typically does not replace DORA-specific requirements, especially around third-party oversight, the Register of Information, and structured reporting outputs. A dora gap analysis is where you separate “we have good general practices” from “we can demonstrate DORA-aligned outcomes with DORA-aligned artifacts.”
The main areas you need to assess
DORA is commonly understood through five pillars: ICT risk management, incident reporting, resilience testing, third-party risk management and oversight, and information sharing. For a practical compliance review, you should assess each area through the lens of governance, data quality, process maturity, evidence, and reporting readiness.
If you want a more detailed breakdown of the structure behind these obligations, see DORA Pillars Explained: Complete Breakdown (2026) and the DORA Fundamentals category.
ICT risk management and governance
Start with your internal control environment. Do you have an ICT risk framework that is updated, assigned to clear owners, and used in practice? Are risks assessed consistently across business units? Are material dependencies, concentration risks, and control weaknesses visible to decision-makers? Under DORA, this means your governance model should typically be more than an annual review exercise.
Incident management and reporting readiness
Many firms have incident processes, but they are often built for security operations rather than regulatory classification and escalation. Your assessment should ask whether you can identify ICT-related incidents, classify them consistently, escalate internally, and prepare reporting in line with supervisory expectations. A weak workflow here often creates hidden compliance risk even if the technical response process is mature.
Third-party oversight and the Register of Information
This is where many dora compliance gap findings appear. Your vendor data may exist, but not in the structure DORA expects. Contracts may be stored in one place, criticality assessments in another, and subcontracting information may be incomplete. The mandatory Register of Information often exposes weaknesses in ownership, data lineage, and record consistency. The dedicated Register of Information category is useful if this is your biggest pain point.
Reporting format and technical submission readiness
Some teams underestimate the reporting side. DORA submissions at EU level use xbrl, which means your source data needs to be structured and validated well before submission. What many people overlook is that technical readiness depends on process maturity upstream. If your underlying records are inconsistent, your export and validation work becomes much harder.
How to run the assessment without making it chaotic
A useful dora gap analysis is cross-functional, time-bounded, and evidence-based. It should not be run by compliance in isolation. In practice, this means bringing together compliance, risk, IT, security, procurement, legal, and business owners where relevant.
Start with the operating model, not the documents
Before reviewing policies, map how work actually happens. Who owns vendor onboarding? Who classifies incidents? Who signs off critical ICT dependencies? Where are approvals stored? Once you know the real operating model, documents become easier to evaluate honestly. This approach usually surfaces practical gaps faster than a document-only review.
Use a simple scoring structure
Consider rating each requirement area using four statuses:
This creates a clearer picture than a binary yes or no. It also gives leadership a better sense of what can be remediated quickly and what may require structural change.
Ask for proof, not verbal reassurance
Here's the thing, almost every institution sounds more mature in interviews than it looks in evidence. Ask for actual artifacts: policies, workflow logs, assessment outputs, contract clauses, issue records, approval trails, and sample reports. DORApp supports this kind of structured work through modular workflows, audit-ready records, and a proprietary data model that auto-converts into DORA-aligned reporting outputs, which can reduce the manual coordination burden during assessment and remediation.
Anchor the review to deadlines and regulatory reality
Your assessment should also consider timing. The first Register of Information submission deadline was 30 April 2025, but 2026 is where proof of compliance becomes more important than first-time submission. If your team still plans around a one-off readiness sprint, reviewing the dora implementation deadline context may help reset expectations.
The gap assessment package: templates and deliverables
Most dora gap analysis efforts become “chaotic” for one simple reason: teams collect a lot of information, but they do not define what they are producing at the end. From a practical standpoint, it helps to treat your assessment as a package of deliverables that management can understand and teams can maintain over time.
In most institutions, a useful gap assessment package includes a few core artifacts. A requirements matrix that maps DORA obligations to your controls and processes. An evidence log that shows where proof is stored and who provided it. An issues register that captures gaps in a consistent way. A remediation plan that turns findings into owned actions with dates. An executive-ready dashboard view that summarizes status, trend, and the few items leadership needs to decide on. You do not need to over-engineer this, but you do need consistency.
A practical template structure you can copy
If you are using Excel, a ticketing system, or a GRC tool, the difference often comes down to having the right fields. Consider using columns like these as a starting point, then tailoring to your organization:
Think of it this way, the requirements matrix tells you what should exist, and the evidence log tells you what actually exists. The issues register is where you keep the uncomfortable truth in a structured form so it can be fixed, not argued about.
Version control and change tracking that holds up over time
What many people overlook is that your gap analysis becomes a living record. In 2026, you may need to explain not only what your status is today, but how it evolved, why decisions were made, and what was done in response. That is where basic changelog discipline matters, even if you are not using a dedicated platform.
At minimum, keep a simple change log: version number, date, author, summary of changes, and approvals if applicable. Track when evidence was added or replaced, when statuses were re-rated, and when requirements interpretation changed. If you revise an assessment because a control improved, capture what changed in the control, not just the new score. This helps keep the work defensible and reduces the chance that the assessment turns into a series of disconnected spreadsheets with no reliable history.
Where most institutions find their biggest gaps
While every institution is different, a few themes come up repeatedly in real implementation work. These are not always failures of effort. Often they are signs that DORA requires a level of structure that older processes were never designed to support.
Fragmented ownership
Compliance may own interpretation, but not the source data. IT may understand systems, but not contractual obligations. Procurement may know suppliers, but not critical business dependencies. A dora gap assessment often reveals that no single team owns the full lifecycle of third-party ICT oversight.
Weak subcontracting visibility
This issue has become more important with Delegated Regulation (EU) 2025/532, which introduced deeper subcontracting risk considerations. Many institutions know their direct providers reasonably well, but have far less visibility into downstream ICT dependencies. That creates a gap in both oversight and defensible reporting.
Good spreadsheets, poor governance
Spreadsheets may work for collecting data, but they often break under version control, approval tracking, recurring updates, and cross-entity consistency. If your dora compliance gap mostly relates to stale data, unclear sign-off, or recurring correction cycles, the real issue may be governance rather than data entry alone.
Policies that do not match workflows
Consider this, a policy may describe annual review, multi-step approval, and risk-based escalation. The real process may be email-driven, inconsistent, and hard to reconstruct six months later. That mismatch is exactly the kind of issue supervisors may focus on when they test whether compliance is operational rather than theoretical.
Technical reporting left too late
Many teams postpone export and validation questions until the end. That is risky. The quality of your reporting output is shaped by how well your internal records are modeled from the start. If you want a broader historical view of how supervisory expectations developed, DORA European Commission Timeline and History (2026) gives useful context.
How tools can help with the hard parts
A tool should not replace your judgment, but it can make recurring DORA work much more manageable. This matters most where teams struggle with data quality, repeatability, approvals, and technically acceptable outputs.
Where specialized support makes the biggest difference
Platforms like DORApp streamline the creation and maintenance of the Register of Information through a practical workflow: importing existing data, managing it in a structured interface, enriching records with public-source data such as LEI information, validating records against reporting logic, and generating DORA-compliant outputs. That does not remove the need for institutional decisions, but it can reduce friction in the operating model.
Why modularity matters
From a practical standpoint, not every institution needs to solve every pillar at once with the same level of depth. DORApp is modular, with dedicated areas for the Register of Information and third-party risk management already available, while other modules are on the roadmap. That can be useful if your largest gap is concentrated in one process area rather than the full framework.
What to evaluate before you choose any approach
If you are comparing internal builds, consultancy-led methods, or software support, assess them against a few practical criteria:
If you are evaluating how DORApp approaches this, the most relevant entry points are its modules, functions, and the option to book a demo for a more institution-specific discussion.
Register of Information gap analysis: a focused checklist of common failure points
If your assessment includes the Register of Information, it helps to zoom in to a field-level view. The RoI is not only about having “a vendor list.” It is about being able to demonstrate traceability between entities, providers, contracts, services, and critical or important functions, using consistent identifiers and rationales.
In practice, a few data fields and linkages tend to break most often:
To test data quality during the gap analysis, sampling is often more effective than debating completeness in meetings. Pick a small set of providers, typically a mix of high-impact and “ordinary” ones. Trace each record to its contracts. Trace contracts to the services being consumed. Trace services to the functions they support. Confirm the criticality decision, approvals, and update cadence. This kind of traceability test usually reveals whether the RoI is operational or just assembled.
Once gaps are identified, categorizing them helps remediation become more than cleanup. Many RoI findings fall into one of three buckets: data missing, data exists but not structured, or governance missing. “Data missing” usually means you need to obtain it from internal stakeholders or providers. “Data exists but not structured” often means the information is in PDFs, emails, or narrative notes and needs modeling. “Governance missing” means the bigger issue is ownership, sign-off, and update discipline, so the same gaps will return even after a cleanup cycle.
Turning findings into an action plan
A dora gap analysis only matters if it leads to action. Once you identify your gaps, group them by impact, urgency, and effort. Some issues can be fixed with clearer ownership or stronger evidence collection. Others may require process redesign, contract remediation, or better systems support.
Prioritize what regulators are most likely to test
Under DORA, this means focusing first on areas where incomplete controls create recurring exposure: ICT risk governance, incident classification and escalation, third-party oversight, and Register of Information quality. The European Supervisory Authorities designated Critical Third-Party Providers in November 2025, which makes third-party governance even more important in practice for many institutions.
Move from one-off project thinking to ongoing operations
The shift in 2026 is subtle but important. Supervisors are increasingly interested in how you maintain resilience over time, not just whether you passed an initial milestone. With features such as automated workflows, validation logic, audit trail support, and structured reporting outputs, DORApp can help teams start operating with imperfect but usable data, then improve quality through controlled iteration rather than waiting for a perfect cleanup before doing any real work.
Document assumptions and open issues honestly
You do not need to present your organization as flawless. In many cases, a transparent remediation plan with clear owners and dates is more credible than an overconfident status report. If your teams are still building maturity, grounding your next steps in a clear dora regulation explained view can help keep remediation aligned with actual obligations rather than internal guesswork.
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.
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 a dora gap analysis in simple terms?
A dora gap analysis is a structured review of how your institution currently manages ICT risk, third parties, incidents, governance, and reporting compared with what DORA expects. In simple terms, it shows what is already in place, what is missing, and what only works partially. The goal is not just to produce a red-amber-green chart. It is to identify practical weaknesses in ownership, documentation, controls, and evidence so your team can build a realistic remediation plan and improve ongoing operational resilience.
Who should be involved in a dora gap assessment?
A dora gap assessment should usually involve more than compliance. In most institutions, the right group includes compliance, risk management, IT, information security, procurement, legal, and business owners responsible for critical or important functions. Senior management input may also be needed where governance and accountability are being reviewed. The reason is simple: DORA requirements are spread across multiple processes and systems. If only one team performs the review, you may miss key dependencies, undocumented practices, or weaknesses in how responsibilities are assigned and evidenced.
How is a dora compliance gap different from a normal internal audit review?
A dora compliance gap review is narrower in one sense and broader in another. It focuses specifically on DORA-aligned obligations, but it often cuts across more teams and operational processes than a standard control test. Internal audit may later validate whether controls are designed and operating effectively. A gap analysis usually comes earlier and is more diagnostic. It helps you understand readiness, identify missing components, and prioritize remediation. In many institutions, it becomes the bridge between regulatory interpretation and a working implementation roadmap.
How often should you perform a dora gap analysis?
There is no single universal frequency that fits every institution. A full dora gap analysis is often useful before major implementation work, after material regulatory updates, following structural business changes, or ahead of expected supervisory review. In practice, many firms benefit from a more detailed baseline assessment and then lighter periodic reassessments. The exact cadence may depend on your size, complexity, outsourcing profile, and maturity. What matters most is that the assessment is not treated as a one-time project if your processes, providers, and reporting obligations continue to change.
What evidence should you collect during the assessment?
You should collect evidence that shows both design and execution. That may include policies, standards, governance minutes, risk assessments, incident records, contract templates, supplier inventories, approval logs, remediation trackers, and reporting outputs. Sample-based evidence is often especially helpful because it reveals whether a process really works in practice. For example, instead of only reviewing the incident policy, look at recent incidents and trace how they were classified, escalated, approved, and documented. That gives you a much more reliable picture of your actual DORA readiness.
Is the Register of Information usually the hardest part?
For many institutions, yes, or at least it is the area that exposes the most hidden issues. The Register of Information brings together provider, contract, service, function, entity, and dependency data that often sits in different systems. As a result, teams discover duplicate records, missing legal entity identifiers, unclear service mappings, or inconsistent criticality decisions. The register itself is not the only challenge. It often reveals deeper governance and data quality problems that affect several DORA areas at once. That is why it is frequently a central part of any meaningful gap assessment.
Do you need a software platform to complete a dora gap analysis?
No, not necessarily. A smaller or less complex institution may begin with workshops, document reviews, and controlled spreadsheets. Still, software becomes more valuable as complexity increases, especially where multiple teams need shared data, repeatable workflows, audit trails, and structured outputs. The tipping point usually comes when manual methods become hard to maintain over time. A platform does not replace legal interpretation or management accountability, but it may help you run the process in a more consistent and evidence-friendly way once remediation moves into ongoing operations.
How detailed should the scoring be?
Keep it detailed enough to guide action, but not so granular that the review becomes unmanageable. A four-level maturity or implementation scale is often enough for an initial assessment, especially if each rating is supported by short comments, evidence references, and named owners. You can always add more depth in high-risk areas later. The most useful scoring models distinguish between having something documented and having it operationalized with evidence. That separation tends to produce better remediation planning than a simple compliant or non-compliant label.
What are the most common mistakes in a dora gap assessment?
Common mistakes include relying too heavily on policy reviews, interviewing too few stakeholders, treating spreadsheet completeness as proof of compliance, and postponing technical reporting considerations until the end. Another frequent issue is rating controls as implemented without asking whether evidence exists for actual execution. Some teams also underestimate subcontracting and fourth-party visibility, which has become more relevant under newer regulatory developments. A strong assessment stays grounded in real workflows, real records, and realistic remediation sequencing rather than optimistic assumptions.
What is a practical next step after identifying the gaps?
Start by grouping findings into immediate fixes, medium-term process changes, and structural transformation items. Assign owners, dates, and evidence expectations for each one. Then decide where manual controls are acceptable for now and where you need stronger workflow support, better data structure, or governance redesign. If you are reviewing tool support, DORApp is one platform worth exploring because it combines modular DORA workflows, structured Register of Information management, validation support, and technically oriented reporting outputs. A demo or trial may help you assess fit before committing to a larger rollout.
What is a gap analysis for DORA?
A gap analysis for DORA is the structured process of comparing your current ICT risk management, third-party oversight, incident handling, testing, governance, and reporting practices to what DORA expects. The output is typically a set of documented findings that show which obligations are met, which are partially met, and which are missing, supported by evidence references and a prioritized remediation plan. It is usually most effective when it is evidence-based and traceable, not only interview-based.
What are the 5 principles of DORA?
DORA is often discussed through practical “principles” that mirror how operational resilience is supervised. In most cases, this comes down to having clear ICT risk governance, being able to detect and manage incidents with proper escalation and reporting, testing resilience in a structured way, controlling third-party ICT risk with defensible oversight, and being able to share and report information in consistent formats. The exact wording may vary depending on how your institution summarizes the regulation internally, so it is worth aligning your internal principles to the specific DORA requirements your compliance team uses.
What are the 5 pillars of DORA compliance?
The five pillars are commonly described as: ICT risk management, ICT-related incident management and reporting, digital operational resilience testing, ICT third-party risk management, and information sharing arrangements. A dora gap analysis typically checks each pillar for governance, process maturity, evidence retention, and whether the institution can produce technically acceptable reporting outputs when required.
Can ChatGPT do a gap analysis?
Tools like ChatGPT can help you draft checklists, summarize requirements, or propose a template for capturing evidence and findings. Still, a true dora gap analysis requires institution-specific evidence, validation of how processes operate in practice, and careful ownership decisions that an AI tool cannot verify on its own. If you use AI support, it is usually best treated as an assistant for structure and documentation, while your compliance, risk, IT, and legal teams validate requirements interpretation and confirm evidence and conclusions.
Key Takeaways
Conclusion
A strong dora gap analysis gives you something more useful than a status report. It gives you a decision-making tool. You can see where your institution is genuinely operating well, where controls exist only on paper, and where process, data, or governance changes are needed to make DORA work in everyday practice. That matters even more now that supervisors are increasingly focused on proof, traceability, and operational consistency rather than one-time preparation efforts.
If your team is trying to move from fragmented spreadsheets and partial evidence toward a more controlled DORA operating model, exploring structured approaches can save a great deal of time. DORApp supports institutions with modular workflows for core DORA areas, including Register of Information management and related reporting processes, while keeping the work practical and auditable. If you want to see how that looks in practice, you can start a 14-day free trial, book a demo, or keep learning through the Dorapp blog and related dora implementation resources.
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.