NIS2 Incident Response and Reporting — Incident, significant incident, near miss

In this lesson

Apply the article 6(6) definition of an incident to a real event, including events with no attacker behind them.
Separate an incident from a near miss, a cyber threat and a significant cyber threat, using the words of article 6.
Identify the single category that triggers the mandatory article 23 chain, and the categories that can only be notified voluntarily under article 30.
Run a five-question triage that puts any alert into the right category and records why.

Why the vocabulary decides the workload

Every reporting obligation in NIS2 hangs on a defined term. Article 23 makes reporting mandatory for one category only, the significant incident. Article 30 lets an entity notify incidents, cyber threats and near misses voluntarily. Article 23(2) attaches a separate communication duty to the significant cyber threat.

The error is costly in both directions. Treat every alert as reportable and analysts spend the first day of a real crisis writing forms. Treat a significant incident as routine and the entity has missed a legal deadline: article 32(7)(a)(ii) lists “a failure to notify or remedy significant incidents” among the infringements that are serious in any event, and article 33(5) applies that paragraph to important entities too. The first skill of an incident response lead is therefore reading article 6 precisely and turning it into a decision the on-call analyst can make at three in the morning.

Incident: a compromise, not necessarily an attack

Art. 6(6)

The directive defines an incident as follows: “‘incident’ means an event compromising the availability, authenticity, integrity or confidentiality of stored, transmitted or processed data or of the services offered by, or accessible via, network and information systems”. Four elements in that sentence do most of the work.

An event, with or without intent

Nothing in the definition requires malice. A firmware update that corrupts a database, a cooling failure that shuts down a server room, a mistaken firewall change that cuts a plant off from its scheduling system: each compromises availability or integrity. Article 21(2) confirms the breadth by requiring an all-hazards approach that aims to protect “network and information systems and the physical environment of those systems from incidents”. Teams that only open an incident when they suspect an attacker apply a narrower definition than the law.

Four properties, not three

The directive adds authenticity to the usual triad. A stolen code-signing key used to sign malware, or a forged token accepted by a partner: the data may be intact and available, but it is no longer what it claims to be.

Data or services

The compromise can affect data that is stored, transmitted or processed, or “the services offered by, or accessible via” network and information systems. An outage of a customer-facing service caused by a failure in your systems is an incident even if no record is touched.

Network and information systems, broadly

Art. 6(1)

Article 6(1) covers “any device or group of interconnected or related devices, one or more of which, pursuant to a programme, carry out automatic processing of digital data”. Programmable controllers and building management systems fall inside it: an incident on operational technology is an incident.

Compromising means it happened

In an incident, one of the four properties has actually been affected. If it has not, you are looking at a near miss or a threat.

Near miss: the event that did not land

Art. 6(5)

The definition mirrors the previous one: “‘near miss’ means an event that could have compromised the availability, authenticity, integrity or confidentiality of stored, transmitted or processed data or of the services offered by, or accessible via, network and information systems, but that was successfully prevented from materialising or that did not materialise”.

Two routes lead to a near miss. Either a control worked (a build pipeline rejects a tampered library before deployment), or luck intervened (a generator starts during a grid failure that would otherwise have stopped the data centre). In both cases nothing was compromised.

The boundary that matters is the one between a near miss and an intrusion caught early. Blocked at the door is a near miss. Caught inside is an incident, because the attacker's presence already compromises confidentiality or integrity. For the entities covered by Implementing Regulation (EU) 2024/2690, article 3(1)(e) goes further: a successful, suspectedly malicious and unauthorised access capable of causing severe operational disruption is a significant incident, and recital 39 gives the example of an attacker who “pre-positions itself” to cause disruption later.

A near miss never triggers the article 23 chain. Article 30(1)(a) allows essential and important entities to notify near misses voluntarily, and article 29 lists near misses among the information entities can exchange in sharing arrangements. Lesson m4l2 covers both.

Significant incident: the only mandatory category

Art. 23(1), 23(3)

Article 23(1) requires notification of “any incident that has a significant impact on the provision of their services as referred to in paragraph 3 (significant incident)”. A significant incident is therefore a subset of incidents. You cannot reach it without first passing through article 6(6).

Article 23(3) gives the test in two limbs: severe operational disruption of the services or financial loss for the entity, or considerable material or non-material damage to other natural or legal persons. Both limbs include the words “capable of”: an incident contained before it caused harm can still be significant if it could have caused it. Lesson m1l2 works through the test and the thresholds of Implementing Regulation (EU) 2024/2690.

Cyber threat and significant cyber threat

Art. 6(10), 6(11)

Article 6(10) borrows the definition of the Cybersecurity Act, article 2(8): “any potential circumstance, event or action that could damage, disrupt or otherwise adversely impact network and information systems, the users of such systems and other persons”. A cyber threat is potential by nature. Nothing in your estate has to be touched.

Article 6(11) defines the significant cyber threat as one “which, based on its technical characteristics, can be assumed to have the potential to have a severe impact on the network and information systems of an entity or the users of the entity’s services by causing considerable material or non-material damage”. A vulnerability being actively exploited in a remote-access appliance you run, with no sign yet of exploitation in your logs, is the classic case.

The category matters because article 23(2) requires entities, where applicable, to tell recipients potentially affected by a significant cyber threat what measures or remedies they can take (lesson m3l2), and because article 30 allows cyber threats to be notified voluntarily.

Large-scale cybersecurity incident: not your label

Art. 6(7)

Article 6(7) defines it as “an incident which causes a level of disruption that exceeds a Member State’s capacity to respond to it or which has a significant impact on at least two Member States”. The test is set at member-state level, so an entity never declares one; such incidents are handled under the national crisis frameworks of article 9.

The categories side by side

Category	Defined in	Has something been compromised?	Reporting consequence
Cyber threat	Art. 6(10)	No, potential only	Voluntary notification (art. 30)
Significant cyber threat	Art. 6(11)	No, but severe impact can be assumed	Communication to potentially affected recipients where applicable (art. 23(2)); voluntary notification
Near miss	Art. 6(5)	No, prevented or did not materialise	Voluntary notification (art. 30); sharing (art. 29)
Incident	Art. 6(6)	Yes	Voluntary notification if not significant (art. 30)
Significant incident	Art. 23(1), 23(3)	Yes, with significant impact	Mandatory chain of article 23(4)

A five-question triage

The definitions become usable as questions asked in a fixed order:

Has the availability, authenticity, integrity or confidentiality of data or of a service actually been compromised? If no, go to question 2. If yes, it is an incident: go to question 3.
Was there an event that could have compromised one of them but was stopped or did not materialise? Then it is a near miss. If there was only a potential circumstance, it is a cyber threat: ask whether it is significant under article 6(11) and whether article 23(2) applies.
Has the incident caused, or is it capable of causing, severe operational disruption or financial loss for the entity, or considerable damage to others? If yes, or if that cannot yet be excluded, treat it as significant.
Is the entity one of the types covered by Implementing Regulation (EU) 2024/2690? If so, test the incident against its articles 3 to 14 as well.
Whatever the answer, record the category, the reasons and the time of the decision.

The last step is the easiest to skip, and it is what a supervisor will ask to see: a decision that an incident was not significant is only defensible if it was written down when it was taken.

In practice

A fictional logistics company, an important entity, logs three events on one Monday morning. At 07:40 its warehouse management system is unavailable for 25 minutes after a failed storage firmware update, and trucks queue at the docks. No attacker is involved, but the availability of a service has been compromised: it is an incident, to be tested for significance under article 23(3).

At 09:15 a vendor advisory reports active exploitation of a flaw in the remote-access gateway model the company runs. Its logs show no exploitation. Nothing has been compromised: a cyber threat, on its technical characteristics probably a significant one. The team patches that afternoon and considers whether business customers who connect through the gateway need to be told what to do.

At 10:30 the build pipeline rejects a third-party library whose signature does not verify, and the release stops before deployment. The tampered component could have compromised the integrity of the customer portal, but the control prevented it: a near miss, which the company may notify voluntarily and share with its sector community.

Three events, three categories, each recorded with a timestamp and a one-line reason.

What a supervisor will ask

How does your procedure define an incident? The article 21(2)(b) incident handling policy, using the article 6 definitions rather than a narrower in-house wording.
How do you tell a near miss from an incident? A written rule with worked examples, including the intrusion caught early.
Show me the incidents you classified as not significant this quarter. The incident register: category, reasons, decision time and decision maker.
Who can classify an event out of hours? A documented delegation to named on-call roles.

Key points

An incident compromises the availability, authenticity, integrity or confidentiality of data or services. Malice is not required.
A near miss could have done so but was prevented or did not materialise. An intruder caught inside is not a near miss.
Only significant incidents trigger the mandatory article 23(4) chain. Near misses, cyber threats and other incidents can be notified voluntarily under article 30.
A significant cyber threat can oblige you to tell potentially affected recipients what they can do (article 23(2)).
Record every classification with its reasons and its time.