NIS2 Compliance: What It Means for Your Monitoring Setup

The NIS2 Directive (Directive (EU) 2022/2555) is the European Union's updated framework for cybersecurity across critical and important sectors. It replaces the original NIS Directive from 2016 and significantly broadens the scope of who must comply.

If you run a SaaS product, a digital platform, or any online service with EU customers, NIS2 likely applies to you — and it has direct implications for how you handle monitoring, incident detection, and incident reporting.

What Is NIS2?

NIS2 is an EU-wide directive that sets minimum cybersecurity standards for organisations operating in sectors deemed essential or important to society. Member states were required to transpose it into national law by October 2024, and enforcement is now active across the EU.

The directive focuses on three pillars:

• Risk management — organisations must implement technical and organisational measures to manage cybersecurity risks
• Incident reporting — significant incidents must be reported to national authorities within strict timeframes
• Accountability — management bodies are personally responsible for ensuring compliance

Who Does NIS2 Apply To?

NIS2 divides organisations into two categories:

Essential entities include energy, transport, banking, health, water, digital infrastructure (DNS, cloud computing, data centres), and public administration. These face the strictest requirements and the most rigorous supervision.

Important entities include postal services, waste management, chemicals, food, manufacturing, digital providers (online marketplaces, search engines, social networks), and — critically for most readers of this blog — managed IT service providers and SaaS platforms.

The threshold is generally medium-sized or larger (50+ employees or EUR 10M+ turnover), but member states can designate smaller organisations if they provide critical services.

If you are a SaaS company with EU customers and you meet the size threshold, or if your service is considered critical by a member state, NIS2 applies to you.

What NIS2 Requires for Incident Management

Article 23 of NIS2 sets out strict incident reporting obligations. When a "significant incident" occurs, you must:

1. Send an early warning within 24 hours — notify your national CSIRT (Computer Security Incident Response Team) or competent authority within 24 hours of becoming aware of the incident
2. Submit an incident notification within 72 hours — provide an initial assessment including severity, impact, and indicators of compromise
3. Deliver a final report within one month — a detailed account of the incident, its root cause, mitigation measures, and cross-border impact if applicable

A "significant incident" is one that causes or could cause severe operational disruption or financial loss, or affects other natural or legal persons by causing considerable damage.

In practical terms: a multi-hour outage of your SaaS product, a data breach, or a security incident that degrades service for your customers almost certainly qualifies.

How Monitoring Fits Into NIS2 Compliance

NIS2 does not prescribe specific tools, but it requires you to have the capability to detect, respond to, and report incidents quickly. This is where monitoring becomes a compliance requirement, not just an operational convenience.

Here is what you need:

Timely Detection

You cannot report an incident within 24 hours if you do not know it happened. Automated monitoring — HTTP checks, TCP checks, response time tracking — is the most reliable way to detect service disruptions the moment they occur.

Without monitoring, you rely on customer complaints to learn about outages. By the time enough customers have emailed, you may already be outside your 24-hour early warning window.

Incident Documentation

NIS2 requires a final report with root cause analysis and a timeline of events. Your monitoring tool should provide:

• Timestamps of when the incident started and ended — based on automated checks, not human memory
• Response time data showing degradation leading up to the outage
• Historical uptime records to put the incident in context

This data forms the backbone of your incident report to authorities.

Status Communication

While NIS2 focuses on reporting to authorities, a public status page serves a parallel function: communicating with affected users. Having a structured incident lifecycle (Investigating, Identified, Monitoring, Resolved) with timestamped updates gives you a ready-made record for both your customers and your compliance team.

Why EU Data Residency Matters

NIS2 sits alongside the GDPR, and both emphasise data protection for EU citizens. If your monitoring tool processes data about your infrastructure, your incidents, and potentially your users' experience, where that data is stored matters.

Using a monitoring provider that stores data in the US or other non-EU jurisdictions introduces additional compliance complexity:

• Data transfer mechanisms like Standard Contractual Clauses (SCCs) add legal overhead
• US surveillance laws (FISA 702, Executive Order 12333) create legal uncertainty about data access
• Audit requirements become harder to satisfy when data is held outside EU jurisdiction

Choosing a monitoring tool hosted within the EU — with data stored in EU data centres — simplifies your compliance posture for both NIS2 and GDPR. For more on the GDPR angle specifically, see our guide on GDPR-compliant status pages.

Practical Steps to Align Your Monitoring with NIS2

1. Set up automated monitoring for all critical endpoints — your main application, API, authentication, and any service whose failure would qualify as a "significant incident"
2. Configure alerting with short intervals — 60-second check intervals mean you detect an outage within one minute, not one hour. This gives you the maximum time within your 24-hour reporting window
3. Use a status page with incident lifecycle tracking — every incident should have timestamped updates from detection to resolution. This is your audit trail
4. Keep monitoring data in the EU — avoid introducing unnecessary data transfer complications by choosing EU-hosted tools
5. Document your monitoring setup — NIS2 requires you to demonstrate your risk management measures. Your monitoring configuration, alerting rules, and incident response procedures should be documented and reviewable

For a deeper look at NIS2's specific requirements and how they map to monitoring capabilities, see our NIS2 guide.

NIS2 Is Not Going Away

Unlike some regulations that fade into the background, NIS2 has real enforcement teeth. Fines can reach EUR 10 million or 2% of global turnover for essential entities, and EUR 7 million or 1.4% of global turnover for important entities. Management can be held personally liable.

The organisations that handle this well are not the ones scrambling to comply after an incident. They are the ones that already have monitoring, incident management, and reporting workflows in place as standard operational practice.

If you do not yet have automated monitoring and a structured incident communication process, now is the time to set one up — not because of NIS2, but because it is good engineering practice. NIS2 just makes it mandatory.