In this article, we look at NIS2 from the perspective of monitoring: what an organization needs to see, what data it must be able to analyze, and why simply having security tools in place does not yet mean operational readiness.
Table of Contents
What is NIS2?
NIS2 is an EU directive that introduces minimum cybersecurity requirements for organizations operating in sectors that are important for the economy and the functioning of society.
The word “minimum” is important here. NIS2 does not describe an ideal security model. It defines the baseline level of expectations — the point below which an organization should not fall.
The directive has two main goals:
- to increase organizations’ resilience to cyberattacks,
- to harmonize cybersecurity approaches across European Union member states.
Until now, similar obligations have often been interpreted differently across countries and organizations. NIS2 aims to bring more consistency to this area, so that companies in Poland, Germany, Spain and other member states operate according to a common set of rules — especially when it comes to risk management, incident monitoring and reporting.
What does NIS2 actually change?
One of the most important changes is the expansion of the range of organizations covered by the regulations. Previously, most attention was given to critical infrastructure — sectors whose disruption could directly threaten the functioning of the state or the safety of citizens. NIS2 goes further and also covers organizations that may not qualify as critical infrastructure, but still play an important role in maintaining the continuity of social and economic processes.
The second major change is management responsibility. Cybersecurity is no longer only a task for IT, SOC teams or administrators. Technical teams are still responsible for implementation, configuration and day-to-day operation of security tools, but responsibility for the effectiveness of the entire risk management system also sits at the management level. Saying “we have a SOC team, they handle it” is no longer enough. An organization must be able to demonstrate that cybersecurity is managed consciously, systematically and in a way that can be documented.
The third change concerns monitoring itself. NIS2 requires a risk-based approach, effective incident handling and the ability to demonstrate that the measures taken are working. In practice, this means having monitoring and data retention capabilities that make it possible to reconstruct the course of an incident, assess its scale and prepare reliable reporting.
The fourth element is consequences. NIS2 introduces significant penalties and strengthens organizational accountability for failing to meet the required obligations. This means that cybersecurity is no longer only an operational issue — it becomes a business, legal and reputational matter as well.
Who does NIS2 apply to — essential and important entities
The directive divides organizations into two main categories: essential entities and important entities.
Essential entities are organizations operating in sectors of particularly high importance for the functioning of the state, the economy and society. In practice, this includes, among others:
- the financial sector, including banks and financial institutions,
- healthcare,
- water supply and wastewater infrastructure,
- public administration,
- organizations processing large volumes of data – this also includes entities in the area of digital infrastructure and ICT service management, such as cloud service providers, data centres, DNS providers, TLD registries, CDN providers, managed service providers, managed security service providers and trust service providers.
- other entities responsible for services necessary for the daily functioning of society.
Important entities are organizations that may not always qualify as critical infrastructure, but still play a significant role in the continuity of economic and social processes. This group includes, among others:
- digital service providers,
- companies in the food production sector,
- logistics companies,
- postal and courier operators,
- organizations supporting key supply chains.
This distinction matters operationally, as the scope of obligations and supervision may vary depending on the category. At the same time, both groups are covered by the directive’s requirements. In many cases, the argument “we are not critical infrastructure, so this does not apply to us” is no longer valid.
What does NIS2 mean by monitoring?
One of the most common misunderstandings around NIS2 is equating monitoring with simply collecting logs. But recording information about an event is only the starting point. Monitoring in the context of NIS2 should enable the detection, analysis and handling of security incidents. An organization must know not only that something happened, but also what it means for systems, data, users and the business.
First, monitoring should support incident detection and resolution, not just event recording. The fact that an event has been captured in logs is not enough. What matters is whether the organization can interpret it, assess its significance and take appropriate action.
Second, monitoring should operate continuously. In practice, this also means accounting for the potential failure of monitoring systems themselves. If one data source becomes unavailable, the organization should still be able to reconstruct the course of events using other independent sources.
Third, monitoring must support risk and impact assessment. In the event of a breach, an organization needs to determine not only that a compromise occurred, but also whether data was exfiltrated, which systems were affected, how long the attacker’s activity lasted and what its actual impact was.
Fourth, NIS2 requires the continuous development and verification of procedures. This includes both self-assessment — regularly checking whether internal mechanisms work as intended — and external audits that confirm the system operates according to its assumptions.
Fifth, full visibility of the environment becomes critical. It is not enough to focus only on workstations, servers or systems where an EDR agent can be installed. Networks also contain devices that have access to infrastructure but are not covered by traditional endpoint protection — such as printers, IoT devices, industrial systems or network infrastructure components.
Such devices can also become an entry point for an attacker or be used for further movement across the network. Since they cannot always be protected with an agent, organizations must rely on other mechanisms — primarily network traffic visibility, behavioral analysis and anomaly detection.
Monitoring should therefore make it possible to correlate events: to show where an incident started, how the activity developed across the network and which systems were affected by the attacker’s actions. Anomaly detection is also important, as unusual behavior is often the first sign that something unwanted is happening in the network. Business context is another key element. An organization must be able to answer not only the question “what happened?”, but also “what does it mean for the business, customers, data and services?”. Without this context, it is difficult to properly assess the scale of an incident and prepare a reliable notification.
The final element is the credibility of evidence. Logs and monitoring data must be complete, verifiable and useful for analysis. Otherwise, an organization may know that an incident occurred, but still be unable to prove its timeline, scope or consequences.
Incident reporting deadlines: 24 hours, 72 hours, 30 days
One of the most practical NIS2 requirements is the set of incident reporting deadlines. They clearly show how important detection speed, data analysis and effective cooperation between teams really are.
The first deadline is 24 hours — early warning. Within this timeframe, after becoming aware of a significant incident, the organization should submit an initial notification. At this stage, a full analysis is not yet required. The goal is to signal that an incident has occurred and, where possible, indicate whether it may result from unlawful or malicious activity and whether it could have a cross-border impact.
The second deadline is 72 hours — incident notification. Within this timeframe, the organization should submit a more detailed notification, including an initial assessment of the incident’s severity, impact and potential consequences. If available, this may also include indicators of compromise.
The third deadline is 30 days — final report. This report should include a description of the incident, the corrective actions taken, an assessment of their effectiveness and information on how the organization intends to reduce the risk of similar incidents in the future.
These deadlines are especially demanding for organizations that lack full visibility of their environment. If a team learns about an incident late, lacks access to data or has to manually collect information from multiple systems, meeting the 24/72/30 framework becomes very difficult.
Stages of incident response
Reporting deadlines are directly linked to the stages of incident handling.
The first stage is threat detection and identification. Monitoring systems capture symptoms, the team analyzes alerts, separates real incidents from false positives, correlates events and classifies their significance. This is where it becomes clear whether the incident is detected early or only after it has already spread across the organization.
The second stage is technical response. This includes actions such as isolating the affected system, securing additional logs, collecting information from different sources and limiting the further impact of the incident. At this stage, the organization should already be able to determine what it is dealing with and what the potential scope of the event may be.
The third stage is remediation. These are actions aimed at eliminating the root causes of the incident: patching vulnerabilities, changing configurations, updating security rules, correcting permissions or redesigning a process that proved vulnerable to abuse. This stage should not happen in chaos — the rapid technical response is meant to limit the damage, while remediation should address the underlying causes.
The fourth stage is the final report. The organization summarizes what happened, what actions were taken, what their effects were and what will be changed to prevent a similar situation from happening again in the future.
What makes NIS2 requirements difficult to meet today?
In practice, the biggest challenge is not awareness of the requirements themselves, but the operational ability to meet them. NIS2 requires fast response, while many organizations still operate in environments where data is dispersed, teams work in silos and the full picture of an incident has to be assembled manually.
The first challenge is the sheer volume of data. Logs from firewalls, servers, applications, endpoints, security systems and network devices create an enormous stream of information. Most of it describes normal, everyday communication. The challenge is to find the signals that truly indicate a threat within all that noise.
The second problem is data silos. Network logs are stored in one place, security data in another, user activity somewhere else, and business information elsewhere again. A SOC team may see an alert, but not immediately know how much data was actually transferred, where it went and whether the event affected critical systems. The time needed to obtain access, collect data and manually compare information can be critical.
The third challenge is the lack of people who have a complete view of the environment. A SOC specialist understands detection and response mechanisms, but may not know the detailed network topology. The network team knows how the infrastructure is built, but does not always work with the same data as the security team. People who combine network expertise, security knowledge and an understanding of the organization’s business context are rare.
The fourth problem is the difficulty of proving compliance. An organization must not only act in line with the requirements, but also be able to prove it. This requires data, procedures, event history, evidence of response and the ability to show that an incident was detected, analyzed and handled within the required timeframe.
All these elements affect detection time and response time. And time is one of the most important factors in the context of NIS2. An organization that detects an incident late or cannot quickly determine its scale immediately starts operating under reporting pressure.
In practice, readiness for NIS2 starts with visibility. Without it, effective detection, reliable reporting and responsible risk management become difficult to achieve.
For a deeper look at how NIS2 requirements translate into everyday monitoring, detection and incident response, you can also read our practical e-book on NIS2 and network visibility.
Read the e-book HERE.
