NIS2 incident reporting starts with exposure context you already have

Once an organization has become aware of a significant incident, NIS2 leaves it no more than 24 hours to submit an early warning. No later than 72 hours, it has to send an incident notification with an initial assessment of severity and impact; for trust service providers that deadline is also 24 hours. A final report follows, as a rule no later than one month after the incident notification (NIS2, Article 23(4)).

This means that information about a service exposed to the internet — its owner, its open interfaces, its recent configuration changes — is too late to start collecting once the clock is running. NIS2 does not explicitly require a separate product for external exposure monitoring. But the content of the notifications requires establishing severity, impact and, as far as possible, the technical indicators of the incident quickly. A history of the external perimeter collected in advance gives facts for that assessment, though it does not replace the decision of the people accountable.

First you have to decide whether the incident is significant

The duty to notify covers significant incidents, not every technical event. Under NIS2, an incident is significant if it has caused or is capable of causing severe operational disruption of the services or financial loss for the organization; the second case is when it has affected or is capable of affecting other persons by causing considerable material or non-material damage (NIS2, Article 23(3)).

Here technology supplies the input data and the process makes the decision. A monitoring system can show that a new public service has appeared, that an open interface has changed, or that a known asset no longer matches its previous configuration. It will not determine on its own whether the event will lead to severe service disruption, financial loss or considerable damage to customers. That requires knowing what the system is for, which business processes it touches, which contractual obligations apply and what the actual consequences were.

For organizations covered by Implementing Regulation (EU) 2024/2690, the moment of awareness is defined more precisely: an organization is considered to have become aware of a significant incident when, after an initial assessment, it has reasonable certainty that such an incident has occurred (Regulation 2024/2690, Article 2). The Regulation applies in particular to the digital infrastructure and service providers it lists, not automatically to every NIS2 entity (Regulation 2024/2690, Article 1).

The practical conclusion: discovering an unusual internet-facing asset does not by itself start a notification as a significant incident. It should start an initial assessment that can be evidenced afterwards. Whether that process exists can be checked against specific signs:

• someone is assigned responsibility for classification
• the data sources are defined
• the time the signal arrived is recorded
• the basis of the decision — significant incident or not — is written down

What has to be in the first 24 hours

The early warning has to indicate, where applicable, whether the incident is suspected of being caused by unlawful or malicious acts and whether it could have a cross-border impact (NIS2, Article 23(4)(a)). At this stage the Directive does not require a completed investigation with a final root cause.

External exposure context helps separate what is known from what is assumed. If the team has an inventory and a history of changes, it can check:

• who owns the discovered service
• when it first became reachable from the internet
• which interfaces were observed before the event and after it
• which configuration changes were recorded
• which other external assets it is connected to

This does not prove malicious intent and does not establish cross-border impact. What it does is keep a guess from being presented as an established fact. The time a service was first discovered, for example, is the time of observation — not necessarily the time it was created or compromised. That limit should be preserved both in the internal assessment and in the notification.

Technically this part is covered by asset inventory, change monitoring and the event logs available. For entities falling under Regulation 2024/2690, the annex requires maintaining a complete, accurate, up-to-date and consistent inventory of assets, making changes traceable, and recording asset details including the owner (Regulation 2024/2690, Annex, point 12.4). The same annex provides for procedures and tools for monitoring and logging events (Regulation 2024/2690, Annex, point 3.2).

The remaining questions are answered by the process: who confirms significance, who separates fact from assessment, who approves the early warning and who sends it to the CSIRT or the competent authority. External perimeter monitoring does not do that.

What the notification at 72 hours requires

The incident notification has to update the information given in the early warning and provide an initial assessment of the incident, including its severity and impact, as well as the indicators of compromise where available — the technical signs of a possible breach (NIS2, Article 23(4)(b)).

This is where context accumulated in advance saves not an abstract analyst time but hours inside a fixed deadline. If the asset owner is already recorded, the team does not have to start by looking for the unit that can explain what the service is for. If a history of open interfaces has been kept, the state before and after the event can be compared. If configuration changes are traceable, they can be matched against logs and indicators of compromise.

That matching helps outline the technical scope: which external asset is affected, what changed on it and which connected systems need to be checked. But it is not the same as an assessment of the full impact. External observation does not by itself show whether internal processes were disrupted, data was lost, a service was stopped or customers were harmed. That information has to come from system owners, operational units and the response team.

It is useful to define in advance the minimum set of fields for an internet-facing asset record:

• accountable owner
• purpose
• date first observed
• available interfaces
• history of changes
• link to the service it supports

The Directive does not prescribe such a form. It is an engineering way to obtain faster the information needed for the initial assessment of severity and impact under Article 23.

A final report cannot be assembled from perimeter observation alone

The final report has to contain a detailed description of the incident, its severity and impact, the likely type of threat or root cause, the mitigation measures applied and ongoing, and the cross-border impact where there was one. If the incident is still ongoing at the time of the report, a progress report is submitted first, and the final report within one month of the completion of the incident handling (NIS2, Article 23(4)(d)–(e)).

A history of external exposure can support the timeline and show the changes that were observed. It does not establish the root cause without an investigation, does not describe every recovery measure and does not calculate the impact on the business. It is particularly important not to substitute correlation for a conclusion: a new interface appearing close in time to an incident does not prove that it was the cause.

NIS2 also requires notifying the recipients of the services without undue delay where a significant incident is capable of adversely affecting the provision of those services. In the case of a significant cyber threat, recipients that are potentially affected are informed, where necessary, of the protective or remedial measures available (NIS2, Article 23(2)). No monitoring tool determines who the recipients are, how the message is worded or when the right moment to communicate is: that is joint work by the service owner, incident response, the legal function and communications.

---

One external asset through the whole process

A useful check is not a presentation about monitoring, but walking a single external asset through the entire process — requirement by requirement, with a clear line between what technology delivers and what only the process can settle.

Determine whether the incident is significant (Article 23(3))

• Technical action — show the affected external assets, their owners, their interfaces and their history of changes
• Covered only by the process — assess the disruption of the service, the financial consequences and the damage to other persons; record the decision
• Source: NIS2, Article 23(3)

Submit the early warning within 24 hours (Article 23(4)(a))

• Technical action — provide a verified timeline of observations and of changes in exposure
• Covered only by the process — approve the assessment of malicious intent and of possible cross-border impact; send the message
• Source: NIS2, Article 23(4)(a)

Submit the notification with an initial assessment (Article 23(4)(b))

• Technical action — match assets, open interfaces, configuration changes, logs and available indicators
• Covered only by the process — determine severity and full impact, separating confirmed information from assessments
• Source: NIS2, Article 23(4)(b)

Maintain inventory and change traceability for entities under Regulation 2024/2690 (Annex, point 12.4)

• Technical action — check that the owner, the purpose of the asset and the history of changes are up to date
• Covered only by the process — assign responsibility for updating the inventory and reviewing it periodically
• Source: Regulation 2024/2690, Annex, point 12.4

Prepare the final report (Article 23(4)(d)–(e))

• Technical action — provide the technical timeline of external exposure and the changes that were observed
• Covered only by the process — establish the likely root cause and describe the impact, the response measures and the cross-border consequences
• Source: NIS2, Article 23(4)(d)–(e)

Notify affected recipients of the services (Article 23(2))

• Technical action — clarify which external systems and services are affected
• Covered only by the process — determine the recipients, the protective measures, the content and the order of communication
• Source: NIS2, Article 23(2)