ICT incident reporting under DORA: timelines and templates

ICT incident reporting under DORA: timelines and templates

DORA’s ICT incident reporting regime is one of the most operationally demanding aspects of the regulation for in-scope firms. Unlike the existing notification frameworks in most EU member states — which require prompt notification of significant events without specifying precise content or format — DORA mandates a structured three-stage reporting process with specific timelines, defined content requirements, and standardised templates prescribed by Regulatory Technical Standards. For UK firms with EU-regulated entities, building the operational capability to meet these requirements is a prerequisite for DORA compliance that many firms underestimated during the implementation phase.

The classification threshold: what is a major ICT incident

The reporting obligations are triggered only by major ICT incidents — not every ICT disruption, however significant internally, must be reported to the competent authority. The Regulatory Technical Standards on incident classification set out the criteria that a firm must apply to determine whether an incident is major. An incident must be assessed against criteria across five dimensions: the number of clients affected; the duration of the disruption; the geographic spread (whether the impact is limited to a single jurisdiction or is cross-border); the data losses involved; including whether personal data or sensitive financial data has been compromised; and the criticality of the services affected, including whether payment processing or trading infrastructure has been impaired.

For most in-scope financial entities, an incident that causes significant disruption to a service delivered to a material number of clients for a period exceeding a defined threshold — typically two hours for tier-one services — will meet the classification criteria for a major ICT incident. Firms must have a documented classification methodology that can be applied consistently by the operational teams responding to the incident, not just by the compliance or regulatory reporting function after the fact. The classification decision must be made within a defined timeframe from first detection — the reporting clock starts ticking from the point of detection, not from the point at which the compliance team becomes aware of the incident.

Stage one: the initial notification

Once an incident has been classified as major, the firm must submit an initial notification to its competent authority within four hours of the classification decision, and in any event no later than 24 hours after the incident was first detected. The four-hour window from classification is the binding operational constraint — firms that take several hours to classify an incident after detection and then several more hours to prepare and submit the initial notification will routinely breach this requirement.

The content of the initial notification is defined by the Regulatory Technical Standards. The firm must provide: a description of the incident including the date and time of detection and the nature of the disruption; an initial assessment of the incident’s impact including the number of clients affected, the services disrupted, and any data losses; the immediate containment and recovery actions taken; and the firm’s initial assessment of whether the incident is likely to have cross-border impact or affect market integrity. The initial notification is not expected to be a comprehensive analysis — it is an alert that allows the competent authority to begin its own assessment and, where necessary, to coordinate with other authorities.

The practical challenge is that the initial notification must be prepared and submitted while the incident response team is simultaneously managing the incident itself. The firm must have pre-built notification templates that can be populated quickly, a designated regulatory notification team that operates in parallel with the technical response, and clear escalation protocols that ensure the decision to classify and notify reaches the right people without delay. Firms that rely on their compliance team to draft notifications from scratch during an active major incident will not meet the four-hour window.

Stage two: the intermediate report

Within 72 hours of the initial notification, the firm must submit an intermediate report to the competent authority. By this stage the firm is expected to have a more complete picture of the incident — its root cause if identified, its full scope, the recovery measures taken and their effectiveness, and the current status of the firm’s services. If the incident is ongoing at the 72-hour point, the intermediate report should describe the current state, the expected timeline for full restoration, and any workarounds in place.

The intermediate report must include an update on the classification criteria applied in the initial notification — confirming or revising the initial assessment of the number of clients affected, the data losses, and the geographic scope. Where the initial notification was submitted under time pressure with incomplete information, the intermediate report is the opportunity to correct any inaccuracies and provide a more precise account of the incident’s impact.

The 72-hour window from the initial notification is typically more manageable than the initial four-hour window, but it requires the incident response and regulatory reporting teams to maintain close coordination throughout the first three days of an incident. Where a major ICT incident extends over multiple days — as significant cyberattacks or infrastructure failures often do — the firm must continue to prepare the intermediate report while simultaneously managing ongoing recovery activities.

Stage three: the final report

Within one month of the incident being fully resolved, the firm must submit a final report to the competent authority. The final report is the most substantive of the three — it must include a full root cause analysis, a description of the permanent remediation measures implemented to prevent recurrence, an assessment of the actual impact of the incident including any client detriment and financial losses, and any lessons learned that have been incorporated into the firm’s ICT risk management framework. Where the root cause involved a third-party ICT provider, the final report must address the actions taken with respect to that provider, including any contract variations or service improvements agreed.

The final report is the document that will be most carefully scrutinised by the competent authority. An incident that was well-managed in the immediate response phase but for which the firm cannot produce a credible root cause analysis or a convincing remediation plan will attract supervisory attention. The quality of the final report reflects the quality of the firm’s post-incident review process — firms that conduct thorough reviews and make genuine improvements to their ICT risk management framework will produce better final reports than those that treat the post-incident review as a compliance exercise.

Significant cyber threats

DORA also requires firms to notify competent authorities of significant cyber threats — not just incidents that have actually disrupted services. Where a firm detects a credible and imminent threat to its ICT systems that could, if realised, constitute a major ICT incident, it must notify the authority promptly. This threat notification requirement is distinct from the incident reporting timeline — there are no prescribed stages for threat notifications, but the firm must act promptly and provide the authority with the information it needs to assess the threat and, where necessary, alert other firms who may face the same threat.

Interaction with UK notification requirements

UK firms operating EU entities under DORA must manage the interaction between DORA’s incident reporting requirements and the FCA’s existing SUP 15 notification framework for their UK operations. An ICT incident that affects both UK and EU entities will typically trigger notification obligations under both regimes simultaneously — a materially different process and timeline under each. The firm’s incident response plan must address this dual-notification scenario explicitly, identifying the content requirements and recipients for each notification, the team responsible for each, and the process for ensuring consistency between notifications submitted to different authorities.

Where a major ICT incident affects the UK parent entity and the EU subsidiary, the FCA’s notification under SUP 15 should typically be submitted at the same time as or shortly after the DORA initial notification to the EU competent authority — not as an afterthought once the DORA reporting cycle is underway. Coordinating both processes in parallel is operationally demanding but essential to avoid the appearance of treating one regulator as secondary.

Building the operational capability

Meeting DORA’s incident reporting requirements consistently requires investment in operational capability that most firms did not have before DORA. The prerequisites are: a documented incident classification methodology that is known and applied by the first-response teams; a pre-built notification template for each of the three stages; a designated regulatory notification lead who is part of the major incident response team, not a separate function that must be briefed; a clear escalation protocol from technical detection to classification decision to notification submission; and regular testing of the notification process, including exercises that simulate the time pressure of the initial four-hour window.

FD Capital places operational resilience professionals, heads of compliance and ICT risk specialists in FCA-regulated and dual-regulated firms where DORA compliance is a live obligation. The specific capability required to build and operate a DORA-compliant incident reporting process — combining regulatory knowledge with operational incident management expertise — is a defining criterion in appointments at firms navigating both the UK and EU frameworks.

Related Guides

• DORA vs FCA Operational Resilience: Comparing the Regimes
• Critical ICT Third Parties: What UK Firms Need to Know
• Important Business Services: How to Identify Them
• FCA Impact Tolerances: Setting, Testing and Reviewing
• DORA: What UK Firms Need to Know