Learn
A gap assessment is only useful if it tells you two things: how far you are from what the regulation actually says, and what to fix first. This guide gives you a model for both, with each domain anchored to the article it comes from.
The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025. It does not prescribe a gap assessment method, a maturity scale or a scoring scheme. Those are yours to choose. What it does prescribe, precisely, is the substance you are scoring against, and that substance is spread across seven areas of the regulation and three technical standards.
So this article separates two things that are usually mixed together. The model is ours: a four-level scale across seven domains, then weighted. We flag it as editorial wherever it appears. The requirements it measures are not ours, and every article number, deadline and count below is quoted from the regulation or a technical standard and cited at the end.
| Governing law | Regulation (EU) 2022/2554 (DORA). Applies from 17 January 2025. It has 64 articles. |
| Who is in scope | The financial entities listed in Article 2(1). Some obligations, including the testing programme in Article 24, apply to financial entities other than microenterprises. |
| Detailed rules | Commission Delegated Regulation (EU) 2024/1774 (ICT risk management), Commission Delegated Regulation (EU) 2025/301 (incident reporting content and time limits), and Commission Implementing Regulation (EU) 2024/2956 (register of information). |
| Does DORA require a gap assessment? | Not in those words. Article 6(5) requires the ICT risk management framework to be documented and reviewed at least once a year, and additionally upon major incidents and following supervisory instructions or conclusions from testing or audit. A gap assessment is how most entities do that review. |
| Is the scoring model below prescribed? | No. The 1 to 4 scale, the seven-domain split and the weights are ours. Use them or replace them. |
Where gap assessments usually go wrong
They confuse existence with adequacy. Asking "do you have an ICT risk management framework?" and recording "yes" tells you nothing about whether it meets DORA. A framework written for an earlier outsourcing regime may say nothing about ICT concentration risk under Article 29, exit strategies under Article 28(8), or the digital operational resilience strategy required by Article 6(8). Existence-based scoring produces false comfort.
They score the policy layer and skip the operational output. DORA has outputs that either exist or do not: a register of information that has to survive validation in the format set by the ITS, and an incident report that has to leave the building inside a fixed number of hours. An assessment that only reads policies will not tell you whether you can produce either one.
They produce a list, not an order. Remediation capacity is finite, and a gap list with no hierarchy of urgency is hard to act on. That is why the model below weights the domains before it plans anything.
Two different questions. Mapping your controls to a control library and measuring implementation gives you an audit-readiness view. That is worth having, but it does not tell you whether you can file a valid register of information or hit the reporting clock. Those two dimensions fail independently, so score them separately. A high control-implementation rate says nothing about whether a submission passes validation.
The maturity scale
Four levels, which is enough to separate meaningfully different states without inventing precision the evidence cannot support. To be explicit: this scale is ours, not the regulator's. DORA defines no maturity levels. What makes a score defensible is not the scale, it is that level 3 is pinned to a named article and you can produce the evidence for it.
| Score | Level | Definition |
| 1 | Initial | No structured approach. The requirement is unknown, not started, or handled ad hoc with no documentation, owner or repeatability. Remediation means building from scratch. |
| 2 | Developing | Something exists but does not meet the requirement in full. Coverage is partial, documentation is thin, or the approach has never been exercised. |
| 3 | Defined | The requirement is met as written, documented and maintained, and you can produce the evidence on request. This is the baseline, not the finish line. |
| 4 | Embedded | Met, exercised or audited, with evidence of effectiveness and a working improvement loop. Article 6(6) already subjects the framework to internal audit; a 4 means that audit found it working. |
The seven domains, scored
Each domain names the articles it is measured against, then defines what each score means. Every figure quoted below, whether a deadline, a count or a frequency, comes from the regulation or a technical standard.
D1. ICT risk management framework
Articles 5 to 15
Article 6(1) requires a sound, comprehensive and well-documented ICT risk management framework. Article 6(5) requires it to be documented and reviewed at least once a year, and additionally upon major ICT-related incidents and following supervisory instructions or conclusions derived from testing or audit. Article 6(6) subjects it to internal audit. Article 6(8) requires it to include a digital operational resilience strategy, and Article 5(2)(d) puts approval of that strategy, including the ICT risk tolerance level, on the management body.
| Score | What this looks like |
| 1 | No framework has been assessed against DORA. A framework built for another regime has never been compared to Articles 5 to 15. |
| 2 | A framework exists with material gaps against the text. Typically: no digital operational resilience strategy under Article 6(8), no documented ICT risk tolerance level, or no evidence of the annual review Article 6(5) requires. |
| 3 | Documented framework covering Articles 5 to 15, including the Article 6(8) strategy and a defined risk tolerance level, with the annual review evidenced and management body approval minuted. |
| 4 | The framework has been through internal audit under Article 6(6), the Article 6(7) follow-up process for remediating critical ICT audit findings is running, and improvements trace back to lessons learned. |
Most often underdeveloped: the Article 6(8) digital operational resilience strategy as a distinct approved artefact rather than a section heading; the ICT risk tolerance level under Article 6(8)(b); and the Article 6(7) formal follow-up process for critical ICT audit findings.
D2. ICT incident management and reporting
Articles 17 to 23, plus RTS 2025/301
Article 17 requires an ICT-related incident management process, and Article 18 sets the classification criteria. Article 19(4) requires an initial notification, an intermediate report and a final report, but it sets no clock: it defers the time limits to a technical standard. They live in Commission Delegated Regulation (EU) 2025/301, Article 5(1), and they are the most commonly misquoted numbers in DORA.
| Score | What this looks like |
| 1 | No DORA-specific classification. The existing ITSM severity model has never been compared to the Article 18 criteria. |
| 2 | Classification criteria mapped but not embedded. The deadlines are known, but no tested workflow exists to produce a four-hour initial notification outside office hours. |
| 3 | A documented, DORA-aligned classification procedure inside the incident process; notification templates prepared; the four-hour and 72-hour workflow defined; and named people who can act on it at three in the morning. |
| 4 | The process has been exercised, through tabletop or live incident. Post-incident reviews feed back into the procedure, and you measure classification accuracy and how close you ran to each deadline. |
Most often underdeveloped: the out-of-hours escalation path that makes a four-hour clock survivable; and the voluntary notification of significant cyber threats under Article 19(2), which is often missed entirely.
Get the clock right. Article 5(1) of RTS 2025/301 sets three deadlines, and the middle one is routinely reported wrongly:
- Initial notification: "within four hours from the classification of the ICT-related incident as a major ICT-related incident and no later than 24 hours from the moment the financial entity has become aware of the ICT-related incident".
- Intermediate report: "at the latest within 72 hours from the submission of the initial notification".
- Final report: "no later than one month after either the submission of the intermediate report, or, where applicable, after the latest updated intermediate report".
72 hours is the intermediate report, not the final one. If your runbook says otherwise, that is a finding in its own right.
D3. Digital operational resilience testing
Articles 24 to 27
Article 24(1) requires a testing programme, for financial entities other than microenterprises, as an integral part of the ICT risk management framework. Article 24(6) requires that, at least yearly, appropriate tests are conducted on all ICT systems and applications supporting critical or important functions. Article 24(4) requires tests to be undertaken by independent parties, internal or external. Article 25(1) lists the kinds of test the programme can draw on. Threat-led penetration testing under Article 26(1) runs at least every three years, but only for entities their competent authority has identified under Article 26(8).
| Score | What this looks like |
| 1 | No DORA-scoped programme. Penetration testing happens, but has never been mapped to critical or important functions. |
| 2 | Testing happens on a schedule, but its scope has never been formally tied to the functions it is meant to cover, and findings are not tracked to closure. |
| 3 | A documented programme scoped to the systems supporting critical or important functions, meeting the at-least-yearly bar in Article 24(6), using independent testers per Article 24(4), with findings tracked and a written position on whether Article 26 TLPT applies. |
| 4 | TLPT completed, or a roadmap in place if identified under Article 26(8). The Article 24(5) procedures to prioritise, classify and remedy issues are demonstrably working, and results feed the risk framework. |
Most often underdeveloped: a written, dated determination of whether the entity has been identified for TLPT under Article 26(8), which many entities have simply never made; and scope traceability from the test plan back to the critical or important functions it is supposed to cover.
D4. ICT third-party risk management
Articles 28 to 30
Article 28 requires a strategy and a policy on the use of ICT services. Article 28(8) requires exit strategies for ICT services supporting critical or important functions. Article 29 requires a preliminary assessment of ICT concentration risk, including whether a provider is not easily substitutable. Article 30(2) lists the elements every ICT contractual arrangement must contain, and Article 30(3) adds further elements where the service supports a critical or important function.
| Score | What this looks like |
| 1 | No DORA-specific ICT third-party policy. Vendor management has never been compared to Articles 28 to 30 and contracts have not been reviewed against Article 30. |
| 2 | Policy drafted, contract review underway but incomplete, and no documented exit strategies for critical or important arrangements. |
| 3 | Approved policy; the Article 30(2) elements confirmed present across arrangements and the additional Article 30(3) elements where the service supports a critical or important function; concentration risk assessed under Article 29; exit strategies documented under Article 28(8). |
| 4 | Provider monitoring is live, exit strategies have been exercised rather than only written, and a standard contract template carries the Article 30 elements by default. |
Most often underdeveloped: the Article 30 review of legacy contracts signed before DORA applied; and exit strategies that have actually been tested. Also watch the count: Article 30(2) lists nine elements, points (a) to (i), and Article 30(3) then adds more for critical or important functions. Any source promising you "12 mandatory Article 30(2) provisions" is miscounting.
D5. Register of information
Article 28(3), plus ITS 2024/2956
Article 28(3) requires the register to be maintained and updated at entity, sub-consolidated and consolidated level, covering all contractual arrangements on the use of ICT services. Its structure comes from Commission Implementing Regulation (EU) 2024/2956: 15 templates, coded B_01.01 through B_99.01. Score two things here, because they fail independently: whether the data is complete, and whether you can actually produce a submission that validates.
| Score | What this looks like |
| 1 | No register. Provider data sits in spreadsheets or a vendor system with no mapping to the ITS templates. |
| 2 | Partially populated. Usually the supply chain in B_05.02 and the contractual detail in B_02.02 are the thin ones, and no export has been run end to end. |
| 3 | All 15 templates populated, referential integrity between them holding, and a package produced and validated before submission. |
| 4 | Maintained year round rather than rebuilt annually, with updates triggered by contract events, LEI validity monitored, and submissions that pass validation without a resubmission loop. |
Most often underdeveloped: B_05.02, the ICT service supply chain, which is where sub-outsourcing lives and which almost always starts incomplete because it depends on data your providers have to hand over. One trap: guidance that uses a "B00 to B14" numbering is not describing the ITS. The real codes run B_01.01 to B_99.01.
D6. Information sharing
Article 45
Article 45(1) says financial entities may exchange cyber threat information and intelligence within trusted communities. It is permissive, not mandatory. Score it anyway, because a documented decision costs almost nothing and an undocumented absence reads like an oversight.
| Score | What this looks like |
| 1 | No awareness of Article 45 and no assessment of the arrangements available. |
| 2 | Article 45 assessed, relevant arrangements identified, and a participation decision recorded but not yet acted on. |
| 3 | Active participation in at least one arrangement, with a process for consuming and acting on what arrives. |
| 4 | Contributing as well as consuming, with intelligence feeding incident response and the scope of the testing programme. |
Most often underdeveloped: nothing structural. This is the one domain where a reasoned decision not to participate is a legitimate answer, provided it is written down.
D7. Governance and management body accountability
Article 5
Article 5(2) requires the management body to define, approve, oversee and be responsible for the implementation of all arrangements related to the ICT risk management framework, then lists its specific duties at points (a) to (i). Article 5(4) requires members to actively keep up to date with sufficient knowledge and skills to understand and assess ICT risk, including by following specific training on a regular basis.
| Score | What this looks like |
| 1 | DORA responsibilities are not assigned at management body level. ICT risk is run operationally with no board accountability. |
| 2 | The board is aware and receives ICT risk reporting, but its approvals are not documented and no training has happened. |
| 3 | The Article 5(2) duties are discharged and evidenced: the resilience strategy approved under (d), the ICT business continuity policy and response and recovery plans under (e), the ICT internal audit plan under (f), the budget under (g), the ICT third-party policy under (h), and the reporting channels under (i). Training under Article 5(4) has taken place. |
| 4 | Minutes show the board challenging ICT risk reporting rather than noting it, a skills assessment has been done and acted on, and accountability sits with named individuals. |
Most often underdeveloped: documented approval as distinct from documented awareness; training records for board members under Article 5(4); and the budget duty under Article 5(2)(g), which is a specific obligation rather than a general aspiration.
Weighting: our judgment, and the reasoning behind it
With every domain scored, weight the gaps. Here we have to be straight with you: we have no supervisory data on which domains draw enforcement attention, and nor does anyone else who is being honest. DORA has only applied since January 2025 and there is no published body of enforcement outcomes to generalise from. So the weighting below is not a claim about what regulators are focusing on.
It is a judgment based on the one thing the text does let you reason about: how visible and how time-bound a failure is. A missed reporting deadline and a rejected register submission are externally visible against a fixed clock. A thin risk framework is a matter of supervisory assessment over a longer horizon. That asymmetry, not a guess about inspection priorities, is what drives the weights.
| Domain | Our weight | Why |
| D2 Incident reporting | Critical | A four-hour clock you either hit or miss, and a miss is visible to the supervisor by construction. |
| D5 Register of information | Critical | A structured submission that either passes validation or does not. The failure mode is binary and externally observable. |
| D4 ICT third-party risk | High | Article 30 compliance is verifiable by reading contracts, which makes a gap easy to establish and hard to argue away. |
| D7 Governance | High | Article 50(5) lets Member States extend administrative penalties and remedial measures to members of the management body, subject to national law. |
| D1 ICT risk management | Medium | Foundational, and everything else stands on it, but assessed over a longer horizon than a filing deadline. |
| D3 Testing | Medium | A firm yearly obligation under Article 24(6), but TLPT only bites for entities identified under Article 26(8). |
| D6 Information sharing | Lower | Article 45 is permissive. A documented decision is a sufficient answer. |
Disagree with a weight? Change it. The reason for printing the reasoning next to the number is so you can argue with it. A weighting you cannot explain to your own board is not worth carrying into a board meeting.
From scores to an order of work
You now have two numbers per domain: how far below 3 it scores, and what it weighs. Cross them.
| Weight ↓ / Score → | Score 1 | Score 2 | Score 3 or better |
| Critical | Immediate. To the management body now, with a dated plan. | Urgent. Close this quarter. | Maintain and evidence. |
| High | Urgent. Close this quarter. | Planned. Next quarter. | Maintain and evidence. |
| Medium or lower | Planned. Next quarter. | Roadmap. | Sustain. |
One rule worth hard-coding: a domain scoring 1 at Critical or High weight goes to the management body with a time-bound plan, not into a backlog. Article 5(2) makes the board responsible for the framework those gaps sit inside, so an unreported critical gap is a governance failure stacked on top of a technical one.
When to run it again
You do not need to invent a cadence. Article 6(5) hands you one. The framework must be documented and reviewed at least once a year, and in addition:
- Upon the occurrence of major ICT-related incidents. A major incident is both a live test of D2 and a signal that D1 may have gaps that looked fine on paper.
- Following supervisory instructions. Straight from the text.
- Following conclusions derived from relevant digital operational resilience testing or audit processes. Test results are an input to the framework review, not a separate exercise filed elsewhere.
Two more triggers are worth adding, not because the article names them but because they change the answers underneath you: a material change in your ICT provider landscape, which moves D4 and D5, and a revision to the technical standards, which can change what a 3 even means in a domain.
Frequently Asked Questions
Does DORA require a gap assessment?
Not under that name, and DORA never uses the phrase. What Article 6(5) requires is that the ICT risk management framework be documented and reviewed at least once a year, and additionally upon major ICT-related incidents and following supervisory instructions or conclusions derived from digital operational resilience testing or audit processes. A gap assessment is the usual instrument for performing that review and evidencing it, but the obligation is the review, not the method.
Is the 1 to 4 maturity scale in this article a regulatory requirement?
No. DORA prescribes no maturity scale, no scoring model and no weighting scheme. The four-level scale, the seven-domain split and the weights here are our editorial model, offered because you need some consistent instrument to compare domains. What is not editorial is what each level 3 is pinned to: a specific article you can be asked to evidence. Substitute your own scale freely. Do not substitute the underlying articles.
What are the actual DORA incident reporting deadlines?
They are not in DORA itself. Article 19(4) names the three submissions and defers the time limits to a technical standard. Article 5(1) of Commission Delegated Regulation (EU) 2025/301 sets them: the initial notification within four hours of classifying the incident as major and no later than 24 hours from becoming aware of it; the intermediate report at the latest within 72 hours of the initial notification; and the final report no later than one month after the intermediate report, or after the latest updated intermediate report where applicable. Note that 72 hours is the intermediate report. It is very commonly, and wrongly, reported as the final one.
How many contractual provisions does Article 30(2) require?
Nine. Article 30(2) lists points (a) to (i): a description of the functions and ICT services and the conditions for subcontracting; the locations where services are provided and data processed; provisions on data protection; provisions on access, recovery and return of data; service level descriptions; incident assistance obligations; cooperation with competent authorities; termination rights and notice periods; and participation in the entity's ICT security awareness and resilience training. Article 30(3) then adds further elements where the arrangement supports a critical or important function. A gap assessment scoring against a list of 12 "Article 30(2) provisions" is scoring against a list that does not exist in the regulation.
Can we reuse our ISO 27001 assessment as a DORA gap assessment?
Partly, and the boundary is sharp. An ISO 27001 assessment gives you real signal on D1 and D3, because the underlying security management substance overlaps. It gives you nothing on D5, because the register of information is a reporting artefact defined by an EU implementing regulation with no ISO analogue. It gives you nothing on the DORA-specific parts of D4, in particular the Article 30 contractual elements, nothing on the Article 18 classification criteria and the reporting clock in D2, and nothing on the Article 5(2) management body duties in D7. Reuse what genuinely overlaps, then assess the rest against the articles.
What score should we be aiming for?
A 3 in every domain means you meet the requirements as written and can evidence it, which is the bar the regulation actually sets. Push to 4 where failure is time-bound and externally visible, which in our weighting means D2 and D5. But the target that matters more than any number: no domain sitting at 1 without a dated plan in front of the management body.
Primary sources
Every article number, deadline and count in this article was checked against the texts below. Confirm the current version before relying on a specific paragraph.
- Regulation (EU) 2022/2554 (DORA) - Articles 5, 6, 17 to 19, 24 to 27, 28 to 30, 45 and 50. It has 64 articles and applies from 17 January 2025.
- Commission Delegated Regulation (EU) 2025/301 - Article 5(1) sets the four-hour, 72-hour and one-month reporting deadlines.
- Commission Implementing Regulation (EU) 2024/2956 - the ITS on the register of information, setting the 15 templates B_01.01 to B_99.01.
- Commission Delegated Regulation (EU) 2024/1774 - the RTS on ICT risk management tools, methods, processes and policies.
Running the assessment in Venvera
Venvera has a gap assessment module, and it is worth being precise about what it does. It runs a scored assessment against a framework, produces an overall score, and turns each gap into a remediation plan carrying a priority, an owner and a due date, so the output is a tracked plan rather than a spreadsheet that quietly ages. It covers DORA and NIS2 today, and DORA assessments come in a full and a micro-entity variant. That is the boundary, and we would rather state it than imply a larger one.
DORA is one of several regimes most financial entities carry at once, and the work overlaps heavily. The crosswalk engine exists so a control you have evidenced once can satisfy its counterparts under NIS2 or ISO 27001 rather than being rebuilt from zero. For a faster read on where you stand before committing to anything, run a free compliance check.
Score your readiness, then track the remediation
A scored gap assessment, remediation plans with owners and dates, and the evidence kept where an auditor can find it.
Book a demo →Last updated: July 2026. General information, not legal advice. The maturity scale, the seven-domain split and the weightings in this article are Venvera's editorial model, not regulatory requirements. Confirm article references against the current text and your competent authority's guidance.
