NIS2 and security monitoring—which requirements really apply?

For essential and important entities, NIS2 means an obligation to monitor systems continuously, although the rules do not specify a particular product or a permanently staffed desk. In Poland, this requirement is introduced by the amendment to the Act on the National Cybersecurity System, in force since 3 April 2026. The question of whether NIS2 requires 24/7 security monitoring therefore concerns the quality of the response to a signal more than working hours. Meeting the requirement takes people, a process and a prompt response.

Key information:

• Continuous monitoring is a legal requirement. Poland’s National Cybersecurity System Act requires continuous operation, without naming a specific product or team.
• Having monitoring does not settle the question of compliance. What matters is the path from a signal to a documented decision.
• SIEM and EDR remain components of a broader process. They themselves need rules, roles, playbooks and documentation.
• A SOC is a natural model for delivering these capabilities. The Act requires a detection and response capability that such a team provides.
• People, processes and a prompt response determine the outcome. Technology provides the signal; roles and procedures do the rest.

Why is there so much misunderstanding around NIS2?

Misunderstanding NIS2 costs an organisation twice: first when buying a tool expected to “take care of compliance”, and again when an audit still identifies a gap. The Directive sets objectives, while Poland’s National Cybersecurity System Act makes some of them more specific, including the obligation to monitor continuously.
Another reason is confusion between a product, a capability and evidence of compliance. SIEM and EDR are components; compliance comes from the complete process, not a single deployment. This leads directly to another question: how to meet NIS2 requirements step by step. That is precisely what is examined in NIS2 compliance auditing.

Does NIS2 really require security monitoring?

For entities covered by Article 8 of Poland’s National Cybersecurity System Act, continuous system monitoring is a legal obligation, although the Act prescribes neither a tool name nor a function called a SOC (Security Operations Center). Measures must be proportionate to the risk and the potential consequences of an incident.

The Directive refers to appropriate and proportionate measures; the explicit requirement for “continuous operation” comes from the Polish amendment. NIS2 treats security monitoring as the ability to handle an event, so whether NIS2 requires 24/7 security monitoring depends on the quality of the response to a signal.

Telemetry may operate around the clock while a high-risk alert still waits until Monday without assessment or escalation. It is difficult to defend such incident handling afterwards. The technical layer of this oversight can be assessed through IT security audit.

Infrastructure monitoring and security monitoring

For decision-makers, the distinction can be costly: monitoring may work well while the requirement remains unmet. Infrastructure monitoring checks whether a service works, tracking availability, performance and errors.

Criterion	Infrastructure monitoring	Security monitoring
Main question	Is the service operating within its parameters?	Does the event indicate a threat, breach or compromise?
Typical data	availability, latency, load, capacity, errors	logins, privilege changes, network traffic, processes, EDR alerts, cloud events
Outcome	technical alarm and maintenance actions	security alert, triage, incident, escalation or closure with a rationale
Context	performance, continuity, service levels	asset criticality, identity, behaviour, business risk
Evidence of action	outage ticket, chart, repair record	timeline, incident ticket, decisions, playbook, containment actions

Having monitoring and meeting an NIS2 requirement are two different states. The first means that a signal is generated at all. The second begins when someone assesses the signal, prioritises it and leaves a decision trail that can be presented at an audit. NIS2 security monitoring is therefore assessed through the quality of alert response that the organisation can document.

Is SIEM enough to meet NIS2 requirements?

SIEM (Security Information and Event Management) alone is not enough to meet NIS2 requirements, although it can be a strong component. The system centralises logs, correlates events and generates alerts, while integrations trigger automated actions. Yet it is still only part of the process.

Factors that determine compliance sit beyond the product: log source quality, detection rules, triage, decision ownership, playbooks and documentation. Whether SIEM is enough for NIS2 is determined after the alert, by people, the process and the time to a decision. These gaps often become clearest during the deployment of SIEM in a company, where simply activating a tool does not yet improve security.

Is EDR enough?

EDR (Endpoint Detection and Response) is also insufficient on its own, as it covers endpoints rather than the entire environment or organisational process. The tool provides strong visibility into workstations and servers, can detect unusual process behaviour, and can even isolate a host. The answer to whether EDR is enough for NIS2 is therefore the same as for SIEM: the process around the tool matters, as the following comparison explains.

Element	Is it enough on its own?	Rationale
Firewall	NO	Controls selected traffic flows and generates telemetry, but does not provide the full detection and incident handling process.
SIEM	NO	Centralises and correlates data, can raise alerts and trigger integrations, but without sources, rules, people and playbooks it does not create a complete response capability.
EDR	NO	Detects threats and can respond on endpoints, but does not independently cover the entire environment or organisation-wide incident management.
SOC 24/7	CAN PROVIDE THE REQUIRED CAPABILITY	Connects people, processes and technology, but compliance depends on scope, proportionality, documentation and the organisation’s responsibilities.

What does NIS2 actually require?

The core requirement is operational: NIS2 expects a complete chain of capabilities, including incident detection and subsequent incident management under NIS2.

The 24-hour and 72-hour windows and the report within one month apply only to significant incidents and run from detection. NIS2 incident response therefore includes recognising when a matter must be reported to a CSIRT (Computer Security Incident Response Team). A structured step-by-step incident response then completes the obligation, from confirming the event to notification and reporting.

Requirement	Operational capability	Example evidence
Continuous monitoring	detections operate around the clock and source failures are detected	source inventory, coverage status, log-loss test, alert history
Incident management	triage, classification, escalation, containment and recovery	ticket, timeline, decisions, playbook used
Mitigating impact	authorised staff take proportionate action	record of isolation, blocking or configuration changes; owner’s decision
Reporting	the organisation recognises a significant incident and contacts the CSIRT	classification procedure, contact persons, notification confirmation
Assessing effectiveness	detections and procedures are tested and improved	exercise results, rule reviews, timing metrics, lessons learned

At VigilHorizon, we see these requirements as a single workflow with clearly assigned roles. A signal enters triage, receives a priority, and a playbook guides the analyst through analysis, mitigation and recording decisions. We treat incident documentation as evidence that NIS2 incident handling has actually worked. An audit can then show not only that an alert was generated, but who handled it and on what basis.

Why is a SOC a natural response to NIS2 requirements?

A SOC addresses NIS2 requirements by connecting people, processes and technology in one model, with day-to-day operations providing a prompt response. The Act does not name it explicitly, so it remains one way of fulfilling the obligation, and the team can operate internally, externally or through a hybrid model.

The term “NIS2-compliant SOC” can be misleading: documented operation determines compliance, not a service label. Simplifications have grown around the term NIS2 SOC; it is more accurate to describe a team supporting the requirements of Poland’s National Cybersecurity System Act. A round-the-clock SOC team organises shifts and escalations around a consistent approach: priority, ownership and a decision trail. If you are unsure whether your monitoring includes a real alert response, at VigilHorizon we start with a free consultation and a review of where signals lose momentum.

How can an organisation prepare for NIS2?

NIS2 readiness develops fastest when the first decisions concern processes and roles; purchasing follows from that structure. The sequence below shows how to prepare a company for NIS2 in practice.

Seven steps to NIS2 readiness:

1. Define the monitoring scope – establish which systems supporting the service covered by the Act must be visible through telemetry.
2. Map telemetry sources – check which logs you already collect and identify gaps in detection coverage.
3. Define detection priorities – derive them from risk and business scenarios.
4. Assign roles – triage, escalation, communications and reporting must have owners.
5. Define out-of-hours operations – arrange on-call coverage and deputies so that alerts do not wait until morning.
6. Test playbooks – run exercises and tabletops, and check log completeness and time synchronisation.
7. Record the response – every handled alert should leave a timeline, decision and containment actions in its ticket.

Consider an organisation with EDR, SIEM and round-the-clock logs that appears formally ready for NIS2. During a readiness exercise, an unusual privilege change occurs on an account with access to a critical service. The alert is generated without difficulty, but nobody can identify who assesses it on a Saturday, the escalation threshold or who decides to restrict access. The illusion of readiness breaks at that point: the tools worked correctly, yet compliance was still absent because the process and decision owner were missing.

At VigilHorizon, we begin NIS2 preparation by tracing a single signal: where it originates, who sees it, who assesses it and who decides on the response. Only this map reveals where the process breaks and which capability is actually missing. It turns a budget discussion into a discussion about a specific capability that needs to be added.

Checklist

Before deadline pressure builds, answer a few questions and support each answer with evidence. Every “I don’t know” points to an initial gap.

Questions to ask before an NIS2 audit:

• 24/7 monitoring – does oversight operate continuously within the agreed scope?
• Log sources – are they inventoried, and does a telemetry failure itself trigger an alarm?
• Alert ownership – does every alert have a priority, a response time and an escalation path?
• Playbooks – do they exist for key scenarios, and have they been rehearsed?
• Incident classification – is it clear when an incident is significant and how to contact the CSIRT?
• Operational documentation – does an incident leave a record of decisions beyond the technical log itself?
• Effectiveness metrics – do you measure MTTD (Mean Time to Detect) and MTTR (Mean Time to Respond)?

A complete set of affirmative answers leaves a documented trail of what people did after an alert, how the process worked and how long the decision took.

“Compliance comes down to one thing: whether a signal has an owner, a priority and a decision record. That is what we check first when entering an organisation.”

— VigilHorizon Expert

The path from monitoring to compliance with NIS2

NIS2 compliance improves where people, processes and a prompt response complete the path from a signal to a documented decision. Monitoring itself provides the starting point; the outcome depends on what happens after an alert. This is a useful perspective for examining your organisation before an auditor does.

Unsure whether your organisation really meets NIS2 requirements? That question alone is a reason to verify the facts on your own terms, rather than under deadline pressure. The answer comes from an NIS2 readiness audit with gap analysis: our experts identify missing capabilities and the order in which to build them. The most common finding in these reviews concerns continuous alert handling; this role is performed by a 24/7 SOC team.

Contact us

Frequently asked questions (FAQ)

Does NIS2 require 24/7 security monitoring?​

For entities covered by Poland’s National Cybersecurity System Act, system monitoring must operate continuously, which in practice means around the clock. However, the rules do not specify a particular tool or team model.

Does NIS2 require a SOC?​

The Act does not require a team called a SOC, but it does require the ability to detect, analyse and handle incidents.

Does monitoring from 8 a.m. to 4 p.m. meet the NIS2 requirement?​

A model that switches off outside business hours is not continuous monitoring, so it is difficult to consider it sufficient.

Is SIEM enough for NIS2?​

Buying SIEM alone does not determine compliance. Source coverage, detection rules, triage, response and oversight around the tool are what matter.

Is EDR sufficient for NIS2?​

EDR covers the endpoint layer and does not replace the complete organisational process. Networks, cloud environments, identities and reporting remain beyond its scope.

Can SIEM or EDR respond automatically?​

Both can perform automated actions, depending on their capabilities and integrations. Automation does not remove the need for rules, permissions and oversight.

Can a SOC be outsourced?​

The law permits tasks to be entrusted to a managed service provider.

Is management responsible for cybersecurity under NIS2?​

The Act assigns the entity’s management responsibility and decision-making and oversight duties. Delegating tasks to another person does not remove that responsibility.

Does every alert have to be reported within 24 hours?​

Reporting deadlines apply only to significant incidents, not ordinary alerts. Most events are resolved through the internal process without reporting.

When do the 24-hour and 72-hour windows begin?​

Reporting windows run from the detection of a significant incident. The first raw event in the logs does not yet start the clock.

Does ISO/IEC 27001 certification mean NIS2 compliance?​

Certification does not automatically confirm compliance with the Act. The standard provides a mature foundation, but the legal scope of Poland’s National Cybersecurity System Act and sector-specific requirements must be assessed separately.

Are MTTD and MTTR mandatory under NIS2?​

The Act does not name these metrics. MTTD and MTTR remain useful indicators for assessing how quickly an organisation detects and handles incidents.

Learn more

• NIS2 compliance audit: how can an organisation prepare?
• What is SOC 24/7, and why is monitoring not enough?
• Incident Response: responding to a cyberattack, step by step
• MTTD and MTTR: why detection time determines incident scale
• SIEM in business: why deployment alone does not improve security
• The alert appeared overnight; the administrator saw it in the morning