Open source SIEM for NIS2 monitoring and logging: what the regulation asks for
If your organization is an essential or important entity under NIS2, your national transposition law will expect you to show that you monitor and log activity on your network and information systems. A self-hosted SIEM can supply the logs, retention and detection evidence that this requires. The regulation sets no fixed retention period and issues no certificate of compliance, so the evidence you produce has to show your own design choices working in practice. Article 21 of Directive (EU) 2022/2555 requires risk-management measures, including incident handling under Article 21(2)(b), and Implementing Regulation (EU) 2024/2690 sets the technical detail for the Article 21(2) measures for the in-scope digital sectors it covers.
Point 3.2 of the Annex to Implementing Regulation 2024/2690 is the core of this section. It requires procedures and tools to monitor and log activity to detect events that could be incidents, with monitoring automated to the extent feasible. Where appropriate, logs must cover network traffic, user creation and permission changes, system and application access, authentication events, privileged activity, access to critical configuration and backup files, security tool logs, resource use, physical access and environmental events. Point 3.2.4 adds that logs must be reviewed regularly for unusual trends and that alarm thresholds must trigger a timely, qualified response. Point 3.2.5 requires logs to be kept and backed up for a predefined period and protected from unauthorized access or change. Decide that retention period yourself, document the reason for it, and confirm it with your national authority or sector guidance.
Authorities do not approve a SIEM. They oversee compliance through inspections, security audits, security scans, information requests and administrative fines, as set out in Articles 32 to 34 of NIS2. Essential entities face ex ante supervision and important entities face ex post supervision, but both must meet the same risk-management obligations. Ask your auditor or national authority which artifacts they expect to see: alert records, review sign-offs, retention settings and access logs for the SIEM itself. ENISA's non-binding technical guidance, published on 26 June 2025, gives examples of evidence and is the natural next read before you map your controls.
Which monitoring and logging requirements map to which SIEM configuration
This table maps each NIS2 monitoring, logging, review, retention, policy and response requirement from Implementing Regulation 2024/2690 to the SIEM configuration that satisfies it. Read each row as a requirement, the configuration to build, and the evidence to keep, then confirm the final scope with your national competent authority and your own environment.
| Requirement (Implementing Regulation 2024/2690) | What the SIEM must do | How to configure it and evidence to keep |
|---|---|---|
| Point 3.2: monitor and log activity to detect possible incidents, automated where feasible | Continuously collect events from in-scope systems and raise detections without manual polling | Deploy Wazuh agents on in-scope endpoints and syslog or API collection for devices that cannot run agents. Keep agent inventory and coverage reports as evidence |
| Point 3.2.3: network traffic and user and permission changes | Ingest network telemetry and identity change events | Forward firewall and network sensor logs, and directory or account change events. Pair with Suricata or Zeek sensors where traffic visibility is needed |
| Point 3.2.3: system and application access, authentication and privileged activity | Capture logins, failed logins, sudo and administrator actions | Enable authentication decoders for Linux, Windows and identity providers. Keep a sample of privileged session records for assessors |
| Point 3.2.3: access to critical configuration and backup files, security tool logs, resource use, physical and environmental events | Log changes to critical configs, backup jobs, security tool health and host resource use | Monitor file integrity on configuration and backup paths. Forward security tool logs and badge or environmental feeds where the entity owns them. Confirm which sources apply to your sector |
| Point 3.2.4: regular review for unusual trends and alarm thresholds | Surface trends and trigger alarms automatically where appropriate | Define written thresholds per rule, such as repeated failed logins or new privileged accounts. Set review frequency and record reviewer sign-off |
| Point 3.2.5: keep and back up logs, protect them from unauthorized access or change | Store logs for a predefined period, with tamper resistance and restricted access | Set index retention in Wazuh indexer or Graylog index rotation to the period in your policy (the regulation sets no fixed period). Limit SIEM access by role, back up indices, and log administrator changes to the SIEM itself |
| Point 3.1.2: incident handling policy inputs (categorization, escalation, roles, templates) | Tag alerts with a category and route them to a named role | Map each detection rule to a category and severity. Use Graylog event definitions or Wazuh rule groups with notification routing. Keep the category list and routing table with the policy |
| Points 3.5.2 and 3.5.3: containment, eradication and recovery; CSIRT or authority communication | Provide the data needed to scope an incident and to notify the escalation chain | Retain alert context and host timelines for each event. Document the notification path to the CSIRT or competent authority and test contact lists before an incident |
| Point 3.5.5: response procedures tested at planned intervals | Support realistic test scenarios through the same detection path | Run tabletop exercises that inject a test alert and track it from detection to closure. Record dates, participants, gaps and corrective actions as test evidence |
Which open source platforms fit NIS2 monitoring
NIS2 monitoring and logging rests on a small set of platforms that collect, store, search and alert on security events. The cards below cover the core SIEM choices, their license terms, and the extensions that feed detection, intelligence and response into the same record.
Wazuh as an all-in-one SIEM
Wazuh combines agents on endpoints, a server that applies decoders and rules, an indexer that stores alerts and a dashboard. Its core repository is licensed under GPL-2.0, which governs how you may distribute modifications. Check that the agent coverage matches the log sources named in your Implementing Regulation 2024/2690 monitoring scope, and confirm how agentless devices such as firewalls will send syslog. The prebuilt compliance views are a starting point for evidence, not proof of compliance.
Wazuh offline installation path
Wazuh documents an offline installation guide for systems without internet connectivity. Vulnerability detection can run against an offline vulnerability repository instead of the Wazuh Cyber Threat Intelligence platform. For operators in restricted networks, this decides whether patches and vulnerability data can be carried in by approved media. Confirm the update procedure, the media handling rules and who signs off on each import before you commit to this path.
Graylog Open for log search and retention
Graylog Open ingests logs through syslog, GELF and Beats inputs, routes them through streams and pipelines, and runs event definitions for alerting. Its server is licensed under SSPL-1.0, which is not an OSI-approved open source license, so have legal review the terms before embedding it in a service you offer others. Index rotation and retention deletion are configured per index set, so the retention period you record for NIS2 must be set there and tested.
OpenSearch or Data Node storage backend
Graylog stores logs in a self-managed OpenSearch cluster or in Graylog Data Node, and it keeps configuration in MongoDB. Graylog recommends Data Node as the search backend and states that OpenSearch 1.x use has been deprecated since Graylog 7.0. Confirm the version pairing in the compatibility matrix before you build, because Graylog Security requires OpenSearch 2.0 or later. Storage sizing, replica counts and backup of the MongoDB metadata all fall to the implementer.
Security Onion for network-led monitoring
Security Onion bundles Suricata, Zeek, osquery and the Elastic stack into one platform for enterprise monitoring and log management. It is licensed under the Elastic License 2.0, which restricts offering the software as a managed service, so read the terms for your delivery model. It fits organizations that need network evidence for incident assessment in addition to host logs. Sensor placement and the volume of traffic it captures should be planned before the platform is sized.
Extensions that feed the SIEM
Suricata (GPL-2.0) and Zeek (BSD-style) generate network detection and traffic records that a SIEM can correlate with host logs. MISP (AGPL-3.0) and OpenCTI (Apache 2.0 Community Edition, separate Enterprise license) add threat intelligence context, and Shuffle (AGPL-3.0) automates triage and enrichment. Each adds its own license, update process and data handling duties. Map which of these you will run before you define the NIS2 detection and reporting workflow.
How a self-hosted SIEM turns logs into NIS2 evidence
The regulation asks for a chain that runs from log source to closed incident, and an assessor will test each link. Point 3.2 of the Annex to Implementing Regulation 2024/2690 requires monitoring and logging to detect events that could be incidents, with monitoring automated where feasible. In a self-hosted SIEM, that chain starts with agents and forwarders on endpoints, servers and network devices, followed by collection into the Wazuh server or Graylog inputs, normalization through decoders or pipelines, correlation rules, alerts, a ticket in the case management tool, and a post-incident review. Each step should write its own record: the source inventory, the decoder and rule versions in use, the alert with its timestamp, the ticket with its owner, and the review notes. Confirm with your SIEM partner exactly where each of these records is stored and how long it survives.
The regulation does not treat the tool as the evidence. Point 3.2.4 requires logs to be reviewed regularly for unusual trends, with alarm thresholds that trigger an alarm, automatically where appropriate, followed by a timely, qualified response. An assessor will usually ask for a sample of alerts and then trace each one back to a review decision, a classification under the incident handling policy and a response record. A dashboard that shows green on a screenshot does not satisfy that request. Decide who performs the review, how often, what counts as an alarm threshold for each log source, and how a reviewer records that an alert was dismissed as benign. Those records are the evidence of review, and they should be kept with the same protection as the logs themselves under point 3.2.5.
The chain also has to hold when something goes wrong with the SIEM. Logs must be kept and backed up for a predefined period and protected from unauthorized access or changes, and the regulation sets no fixed retention period, so you must define one and document the basis for it. Test that gaps are visible: an agent that stops reporting, a Graylog or Wazuh indexer that fills, or a forwarder that fails should itself generate an alert. Ask your implementation partner to show a full trace from one test event through the rule, the alert, the ticket and the review note, using your own environment, before go-live. That single trace is usually the most useful evidence you can give an assessor.
Evidence national authorities ask for and which component produces it
This table pairs the records a national authority is likely to request under Implementing Regulation 2024/2690 with the component that produces each one. Read each row as a question to answer during preparation: what exists, where it comes from, and what to confirm about the format each authority accepts. The main takeaway is that most monitoring evidence comes from the SIEM itself, but incident timelines and tabletop records depend on processes outside the platform.
| Evidence item | Produced by | What to confirm |
|---|---|---|
| Log source inventory with agent coverage | Wazuh server agent registry and agent list; Graylog inputs list | Export format and whether the inventory includes agentless syslog sources and their owners |
| Retention settings and backup records | Wazuh indexer index policies and backups; Graylog index rotation and retention settings | Retention period per log type, as set by your own policy, and backup job logs kept outside the SIEM |
| Access logs for the SIEM itself | Wazuh server and dashboard authentication logs; Graylog user authentication audit entries | That administrator and query activity on the SIEM is forwarded to a separate, protected store |
| Alert rule and threshold records | Wazuh rule files and ruleset change history; Graylog event definitions and their configuration exports | Version control or change approval records for each rule and threshold change |
| Review and triage records | Dashboard alert queues with analyst notes, plus the case management record | That daily or regular log reviews are documented with reviewer, date and outcome |
| Incident tickets with timestamps | Case management record linked to Wazuh or Graylog alert identifiers | Timestamps from synchronized time sources and the authority's required reporting fields |
| Security tool and Security Onion detection logs | Security Onion sensor and Suricata or Zeek alert data, forwarded to the central store | Whether network sensor logs are retained for the period your policy sets |
| Tabletop and incident response test reports | Written reports from your own exercises, filed in the case management or document system | Test intervals and the format the CSIRT or competent authority expects for submission |
What a SIEM alone does not satisfy
Point 3.2 of Implementing Regulation 2024/2690 covers logging and monitoring, but the same annex asks for a written incident handling policy, defined response roles, tested procedures and reviews that a SIEM cannot produce by itself. The cards below cover the people, documents and decisions an entity must own so that the SIEM output becomes accountable incident handling.
Incident handling policy and roles
The incident handling policy must set an incident categorization system, escalation and reporting communication plans, and assigned response roles, supported by response manuals, escalation charts, contact lists and templates. A SIEM generates alerts, but only a named role can decide that an alert is an incident. Check that every alert severity maps to a documented owner and a backup, and that the policy is approved by management and kept current. Illustrative: an alert with no named on-call owner at night will sit unassessed regardless of how good the rule is.
Categorization and escalation plans
Categorization gives each event a class that drives who is paged, how fast, and which reporting path applies. The escalation chart should tie SIEM alert classes to these categories and to the timing of NIS2 early warning and notification steps set under Article 23. Confirm with your national competent authority and CSIRT how they expect the first reports to be made, since the regulation does not fix those channels in the SIEM context. Keep the mapping as a versioned document so auditors can see what changed and when.
CSIRT and authority communication
Incident response must include communication plans with the CSIRT or competent authority. A self-hosted SIEM can export evidence and alert timelines, but it does not decide who calls whom or through which secure channel. Agree contact points, reporting formats and out-of-hours arrangements before an incident, and test them. Confirm whether your Member State designates a specific CSIRT and what it requires in its reporting portal or template.
Log retention period you set
The regulation requires logs to be kept and backed up for a predefined period and protected from unauthorized change, but it sets no fixed retention number. The period is your decision and must be written down, justified against your risk assessment and national law, and enforced in the SIEM through index lifecycle or rotation settings. Check that backups of the log store are also tested, and that retention applies to security tool logs and backup configuration files as well as network and user activity.
Post-incident reviews and tested response
Incident response procedures must cover containment, eradication and recovery and be tested at planned intervals, and post-incident reviews feed lessons back into the policy and detection rules. A SIEM records what happened during an incident, which is the raw material for a review. Schedule tabletop or technical exercises, record their results, and track corrective actions to closure. Ask your partner which review templates and exercise records they will produce as part of the delivery.
Staffing for regular log review
Logs must be reviewed regularly for unusual trends, and alarm thresholds must trigger a timely, qualified response. Automation can raise alerts, but someone must perform and document the review, and the reviewer must be competent to assess the alert. Define who reviews which sources and at what cadence, how coverage survives holidays and absences, and how reviewer training is recorded. Staffing is a recurring cost, so include it in your SIEM business case from the start.
No certificate, pending amendments
NIS2 creates no certificate of compliance. National authorities supervise through inspections, security audits, scans, information requests and administrative fines, so the evidence you keep is what you show them. Separately, the Commission proposed targeted amendments on 20 January 2026 (COM(2026) 13), including a new small mid-cap category, which still need approval by Parliament and Council. Track the proposal and your national transposition law, and confirm with counsel how any change affects your entity category.
Questions buyers ask before hiring help with NIS2 SIEM work
What drives the cost of a self-hosted NIS2 SIEM project?
The main drivers are the number of log sources, daily ingest, how long logs must stay searchable, how much detection content must be written and tuned, and who staffs the work. Costs split into one-time items (design, deployment, onboarding log sources, writing detections, testing the incident response procedures) and recurring items (compute and storage that grow with ingest and retention, licenses for any paid edition, patching, rule tuning and on-call monitoring). Software from Wazuh or Graylog Open carries no license fee, so the budget mostly goes to infrastructure and people. Ask any provider for a quote that lists each source, the assumed daily ingest, retention in hot and archive tiers, and who runs the platform after go-live.
Can our internal team run a NIS2 SIEM without outside help?
Yes, many organizations do, provided they have people who can operate Linux servers, manage agents, write and tune detection rules, and maintain the storage platform. The harder part is the process evidence: Implementing Regulation 2024/2690 expects reviews of logs for unusual trends, alarm thresholds followed by a timely, qualified response, and tested incident response procedures. Those are staffing and governance questions as much as technical ones. Before deciding, count the engineers who would own the platform, check whether they have time for patch cycles, and decide who reviews alerts outside business hours.
How long does a NIS2 SIEM rollout take?
The duration depends on scope: how many systems and sites must send logs, whether the platform is built in a cloud account, a data center or an air-gapped network, how many detection use cases are in scope, and how quickly the client approves changes. No fixed timeline applies across organizations. Wazuh's 4.14 line shows how often patch releases arrive (six patch releases in 2026 through October 14), so plan for ongoing maintenance as well as the first build. DeployOpen agrees timelines in writing as part of a fixed-scope engagement, so ask for a phased plan with dated milestones tied to log source onboarding.
What do we need to provide before an implementation partner starts?
A partner needs an asset inventory listing systems, applications, network devices and cloud accounts, along with their owners and the log types each can produce. The client should also name a sponsor who approves scope and retention, technical owners for each source, and an approver for changes to production systems. Document where logs may be stored, who may read them, and which contacts receive alerts and incident communications, because the incident handling policy must include escalation and reporting roles. Missing inventory data is the most common cause of delays, so collect it before signing the statement of work.
Is Wazuh or Graylog Open the better fit for our license requirements?
It depends on how your legal team reads each license. Wazuh's core repository is licensed under GPL version 2, with an exception permitting linking with OpenSSL, and includes the indexer, server, dashboard and agents. Graylog Open is licensed under the Server Side Public License version 1 (SSPL-1.0), which is not an OSI-approved license, so have counsel review it against your distribution and hosting plans. Graylog's pricing page lists Graylog Open as free with no volume limits and community support, while Graylog Enterprise starts at 15,000 US dollars per year and Graylog Security at 18,000 US dollars per year, each with a minimum of 10 GB per day or 100 Graylog Compute Units. Those paid tiers add support and features such as a correlation engine and compliance packs, so compare them with the features you need.
What should we confirm with our national competent authority?
Confirm how your national transposition law applies to your entity, whether you are classified as essential or important, and which reporting channels and deadlines apply. NIS2 creates no certificate of compliance, so ask which evidence the authority expects during inspections, security audits or information requests. Also ask whether national rules add requirements beyond Implementing Regulation 2024/2690, including retention periods, since that regulation sets no fixed retention period for logs. Check whether the proposed amendments in COM(2026) 13 would change your category, because they still need approval by the European Parliament and the Council. ENISA's June 2025 technical guidance gives examples of evidence and can help frame your questions.
What logs must the SIEM collect to meet the Annex logging points?
Where appropriate, the regulation expects logs covering network traffic, user creation and permission changes, system and application access, authentication events, privileged activity, access to critical configuration and backup files, security tool logs, resource use, physical access and environmental events. Not every entity needs every category, so map each one to a system you run and record the decision. Graylog's sizing guidance suggests daily ingest multiplied by retention days and multiplied by 120 percent for log storage, with the message journal at 3 to 5 times daily ingest on SSDs. Use those formulas as a starting point and replace the inputs with measured figures from your own sources.
How a NIS2 SIEM rollout is phased
The sequence moves from defining what is in scope to proving that the SIEM supports incident handling in practice, so each phase produces evidence an authority or auditor can sample. Work stays in the client's own infrastructure throughout.
Confirm scope and build the asset inventory
The client confirms which entities, sites and systems fall under its NIS2 obligations, and the implementation team maps them into an asset inventory with owners, criticality and network zones. The team also confirms the sector annex and whether the entity is essential or important, since that shapes how much evidence the authority may request. The step closes when the client signs off the inventory and the list of log sources that must be onboarded.
Onboard log sources by priority
Sources are ranked by how directly they reveal incidents against critical services, starting with identity systems, remote access, firewalls, server and endpoint agents and cloud control planes. Wazuh agents are deployed where they can run, and syslog or API collection covers devices that cannot host an agent. The step closes when each source shows events arriving in the platform, with the time source confirmed and a record of what is still missing.
Tune detection rules and alert thresholds
The team enables detections for the event categories the regulation expects, including user creation, permission changes, authentication failures, privileged activity and access to critical configuration and backup files. Thresholds are tuned against a baseline period so that alarms fire on unusual trends without flooding the on-call queue. The step closes when test events trigger the expected alerts, each rule has a named owner, and the client accepts the tuning decisions in writing.
Set retention, backup and access controls
The client chooses a retention period for each log category, since the regulation requires a predefined period but sets no fixed length. The team configures backups, index lifecycle rules and restricted roles so that logs are protected from unauthorized access or change, and only defined staff can alter retention. The step closes when a restore test succeeds and the retention policy, access matrix and backup record are filed as evidence.
Integrate alerts with incident handling
Alerts are linked to the incident handling policy, including the categorization scheme, escalation paths, response roles and contact lists. Where automation is appropriate, the team connects triage steps and notifications to the response workflow, and it documents which alerts require a human decision. The step closes when a sample alert travels from detection to a recorded incident ticket with classification, owner and escalation timestamps.
Run tabletop exercises and close gaps
The client runs tabletop exercises that walk through containment, eradication, recovery and communication with the CSIRT or competent authority, using the SIEM outputs as the evidence trail. The team records what the exercise revealed, such as missing log sources, unclear reporting roles or slow escalation, and assigns fixes. The step closes with a dated exercise report, a gap register and a plan to repeat the test at planned intervals.
How DeployOpen scopes and delivers a NIS2 monitoring SIEM
DeployOpen starts every NIS2 monitoring engagement with a written scope that names the log sources, the detection content, the retention tiers and the evidence package before any build work begins. Engagements are fixed-scope, so the deliverables and timelines are agreed in writing first, and a quote follows from that scope. Scoping typically starts with an inventory of the systems in the entity's network and information systems that fall under the Annex to Implementing Regulation 2024/2690, then maps each system to the log categories in point 3.2.3, such as authentication events, privileged activity, security tool logs and backup file access. Confirm early whether your sector is covered by the Regulation's technical requirements or by your national transposition law, because that changes which systems the scope must reach.
Delivery takes place inside your own cloud accounts, data centers or segmented networks. DeployOpen installs the chosen platform, which may be Wazuh, Security Onion or Graylog Open on OpenSearch or Data Node, and onboards log sources through agents or syslog. Each source is tested for parsing, time synchronization and the fields the detection rules depend on. Detection configuration follows, covering alarm thresholds, automated alerting where appropriate and the routing that point 3.2.4 expects. Your incident response roles, escalation paths and CSIRT contacts from the incident handling policy must be supplied by your team, because DeployOpen cannot define your reporting decisions for you. Retention settings, index rotation and access controls on the logs themselves are configured and documented as part of the same work.
Evidence preparation covers the configuration exports, retention and backup records, detection test results and review logs that a competent authority or an independent auditor may request. DeployOpen prepares these artifacts and the documentation that explains them, but it does not issue audit reports, attestations or certifications, and NIS2 creates no certificate of compliance. After go-live, ongoing support, upgrades and continuous testing can be covered by a retainer, and the retainer terms should be agreed in writing alongside the initial scope. Ask any partner, including DeployOpen, for the named deliverables, acceptance tests and the support hours and response commitments in writing before signing.
