Organisations implement Major ICT Incident Reporting by defining what qualifies as a major incident, detecting and triaging events quickly, and reporting within the required deadline to the relevant authority. They need clear severity criteria, escalation paths, evidence preservation, and post-incident review, so reporting is consistent, timely, and based on confirmed facts rather than early speculation.
What organisations need before they can report a major ICT incident
Implementation starts long before the first notification. Organisations need a documented classification model that separates major from non-major events, maps those thresholds to business services and supporting technology, and names who can make the reporting decision. Without that, teams either under-report because they wait too long for certainty, or over-report because every high-profile outage looks reportable.
The reporting rule also needs operational ownership. Security, IT operations, service owners, legal, compliance and incident commanders should all know who gathers facts, who approves the report, and who submits it. A good process is not just a template, it is a decision chain that works under pressure and survives shift handovers, vendor dependencies and incomplete telemetry.
How to move from detection to a defensible report
Fast reporting depends on fast triage. The organisation should capture the minimum facts needed to decide whether the event meets the major incident threshold, then preserve the evidence that supports that decision: timestamps, affected services, containment actions, user impact, and whether the event is ongoing. That same evidence trail reduces the risk of inconsistent or contradictory updates later.
Where the incident involves third-party platforms, cloud services or shared infrastructure, the reporting workflow needs a way to reconcile internal observations with supplier input. The reporting clock does not stop because a vendor has not yet confirmed root cause. Practitioners should work from confirmed impact and observed behaviour first, then refine the narrative as evidence improves.
For organisations that operate in regulated environments, the practical standard is often to report the early facts, not the final theory. That is why a strong process uses staged updates, clear confidence levels, and a post-report correction path. The organisation should be able to say what happened, what is affected, what is contained, and what remains unknown without guessing at the cause too early.
Making incident reporting consistent across teams and jurisdictions
major ict incident reporting is usually a governance problem as much as a technical one. The same event may trigger internal escalation, customer communication, regulatory notification and board-level visibility, each on different timelines. A workable implementation therefore maintains a single incident record that feeds multiple obligations, instead of letting each function build its own version of the facts.
That record should align to the organisation’s regulatory scope and incident taxonomy. The thresholds and deadlines differ by regime, so teams need a controlled mapping from incident severity to the relevant reporting obligation. For financial entities, EU Digital Operational Resilience Act (DORA) is a useful reference point because it ties incident reporting to broader ICT resilience and third-party risk expectations. For wider regulatory comparison, Global Cybersecurity Regulatory Map helps teams compare reporting clocks and scope across jurisdictions.
Organisations should also practice the handoff between operations and compliance. If the first responders cannot translate technical impact into a reportable business event, the process fails even when detection is strong. The same applies when a report must be revised after new evidence emerges, because consistency matters as much as speed.
Risk and Threat Considerations
Major incident reporting fails when organisations treat the deadline as a paperwork issue rather than a control. Delayed triage, vague severity criteria or poor evidence preservation can cause late filing, incomplete disclosure or conflicting statements across functions. That creates regulatory exposure and can also weaken trust with customers, supervisors and internal leadership.
Failure mechanism: Teams wait for root cause before reporting, rely on fragmented logs, or let vendors control the timeline for confirmed facts, which can push the organisation past the required clock.
Impact: The organisation may miss mandatory deadlines, understate scope, or issue inconsistent updates that complicate remediation, supervision and later review.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while DORA and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| DORA | N/A — Major ICT Incident Reporting | Covers the incident reporting obligation central to the question. |
| Recommendation — Define major-incident thresholds and run a deadline-based reporting workflow. | ||
| NIST CSF 2.0 | RC.CO-03 — Personnel and Stakeholders are Informed of Incident Response Plans, Roles, Responsibilities, and Status | Supports coordinated incident communications and reporting during major events. |
| Recommendation — Assign clear reporting roles and issue status updates from one incident record. | ||
| ISO/IEC 27001:2022 | A.5.24 — Information security incident management planning and preparation | Requires a prepared incident-management process, including reporting readiness. |
| Recommendation — Prepare incident classification, escalation and reporting procedures before incidents occur. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Supports timely review and reporting of evidence used to substantiate incident decisions. |
| Recommendation — Review event evidence quickly and report substantiated incident facts through defined channels. | ||
Practitioner Guidance
What to prioritise: Build the incident classification and reporting decision path before you need it. The first win is not a larger response team, it is a shared threshold model that lets responders decide quickly whether the event is reportable.
What to verify: Confirm that the process can produce a report from partial but defensible facts. Practitioners should verify that timestamps, service impact, containment steps and ownership are captured in one place, because those are the details most often needed for the first submission and any subsequent update.
Decision rule: If the event is plausibly major, report on confirmed impact and state uncertainty explicitly rather than waiting for perfect attribution. That keeps the organisation inside the deadline while preserving room to refine the narrative later.
Practitioner takeaway: The best reporting programmes are designed for decision-making under uncertainty, not for retrospective perfection, so they privilege speed, evidence and consistency over speculation.
Related resources from NHI Mgmt Group
- Why does DORA force organisations to integrate ICT risk, supplier oversight, and incident reporting instead of treating them separately?
- Why do mandatory cyber incident reporting rules change how organisations prepare for major attacks?
- How does Major ICT Incident Reporting work?
- Major ICT Incident Reporting