NIS2 compliance with Wazuh
NIS2 compliance with Wazuh.
The NIS2 directive requires monitoring, incident handling and risk management capabilities that most organisations don't yet have in place. Wazuh is a free, open source platform that covers a large part of what the directive demands — but not all of it. This guide explains what it does, what it doesn't, and what you actually need to pass an audit.
NIS2 (Directive EU 2022/2555) is the EU regulation that raises cybersecurity standards for businesses operating in critical and important sectors. If your organisation provides essential services — or supplies technology to one that does — this applies to you. The fines are real: up to €10 million or 2% of global turnover.
Wazuh is an open source security platform that centralises your logs, detects threats, monitors vulnerabilities and generates the evidence trail an auditor expects. It's free, widely adopted across European public administrations and research institutions — including CERN — and at SIXE we deploy it in production environments configured specifically for regulatory compliance. This article explains NIS2's requirements in plain language, maps them to Wazuh's capabilities, and is honest about the gaps.
Does NIS2 apply to your organisation?
NIS2 broadens the scope of the original 2016 directive significantly. It applies to essential entities (energy, transport, banking, health, water, digital infrastructure, public administration) and important entities (postal services, waste management, food, manufacturing, chemicals, digital providers). If you supply technology or services to any of these sectors, you may also fall within scope.
Essential vs. Important: two levels of obligation
Essential entities (energy, health, transport, digital infrastructure, banking, public administration) face proactive supervision — authorities can audit you at any time. Important entities (manufacturing, food, chemicals, postal, digital providers) face reactive supervision — authorities investigate after an incident or a complaint. The security obligations under Article 21 are the same for both. The difference is how strictly they're enforced.
NIS2 describes SIEM capabilities — without using the word
A SIEM (Security Information and Event Management) is a system that collects log data from all your servers and devices, analyses it automatically to find suspicious patterns, and raises alerts when something looks wrong. Think of it as a security camera for your entire IT infrastructure — one that can actually understand what it sees.
NIS2 doesn't say "install a SIEM". But Article 21 requires a set of measures that in practice demand SIEM-class capabilities:
- Incident handling (Art. 21.2.b) — detect, respond to and report security incidents. NIS2 requires a three-stage reporting timeline: early warning within 24 hours, notification within 72 hours, and a final report within one month.
- Risk management (Art. 21.2.a) — continuous risk analysis and policies for information system security.
- Business continuity (Art. 21.2.c) — backup management, disaster recovery, crisis management.
- Supply chain security (Art. 21.2.d) — security of relationships with direct suppliers and service providers.
- Vulnerability handling (Art. 21.2.e) — vulnerability disclosure and management.
- Monitoring and logging (Art. 21.2.g/h) — policies for assessing the effectiveness of cybersecurity measures, including logging and monitoring of network and information systems.
Meeting the 24-hour early warning requirement without automated detection is extremely difficult. Detecting incidents, preserving evidence, and reporting within the required timelines is exactly what a SIEM does.
NIS2 doesn't mandate a specific tool. It prescribes outcomes — incident detection, response, logging, risk management. Using Wazuh to deliver those outcomes is a technical and economic decision, not a regulatory requirement.
Where ISO 27001 fits in
ISO 27001:2022 is a voluntary international standard for information security management. Many organisations pursue it alongside NIS2 because the controls overlap significantly. Annex A controls A.8.15 (Logging), A.8.16 (Monitoring activities), A.8.8 (Vulnerability management) and A.8.7 (Malware protection) map directly to Wazuh capabilities. If you're building for NIS2 with Wazuh, you're covering much of ISO 27001's technical layer at the same time.
Which NIS2 and ISO 27001 measures does Wazuh support?
Wazuh is an open source platform (free) that combines several security functions in a single product: it centralises logs from all your devices, watches for changes in critical files, detects known vulnerabilities, checks that your servers follow security best practices, and can automatically block an IP that's trying to brute-force its way in.
It doesn't cover everything NIS2 or ISO 27001 requires — no product does on its own. But it supports the technical measures that require monitoring, detection and traceability:
An important nuance: the table above shows Wazuh's technical capabilities. But a tool doesn't "comply" with NIS2 — your organisation does. Wazuh is the instrument; policies, procedures, governance and an incident response plan are the framework that gives it legal validity.
What Wazuh does NOT do on its own
This is the section most vendors skip. It's also the one that builds the most credibility.
A risk management framework. NIS2 requires a formal, ongoing risk analysis process. Wazuh detects threats, but it doesn't assess business risks or define risk appetite.
Governance and policies. You need documented security policies approved by management. NIS2 Article 20 makes management directly accountable. No tool writes these for you.
Incident reporting. Wazuh detects incidents and preserves evidence. But filing the 24h early warning, 72h notification and final report with your national authority is an organisational process, not a software feature.
Supply chain security. Article 21.2.d requires you to manage risks in your supply chain. Wazuh monitors your own infrastructure, not your suppliers'.
Business continuity planning. Backup strategy, disaster recovery, crisis management — these are organisational capabilities. Wazuh can monitor backup integrity, but it doesn't design your DR plan.
A team that reviews alerts. A SIEM that nobody looks at is a security camera with the monitor turned off. Wazuh generates alerts; if nobody triages and acts on them, compliance is only on paper.
Understanding these boundaries doesn't weaken the case for Wazuh — it strengthens it. When you know what it does and what it doesn't, you can build a realistic project instead of one that falls apart at the first audit.
NIS2 doesn't certify products — it demands outcomes
Unlike some national frameworks that maintain catalogues of "approved" security products, NIS2 doesn't prescribe specific tools. There is no "NIS2-certified SIEM" label. The directive requires organisations to implement appropriate technical and organisational measures proportionate to the risks they face.
This means two things:
- You can use Wazuh. There's no regulatory barrier to using open source tools for NIS2 compliance. What matters is demonstrating that your measures are effective, documented and proportionate.
- You need to prove it works. During supervision or audit, you'll need to show evidence that your monitoring, detection and response capabilities actually function — through logs, dashboards, incident records and documented procedures.
This is where Wazuh's audit trail and reporting capabilities become valuable: they generate the evidence an auditor needs to see. But the evidence only has value if it's organised, retained and linked to your documented risk management process.
Any Wazuh deployment for NIS2 needs documented procedures that link the tool's outputs to your risk management framework. Detection without documentation is invisible to an auditor.
Switching from Splunk or QRadar without losing compliance
If you're running a commercial SIEM with a renewal coming up, Wazuh is a viable alternative. The question isn't whether it works — it's how to migrate without creating a gap in your compliance evidence.
At SIXE we have a strong IBM QRadar practice with official training courses. We know what QRadar does and what Wazuh does, and exactly which pieces need to be rebuilt when you migrate.
Installing Wazuh out of the box is not NIS2 compliance
Wazuh ships with over 3,000 pre-built detection rules. Most of them don't apply to your environment. If you only run Linux servers but leave Solaris, Windows Server 2012 and AIX rules active, what you get is noise — alerts nobody understands, nobody reads, and after a few weeks, nobody checks.
No NIS2-specific dashboards. The built-in compliance dashboards cover PCI DSS, HIPAA, GDPR and NIST. For NIS2 you need to build them: panels grouped by Article 21 measures with data an auditor can review at a glance.
No decoders for your internal applications. Your internal portals, batch processes and custom software — without decoders tailored to these, their logs arrive as unstructured text and correlation becomes meaningless.
Installation takes 1–2 days. Tuning takes 4–6 weeks. Installation is what looks like the project. Tuning is the project.
If you already have Wazuh deployed but untuned, tell us what you have — the initial assessment has no commitment.
What you need ready before supervision or audit
NIS2 supervision can be proactive (essential entities) or reactive (important entities). Either way, when authorities or auditors come knocking, these are the documents and evidence they'll expect:
- Risk management documentation — a formal risk analysis linked to the Article 21 measures you've implemented, including which tools support each measure and why.
- Log retention policy — how long you keep logs, where they're stored and how integrity is maintained. NIS2 doesn't specify a minimum period, but industry practice is 12–24 months depending on your risk assessment.
- Incident response procedures — who receives alerts, how incidents are triaged, contained and reported within the 24h/72h/1-month timeline.
- Vulnerability management procedures — how often you scan, how fast you patch, what your SLA is based on severity.
- NIS2-specific dashboards — compliance views grouped by Article 21 measures, separate from generic PCI/HIPAA panels.
- Archived evidence — periodic exports of critical events, rule configurations and change logs. Ready to hand over without last-minute scrambling.
- Continuous improvement records — evidence that you review and update your measures regularly, not just when an audit is announced.
Training your team to operate Wazuh for NIS2
A monitoring platform that nobody reviews doesn't detect incidents — it just records them. If your IT team doesn't understand what they're looking at in the Wazuh dashboard, alerts accumulate unmanaged and the tool becomes invisible.
The skills needed to operate Wazuh in a compliance context are specific: reading events and distinguishing real alerts from noise, building custom rules for your applications, mapping evidence to NIS2 and ISO 27001 requirements, and responding to incidents within the reporting timelines.
The essentials, for those short on time
→ NIS2 describes SIEM capabilities in Article 21 — incident handling, monitoring, logging, vulnerability management. It doesn't name a tool.
→ Wazuh supports 10 NIS2 and ISO 27001 measures related to monitoring, detection and traceability.
→ There is no NIS2 product certification. The directive prescribes outcomes, not tools. You demonstrate compliance through documentation and evidence.
→ Wazuh doesn't replace risk management, governance, incident reporting processes, supply chain security or the team that reviews alerts.
→ Installing is not complying. The gap between "we have Wazuh" and "we're audit-ready" is 4–6 weeks of serious tuning work.
→ Wazuh is free. Implementing it properly is not.
Frequently asked questions
Does NIS2 require a SIEM?
Not by name. But Article 21 requires incident handling, continuous monitoring and logging capabilities that in practice are only achievable with a SIEM or equivalent platform. Wazuh provides most of these capabilities natively.
Can Wazuh help with NIS2 compliance?
Wazuh provides the technical capabilities to support several Article 21 measures — monitoring, detection, vulnerability management, incident response and audit logging. But compliance is demonstrated by the organisation through policies, procedures and governance, not by any single tool.
Is Wazuh certified for NIS2?
There is no NIS2 product certification scheme. NIS2 prescribes outcomes, not specific tools. Organisations choose their own tooling and demonstrate compliance through audits and supervision by national authorities.
Does Wazuh support ISO 27001?
Yes. Wazuh maps to several Annex A controls in ISO 27001:2022 — particularly A.8.15 (Logging), A.8.16 (Monitoring), A.8.8 (Vulnerability management) and A.8.7 (Malware protection). It provides technical evidence that auditors can review during certification.
What's the difference between NIS2 and ISO 27001?
NIS2 is an EU regulation — mandatory for essential and important entities, with fines up to 2% of global turnover. ISO 27001 is a voluntary international standard. Many organisations pursue both: NIS2 for legal compliance, ISO 27001 for the management framework. The technical controls overlap significantly.
How quickly must incidents be reported under NIS2?
Three stages: early warning within 24 hours, incident notification within 72 hours, final report within one month. Wazuh provides the detection and logging to meet these timelines, but the reporting itself is an organisational process.
References and regulation cited
Directive (EU) 2022/2555 (NIS2). EUR-Lex — Official Journal
Wazuh — Ensuring NIS2 compliance with Wazuh. wazuh.com
Wazuh — Regulatory compliance use cases. wazuh.com
ISO/IEC 27001:2022 — Information security management systems. iso.org
ENISA — NIS2 Directive guidance. enisa.europa.eu
Wazuh — Official documentation. documentation.wazuh.com
Full training catalogue · SIXE.
Last updated:
Let's talk about your project
Tell us which NIS2 category applies to you, what you have in place today and when your next audit is expected. We'll leave with an architecture sketch and next steps.
