What a DORA gap analysis checks and who signs off the result
A DORA gap analysis compares your current practice against Regulation (EU) 2022/2554 and the delegated and implementing regulations that detail it, and no auditor certifies DORA compliance. If a regulator, client or contract now asks for DORA readiness, the baseline you need is an internal finding that lists each obligation, the document or control that answers it, and the distance between the two. The organization owns its controls and signs off the result. An implementation partner can prepare systems, configuration records and evidence for the review, but the partner's work is not an attestation, and no independent party issues a report or certificate on the outcome. The Regulation has applied since 17 January 2025, so a baseline that predates that date should be re-run against current requirements.
The checks cover the full baseline: the Regulation's five areas (ICT risk management, incident management and reporting, resilience testing, ICT third-party risk and information sharing) together with Delegated Regulations (EU) 2024/1774, 2024/1773, 2025/301, 2025/532 and 2025/1190, and Implementing Regulations (EU) 2025/302 and 2024/2956. Ask for a written scope that names which of these texts the assessment covers and which entity or group entities it applies to. Confirm with your competent authority which entity types and proportionality options apply to you, because the answer changes the depth of each check. Article 4 requires the rules to be applied proportionately to size, risk profile and complexity, and the simplified framework in Title III of Delegated Regulation (EU) 2024/1774 applies to entities under Article 16(1). Your gap list should record which simplifications you rely on, and why, so the reasoning is visible to a supervisor.
Plan for the evidence a supervisor can request, because the gap analysis should be built to produce it. Under Article 6(5), an entity submits a report on the review of its ICT risk management framework when the competent authority asks, and Article 27 of Delegated Regulation (EU) 2024/1774 sets its format and content. Article 6(6) requires regular internal audit of that framework, except for microenterprises. In practice, the gap analysis is a dated, owner-signed record that maps each requirement to a policy, a configuration, a test result or a log, and flags what is missing. Decide before work starts who in the management body will accept the findings and who owns remediation, and ask any partner to state in the quote which artifacts they will deliver and which ones remain your responsibility.
How to run a DORA gap analysis step by step
This sequence turns the DORA Regulation and its technical standards into a scoped baseline, a documented comparison of current controls, and a prioritized remediation plan that an owner can act on.
Confirm scope and entity type
Start by recording which legal entity is in scope, which type of financial entity it is under Article 2(1), whether it qualifies as a microenterprise, and whether it falls under the simplified regime in Article 16(1). Include any group entities and ICT services shared with them. The management body or the compliance lead signs off the scope statement, and the analysis is ready to proceed once the scope, entity type and proportionality position are written down and approved. Confirm the competent authority that supervises the entity, since its expectations shape the review.
Build the requirement baseline
Assemble the baseline from the Regulation itself, then add the technical standards that detail each chapter: Delegated Regulations 2024/1774 (ICT risk management), 2024/1773 (ICT services policy), 2025/532 (subcontracting) and 2025/1190 (TLPT), plus Implementing Regulations 2025/302 (incident templates) and 2024/2956 (register of information). Split the baseline into discrete requirement lines, each tagged with its article and the standard that details it. The output is a requirement register that a reviewer can trace line by line, and the owner of the baseline confirms that no standard in scope has been left out.
Collect current documents and evidence
Gather the policies, plans, registers, inventories, reports and logs the entity already holds, such as the ICT risk management framework, the information security policy, continuity and recovery plans, backup policies, the incident management process, the testing programme, the register of information and exit plans. Record each item with its version, approver, approval date and last review date. Mark anything that is missing or only exists in draft. The step closes when every requirement line has at least one named source document or a recorded gap.
Test operations against the documents
Compare what the documents say with what systems and teams actually do. Sample recent review cycles, access reviews, vulnerability scans, firewall rule checks, backup restores, continuity tests and incident records against the frequencies the standards set, including the yearly activities in the Regulation and the shorter intervals in Delegated Regulation 2024/1774 for systems supporting critical or important functions. Record the evidence reviewed and its date. The output is a set of observations that show whether each control operates as written.
Map each gap to its article
For every requirement line that is missing, partial or not operating, record the gap statement, the article or regulation reference, the affected system or function, and the evidence that would close it. Keep the mapping one-to-one where possible so that a supervisor can follow the logic from the article to the finding. The step closes when every gap has a single traceable reference and a short description written in plain terms.
Rate severity of each gap
Assign each gap a severity using a scale the management body approves in advance. Consider the criticality of the function or system affected, whether it supports critical or important functions, the likelihood of an incident, and the reporting or supervisory exposure. Document the rationale for each rating so that the scale can be applied consistently and reviewed later. The output is a ranked gap list, and the approver confirms that the ranking reflects the entity's risk appetite and proportionality position.
Produce a remediation plan with owners
Turn the ranked gap list into a remediation plan that names an accountable owner, the specific action, the evidence that will prove closure, and the dependencies on suppliers or intra-group services. Agree target dates with the owners and the management body, and do not adopt dates that are not grounded in the entity's own capacity or in a written scope with any outside implementation partner. The plan is complete when every high-severity gap has an owner, an action and an approved date, and the management body has accepted the plan in writing.
Which requirements to compare against
A DORA gap analysis compares your current controls against the Regulation and the technical standards that detail it. Each card below covers one part of that baseline, with the question to ask when you compare your evidence against it.
ICT risk management framework
Chapter II of the Regulation sets the governance and framework duties, and Delegated Regulation (EU) 2024/1774 sets the detailed controls behind them. Compare your framework, policies, asset inventory and risk assessments against both, and confirm which parts apply through the simplified regime if you qualify. Check whether the framework review report is ready to produce on request.
Incident management and reporting
Compare your incident process against the classification criteria in Delegated Regulation (EU) 2024/1772, the report content in 2025/301 and the templates in Implementing Regulation (EU) 2025/302. Test whether your detection, escalation and classification steps produce the data needed for the initial, intermediate and final reports within the deadlines. Confirm who can sign and submit each report.
Digital operational resilience testing
Chapter IV requires a testing programme, and Article 24(6) requires testing of systems that support critical or important functions at least yearly. Compare your test plan, test records and remediation tracking against those duties. Separately, check whether your entity falls within threat-led penetration testing under Delegated Regulation (EU) 2025/1190, which is a different regime with its own cycle and deliverables.
ICT third-party risk management
Chapter V, Delegated Regulation (EU) 2024/1773 on ICT services policy and Delegated Regulation (EU) 2025/532 on subcontracting together set the rules for providers. Compare your third-party strategy, policy, due diligence records, contract clauses and exit plans against them. Check that the management body reviews the policy on ICT services supporting critical or important functions at least once a year.
Register of information
Implementing Regulation (EU) 2024/2956 defines the templates for the register of information on contractual arrangements with ICT providers. Compare your current contract inventory against the required fields and identifier rules, because gaps usually sit in provider identifiers, subcontractor chains and intra-group arrangements. Confirm which version of the register your competent authority expects and how the data is exported.
Information sharing arrangements
Article 45 allows financial entities to share cyber threat information with each other under trusted communities, with notification to the competent authority where the arrangement requires it. Review whether you have documented participation criteria, confidentiality terms and any sharing agreements. Record the decision to participate or not, since supervisors may ask how you use threat intelligence.
Which documents and yearly activities DORA names
The top layer of the ICT risk management regime is the framework and the strategy that sets its direction. DORA names the ICT risk management framework and the digital operational resilience strategy in Article 6, and expects the management body to own both. A gap analysis should confirm that a current version exists, that it links to the risk appetite and business objectives, and that the management body approved it. Check the approval record and the date, not only the document.
- ICT risk management framework (Article 6): the documented structure of controls, roles and processes that the rest of the regime runs on.
- Digital operational resilience strategy (Article 6): the direction, tolerances and objectives that the framework is built to meet.
- Information security policy (Article 9(4)(a)): the top-level security policy that the detailed ICT security rules implement.
- ICT third-party risk strategy (Article 28(2)): the strategy for how ICT providers are selected, monitored and exited.
- Management body approval: evidence of who approved each document, when, and on what basis.
For each item, confirm that it exists, that it reflects the current estate and that the review date has not passed.
Operational documents cover how services keep running, how data is protected and how incidents are handled. DORA names an ICT business continuity policy with response and recovery plans in Article 11, a backup policy in Article 12, crisis communication plans in Article 14, an incident management process in Article 17 and a testing programme in Article 24. A gap analysis should check that each one is specific to the entity's critical or important functions rather than a generic template.
- ICT business continuity policy and response and recovery plans (Article 11): the rules and plans that keep critical functions running during disruption.
- Backup policies (Article 12): the rules for what is backed up, how often, where it is stored and how it is restored.
- Crisis communication plans (Article 14): who communicates with staff, clients, authorities and the public during a serious event.
- Incident management process (Article 17): the steps from detection to closure, including classification and reporting triggers.
- Testing programme (Article 24): the plan that sets which tests run, on which systems and how findings are tracked.
Check that each plan names owners and contact routes, and that the most recent test or exercise is recorded against it.
DORA requires several activities at least once a year. These reviews show whether the framework still matches the business and the technology. The gap analysis should list each activity, the owner, the last completion date and the output. A review with no written output is hard to defend during supervision.
- Framework review (Article 6(5)): the annual review of the ICT risk management framework, which entities report on when the competent authority asks.
- Classification review (Article 8(1)): the review of how functions and information assets are classified.
- Risk scenario review (Article 8(2)): the review of the risk scenarios that feed the risk assessment.
- Legacy system risk assessment (Article 8(7)): the assessment of older systems that cannot be fully supported or secured.
- Continuity and recovery testing (Article 11(6)), senior staff reporting (Article 13(5)) and testing of critical systems (Article 24(6)): annual tests and reports that show recovery and oversight actually work.
Confirm that each yearly activity has a dated record, a named owner and a follow-up on open findings.
Delegated Regulation (EU) 2024/1774 sets shorter cycles for systems that support critical or important functions. These cycles are higher than the yearly baseline, so a gap analysis must treat them as separate checks with their own evidence. The analysis should identify which systems fall in scope, then test whether scanning, rule reviews and access reviews run at the required frequency, not just whether a policy describes them.
- Weekly automated vulnerability scanning (Article 10): scans of assets supporting critical or important functions, run automatically each week.
- Firewall rule checks at least every six months (Article 13): a documented review of firewall rules for those systems.
- Access rights review at least every six months (Article 21): a review of who holds access to those systems and whether it is still needed.
- Scope record: a current list of the systems and functions these cycles apply to.
- Run history: scan reports, review sign-offs and ticket records showing each cycle actually happened.
Confirm the scan and review logs for the last full period, and check that exceptions are approved and tracked to closure.
How proportionality changes the gap analysis scope
Proportionality decides how much of the DORA baseline a gap analysis must cover, so write down the basis before you list a single gap. Article 4 requires the ICT risk management rules to be applied in proportion to your size, risk profile and complexity. Competent authorities take that proportionality into account when they review your framework under Article 4(3). If your scoping memo does not state which of these three factors you relied on, and why, an supervisor reviewing the framework has no way to see why a requirement was left out. Record the size of the entity, the criticality of its ICT services, the number and type of ICT dependencies, and the reasoning that links those facts to the requirements you treat as out of scope or lighter.
Two structural choices change the scope materially. First, if you qualify for the simplified framework under Article 16(1) of the Regulation, Title III of Delegated Regulation (EU) 2024/1774 sets a separate, shorter set of ICT risk management requirements, so your gap assessment should be run against Title III rather than the fuller Title II. Confirm your eligibility with your competent authority or legal counsel before you adopt it, because the choice must rest on the Article 16(1) criteria, not on preference. Second, Article 6(6) requires regular internal audit of the ICT risk management framework, but microenterprises are exempt from that requirement. A microenterprise should still record the exemption and its basis in the gap file, so the absence of an audit function is an explained decision rather than an apparent omission.
Once the proportionality basis is documented, scope the gaps against the obligations that actually apply to you, and keep a separate line for each requirement you exclude or reduce. Ask an independent auditor or your legal adviser to review that basis before the analysis is finalised, since an implementation partner can prepare the evidence but cannot decide your regulatory position. Illustrative example: a small payment institution that concludes a requirement is disproportionate should be able to show the factors, the regime it falls under and the date of its last review, so the decision can be defended in a supervisory conversation.
What supervisors can ask to see
A competent authority can ask for documents, data, on-site inspections and investigations under its Article 50 powers. The cards below cover the core items a gap analysis should prove exist, are approved and are current before an authority asks.
Documents and data under Article 50
Article 50 gives competent authorities access to documents and data and the power to run on-site inspections and investigations. A gap analysis should map each DORA policy, plan and register to a named owner, a storage location and a last-reviewed date, so the team can produce any of them within a short notice period. Check that the register of information and the policy set are consistent with each other.
Framework review report
Under Article 6(5), an entity submits a report on the review of its ICT risk management framework when the competent authority asks. Article 27 of Delegated Regulation (EU) 2024/1774 sets the format and content of that report. The gap analysis should confirm that a review has been done at least yearly, that findings are logged with owners and dates, and that the report can be produced in the prescribed structure.
Internal audit reports on the framework
Article 6(6) requires regular internal audit of the ICT risk management framework, with an exception for microenterprises. Article 11(3) adds independent internal audit reviews of ICT response and recovery plans. The gap analysis should identify who performs these audits, whether they are independent of the teams they review, and whether the findings have been tracked to closure. Auditors and supervisors will ask for the reports, not only the audit plan.
Continuity and recovery test records
Article 11(6) requires testing of ICT business continuity and response and recovery plans, and the framework expects that testing to be recorded. Supervisors commonly ask for test scope, dates, participants, results and the remediation actions that followed. The gap analysis should confirm that each plan has a test record and that failed tests have a documented follow-up, not only a scheduled date.
Evidence that the gap analysis is current
A gap analysis is only useful if its findings can be traced to current evidence. For each DORA requirement, record the document or log that proves it, the date it was last produced, and the owner responsible for refreshing it. Where evidence is missing or stale, the gap should be listed as open with a remediation date. This is the record that shows the organization, not an outside party, has checked its own position.
Records of on-site and investigation requests
Investigations can extend beyond documents to interviews, system access and on-site review of how controls operate in practice. The gap analysis should name a single contact for supervisory requests, define who can grant access to systems and data, and confirm that staff know where evidence is stored. Ask whether the organization has rehearsed a supervisory request, because the first request often exposes gaps in ownership.
Who does what in a DORA gap analysis
The financial entity owns the gap analysis, its conclusions and every control that results from it. Under DORA the management body carries final responsibility for the ICT risk management framework, so it must approve the policies, accept or reject residual risk and set the resources the programme needs. Operational owners then decide how each gap is closed and who is accountable for each system and process. Responsibility does not move when external help is involved, and an assessor will ask the entity, not a vendor, to explain its decisions.
- Management body approval: Directors approve the framework, the information security policy and the other policies DORA names, and they record the risk acceptance decisions behind them.
- Gap ownership: A named owner for each gap, with a target date agreed inside the entity's own governance.
- Risk acceptance: Decisions to accept residual risk are made and documented by the entity, never delegated to a consultant.
- Scope decisions: The entity defines which functions and ICT services are critical or important, which drives how deep the comparison goes.
- Source of truth: The entity keeps the asset inventory, the register of information and the evidence library that the comparison relies on.
Before starting, confirm internally who signs off the gap report and who can close findings.
An implementation partner such as DeployOpen can prepare the systems, documentation and evidence that the comparison examines, and it can help run the comparison itself. Its work is preparatory. It can map existing controls against the Regulation and its technical standards, draft policy and procedure text for the entity to review, configure logging, backup, access and vulnerability management on self-hosted platforms, and assemble the evidence an assessor would request. It does not decide whether a control is adequate for the entity, and it does not sign the outcome.
- Comparison support: Working through the requirements of Delegated Regulation (EU) 2024/1774 and the other standards against the current environment, with findings recorded for the entity.
- Documentation drafts: Proposed text for policies, plans and registers, which the entity reviews and approves.
- Technical preparation: Configuration of self-hosted open-source platforms so that logs, backups, access reviews and scan results exist and can be produced on request.
- Evidence packaging: Organized, dated and traceable artifacts mapped to each requirement.
- Knowledge transfer: Training for the entity's staff so they can maintain the evidence after the engagement.
Agree the boundary in the written scope: which deliverables are drafts, who approves them and what the partner will not certify.
Verification sits with the entity's own internal audit function or an independent reviewer. Article 6(6) requires regular internal audit of the ICT risk management framework, except for microenterprises, and Article 11(3) requires independent internal audit reviews of ICT response and recovery plans. Where the entity does not do this work in-house, Article 6(10) allows it to outsource the verification of compliance with the ICT risk management requirements to intra-group or external undertakings. Outsourcing the work does not transfer responsibility: the entity remains fully responsible for the verification.
- Independent testing: Reviewers test whether controls operate as described, not only whether documents exist.
- Sampling and walkthroughs: Evidence is checked against live systems, logs and tickets.
- Reporting lines: Findings go to the management body or its audit committee, not only to the team being reviewed.
- Competence: The reviewer needs knowledge of DORA and of the platforms in scope, and the entity should confirm this in writing.
- Independence from the partner: A reviewer should not verify controls it helped build, and the entity should document how it separates these roles.
Confirm that internal audit has the mandate, access and skills to review the framework before the gap analysis is scheduled.
Only the competent authority supervises DORA compliance. The national competent authority for each type of financial entity uses its Article 50 powers, including access to documents and data and on-site inspections and investigations, and the ECB handles significant credit institutions. No auditor, consultant or certification body can issue a DORA certificate or declare an entity compliant. The one authority-issued document the Regulation provides for is the attestation that a threat-led penetration test met its requirements under Article 26(7). External auditors may still be engaged for financial statement or other assurance work, but their output is not a DORA compliance certificate.
- Supervisory evidence: Authorities may request the ICT risk management framework review report under Article 6(5), prepared under the format in Article 27 of Delegated Regulation (EU) 2024/1774.
- Supervisory powers: Document requests and inspections are the mechanisms through which compliance is tested.
- No certificate: Marketing or contract language claiming a DORA certificate should be challenged.
- Assessor questions: Supervisors ask how the entity reached its conclusions, so the gap analysis must show its reasoning.
- Authority contacts: Confirm with the relevant national authority which documents it expects and in what format.
Check the authority's current guidance for your entity type before presenting any gap report externally.
Should you run the gap analysis in-house or with a partner
The entity owns the gap analysis conclusions, so the real choice is which work you hand to others. Three roles are often confused. An internal team does the analysis and decides what the gaps mean. An external reviewer checks that the analysis is sound, but does not issue anything under DORA, because no auditor or authority certifies compliance with the Regulation. An implementation partner prepares systems, configuration and evidence so that the controls can be shown to work. Article 6(10) of Regulation (EU) 2022/2554 allows verification of ICT risk management compliance to be outsourced to intra-group or external undertakings, but the entity stays fully responsible for that verification. Plan your team around that sentence before you request any quotes.
Work that is commonly outsourced includes collecting technical evidence (access review exports, scan results, firewall rule listings, backup restore logs), supporting testing that the testing programme requires, and drafting documentation such as procedures and technical annexes. These tasks are measurable and can be specified in advance. Work that should stay with the entity includes accepting residual risk, approving the framework and strategy, the management body sign-off that Chapter II expects, and ownership of the register of information and the classification of functions and assets. A partner can prepare the register data, but the entity must be able to explain every entry to its competent authority.
Put the engagement on a fixed scope with written deliverables agreed before work starts. The statement of work should list each system or ICT service in scope, each document to be produced or updated, the evidence items to be captured, who signs off each deliverable, and what happens if a gap is found mid-project. Ask for the proportionality position in writing: which of the simplified regime's options apply, and why. Confirm with your competent authority which reports it may request, and make sure the partner's output maps to those requests. Any quote should follow directly from that written scope, and the scope should name the internal owner who accepts each deliverable.
How to choose a consultant or reviewer for the gap analysis
A DORA gap analysis is only as useful as the person running it, and the wrong choice leaves you with a report no supervisor will accept. The cards below set out the checks to run before signing, and the questions that show whether a firm can do the work and stay independent of it.
Working knowledge of the Regulation and standards
Ask the reviewer to walk you through how Chapter II maps to Delegated Regulation (EU) 2024/1774, and where the simplified framework in Title III applies. A credible team can explain which technical standard governs incident classification, subcontracting and TLPT, and can name the Implementing Regulations for templates and the register. If the answers stay at the level of the Regulation's title, the gap list will miss specific documents and recurring activities.
Experience with your entity type
DORA lands differently on a bank, a payment institution, an insurer or a fund manager, and the sectoral directive changes apply to each. Ask for examples of prior work on your type of financial entity, described without client names, and ask how the team handled proportionality under Article 4. A reviewer who has only worked on large banks may over-scope a small investment firm.
Evidence a supervisor can review
Ask what the deliverable looks like and whether each gap points to a specific artifact: a policy, a log extract, a test record or a review report. The output should be something a competent authority could request under Article 50 and read without the consultant in the room. Ask who in your organization will own each artifact after the engagement ends.
Independence from later verification
Article 6(10) lets an entity outsource verification of its ICT risk management, but the entity stays fully responsible for it. If the same firm designs your controls and later verifies them, the verification has little independent weight. Ask whether the firm will commit to not performing the later review, and whether an internal audit function or a separate assessor will test the outcome.
Fixed-scope deliverables and prioritization
Most credible engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts. Ask for a written list of what the gap analysis covers, the named documents and activities reviewed, and what it excludes, such as TLPT or contract remediation. Ask how gaps are ranked, for example by effect on critical or important functions, and what each rank triggers.
Limits on what any consultant can issue
No consultant, auditor or certification body can certify an entity as DORA compliant, because DORA sets no certification scheme. The only authority-issued document is the TLPT attestation under Article 26(7). Be wary of any offer that promises a DORA certificate or attestation of overall compliance, and ask the firm to confirm in writing that its output is preparation material for your own review and for supervisors.
DORA gap analysis questions buyers ask
How long does a DORA gap analysis take?
No duration is fixed by DORA or its technical standards, so the length depends on the scope you set. The main drivers are the number of ICT systems and services in scope, how many of them support critical or important functions, how complete your existing policies and asset inventory already are, and how many ICT third-party contracts you need to review against the contract requirements. A gap analysis covering a single entity with a documented framework will move much faster than one that starts with no inventory and no register of information. Ask any partner to state the assumed scope, the number of systems and contracts reviewed, and the interview hours in the written scope before work starts.
What does a DORA gap analysis need from our internal staff?
Your staff own the answers, so the work needs named people with authority over each area. In practice this usually includes a senior owner for ICT risk, the security lead, the business continuity and crisis management owner, the people who run incident response, the procurement or vendor management lead, and the owners of the systems that support critical or important functions. Expect them to provide the existing policies, the asset and ICT service inventory, backup and recovery records, test reports, incident logs and the contracts in force. Agree in advance how many hours each owner can give and who signs off the findings, because gaps that stay unanswered tend to delay the whole analysis.
Is there a DORA certificate that proves we are compliant?
No. DORA sets no certification scheme, and no auditor or certification body can certify an entity as DORA compliant. Competent authorities supervise compliance using their powers under Article 50, and they can request documents and data or carry out on-site inspections. The one authority-issued attestation the Regulation provides for concerns a threat-led penetration test that met the requirements under Article 26(7). A gap analysis is therefore an internal assessment that tells you where your controls and documents fall short of the Regulation and its technical standards. Treat any offer of a DORA certificate with suspicion and ask the provider which legal basis it relies on.
Can a small financial entity run a DORA gap analysis alone?
A small entity can often run a first pass internally, but whether that is sufficient depends on its size, risk profile and complexity. Article 4 requires the ICT risk management rules to be applied proportionately, and competent authorities consider that proportionality when reviewing the framework under Article 4(3). Delegated Regulation (EU) 2024/1774 also sets a separate simplified framework in Title III for entities under Article 16(1), and microenterprises are excluded from the internal audit requirement in Article 6(6). Before deciding to work alone, check which regime applies to you, confirm with your competent authority if the status is unclear, and be honest about whether your staff can assess technical controls such as logging, access reviews and vulnerability scanning against the detailed requirements.
What should we ask a partner to include in a gap analysis quote?
Ask for a written scope that lists the entity or entities covered, the regime that applies, the requirements compared (the Regulation and each relevant technical standard), the systems and ICT services reviewed, and the contracts sampled. The quote should name the deliverables, such as a gap register with severity, an evidence list, a remediation plan and a summary for the management body, and it should state what is one-time work and what recurs. Confirm who performs each activity, which parts the partner will not cover, and what internal time you must provide. Also ask how changes in scope are priced. A partner prepares systems, controls and evidence; it does not issue audit reports or attestations, so the quote should say so.
How does a gap analysis feed later audit or supervisory requests?
The gap analysis becomes the baseline for your remediation plan and for the evidence you will later show. Competent authorities can ask for documents such as the report on the review of your ICT risk management framework under Article 6(5), whose format Article 27 of Delegated Regulation (EU) 2024/1774 sets. Findings from the analysis should map to named policies, owners, dated actions and the records that prove each control operates, so you can produce them quickly. Keep the analysis itself under version control and record how each gap was closed. Any independent audit you commission later, whether internal under Article 6(6) or by an external assessor, will test the operating evidence, not the analysis document alone.
How DeployOpen works on this
DeployOpen plans and runs DORA gap analysis as a fixed-scope engagement, comparing your ICT environment against the Regulation and its technical standards. We prepare systems, documents and evidence inside your own infrastructure, while your organization owns its controls and any report on compliance comes from your competent authority or an independent auditor.
How we scope
- Agree in writing which entity types, ICT systems and services fall inside the gap analysis before work starts
- Map the in-scope ICT systems and any critical or important functions to the requirements they must meet
- Confirm which simplified or proportionate requirements apply to your size, risk profile and complexity
How we build
- Compare current policies, controls and configurations against the Regulation and each technical standard in scope
- Identify gaps in documents, recurring activities and review cycles, and record each one with an owner
- Prepare the missing documentation drafts, such as the framework review report and testing programme, for your management body
How we hand over
- Deliver a written gap register with requirement references, severity, remediation steps and proposed owners
- Provide an evidence index showing where each artifact is stored, who maintains it and how often it is refreshed
- Walk your compliance, security and platform teams through findings so they can act on them after handover
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work ends
- Help your team keep yearly reviews, internal audit inputs and control evidence current between assessments
- Confirm with your competent authority or independent auditor which evidence they expect before you finalize it
