What NIS2 Means for Your IT Team — and the One Workflow Change That Covers Most of It

NIS2 — the EU's Network and Information Security Directive 2 — came into force in October 2024 when EU member states were required to transpose it into national law. If you're a European business in a regulated or critical sector, or a supplier to one, NIS2 applies to you — and the penalty regime is serious: up to €10 million or 2% of global annual turnover for essential entities.

This post is not legal advice, and NIS2 implementation varies by member state. What it is, is a plain-English explanation of what the directive actually requires and why a structured incident management workflow is the most practical way to satisfy the core obligation.

Who NIS2 applies to

NIS2 divides entities into two categories — "essential" and "important" — across 18 sectors. The key sectors include:

The threshold for "important" entities is generally 50+ employees or €10M+ annual revenue. But there are exceptions — critical infrastructure operators can be in scope regardless of size, and member states can designate additional entities.

Beyond direct applicability, there's the supply chain dimension. NIS2 requires essential and important entities to manage cybersecurity risks in their supply chains — which means their suppliers face pressure to demonstrate comparable security practices even if they're not directly in scope.

What NIS2 actually requires

The directive has several requirements. The one most businesses focus on first — because it has the clearest operational implication — is incident reporting.

When a significant incident occurs, you must:

Why most businesses aren't ready for this

The 24-hour early warning requirement is tight. For a business that tracks incidents in a shared spreadsheet or a Slack thread, assembling a coherent notification within 24 hours of detection is a real challenge. You need to know when the incident was first detected, by whom, what the initial impact assessment is, and what containment steps have already been taken. If that information is scattered across Slack threads, personal notes, and memory, the 24-hour clock creates genuine operational pressure.

The one-month final report requirement — a root cause analysis with documented timeline and remediation steps — is even harder to produce if the incident was handled informally. Reconstructing a timeline from Slack and emails weeks after the fact is time-consuming, and the result is rarely as complete as a contemporaneous record would be.

The workflow change that covers most of it

A structured incident management system — one where every incident is logged from the moment of detection, with timestamped updates at each stage — produces the NIS2 reporting material as a byproduct of the normal incident workflow.

Here's how the workflow maps to the reporting requirements:

• Incident detected and logged — timestamp recorded, classification applied, initial description captured. This becomes the basis for the 24-hour early warning.
• Updates logged during investigation — each action taken, each finding, each decision to escalate or contain. These become the incident notification at the 72-hour mark.
• Post-incident review completed — root cause analysis, timeline reconstruction, remediation plan. This becomes the one-month final report.

If the workflow is structured, the report writes itself. If it isn't, someone has to reconstruct it under time pressure — which is where errors, omissions, and regulatory risk appear.

Beyond reporting: the other NIS2 requirements

Incident reporting is the most urgent operational requirement, but NIS2 also requires:

• Risk management policies — documented policies for cybersecurity risk, including supply chain risk
• Business continuity planning — documented plans for maintaining operations during and after a significant incident
• Access management — controls over who has access to critical systems, with documented justification
• Cryptography and encryption — use of appropriate encryption for sensitive data and communications
• Security in supply chain — assessment of suppliers' security practices

Many of these requirements are addressed by operational controls that good IT management should already have. NIS2 formalises them and adds the requirement to document and demonstrate compliance.

Does HubSecure Incident Management produce NIS2-formatted reports?

HubSecure Incident Management includes a post-incident review template aligned to NIS2 reporting requirements — timeline, root cause, contributing factors, remediation actions with owners and due dates. The report is generated from the incident record, not written from scratch. We also support 24-hour early warning export in a format compatible with most national authority submission portals.

What if we're not sure whether we're in scope?

That's a question for qualified legal counsel in your member state — NIS2 implementation varies, and the thresholds have nuance. What we'd say is that the operational controls NIS2 requires — structured incident management, documented access controls, encryption, business continuity planning — are good practice for any technology-dependent business regardless of formal scope.

This post is for informational purposes only and does not constitute legal advice. NIS2 implementation varies by EU member state. Consult qualified legal counsel for advice specific to your obligations.