DORA Major ICT Incident Reporting Checklist Template

Start the run as soon as an ICT-related incident is detected. The first task records the incident, the entity, the competent authority, the date of detection that every due date counts from, and the six people. Classification decides whether the reporting clock runs.

• Open the incident record and name the people — the entity’s incident reference code, the financial entity and its LEI, the competent authority, the date and time of detection (every due date counts from the date), whether the weekend and bank holiday rule applies to you, and the six people; later tasks are assigned from these fields
• Log the incident and start the timeline — what happened, when it occurred if known, when it was detected, how it was discovered, the services and systems affected, and whether it comes from an ICT third-party provider
• Check whether critical services are affected — ICT services or systems that support critical or important functions, financial services that need authorisation or are supervised, or a successful, malicious and unauthorised access to your systems (Article 6 of Delegated Regulation (EU) 2024/1772)
• Test the materiality thresholds — clients, financial counterparts and transactions, reputational impact, duration and service downtime, geographical spread, data losses and economic impact, each against its threshold in Article 9, using estimates where actual figures are not yet known
• Record the classification decision and its time — major or not major, the date and time of the decision, who decided and why; the four-hour limit for the initial notification starts here when the incident is major
• Record why the incident is not major and keep it under watch — the criteria and thresholds not met, the date to look again as the facts change, and the monthly check for recurring incidents that together may count as one major incident

On the day of detection or the next. Senior management hears of the major incident, the client and data protection questions are answered, and any other report or copy the law asks for is listed.

• Report the incident to senior management — what happened, the classification, the reporting time limits and the response so far
• Decide whether clients’ financial interests are affected — for example payments that failed or were delayed, funds that could not be reached, or costs clients may bear
• Tell affected clients about the incident and the measures taken — without undue delay, the incident and the measures taken to limit its effects, through the channels in your crisis communication plan
• Check whether personal data is involved — whether personal data was lost, altered, disclosed or made unavailable; the data protection officer decides whether a GDPR breach assessment starts
• Run the GDPR breach assessment on its own clock — the GDPR notice is separate from the DORA reports, with its own authority and time limit; use your data breach response process and record the link to this incident
• Brief the management body — a short first briefing now; the full account of impact, response and additional controls goes to it in Phase 7
• List the other reports and copies that are due — copies your Member State asks for under NIS2, payment-related incident rules for credit, payment and e-money institutions, group or ECB routes, insurers and any contract that requires notice

On the day the incident is classified as major: within four hours of classifying it and no later than 24 hours after becoming aware of it. Use the authority’s template and its secure channel.

• Confirm the time limits and the weekend rule for this incident — the latest time for the initial notification, and for the intermediate report once it is sent, and whether a limit that falls on a weekend or bank holiday moves to noon of the next working day for you
• Complete the initial notification in the authority’s template — the general information and the initial fields: reference code, detection and classification times, description, the criteria met, Member States affected, how it was discovered, its origin and whether a business continuity plan was activated
• Submit the initial notification — through the secure electronic channel your authority provides, or, if that is not possible, by other secure means agreed with the authority
• Record the authority’s reference code — the incident reference code the authority gives, quoted in field 3.1 of the intermediate and final reports, and the confirmation of receipt
• Resubmit through the authority’s channel if it asks — once the channel works again, send the same notification through it so it is linked to the later reports

Within 72 hours of the initial notification, even if nothing has changed, then an updated report when regular activities recover and whenever the status changes significantly.

• Update the impact figures — clients, counterparts and transactions affected, duration and service downtime, Member States, data losses and the functions and infrastructure affected, marked as actual or estimated
• Complete the intermediate report — the intermediate fields of the same template: occurrence and recovery times, how the criteria were met, type of incident, threats and techniques, areas and infrastructure affected, impact on clients’ financial interests, other authorities told, temporary measures and indicators of compromise
• Submit the intermediate report — at the latest 72 hours after the initial notification was submitted, linked to it in the authority’s channel; you may combine it with the initial notification if regular activities had already recovered and the time limits are met
• Send an updated intermediate report when regular activities recover — without undue delay, and in any case when regular activities have been recovered, with the recovery time
• Send further intermediate updates while the incident is open — an updated report each time the status changes significantly or the authority asks, and at least one a month until the final report; a correction goes in as a new version of the latest report
• Review the classification with the facts now known — if the incident at no time met the criteria and thresholds for a major incident, it is reclassified as non-major and the authority told in the template
• Submit the reclassification as non-major — the template with the type of submission “major incident reclassified as non-major” and the reasons in field 2.10; then mark the final report tasks not applicable

The final report is due when the root cause analysis is complete and the actual impact figures replace the estimates, whether or not every fix is in place.

• Complete the root cause analysis — the high-level, detailed and any additional root cause classification and the sequence of events that led to the incident
• Record when the root cause was addressed and the incident resolved — both dates and times, the actions taken, and the permanent resolution date if it differs
• Replace the estimates with actual impact figures — clients, counterparts, transactions, duration, downtime and data losses as finally measured
• Total the costs, losses and financial recoveries — the direct and indirect costs and losses listed in Article 7 of Delegated Regulation (EU) 2024/1772, leaving out day-to-day costs, upgrades and insurance premiums, and the recoveries shown separately
• Assess the information for resolution authorities — only for entities within Article 1(1) of Directive 2014/59/EU (for example credit institutions and investment firms): whether the incident posed a risk to critical functions or affected the resolvability of the entity or group; leave fields 4.10 and 4.11 blank if not, or if your entity is outside that Directive
• Check for linked recurring incidents — other incidents in the last six months with the same apparent root cause that together meet the major incident criteria, reported in aggregated form

No later than one month after the latest intermediate report. The senior manager signs off the report before it goes, but a sign-off never holds a report past its time limit.

• Draft the final report in the authority’s template — the root causes, when they were addressed and the incident resolved, the resolution, information for resolution authorities, costs, losses and recoveries, and any recurring incidents, with every earlier field brought up to date
• Check the final report against the earlier reports — identifiers unchanged, estimates replaced, amounts in thousands, the authority’s reference code in field 3.1 and the type of submission set to final report
• Sign off the final report — the senior manager confirms the report is complete and accurate, or says what to change
• Revise the final report and return it for sign-off — make the changes asked for, then ask the senior manager to change the decision to Approved; if the time limit is close, submit and send a correction later, or tell the authority before the limit
• Submit the final report — through the authority’s channel, linked to the earlier reports, no later than one month after the latest intermediate report
• Answer the authority’s questions and requests — questions on the reports, requests for an individual report, and, on request, the changes made after the post-incident review

The review of what happened and what changes, reported to the management body. The checklist halts at the approval in this phase; every report to the authority comes before it.

• Hold the post-incident review — whether procedures were followed and actions worked: the speed of the response and of judging severity, forensic analysis, escalation, and internal and external communication
• Agree the improvements, owners and dates — changes to ICT operations, the business continuity policy, controls, the incident process and the reporting itself
• Report the impact, response and additional controls to the management body — the incident, the reports made, the root cause, the costs and the improvements proposed
• Approve the post-incident review and improvement plan — the management body member named on task 1 approves the review and the plan, or sends it back; the reports to the authority are already made
• Rework the review and plan and return them for approval — address the reasons given, then ask the approver to change the decision to Approved, or to un-complete and complete the approval again

The lessons go into the ICT risk assessment and the incident process, and the incident closes when the improvements are done and checked.

• Feed the lessons into the ICT risk assessment — findings from this incident and from activating the continuity and recovery plans, as the basis for reviewing the ICT risk management framework
• Update the incident process and reporting playbook — classification steps, contact lists, template guidance, channel access and the people who can submit
• Track the improvements to completion — each action in the plan done, or moved with a reason recorded
• Check the improvements worked — a test, an exercise or monitoring evidence that each fix closes the root cause
• Close the incident record — reports, sign-offs, client notices, the review and the evidence kept together, and the incident marked closed in the log