DORA post-incident reviews and root cause analysis

What DORA post-incident review and root cause analysis require from your organization

A financial entity that has just closed a major ICT-related incident must be able to show its competent authority a post-incident review and a root cause analysis. Article 13(2) of DORA requires a post-incident review after a major ICT-related incident disrupts core activities, and the final incident report under Article 19(4) can only be filed once the root cause analysis is complete and actual impact figures replace estimates. The organization owns that review and its conclusions, including who decided what went wrong and which changes follow. An implementation partner can prepare the process, templates, evidence folders and system logs that make the review credible, but it does not assess compliance. DORA sets no certification scheme, so the only judgment that matters comes from the competent authority and its supervisors, who use their Article 50 powers to test what the entity produced.

What the review must cover varies by entity. A small firm with a handful of ICT systems and one hosting provider can run a compact review with a short timeline and a single accountable manager. A larger group with many critical functions, several intra-group services and multiple external providers needs a review that traces the incident across each dependency and records how each provider contributed. The number of incidents in the reference period matters too, because a review that finds an earlier, similar event has to connect it to the current root cause. Before the next major incident, confirm with your competent authority how it expects reviews to be documented, and check whether your provider contracts give you the logs, timelines and forensic access the review will need.

How the review moves from incident closure to a final report

The sequence turns a contained incident into a documented root cause, a review that tests the response, tracked corrective actions and a final report built on actual impact figures. Each phase hands a defined output to the next, so nothing is reported on estimates once the facts are known.

Confirm incident closure and freeze the record
The incident owner confirms that service has been restored, that the affected functions are stable and that no open containment tasks remain. The incident record, timeline, chat logs, tickets and forensic artifacts are then locked with a version and timestamp, and evidence is stored securely under the entity's retention rules. Closure is complete when the incident manager signs the closure record and the evidence index lists every source that the later analysis will cite.
Establish the actual impact and timeline
Operations, finance and the affected business owners replace the estimates used in earlier notifications with measured figures: downtime, affected clients and transactions, data affected and recovery costs. The response team reconstructs the sequence of detection, escalation, containment and recovery against the entity's own procedures. The output is a validated impact statement and a reconciled timeline, which become the inputs for the root cause analysis and the final report.
Complete the root cause analysis
The security and platform engineers, with the owners of the affected ICT service, work from the timeline and forensic results to identify the underlying cause, the contributing factors and why existing controls did not prevent or limit the event. Article 17 expects root causes to be identified, documented and addressed to prevent recurrence, so the write-up must separate the trigger from the systemic weakness. The root cause write-up is complete when a reviewer outside the incident team has checked that the evidence supports each conclusion.
Run the post-incident review
The review, led by someone independent of the response, assesses whether procedures were followed and whether actions were effective. Under Article 13(2) it covers the promptness of response, the quality and speed of forensic analysis, and escalation and communication. The review team compares performance against the entity's policy and records gaps as findings, each linked to evidence. The output is a signed review report that states its conclusions and the sources it relied on.
Register and track corrective actions
Each finding and each root cause action becomes an entry in an action register with a named owner, a planned change, the affected control or ICT asset and a verification method. Changes to the ICT risk management framework, controls, configurations or contracts are recorded alongside the incident they address. Actions are closed only when the change is verified, and the register shows the status of earlier review actions, which the review report must carry forward. Ask your competent authority how it expects changes to be shared on request, and confirm the timelines in your own policy.
Issue the final report under Article 19(4)
The final report is prepared once the root cause analysis is complete and the actual impact figures replace the estimates in the intermediate report. It states the root cause, the impact measured, the recovery actions taken and the corrective actions planned or completed, and it is submitted through the reporting channel the entity uses for its competent authority. The report is ready to submit when the incident owner, the root cause reviewer and the accountable senior manager have each approved the figures and conclusions in writing.
Feed lessons into the framework review
The incident and its review are added to the ICT risk assessment, the monitoring of the resilience strategy and the pattern analysis for recurring incidents. Senior ICT staff report the outcome to the management body, which supports the yearly reporting that Article 13 requires. The output is an updated risk register entry, a note in the framework review material and a record that the management body received the findings. Confirm with your own governance calendar how and when this reporting happens.

What root cause analysis must establish in the final report

Article 17 requires root causes to be identified, documented and addressed so that incidents do not recur. The cards below set out what a final report should be able to show, from the primary cause through to the corrective actions and the pattern checks that follow.

Primary cause versus contributing factors

Separate the one condition that started the incident from the factors that made it worse or slowed recovery, such as a delayed alert, an untested failover or an unclear escalation path. Name the primary cause in one sentence so that corrective actions target it directly. Check that contributing factors are recorded too, because they often point to weaknesses in detection or response that the primary cause does not reveal.

Linking the cause to affected services

Trace the root cause to each ICT service and critical or important function it disrupted, using the entity's own service and asset records. A cause in a shared component can affect several functions at once, and the report should say which ones. Confirm that the mapping matches the impact figures used in the final notification, since a mismatch will be noticed by the competent authority.

Documenting the evidence trail

Keep logs, forensic images, timelines, change records and decision notes that support each statement in the root cause analysis. The analysis should let a reviewer follow the path from symptom to cause without relying on memory. Retention must follow the storage and retention rules for incident evidence, so confirm which systems hold the records and for how long they are kept.

Tracking corrective actions to closure

Each root cause should lead to named corrective actions with an owner, a due date and a verification step. Record when each action is closed and how its effect was tested. Open actions from earlier reviews must also appear in later reports, so that a review shows whether past commitments were delivered and whether the same weakness remains.

Matching against earlier incidents

Compare the root cause with the incident register to see whether the same cause appeared before. A repeat cause suggests the earlier fix was incomplete or never delivered, and it may bring the incident within the recurring-incident analysis. Record the match in the report and feed it into the ICT risk assessment so that the pattern is reviewed at framework level.

How long to keep incident evidence and how to store it securely

Article 22 of Delegated Regulation (EU) 2024/1774 sets the rule for incident evidence: keep it no longer than necessary, store it securely, and match the protection to the criticality of the affected functions while staying consistent with legal retention requirements. That combination matters for post-incident reviews because the evidence you keep is what an assessor will later use to test whether procedures were followed, whether forensic analysis was timely and quality-assured, and whether the root cause analysis in the final report holds up. The rule is not a retention period. Your organization must set one, and the period must be defensible on both ends: long enough to support the review, the root cause analysis and any follow-up questions, and no longer than there is a reason to hold it. In practice, start with an evidence register for each major incident that lists what was collected, where it sits, who owns it, and which legal or supervisory reason justifies keeping it. Typical items include detection and alert logs, forensic images and memory captures, chat and bridge call records, decision logs from the crisis team, copies of notifications sent to the competent authority, and the working files behind the root cause analysis. Classify each item by the criticality of the function it touches. Evidence from a payment or core banking platform will usually warrant tighter access control, encryption and separation from general file shares than evidence from a low-impact internal tool, and the register is where that proportionality becomes visible to an auditor. Storage needs decisions as well as technology. Confirm with your legal counsel which retention periods apply to incident records under the national law of each member state where you operate, and confirm with your competent authority what they expect to see on request, because DORA itself does not supply a figure you can copy. Ask whether those periods also cover the records a supervisor may request during the post-incident review, and whether personal data inside logs triggers separate limits under GDPR. Then check the practical side: write-once or immutable storage for forensic material, encryption keys held separately from the data they protect, tested restore procedures, and a documented deletion step that runs when the period ends. Self-hosted platforms inside your own infrastructure can host this store, but the retention schedule, access rules and deletion records remain your organization's responsibility.

Who owns the review, who prepares the evidence and who assesses it

The financial entity owns the post-incident review. Under DORA, the obligation to review, to identify root causes and to act on the results sits with the entity and its management body, not with any vendor. The ICT incident owner is usually the senior ICT staff member who runs the incident process day to day and who reports to the management body at least yearly. This person decides whether an incident has disrupted core activities, signs off the review report, approves corrective actions and confirms the root cause analysis that goes into the final report.

Review decisions: Confirm that the review was triggered after a major ICT-related incident and record the scope of what it covers.
Root cause sign-off: Approve the root cause analysis before it is used in the final report to the competent authority.
Corrective action ownership: Assign named owners, deadlines and status tracking for each action that came out of the review.
Management body reporting: Make sure lessons and open actions reach the management body through the regular ICT reporting line.
Authority communication: Answer any request from the competent authority on changes resulting from the review.

Before the first major incident, ask who in your organization holds each of these decisions and whether the management body has approved that allocation in writing.

What must be in place before a post-incident review can be defended

A post-incident review is only as credible as the records behind it. The five items below are the working base that lets a review show whether procedures were followed, whether actions worked, and whether root causes were fixed. Check each one before the next major incident, not during it.

Documented ICT incident management process

Article 17 requires a defined process to detect, manage and notify ICT-related incidents, and the process must be written down before an incident occurs. A review cannot judge whether procedures were followed if no approved procedure exists. Check that the process names owners for each stage, sets escalation paths, and was approved by the body responsible for the ICT risk management framework. Confirm the version in force on the incident date, because reviewers will compare the actual response against that version.

Recording mechanism for all incidents

Article 17 also requires every ICT-related incident and significant cyber threat to be recorded, including minor ones that never reach reporting thresholds. Reviews of major incidents depend on this register to show patterns and prior occurrences. Check that the register captures timestamps, classification, affected functions, and links to tickets and forensic records. Ask whether entries can be edited after closure and whether changes are logged.

Review template covering mandatory items

Article 13(2) sets the questions a post-incident review must answer, including promptness of response, quality and speed of forensic analysis, and escalation and communication. Article 27 of Delegated Regulation (EU) 2024/1774 adds planned developments, conclusions, status of corrective measures from earlier reviews, and the list of incidents with root cause analysis. Build a template with a field for each item, so no required question is skipped. Confirm the template is approved and that reviewers cannot close a review with blank sections.

Retained evidence store with access controls

Incident evidence such as logs, forensic images and communications must be stored securely and kept no longer than necessary, while staying consistent with legal retention rules. Reviews often fail because the evidence has been rotated or deleted before analysis finishes. Check that the store has defined retention periods per incident class, restricted access with logged reads, and integrity controls. Ask who can authorize deletion and how legal holds are applied.

Contact list for threat detection and vulnerability

Article 22 of Delegated Regulation (EU) 2024/1774 requires a list of internal and external contacts for threat and anomaly detection and vulnerability management. During a review, reviewers will ask who was called, how fast, and whether those parties were able to help. Check that the list names roles and a primary and backup person for each, includes key ICT providers and the national authority channels, and is tested at least once a year. Record the date of each check.

Questions teams ask about DORA post-incident reviews

Does DORA require a post-incident review for every ICT incident?

No. The review under Article 13(2) follows a major ICT-related incident that disrupts core activities. Minor incidents still have to be recorded and analysed under the incident management process, and their root causes still have to be identified and addressed, but they do not each trigger a formal post-incident review. Your incident classification decides which events cross the threshold, so the classification criteria and the record of each decision should be documented before an incident occurs. Ask your competent authority or auditor to confirm how they read the trigger for your entity type.

Can our own team run a DORA post-incident review without outside help?

Yes, the regulation places the duty on the financial entity, and the management body remains accountable for the outcome. Many teams run the review internally because they hold the logs, the timeline and the decisions. Outside help is usually considered for independent challenge, for forensic depth that the internal team lacks, or for preparing the review report and the supporting evidence. An implementation partner can prepare the templates, the evidence set and the workflow, but it cannot sign off the review or issue an assessment result. Decide early who chairs the review and who approves it, so independence is clear to the auditor.

How does the effort of a post-incident review grow with incident count and system scope?

Effort grows with the number of systems, services and third parties touched by the incident, and with how many decisions need to be reconstructed from records. A single incident confined to one application with clean logs is far less work than one that crosses shared infrastructure, several providers and manual workarounds. The review must also cover the status of corrective measures from earlier reviews and list all related ICT-related incidents with their root cause analysis, so a backlog of unresolved actions adds work even when the new incident is small. Ask for a scope estimate that states the number of systems, providers and open actions you expect the review to cover.

What does the post-incident review need from the incident response team?

The review needs complete, time-stamped records from the people who ran the response. In practice, the team must supply:

A timeline of detection, triage, escalation, containment and recovery, with the decision owner for each step
Forensic analysis outputs, including how quickly they were produced and their quality
Communication records with clients, the competent authority and any ICT providers involved
Notes on which procedures were followed, skipped or found unworkable

If these are not captured during the incident, reconstructing them later is slower and less reliable. Agree a short incident record template in advance and assign someone to keep it current during the response.

Will the competent authority approve our post-incident review?

No. Competent authorities supervise compliance, and DORA does not provide for them to approve or certify post-incident reviews. Under Article 13(2), entities other than microenterprises communicate the resulting changes to the competent authority on request, so the authority may ask to see the review and the actions taken, and it may challenge them. Your own management body remains responsible for the content. Prepare the review so that it stands on its own evidence, because a supervisor will test whether the findings and corrective actions are credible rather than accept a summary.

How does a post-incident review connect to the recurring incident test?

The two work from the same records. The recurring incident test asks whether minor incidents with the same root cause happen repeatedly within a six-month window, and the post-incident review checks whether the root cause analysis actually prevented recurrence. Article 17(2) requires root causes to be identified, documented and addressed, and Article 22 of Delegated Regulation (EU) 2024/1774 requires analysis of significant or recurring incidents and their frequency. A review that finds a root cause already seen in earlier incidents should say so explicitly and track whether the earlier corrective measure failed. Keep one incident register that both processes read from, so a recurrence does not get analysed twice with different conclusions.

How long must we keep incident evidence after a review?

DORA does not set one fixed period. Under Article 22 of Delegated Regulation (EU) 2024/1774, incident evidence must be kept no longer than necessary, stored securely, proportionate to the criticality of the affected functions and consistent with legal retention requirements. In practice, this means your retention schedule must balance two pressures: keeping enough evidence for supervisory requests and later reviews, and not holding personal or sensitive data longer than needed. Confirm the specific periods with your legal team and your data protection officer, since other laws may apply to the same records.

What to confirm with your competent authority and counsel

Before you finalize your post-incident review template, confirm with your competent authority the format it expects for the review and the root cause analysis that feeds the final report. DORA sets the content the review must cover, including promptness of response, the quality and speed of forensic analysis, and escalation and communication, but the practical layout, the level of detail for root causes, and the way evidence is referenced are matters your supervisor may shape through its own expectations or supervisory dialogue. Ask whether it has a preferred template, whether it expects the review to be submitted or only held available, and how it wants the status of corrective measures from earlier reviews to be presented. Record the answers in your ICT-related incident management policy so the reviews your teams produce later are consistent with what the authority has already seen.

Next, confirm how the authority wants resulting changes communicated when it asks for them. Article 13(2) requires entities other than microenterprises to communicate the changes that follow a review to the competent authority on request, so the request itself is the trigger. Ask who the named contact is, what period the authority usually allows for a response, and whether it wants a summary, the full root cause analysis, or both. Ask counsel to check whether any of these communications also touch confidentiality or legal privilege, since root cause analysis can contain sensitive detail about vulnerabilities and third-party failures.

Finally, plan for the pending Digital Omnibus proposal COM(2025) 837 of 19 November 2025, which would amend Article 19 so that major incident reports and voluntary threat notifications go through a single entry point under NIS2. Procedure 2025/0360(COD)) was still awaiting committee decision as of October 2026, so the reporting route and timing that apply to you may change. Ask your authority and counsel which entry point will apply if the proposal is adopted, whether your post-incident review cycle needs to change, and how you will document that the review and final report were produced under the rules in force at the time of each incident.

How DeployOpen prepares incident records, reviews and evidence for DORA

DeployOpen helps financial entities set up the systems, records and evidence that a post-incident review and root cause analysis depend on. We prepare the material and documentation; the organization owns its incident process, its conclusions and its regulatory reporting.

How we scope

Engagements are fixed-scope, with the systems, incident types and review deliverables agreed in writing before work starts.
The written scope names which self-hosted platforms, logs and ticketing sources feed the incident timeline and root cause record.
Ongoing support for review cycles and evidence upkeep can be added as a retainer once the initial scope is delivered.

How we build

We configure centralized logging and ticket records so each major incident has a timeline that can be reconstructed afterward.
We set up evidence storage with access controls and retention settings that the organization defines against its legal obligations.
We document the review template covering response promptness, forensic analysis quality, escalation and communication, and resulting changes.

How we hand over

We deliver the review procedure, templates and root cause record structure as documented, editable artifacts owned by the client.
We walk the client's incident, risk and compliance staff through how to run a review and log the lessons learned.
We identify which review outputs the competent authority may request on demand, so the organization can locate them quickly. Confirm the expected format with your supervisor.

How we support

Retainers can cover upkeep of runbooks, evidence stores and review templates as the platforms change over time.
We can run security testing that produces findings feeding back into the ICT risk assessment after an incident.
Independent auditors and supervisors assess the outcome. DeployOpen prepares the systems and evidence but does not issue reports or certifications.