Centralized log management is one of the clearest ways to turn NIS 2 security requirements into operating evidence. Wazuh can collect endpoint logs, receive syslog data, analyze events, and generate alerts. The compliance value depends on what is collected, how long it is retained, and how alerts are handled.
Sources: Wazuh log data collection, Wazuh syslog configuration, NIS 2 Directive, ACN baseline obligations determination.
Key takeaways
- Wazuh can support centralized log collection, analysis, and alerting.
- NIS 2 evidence requires documented log sources, retention, access control, and review process.
- Collected logs should map to critical services, identity systems, network controls, endpoints, and cloud workloads.
- Integrity and segregation matter as much as collection volume.
- Wazuh supports detection, but regulatory notification remains a governance process.
NIS 2 logging and detection requirements
NIS 2 requires cybersecurity risk-management measures and incident-handling capability. Italian ACN baseline materials operationalize these expectations through governance, identification, protection, detection, response, and recovery logic. Logging is the evidence layer that connects these controls to real events.
Mapping Wazuh to NIS 2 controls
| Control objective | Wazuh capability | Evidence to keep |
|---|---|---|
| Event monitoring | Agent and syslog event collection, decoders, rules. | Source inventory, rule configuration, alert history. |
| Anomaly detection | Rules and correlation for suspicious behavior. | Tuning decisions, test alerts, investigation notes. |
| Vulnerability visibility | Software inventory and vulnerability detection. | Vulnerability reports, remediation records. |
| Incident response | Alert workflow supporting triage and escalation. | Tickets, escalation logs, post-incident review. |
| Audit readiness | Dashboards, exports, and retained event data. | Retention settings, access logs, management reports. |
Minimum log sources
- Identity and directory services.
- Privileged access systems.
- Critical servers and endpoints.
- Firewalls, VPNs, routers, and switches through syslog where appropriate.
- Cloud control planes and security services where APIs or forwarding are available.
- Backup, endpoint protection, and vulnerability-management tooling.
Retention and integrity
Wazuh documentation notes that collected logs and alerts can be stored in archive and alert files and that retention should be governed by legal and regulatory needs. For NIS 2, define retention by incident investigation, audit, and business continuity requirements. Protect indexes, exports, and backups against unauthorized changes.
Alerting and incident detection
A detection rule is useful only if someone receives it, understands it, and can act. Define severity thresholds, escalation paths, business hours and out-of-hours handling, false-positive review, and owner accountability. Map critical alert types to incident playbooks.
Reporting for management and ACN readiness
Management does not need raw log volume. It needs indicators that show coverage, high-severity events, unresolved incidents, detection gaps, and remediation progress. For regulated entities, Wazuh outputs should feed board-level reporting and evidence packs.
What Wazuh does not cover
- It does not decide legal notification to CSIRT Italia or ACN.
- It does not replace incident-response ownership.
- It does not solve supplier-risk evidence by itself.
- It does not guarantee complete detection without source coverage and tuning.
Log-source onboarding plan
Onboarding should be staged. Start with sources that support identity, remote access, internet exposure, privileged actions, and backup integrity. Then add business applications and cloud workloads. Each source should have an owner, a purpose, a parsing status, a criticality label, and a review cadence.
| Source class | Reason to collect | Typical control question |
|---|---|---|
| Identity systems | Detect account abuse and privilege escalation. | Can we see suspicious authentication patterns? |
| Network security | Monitor perimeter and lateral movement signals. | Can we reconstruct traffic and access paths? |
| Critical servers | Detect service disruption and unauthorized changes. | Can we prove monitoring on essential systems? |
| Backup platforms | Protect recovery capability from tampering. | Can we detect backup deletion or failure? |
| Cloud control planes | Monitor administrative changes and API abuse. | Can we see privileged cloud events? |
Retention decision model
Retention must be explicit. A useful model separates hot search data, warm investigation data, and cold archive data. The organization should document why each retention period is sufficient for incident investigation, audit, and business needs. If storage constraints force shorter retention, that risk should be visible to management.
Integrity controls for log evidence
- Restrict administrative access to indexes and archive locations.
- Keep SIEM administrators separate from monitored system administrators where feasible.
- Back up configuration and critical evidence to a protected location.
- Record changes to rules, decoders, retention, and access rights.
- Test that exported evidence can be read and explained after an incident.
Alert quality metrics
Coverage alone is not enough. Track alert volume, false-positive ratio, mean time to triage, unassigned alerts, repeat noisy rules, and missed-detection lessons from incidents. These metrics show whether Wazuh is improving detection or merely collecting data.
Board-ready reporting pack
A quarterly report should summarize monitored critical assets, high-severity alerts, confirmed incidents, open detection gaps, vulnerability trends, and remediation status. This transforms SIEM operation into governance evidence aligned with NIS 2 accountability.
Detection scenario catalog
A NIS 2-oriented Wazuh program should maintain a small catalog of detection scenarios. Examples include privileged account misuse, repeated authentication failures, suspicious process execution, endpoint malware alerts, unauthorized service changes, backup deletion, VPN anomalies, and firewall deny spikes. Each scenario should have a source, a rule, an owner, and an escalation path.
| Scenario | Minimum sources | Operational response |
|---|---|---|
| Privileged login anomaly | Identity logs, endpoint logs, VPN logs. | Verify user, session, source IP, and change window. |
| Backup tampering | Backup platform, admin logs, endpoint logs. | Escalate immediately to recovery owner and incident lead. |
| Malware alert | Endpoint protection, Wazuh agent, network logs. | Contain host, collect evidence, verify lateral movement. |
| Critical service failure | Application logs, system logs, monitoring events. | Assess service impact and incident classification. |
Review cadence for log quality
Log quality decays unless reviewed. New applications, cloud services, identity changes, endpoint replacements, and supplier integrations can create coverage gaps. A monthly review should compare the asset inventory with the log-source register and highlight unsupported critical systems.
Evidence workflow from alert to audit
- Alert is generated and assigned severity.
- Analyst records triage decision and affected asset.
- Incident owner decides whether escalation is required.
- Evidence is attached to ticket or case record.
- Closure note explains root cause, impact, and remediation.
- Monthly report aggregates trends and unresolved gaps.
This workflow makes Wazuh outputs reusable for audit. Without it, dashboards may show activity, but auditors and management cannot see whether the organization acted on the signal.
Series navigation
- introduction to Wazuh
- Wazuh deployment step-by-step
- Wazuh vs commercial SIEM
- NIS2 detection and event monitoring
- operational registers and logs
For a managed operating model, see Aegister Cyber Console and Aegister vCISO.
FAQ
How long should logs be retained?
There is no universal answer. Define retention from legal obligations, incident investigation needs, risk assessment, and storage constraints. Document the decision.
Does Wazuh support syslog?
Yes. Wazuh documentation describes syslog ingestion for devices that cannot run an agent.
Can Wazuh produce board reports?
It can provide data and dashboards, but board reports need business interpretation, risk context, and accountability.