Significant incident explained

What is a significant incident?

A significant incident is an Incident, one with serious consequences – longer outages, a large data leak or many affected users, for example. It is that severity which makes an incident reportable at all. The term is therefore the threshold, the point that decides whether the NIS2 reporting chain is triggered or not: an ordinary incident stays an internal matter, a significant incident becomes a duty towards the authority.

When an incident is “significant”

What counts includes the duration of the disruption, the number of people or customers affected, possible financial damage, the leaking of sensitive data and the effect on other entities or on public supply. Because NIS2 prescribes no rigid score and leaves it to your entity to judge significance from the circumstances, you should translate these factors into your own documented thresholds before the first real case – otherwise valuable minutes are lost to internal debate inside a 24-hour deadline that is tight enough already.

Decision checklist: is the incident significant?

One clear yes is usually enough to trigger the reporting chain. When in doubt: report.

• Serious operational disruption? A core service down for a longer period or heavily degraded → probably yes. A short glitch that fixed itself, with no customer impact → probably no.
• Substantial financial damage? Noticeable loss of revenue, a ransom paid or recovery costs for the entity → Yes. Negligible cost → No.
• Third parties affected? Customers, suppliers, other entities or public supply are touched → Yes. Contained purely internally → No.
• Sensitive data leaked? Personal or business-critical data has been exfiltrated or manipulated → Yes. No data access detectable → No.
• Many people affected, or a repeat? A large number of users affected, or a deliberate or repeated attack → Yes. An isolated case with no wider effect → No.

Consequence: the reporting obligations

Where a significant incident has occurred, the three-stage Reporting obligations apply, with an early warning (24 h), an incident notification (72 h) and a final report (one month). An incident that has actually occurred has to be kept apart from a significant cyber threat, which is a danger that has not yet caused harm.

Two cases, one threshold

A scenario: an online retailer notices that customer data from around 40,000 accounts has leaked through a vulnerability. Data leak plus many people affected – two clear yeses on the checklist. The team classifies the incident as significant within minutes and starts the reporting chain. A brief load spike in the web shop the day before, by contrast, stayed below every threshold, affected no customer and was merely logged internally. The same yardstick, two opposite results.

What you actually have to do

As soon as the checklist shows a yes, every minute counts. These steps belong in the sequence:

• Document the classification: note the time of detection and the decisive criterion briefly – that later evidences a timely assessment.
• File the early warning: report within 24 hours through the national channel your Member State provides (if you are in scope but not yet registered, the registration duty stands and has to be caught up).
• Contain the incident: isolate the affected systems and secure the evidence, in parallel with the reporting.
• Track the deadlines: plan for the incident notification after 72 hours and the final report after one month.
• Trigger the plan: activate your incident response plan so that roles and escalation take effect immediately.

Hesitate here and you risk fines: Article 34 sets minimum ceilings of at least EUR 10 million or 2 % of total worldwide annual turnover (essential entities) and EUR 7 million or 1.4 % (important entities), and Member States may set higher amounts. Clear criteria save exactly that time spent debating.

Further reading: Directive (EU) 2022/2555, criteria for significant incidents (Article 23)