Wazuh can help NIS 2 entities build centralized logging, detection, vulnerability visibility, and audit evidence. It does not make an organization “NIS 2 compliant” by itself. It is a technical control that must sit inside governance, incident response, evidence management, and documented risk treatment.
Sources: Wazuh official site, Wazuh architecture documentation, ACN baseline obligations determination, ENISA NIS2 technical implementation guidance.
Key takeaways
- Wazuh is a free and open-source security platform that provides SIEM and XDR capabilities.
- The documented architecture uses a multi-platform agent plus Wazuh server, indexer, and dashboard components.
- For NIS 2, Wazuh is most relevant to logging, monitoring, alerting, vulnerability visibility, and evidence production.
- The compliance result still depends on operating model, incident procedures, retention choices, and board-level accountability.
- DIY deployment reduces license cost but increases internal engineering, tuning, maintenance, and response workload.
Scope of this article
This article explains what Wazuh is and when it can support a NIS 2 compliance program. It does not replace a legal assessment, an ACN filing analysis, or a full SOC design.
What is Wazuh?
Wazuh is an open-source security platform used for SIEM and XDR use cases. In practical terms, it collects endpoint and infrastructure signals, normalizes and analyzes events, raises alerts, and exposes dashboards for security operations. Wazuh documentation states that the platform is free and open source, with components under GPLv2 and Apache License 2.0.
For SMEs, the attraction is clear: a SIEM-like capability without a traditional per-GB or per-endpoint commercial SIEM license model. The tradeoff is equally clear: the organization must still design, run, secure, tune, and evidence the platform.
Wazuh architecture: agent, server, indexer, dashboard
| Component | Role | NIS 2 relevance |
|---|---|---|
| Wazuh agent | Collects endpoint telemetry and forwards events to the manager. | Endpoint visibility, asset evidence, event collection. |
| Wazuh server | Analyzes events, applies decoders and rules, and coordinates agents. | Detection logic, alert generation, operating evidence. |
| Wazuh indexer | Indexes and stores alert/event data for search and analysis. | Log retention, investigation, audit trail. |
| Wazuh dashboard | Provides the web interface for alerts, configuration, and visualization. | Operational monitoring and reporting. |
The architecture can be all-in-one for labs and small environments, single-node with separated components for medium environments, or multi-node for higher throughput and availability. Wazuh also supports agentless monitoring and syslog ingestion for devices where an agent is not possible.
Why Wazuh is relevant for NIS 2
NIS 2 and the Italian implementation model require cybersecurity risk-management measures, incident handling, and evidence that controls are operating. ACN baseline materials and ENISA technical guidance both make logging, monitoring, detection, and incident-response evidence central to operational readiness.
Wazuh can support these needs in four ways:
- Centralized logging: agents and syslog collection can feed a common evidence base.
- Detection: decoders and rules can identify suspicious activity and policy violations.
- Vulnerability visibility: software inventory and vulnerability detection can support risk treatment.
- Reporting: dashboards and exports can help demonstrate operating controls to management and auditors.
Comparison: Wazuh vs commercial SIEM
| Criterion | Wazuh | Commercial SIEM |
|---|---|---|
| License model | Open-source core, lower entry cost. | Usually subscription, ingestion, or endpoint pricing. |
| Deployment | Requires internal Linux, storage, indexer, and security skills. | Often supported by vendor or integrator. |
| Detection content | Strong baseline, but needs tuning for the environment. | Vendor-managed content is often broader, but still needs tuning. |
| Compliance evidence | Possible, if governance and retention are designed properly. | Often easier to package, but not automatic. |
| Responsibility | Mostly on the implementing organization. | Shared with vendor, MSSP, or integrator depending on contract. |
When to choose Wazuh
Wazuh is a strong candidate when the organization has Linux and security engineering skills, wants transparency over detection logic, and can maintain retention, hardening, backup, and response processes. It is also suitable for labs, phased NIS 2 readiness programs, and organizations that need more visibility before purchasing a commercial SIEM.
When not to choose Wazuh
Wazuh is not the best starting point when no one owns daily triage, log source onboarding, rule tuning, and incident escalation. A tool without operating capacity becomes shelfware. For regulated entities, that creates a false sense of compliance and weak audit evidence.
Limits and TCO considerations
- Storage and indexer capacity must be sized against event volume and retention needs.
- Rules need tuning to reduce false positives and missed detections.
- Availability, backup, encryption, and administrator access must be designed explicitly.
- Incident notification remains a process obligation. Wazuh can alert, but it cannot decide regulatory notification alone.
Coordination with a managed service
Organizations that like Wazuh but lack SOC capacity can use it as part of a managed operating model. Aegister’s Cyber Console and vCISO service can help connect telemetry, governance, evidence, and executive reporting instead of leaving the SIEM as a standalone tool.
Implementation model for a NIS 2 program
A practical Wazuh program should be managed as a control implementation project. The organization should first define the services in scope, then identify the systems that support them, then decide which events are needed to prove monitoring and response capability. This prevents the common mistake of collecting logs because they are easy to collect, while missing the systems that matter most for service continuity.
The minimum governance package should include a log-source register, a SIEM ownership matrix, a retention decision, an alert review procedure, and an incident-escalation map. These documents are not bureaucracy. They are the bridge between the technical tool and the evidence expected in a regulated environment.
Evidence checklist for Wazuh readiness
| Evidence | Why it matters | Owner |
|---|---|---|
| Log-source register | Shows which critical systems are monitored and which are not. | IT/security operations |
| Retention policy | Explains how long alerts and archive logs are kept. | CISO/legal |
| Rule-tuning record | Documents why detection thresholds were changed. | SOC or security lead |
| Escalation procedure | Connects alerts to incident response and regulatory triage. | Incident manager |
| Management report | Shows coverage, open risks, and control maturity to leadership. | CISO/vCISO |
Common implementation failure modes
- Tool-first deployment: Wazuh is installed before the organization defines what it must prove.
- Unowned alerts: alerts exist, but no role is accountable for triage and closure.
- Retention without restore: logs are retained, but backup and recovery of the SIEM are not tested.
- Admin overexposure: dashboard and API access are broader than necessary.
- No regulatory routing: security incidents are handled technically, but not mapped to NIS 2 notification logic.
How to position Wazuh in the control stack
Wazuh should be treated as one part of the control stack. It can provide telemetry and alerts, but it should integrate with asset management, vulnerability management, ticketing, backup evidence, supplier-risk records, and executive reporting. Without these connections, the SIEM becomes a monitoring island.
The mature target is a traceable chain: critical service → supporting assets → monitored log sources → detection rules → alerts → tickets → incident decision → management evidence. That chain is what makes a technical platform useful for compliance and risk governance.
90-day adoption roadmap
| Phase | Objective | Output |
|---|---|---|
| Days 1-30 | Design scope and pilot architecture. | Service map, log-source register, pilot deployment. |
| Days 31-60 | Onboard priority systems and validate alerts. | Connected agents, test alerts, escalation path. |
| Days 61-90 | Package evidence and decide operating model. | Management report, open-gap list, runbook. |
This roadmap keeps the first deployment focused. It avoids the common pattern where teams install the platform, connect many noisy sources, and then lack enough time to turn alerts into usable evidence.
Service coverage model
For NIS 2, endpoint count is less important than service coverage. A small number of critical systems may matter more than hundreds of low-impact endpoints. The coverage model should therefore start from services, map dependencies, and only then list log sources. This produces a defensible reason for monitoring priorities.
Governance handoff
At the end of the first implementation phase, Wazuh ownership should move from project mode to operating mode. That handoff should name who owns platform health, rule tuning, source onboarding, evidence exports, backup tests, and management reporting. Without this handoff, the SIEM remains a project artifact rather than a control.
Series navigation
- Wazuh deployment step-by-step
- centralized log management with Wazuh
- Wazuh vs commercial SIEM decision guide
- NIS2 detection and event monitoring
- operational registers, logs, backups and recovery
FAQ
Is Wazuh enough for NIS 2 compliance?
No. Wazuh can support several technical controls, but compliance also requires governance, documented policies, risk management, incident procedures, and evidence.
Is Wazuh really open source?
Wazuh documentation describes the platform as free and open source, with components under GPLv2 and Apache License 2.0. Organizations should still review licensing for their exact deployment and integration model.
Can Wazuh replace a SOC?
No. It can support SOC workflows, but someone must monitor alerts, investigate incidents, tune rules, and report outcomes.