What the DORA ICT risk management framework review report must show
Article 6(5) requires the ICT risk management framework to be reviewed at least once a year, or periodically for microenterprises, and the report on that review is submitted to the competent authority on request. Its content is set by Article 27 of Delegated Regulation (EU) 2024/1774, so a regulator, board or customer asking for the report is asking for a specific structure, not a general summary. The entity owns the review, the findings and the report. An implementation partner can prepare the systems, configuration records, logs, test results and corrective-action trackers that the report draws on, but it does not sign the report or vouch for its conclusions. Those stand behind the entity's own management body and any independent audit the entity commissions.
The answer to what the report must contain changes with the entity. Size and regime matter most: a full-regime entity owes the complete Article 27 content, while an entity under the simplified framework works from the shorter report set out in Article 41 of the same Delegated Regulation. Incident history changes the scope, because a review triggered by incidents must list every ICT-related incident with its root cause analysis. The maturity of existing evidence changes the effort. An entity whose asset inventory, risk assessments, remediation register and test records are current can assemble the report quickly, while one with scattered records will spend most of its effort reconstructing history. Before work starts, confirm which regime applies, which incidents fall in the review period, and where each evidence source lives.
No authority-issued certificate or attestation exists for this report. Competent authorities review it as supervisory evidence and, under Article 4(3), consider how the entity applied proportionality. The only authority-issued attestation DORA provides for relates to threat-led penetration testing under Article 26(7), which is a different obligation. Readers should therefore treat the report as an internal governance document that must be defensible on inspection, approved by the management body with a stated approval date, and supported by records that a supervisor can trace. Check the current text of the Regulation in the EUR-Lex copy of DORA and confirm with your competent authority how it expects the report to be delivered.
When a DORA framework review is due and what triggers an extra one
This sequence shows the entity which events oblige it to review its ICT risk management framework, and what record or report it should hold at each point. Working through the triggers in order lets the team show a supervisor, on request, that every required review happened and why.
Confirm the framework is documented and in force
Before any review can be measured, the management body and the responsible function need a current, written ICT risk management framework that the review will test. Under Article 6(5) of DORA, the framework must be documented, so the review starts from a dated version with a named owner. Done when the current version, its approval date and its owner are recorded in the governance file, ready to be compared against during the review.
Run the annual review
The first trigger is the yearly review. Article 6(5) requires the ICT risk management framework to be reviewed at least once a year, and the responsible function carries it out against the current risk, incident and testing record. The output is a review record covering the period, the reason for the review and the findings. Done when that record is complete and the findings are logged for remediation tracking.
Apply the periodic review for microenterprises
Microenterprises are allowed a periodic review in place of the yearly cycle, as Article 6(5) provides. The entity should confirm in writing that it qualifies as a microenterprise under DORA and set the review interval with its management body. The output is the documented interval and the review record produced at each cycle. Done when the qualification and the interval are on file and each periodic review is recorded.
Review after a major ICT-related incident
A major ICT-related incident triggers a further review outside the normal cycle, as Article 6(5) requires. The responsible function reviews the framework against the incident, its root cause and the controls that failed. If the review is incident-driven, the report must list all ICT-related incidents and their root cause analysis. Done when the incident review record is approved and linked to the incident file.
Review after supervisory instructions or testing conclusions
The framework must also be reviewed after supervisory instructions, and after conclusions from resilience testing or audits. Each of these inputs should be logged with its source and date so the review can show what prompted it. The output is a review record that maps each instruction, test conclusion or audit finding to a decision and a remediation item. Done when every input has a recorded disposition.
Hold the review report ready for the competent authority
Each review produces a report that the competent authority can request under Article 6(5). The report should follow the format that Article 27 of Delegated Regulation (EU) 2024/1774 sets, or the shorter format under Article 41 for entities on the simplified framework. Confirm the format with your competent authority and the current RTS text. Done when the report is approved by the management body, stored in a searchable electronic format and ready to submit on request.
What the Article 27 review report must contain, section by section
The full report is the standard format that Article 27 of Delegated Regulation (EU) 2024/1774 sets for a review of the ICT risk management framework. It must be submitted in a searchable electronic format, so a supervisor can filter and search it without retyping. The report opens with the entity's identity, its group structure, the services it provides, its critical functions and dependencies, and an executive summary of its risk and security posture. The core body then covers the sections below.
- Approval and scope: the management body's approval date, the reason for the review, the review period and the responsible function.
- Findings and severity: each finding with a severity analysis that explains how the rating was reached.
- Remediation: each measure with its expected date, responsible function and resource impact.
- Planned developments and conclusions: upcoming changes to the framework and the review's overall conclusions.
- Past measures and sources: the status of corrective measures from earlier reviews, and the sources the review relied on.
Before submission, check that each section can be traced to evidence in your own records, not only to narrative statements.
A review triggered by a major ICT-related incident, as Article 6(5) of DORA requires, uses the full structure above with one important addition. Article 27 of Delegated Regulation (EU) 2024/1774 requires this variant to list all ICT-related incidents that prompted or fed into the review, each with its root cause analysis. The purpose is to show the supervisor that the framework changed in response to what actually went wrong, not only in response to a general annual cycle.
- Complete incident list: every ICT-related incident in scope, not only the major one that triggered the review.
- Root cause analysis: a documented cause for each incident, with the reasoning that connects the cause to any framework gap.
- Linkage to findings: each root cause should map to a finding, a severity rating and a remediation measure with a date and owner.
- Recurring patterns: repeated causes across incidents, which often point to a control design issue rather than a one-off failure.
- Illustrative example: an entity could find that three separate outages shared one unpatched dependency, and record that as a single finding with three linked incident entries.
Confirm with your incident management team that the incident list is complete and reconciles with the records you submitted under the reporting rules.
Article 41 of Delegated Regulation (EU) 2024/1774 sets a shorter review report for entities that apply the simplified framework. It must also be in a searchable electronic format. The structure is lighter, but it still has to be complete on the points a supervisor needs to assess the framework. Findings are self-assessed rather than measured against a full severity analysis, so the entity's own rating logic should be written down and applied consistently.
- Context and reasons: why the review took place and what situation it addresses.
- Review period and responsible person: the timeframe covered and the named individual accountable for the review.
- Self-assessed findings: each finding with a severity rating the entity has assessed itself, supported by a short explanation.
- Remediation with dates: each measure with a completion date and the conclusion it leads to.
- Conclusions: an overall statement of whether the framework remains fit for the entity's risk profile.
Confirm with your competent authority whether it expects any section beyond those listed in Article 41, and whether your proportionality rationale should appear in the report.
How proportionality shapes what supervisors expect in the review report
Article 4(3) means supervisors will judge the review report partly on how the entity applied proportionality, so the report must explain its reasoning, not only its results. When a competent authority asks for a review report under Article 6(5) or Article 16(2), it considers how the entity scaled its ICT risk management framework to its size, risk profile and the nature of its services. For a smaller entity, that usually means showing why certain documentation, testing or governance elements were scoped in or out, and what evidence supports that choice. For a large group, the same question applies in reverse: the report should show why a group-wide framework was tailored for particular subsidiaries, functions or critical services, and how the board and control functions tested that tailoring.
Practically, each scope decision in the report should carry three things: the decision itself, the factors behind it (such as the entity's category, its critical or important functions, its ICT dependencies and its incident history), and the review evidence that the decision still holds. Reviewers can then see whether the framework is proportionate or simply thin. Confirm with your competent authority whether it has published any expectations on the level of justification it wants beyond the Regulation and the delegated regulation, and align your template before the first report is due, not when a request arrives.
Proportionality is a way of calibrating obligations, not a way of reducing them. The report must not present a scaled-down approach as a lighter legal duty, and it should not treat a decision to omit a control as settled without showing it was assessed. A useful check before submission is to ask whether an independent reviewer could follow the reasoning from the entity's risk profile to each scope choice and find that every element the Regulation requires is either covered or justified.
What makes a DORA review report harder to produce
The review report under Article 6(5) is a snapshot of how the framework performed over the period, so its effort depends on how much material the entity has to pull together. The six drivers below set how many incidents, entities, functions, providers and past findings the report must cover, and whether the full or simplified format applies.
Incident volume and root cause analyses
An incident-driven review must list every ICT-related incident in the period along with its root cause analysis. The count of incidents, not the count of major incidents, sets the length of that section. Keep incident records in one searchable register with fields for classification, timeline, root cause and linked corrective measures, so the list can be generated without rebuilding it from email and tickets. Check whether minor incidents are logged consistently, because gaps in the log become gaps in the report.
Group structure and covered entities
The report opens with the entity's identity and group structure, so a group with several legal entities, shared platforms or intra-group service providers must explain how each unit sits in the framework. Each additional entity adds scope, owners and findings to reconcile. Maintain a current group chart and a list of which entities rely on which shared ICT services, and confirm with your legal and compliance team which entities the report must cover before work starts.
Critical functions and dependencies
The report must describe the services, critical functions and dependencies that the framework protects. The more critical or important functions an entity has, and the more systems each depends on, the more mappings the report must reproduce. Link each critical function to its supporting assets and providers in the asset inventory, and record the date of the last dependency check. Stale mappings are the most common reason a review section cannot be backed by evidence.
ICT third parties and subcontractors
Findings about providers and their subcontractors feed the review, so the number of ICT third-party service providers and the depth of their subcontracting chains affect how much evidence must be gathered. Each provider's performance, incidents and contract changes during the period may need a finding. Keep the register of information current and ask providers for their incident and change records on a fixed schedule, so the review does not depend on ad hoc requests during the reporting window.
Status of past corrective measures
The report must show the status of corrective measures from earlier reviews and name its sources. An entity with many open or partly closed actions, or with actions that lack an owner, dates or closure evidence, will spend most of its effort reconstructing history. Track each measure from finding to closure in one action log with the evidence reference attached. Ask the responsible functions to confirm status in writing before the report is drafted.
Full or simplified regime
Entities under the simplified framework use a shorter report under Article 41 of Delegated Regulation (EU) 2024/1774, which asks for self-assessed severity rather than a full severity analysis. Confirm with your competent authority whether your entity qualifies, because the wrong format can make a complete submission non-compliant. Entities on the full regime must also explain how proportionality was applied, since competent authorities consider this when they review the report.
Which report format fits your entity
This table compares the full Article 27 review report under Delegated Regulation (EU) 2024/1774 with the shorter Article 41 report for entities under the simplified framework. Read each row to see which format applies to your regime and size, what the report must contain, and what to confirm with your competent authority before drafting.
| Aspect | Full review report (Article 27) | Simplified review report (Article 41) |
|---|---|---|
| Regime | Entities subject to the standard ICT risk management framework under Chapter II of DORA | Entities that qualify for the simplified ICT risk management framework |
| Size and profile | Larger or more complex financial entities, including those with critical functions and broad ICT dependencies | Smaller or less complex entities that the simplified regime covers; confirm eligibility with your competent authority |
| Opening content | Entity identity, group structure, services, critical functions, dependencies and an executive summary of risk and security posture | Context of the entity and the reasons for the review |
| Findings | Findings summarized with a severity analysis, with the status of corrective measures from past reviews | Findings with self-assessed severity |
| Remediation | Measures with expected dates, responsible functions and resource impact | Measures with dates |
| Incident-related content | An incident-triggered review must list all ICT-related incidents with their root cause analysis | Confirm with the authority how incident-triggered reviews are to be documented |
| Governance details | Management body approval date, reason and period of review, responsible function, planned developments and conclusions | Review period, responsible person and conclusions |
| Confirm before drafting | Expected format, searchable electronic submission, level of detail for dependencies and group structure | Eligibility for the simplified regime, expected depth of self-assessment, and whether any additional sections are requested |
What must be in place before the review report can be requested
A supervisor can ask for the review report under Article 6(5) at any time, so the report has to be assembled from records that already exist. The cards below cover the documents, histories and sign-offs the compliance lead should confirm are ready before a request arrives.
A current, documented framework
The framework itself must be written down and reviewed at least once a year, with extra reviews after major ICT-related incidents and after supervisory instructions or test and audit conclusions. Before a request arrives, the compliance lead checks that the framework document carries a version, a last review date and a named owner. Any gap between the last review and today is the first thing a supervisor will question.
Records of past reviews
The report must cover the status of corrective measures from earlier reviews, so each prior review needs its own record. The compliance lead checks that every past review has a dated report, a list of findings, and a remediation tracker showing what was closed, what is open and who owns each item. Missing records for earlier cycles make it hard to show that findings were followed up.
Complete incident register with root causes
A review triggered by incidents must list every ICT-related incident with its root cause analysis, so the register must be complete and not limited to major incidents. Before a request arrives, the compliance lead checks that each entry has a timestamp, a classification, a linked root cause analysis and a link to the corrective action it produced. Incidents that were logged but never analysed are a common gap.
Named function and management body approval
The report must state the responsible function, the reason for the review, its period and the date the management body approved the review. The compliance lead confirms which function owns the review, that the management body has a documented approval path, and that the minutes recording that approval can be retrieved. The approval date in the report must match the minutes.
Searchable electronic report template
Article 27 of Delegated Regulation (EU) 2024/1774 requires the report in a searchable electronic format that opens with the entity identity, group structure, services, critical functions and dependencies, followed by an executive summary. The compliance lead checks that a template with these sections exists, that it is kept up to date, and that a test export can be produced quickly. Simplified-regime entities follow the shorter structure in Article 41 of the same regulation.
Evidence index linking findings to sources
Each finding in the report needs a traceable source, such as a test result, audit note, incident record or policy version. The compliance lead builds an index that maps every finding to its evidence and to the remediation item it created, then spot-checks several entries against the source files. A finding without a traceable source weakens the severity analysis the report must include.
Who owns the review, who prepares the evidence and who issues anything external
The financial entity owns the ICT risk management framework and the review of it. The management body approves the framework review report and its approval date is stated in the report itself. The entity names the responsible function, decides the scope and reason for each review, and accepts the remediation measures, their dates, responsible functions and resource impact. When a competent authority asks for the report under Article 6(5), the entity submits it, and the entity answers for its contents.
- Ownership of the review: The entity sets the review period, the trigger (annual, after a major ICT-related incident, or following supervisory instructions or test and audit conclusions) and the responsible function.
- Approval: The management body approves the report and the approval date is recorded in it. Delegating the drafting is normal, but the approval stays with the body.
- Findings and severity: Staff inside the entity assess findings and decide severity. Simplified-regime entities self-assess severity under the shorter format.
- Remediation: The entity commits to remediation dates, owners and resource impact, and tracks the status of corrective measures from earlier reviews.
- Outsourced work: Drafting support, data collection and template work can be outsourced, but the entity keeps the decisions.
Before you engage anyone, confirm which person or body in your organization approves the report and who signs off findings.
An implementation partner such as DeployOpen prepares the systems, records, templates and evidence that the review draws on, on the basis of a written scope. Typical work includes organizing asset and configuration records, collecting logs and incident records, setting up tracking for remediation items, and preparing report templates that follow the sections Article 27 of Delegated Regulation (EU) 2024/1774 sets out. The partner does not approve the review, does not decide severity on the entity's behalf and does not issue or sign the report.
- Evidence preparation: Collecting configuration exports, change records, incident root cause analyses and test results from self-hosted platforms inside the entity's own environment.
- Templates: Building searchable electronic report structures that cover the entity's identity, group structure, services and dependencies.
- Remediation tracking: Maintaining the list of corrective measures, owners and dates so the entity can report their status.
- Documentation: Writing system descriptions and runbooks that the entity reviews and adopts.
- Boundary: The partner's work product is input to the entity's review. Named staff at the entity approve it, and the partner's name does not appear as approver.
Ask any partner to show in writing which artifacts it will produce and which decisions remain with your staff.
An independent auditor or assessor tests the framework when the entity commissions an audit or when a competent authority relies on independent assurance. The auditor reviews the framework and its evidence, forms its own conclusions and issues its own report. The auditor never signs or approves the entity's Article 6(5) review report on the entity's behalf, because that report is the entity's own statement to its supervisor. DORA does not create a certification scheme for the framework review.
- Independent testing: The auditor samples evidence, interviews staff and checks whether the review was performed as documented.
- Own report: The auditor's report is a separate document with its own scope and limitations.
- Independence: The auditor must not have designed or implemented the controls it tests, so it should not be the same firm that prepared the evidence.
- Outsourced scope: Entities sometimes commission an internal audit function or external auditor to test the review process, which is distinct from preparing the review report.
- Boundary: Do not present an auditor's report as the entity's review report, and do not ask an auditor to draft findings you then adopt without review.
Before engaging an auditor, confirm its ICT audit experience, its independence from your implementation partner and the exact scope of its report.
How to choose a consultant or auditor for DORA review support
A DORA review report is only as credible as the people who prepared it and the people who approved it. The cards below cover the checks to make before signing, from the firm's role in writing to who inside your organization stands behind the report.
Confirm the firm's role in writing
Ask whether the firm will prepare the review report and its evidence, or whether it will give independent assurance on the framework. These are different services. An implementation partner can prepare systems, controls and evidence for your review, but only your own management body and any independent assessor you engage can stand behind conclusions about the framework. Put the role in the signed scope so no one later assumes the firm certified anything.
Check independence before overlap
If the same firm designed your framework, runs your testing and might also review the framework, ask how it will separate those roles. Independence matters most where the reviewer is judging its own work. Request a written statement of any prior work for you in the last review period, and decide in advance whether a different party will validate the findings.
Ask for DORA experience with financial entities
Ask for named examples of prior DORA work with financial entities of your type, such as a bank, payment institution or insurer, and check whether those engagements covered the review cycle, not only the initial build. Ask how the team keeps current with the delegated regulations, including Delegated Regulation (EU) 2024/1774, and what it does when supervisory expectations change. Verify every credential in writing, and do not accept verbal assurances.
Require searchable electronic handover
Agree up front that findings, severity analysis, remediation records and source evidence will be delivered in a searchable electronic format, because the report must be submitted that way. Ask the provider to name the files, index and tracking tool it will use, and confirm that you retain full copies of everything, including the status of corrective measures from earlier reviews.
Name the internal approver
The report must state the management body's approval date, so the approval step belongs to your organization. Before work starts, name the person or body that will review the draft, the responsible function listed in the report, and the date the board will approve it. Make sure the external firm cannot approve the report on your behalf, and confirm who answers supervisor questions after submission.
Agree a fixed written scope
Before any work begins, agree in writing the review period, the triggers covered (annual, incident-driven or supervisory), the deliverables, the evidence sources, the acceptance criteria and the timeline. Ask for the quote to break down the fixed scope and separate any optional retainer work, such as follow-up testing or re-review. Any change to scope should go through a written change request, so the cost and effort stay visible.
Common questions about the DORA review report and outside help
How often must a DORA framework review take place?
Article 6(5) of DORA requires the ICT risk management framework to be documented and reviewed at least once a year, with microenterprises reviewing it periodically. The framework must also be reviewed after major ICT-related incidents and after supervisory instructions or conclusions from testing or audits. The yearly review is the baseline, not the only trigger. Entities should set the annual date in their governance calendar and define in advance who starts an extra review when an incident is classified as major or when an audit or penetration test produces findings that change the risk picture. Ask your compliance lead to confirm how your own triggers map to the calendar before the first cycle closes.
Does every entity have to produce a review report each year?
No. Under Article 6(5), the review report is submitted to the competent authority on request, so the document must exist and be ready, but it is not filed automatically each year. The practical consequence is that the review must be documented every cycle, with approval, findings, remediation and sources recorded, so that the report can be produced quickly when a supervisor asks for it. Article 4(3) directs supervisors to consider how proportionality was applied when they review the framework through these reports, so the reasoning behind your scope choices should be written down as well.
What must the review report contain for a simplified-regime entity?
Article 41 of Delegated Regulation (EU) 2024/1774 sets a shorter report for entities under the simplified framework. It must be in a searchable electronic format and cover the context of the entity, the reasons for the review, the review period, the responsible person, findings with self-assessed severity, remediation measures with dates, and the conclusions. Compared with the full Article 27 report, it omits the detailed group structure, service and dependency mapping and the status history of earlier corrective measures. Smaller entities should still record the approval date and the sources they relied on, because a short report with missing basic elements is easier for a supervisor to challenge than a complete one with brief wording.
Does a major ICT incident always require a full framework review?
A major ICT-related incident is one of the triggers in Article 6(5), so it requires a review of the framework, but the scope of that review depends on the incident. Under Article 27 of Delegated Regulation (EU) 2024/1774, an incident-driven review must list all ICT-related incidents covered by the review with their root cause analysis, so the report cannot simply describe the one event that prompted it. Teams should prepare an incident log that links each incident to its root cause and to any control change it produced. Whether the review also needs a wider scope than the incident is a judgment for the management body and the responsible function, and should be recorded in the report with its reasoning.
Can our own team write the review report without an outside partner?
Yes, the organization can write the report itself, and the regulation assigns the review and its approval to the entity's own governance. What an outside partner can do is prepare systems, controls and evidence so the team can produce the report on time. Cost and effort depend on how many systems are in scope, how current the asset inventory and incident log are, how many findings from earlier reviews remain open, and whether the entity must include group structure and critical service dependencies. Ask any provider to confirm, in writing, which parts of the report they draft, which parts management approves, and what evidence they hand over.
What can an outside partner cover, and what must stay in-house?
An implementation partner can help assemble the evidence behind the report, draft the findings and remediation tables, test that remediation has been implemented, and prepare self-hosted platforms and documentation that show their controls working. DeployOpen, for example, plans, implements, documents and supports self-hosted open-source platforms in the client's own infrastructure, and runs security testing whose results can feed findings. It does not issue audit reports or attestations, and it cannot approve the review or replace the management body's accountability. Independent auditors and supervisors make the assessments, and the organization owns the decision to accept residual risk. Scope, deliverables and timelines should be agreed in writing before work starts, and most engagements are fixed-scope.
What does the review need from management and the compliance team?
The review needs a named responsible function, a date on which the management body approves the report, and access to the incident, testing and audit records that feed it. Under Article 27 of Delegated Regulation (EU) 2024/1774, the report must state the approval date, the reason and period of the review, and the remediation measures with expected dates, responsible functions and resource impact, so management must agree on those commitments and the budget they imply. Compliance teams need to keep corrective actions from past reviews in a tracked register and to confirm sources for each finding. Effort rises with the number of open findings, the number of incidents in the period and the number of systems in scope.
How DeployOpen prepares systems and evidence for your review report
DeployOpen prepares the systems, records and evidence that a DORA framework review report draws on, inside your own infrastructure. The organization owns its framework and approves the report, and the review itself is performed and signed off by your own management body and functions.
How we scope
- Engagements are fixed-scope, with the review report deliverables agreed in writing before work starts.
- The written scope lists the platforms, services and ICT dependencies whose records feed the review period.
- Scope also confirms which past incidents, audit findings and supervisory instructions the review must address.
How we build
- We configure logging, change records and incident tickets so that each review period produces searchable, dated records.
- We set up tracking for remediation actions with owners, target dates and resource notes, matching the report's required fields.
- We document the platforms in scope, their group structure links and critical dependencies so the opening sections can be completed.
How we hand over
- We deliver a draft report template in searchable electronic format, populated from the evidence we prepared.
- We document how each figure was derived so your functions can verify it before the management body approves it.
- Handover includes a runbook for repeating the review each year and after major ICT-related incidents.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers for the platforms in scope.
- Retainers can keep remediation tracking and evidence collection current between annual reviews.
- Confirm with us in writing which review obligations stay with your internal functions and which may be supported externally.
