SIEM for NIS2: What Detection the Directive Actually Requires

NIS2 does not prescribe a particular SIEM product.

It does name technical measures, including cryptography and multi-factor authentication. National law and sector-specific rules also matter: in Germany, section 31(2) BSIG requires attack-detection systems for the systems essential to operating critical installations. Regulation (EU) 2024/2690 specifies monitoring and logging for the digital service categories within its scope. The suitable architecture therefore depends on entity type, risks and applicable requirements. Check national scope exceptions before applying these provisions; Germany has specific exceptions for certain financial entities and energy or telecommunications activities.

Logs can support incident handling, access-control checks and evaluation of security measures.

Article 21(2) does not establish that exactly six measures can only be evidenced through a central SIEM. Each measure needs appropriate, traceable evidence. Risk assessments, restoration tests, training records and management decisions remain relevant alongside technical logs. The design depends on risk, entity type and applicable rules.

Article 23(4) sets three stages.

Within 24 hours of becoming aware of a significant incident an early warning is due, indicating where applicable whether the incident is suspected to be caused by unlawful or malicious acts or to have cross-border impact. Within 72 hours the incident notification follows, including an initial assessment of severity and impact. A final report is due no later than one month after that notification. If the incident is still ongoing, a progress report takes its place first. Notifications must be made without undue delay; these are maximum periods. Article 23(4) provides a specific 24-hour incident-notification deadline for trust service providers. Verify the applicable national implementation and sector-specific rules.

Registration depends on the applicable national rules.

In Germany, section 33(1) BSIG gives particularly important and important entities, and domain-name registry service providers, up to three months after first or again meeting the stated conditions. Section 33(6) concerns the BSI registration procedure, rather than establishing that deadline. A missed registration should be remedied; registration does not demonstrate implementation of security measures. Section 33(2) refers registration of critical installations to section 8 of the KRITIS umbrella legislation.

NIS2 broadens the range of regulated entities and strengthens requirements for risk management, incident handling and evidence.

A SIEM project should start by identifying the entity and systems in scope, then selecting log sources, rules and escalation paths according to risk and applicable requirements. The 24-hour early-warning deadline is not a general requirement to detect every attack within 24 hours: it is tied to becoming aware of a significant incident. A SIEM supports assessment; it does not replace legal classification or organisational responsibility. Check national and sector-specific notification rules separately.

Start with a relevant attack scenario and available evidence, rather than a universal list of supposedly mandatory SIEM rules. Prioritise identity providers, privileged accounts, remote access, endpoints, network boundaries and critical applications according to risk and business impact. For each source, check the origin, timestamp, affected identity or resource, action and outcome where available. Verify parsing, time alignment and detection of missing events.

Editorial test example, not a customer case: In an authorised test environment, generate several failed sign-ins followed by a successful sign-in by a test administrator and a privilege change. Correlate the identity and system within a justified time window. Use an approved maintenance activity as a benign comparison. The assigned analyst checks the change authorisation, account and affected service; an anomaly alone does not prove an attack.

Keep the source events, rule version, expected and actual outcomes, alert and handling timestamps, decision, owner and unresolved defects in the test record. Correct and retest missed detections or failed benign comparisons. Assess service disruption, affected users and data to determine whether the event is a significant incident. A SIEM score does not replace that assessment or the recorded notification decision.

Supply-chain security includes relationships with direct suppliers and service providers. A SIEM can analyse only the events that are technically available and lawfully collected. Prioritise critical dependencies and privileged supplier access. Useful sources include VPN and identity logs, administrative changes, API access and cloud audit logs. Check unusual sign-in times, new privileges, unexpected transfers and interrupted log delivery.

Agree data access, permitted use, retention, notification procedures and responsible contacts with the supplier. Test a suspicious third-party access scenario through escalation and acknowledgement. An access or certificate alert is one signal; it does not establish the supplier's overall security posture or compliance. Supplier assessment, contract review and appropriate evidence remain separate responsibilities.

Separate mandatory incident notifications from voluntary sharing of threat information. Establish the competent authority, national procedure and responsible person for each entity before configuring technical exchanges. Share only information needed for the purpose, with appropriate authority, access restrictions and protection for personal or confidential data. Pseudonymisation does not automatically remove data-protection obligations.

For technical threat feeds, agreed formats such as STIX and TAXII can help interoperability; they are not universal NIS2 requirements. Record the source, confidence, permitted recipients and expiry of an indicator, and verify that recipients interpret it correctly. Test authentication, delivery acknowledgement and revocation of access. A SIEM integration supports the exchange but does not determine its legal basis or discharge the organisation's reporting duties.

Start with the entity, critical services, systems and applicable obligations. Use an asset inventory, threat scenarios, vulnerabilities and a business-owned impact assessment. SIEM events enrich this picture; they do not automatically produce a complete business impact analysis or a definitive compliance assessment.

Link each prioritised risk to a detection measure, accountable role and effectiveness test. For example, monitor a compromised administrator scenario using identity and change logs, while documenting unavailable sources as residual risk. Keep actions, due dates and risk acceptance in the risk register. Changes to services, threats or suppliers should trigger reassessment. Management review and traceable decisions connect operational monitoring with organisational governance. Risk scores can support prioritisation when their inputs and limitations are understood; they are not proof that every obligation is fulfilled.

SMEs should first verify whether they fall within the applicable scope; company size alone is not the whole test, and proportionality matters. Limited staffing, budget and integration capacity make prioritisation essential. Start with the services and attack scenarios carrying the greatest risk, then connect a manageable set of useful log sources.

Compare internal operation, managed SIEM and hybrid arrangements using total costs, required expertise, data access and actual response coverage. Specify who reviews alerts, who can contain an incident and who makes the notification decision. SaaS reduces some infrastructure work but still requires configuration, access management and oversight. A phased rollout should include acceptance tests and staff exercises. Outsourcing monitoring does not transfer the organisation's accountability or remove the need to verify service performance.

Assign responsibility for approving measures, operating the SIEM, assessing incidents, notifying authorities and accepting residual risks. Management needs an understandable view of covered risks, detection gaps, test results and overdue actions. SIEM data supports this view; decisions and accountability must be recorded through the organisation's governance process.

A useful management report covers critical logging outages, confirmed incidents, handling times, detection-test outcomes and unresolved risks. Explain the definition and limitations of each metric. A green dashboard is not a complete NIS2 compliance assessment. Review whether decisions were implemented and whether deputies, escalation routes and training work in practice. A particular committee structure or dashboard product is not a universal NIS2 requirement.

There is no universally optimal NIS2 SIEM architecture. Compare on-premises, cloud and hybrid operation using data access, protection needs, operational capacity, integrations and total cost. Relevant components include log sources and collectors, reliable transport, normalisation, analysis, protected storage and a working alert route. SaaS shifts some infrastructure responsibilities; it does not eliminate configuration or oversight.

Check buffering during connection failures, clock synchronisation, access controls, integrity protection and monitoring of the logging infrastructure itself. Set retention by purpose, risk and applicable legal requirements rather than assuming one universal duration. Test retrieval, export and restoration of relevant events. A system that receives logs but loses events under load or cannot reach an accountable responder has not demonstrated an effective detection process. SOAR and machine learning are optional design choices that need their own validation.

Separate legal scope from technical sector characteristics. Verify the entity's national implementation and any sector-specific regime. For example, Germany's section 28 BSIG contains exceptions for specified financial entities and certain energy and telecommunications activities. Financial entities covered by DORA need their applicable DORA obligations assessed separately; a shared detection use case does not make NIS2 and DORA interchangeable. Regulation (EU) 2024/2690 addresses specified digital service categories.

In energy and water, relevant scenarios may involve OT remote access, controller changes and network boundaries. Healthcare may prioritise identities, sensitive data and clinical service availability. Select sources and tests that fit the operating environment without endangering critical processes. SIEM logs alone do not establish environmental quality, patient safety or compliance with every sectoral requirement.

Define which threats matter to your services. Select appropriate government, sector, open or commercial sources and record provenance, freshness, confidence and permitted use. Correlate technical indicators such as IP addresses or file hashes with internal events and business context.

Test whether a feed produces actionable detections. Stale indicators, shared cloud infrastructure and poorly scoped rules can create false positives. Set expiry rules, maintenance ownership and feedback from triage. Strategic threat assessments and technical detection rules serve different purposes. An indicator match does not establish a particular attacker's identity. Neither machine learning nor a commercial feed reliably predicts future attacks or guarantees NIS2 compliance; their value should be demonstrated against relevant scenarios and measured operational results.

Inventory each legacy system's interfaces, logs, protection needs and constraints. Some devices cannot run agents or provide complete timestamps. Assess available system logs, upstream identity and remote-access records, and suitable passive network sensors. A SIEM does not automatically discover every device or develop missing application interfaces.

Test collection under realistic, authorised operating conditions. For production and OT systems, agree configuration changes and additional logging load with the operator first. Record missing data, compensating controls, accountable owners and modernisation actions. Buffering, protected transport and parser maintenance are operational requirements to address. Where direct visibility is unavailable, explain the limitations of compensating controls rather than claiming comprehensive monitoring.

Derive recovery objectives from a business-owned impact analysis. Where suitable sources are connected, a SIEM can flag backup failures, unusual administrative changes or attacks on recovery systems. It does not automatically calculate valid RTO/RPO targets, and a successful backup event does not prove recoverability.

Test restoration separately and record the recovered data state, elapsed time, dependencies and deviations. Also test how detection and alerting continue when the SIEM, a collector or a connection fails. Emergency contacts, alternative communication and handover to the crisis team belong in the process. Turn exercise findings into assigned actions and repeat the relevant tests after correction.

Design training by role: analysts practise triage and evidence handling, administrators practise log-source operation and controlled changes, and responsible staff practise incident assessment and notification. Management needs the understanding of risks, measures and evidence required for its responsibilities. A SIEM can provide exercise events but cannot automatically determine everyone's competence.

Use authorised test data and a realistic scenario with incomplete information. Check whether participants understand the alert, know their responsibilities, record decisions and escalate correctly. Keep learning objectives, participation, observed difficulties and follow-up actions. Attendance and successful performance in an exercise are different forms of evidence; neither replaces an effective operational process.

Maintain a traceable lifecycle for sources, rules and playbooks. Changes to services, identities, threats or legislation can require reassessment. Assign an owner and record which rules are modified, tested or retired.

Open interfaces, exportable data, versioned configuration and tested recovery make later changes easier. Review capacity, support lifecycles and supplier dependencies. AI, blockchain and immersive training are not universal NIS2 prerequisites. Evaluate new technology against a concrete benefit and its risks. A SIEM does not automatically anticipate legislation: monitoring legal developments, assessing their effect and approving changes remain organisational responsibilities.

Use metrics with explicit definitions and data sources: coverage of prioritised log sources, collection outages, processing delay, detection-test outcomes and time to triage and handling. For detection time, specify the starting event; the actual start of a real attack may be unknown.

Distinguish false alerts, missed test events and alerts awaiting assessment. Show sample size, period, severity and exceptions rather than only an average. For notifications, record awareness, assessment, authorisation and transmission separately. An automated overall NIS2 score or audit-readiness index is not evidence of conformity without supported assessment criteria. Technical test results, organisational evidence and legal assessment remain distinct.

Plan changes with system owners, operations and incident response. Record the purpose, affected sources and rules, risks, approval, maintenance window and rollback plan. Roles, communication and training are organisational tasks; a SIEM neither detects organisational resistance nor guarantees an uninterrupted rollout.

Introduce changes in stages and test both intended detections and known benign activities. Check data volume, system load, alert quality and responder availability. If problems occur, the previous configuration must be recoverable. Complete the change through documented acceptance and operational handover. A successful deployment alone does not demonstrate that detection and response work.

Compare total costs across licences, ingestion, storage, integrations, rule maintenance, analyst time, response coverage, training and effectiveness tests. Measure normal and peak data volumes and required query performance. Compare prices only where scope and operating models are comparable.

Prioritise sources and detection scenarios by risk. Remove unnecessary duplication and align storage tiers with justified retention and access requirements. Do not indiscriminately discard security-relevant data to stay below a licensing threshold. Automation is useful when a tested, controllable workflow demonstrably reduces handling effort. For an initial discussion, bring existing sources, data volumes, operating hours and known gaps. Project scope and effort can then be established without inventing a universal package price.

A well-operated SIEM can accelerate investigations, expose recurring attack patterns and improve coordination between IT, security and business teams. These benefits depend on usable data, relevant rules and an alert process that people actually operate, rather than installation alone.

Assess improvements through comparable detection tests, handling effort and documented incidents. For example, a new cloud integration can be checked for unusual access or configuration changes when suitable audit logs are available. Customer trust, market access and financial return are potential downstream effects, not guaranteed SIEM outcomes. Support such claims with relevant evidence and clearly stated limitations.

Assess SIEM and operating providers against required integrations, data access, support, response coverage, security evidence and exit options. Financial stability and contractual risks require assessment outside the SIEM. Operational events cannot automatically establish a supplier's viability or complete regulatory conformity.

Agree responsibilities, escalation, data processing, subcontractors, log export, retention and incident support. Check service levels against defined measurement points and actual cases. Test collaboration when acknowledgement is missing and verify data handover for a provider change. Certificates and assurance reports must cover the contracted service; their existence alone does not replace risk assessment.

AI can help group similar alerts, analyse behaviour and summarise investigation data. Verify its value in your environment using suitable test cases, false alerts, missed events and analyst effort. A plausible summary is not a confirmed finding.

Assess data access, protection of confidential logs, traceability, model changes and human approvals. Automated intervention in critical systems requires constrained permissions, tested fallback procedures and explicit accountability. Start with bounded assistance tasks. AI does not reliably predict future attacks or certify NIS2 conformity. Retain verifiable rules and a workable process for model failures or incorrect recommendations.