A managed SIEM service should be able to produce more than stored logs. For NIS2 reporting and supervisory review, the useful evidence package connects monitored assets, source health, time-stamped events, alert logic, analyst decisions, incident scope, response actions, approvals, and export history. A reviewer should be able to follow what happened, what the team knew at each stage, who acted, and what changed afterward.
NIS2 does not require a named SIEM product, and a managed SIEM service does not make an organization compliant. The regulated entity still owns its risk decisions, policies, reporting duties, management oversight, and relationship with the competent authority. SIEM contributes technical and operational records to that wider evidence set.
This guide shows what to ask from a provider, what the evidence should prove, and how to test the service before a real incident starts the reporting clock.
SHORT ANSWER: A NIS2-ready managed SIEM evidence package links telemetry to decisions. It should show coverage, data continuity, detection and triage, incident chronology, response actions, reporting support, control review, and a traceable export path. Logs without context, ownership, or time integrity are weak evidence.
Find the gaps in your NIS2 evidence readiness
Use the NIS2 Compliance Self-Assessment Toolkit to assess incident handling, reporting readiness, supplier controls, and the evidence your organization can produce.
Download the NIS2 Compliance Self-Assessment ToolkitThe NIS2 Directive requires essential and important entities to apply appropriate and proportionate cybersecurity risk-management measures. The minimum areas include incident handling, business continuity, supply-chain security, vulnerability handling, evaluation of control effectiveness, access control, and asset management. Article 23 creates staged reporting for significant incidents.
Supervision is broader than a single certification audit. The European Commission's NIS2 FAQ explains that competent authorities can use regular or targeted audits, on-site and off-site checks, information requests, and access to documents or evidence. The exact process depends on whether the entity is essential or important, the Member State, the sector, and the facts of the case.
For specified digital providers, Commission Implementing Regulation (EU) 2024/2690 adds technical and methodological requirements. ENISA's implementation guidance supplies non-binding examples of evidence, including security-tool records, incident logs, response records, testing records, and proof that monitoring is operating. Other organizations should check their national transposition and sector guidance before treating those examples as their legal checklist.
A provider should demonstrate each evidence category with a live example or a sanitized record from the buyer's environment. A brochure or dashboard screenshot cannot prove that the same information is retained, searchable, attributable, and exportable when needed.
| Evidence category | What it should prove | Acceptance check |
| Scope and source coverage | Which assets and services are monitored, when each source last reported, and where coverage is missing | Export the source inventory, ownership, onboarding date, health state, last-event time, and gap history |
| Time and record integrity | Events can be placed in a reliable order and protected from silent alteration | Show time-source controls, time zone, raw event access, access history, retention rule, and integrity protection |
| Detection and triage | A rule or analytic fired, an analyst reviewed it, and the decision has a reason | Export the alert, triggering events, rule version, severity, analyst notes, disposition, and escalation timestamps |
| Incident chronology | The organization can reconstruct what happened and when it became aware | Produce one timeline linking evidence, affected assets, indicators, decisions, and changes in scope or impact |
| Response actions | Containment, eradication, and recovery actions were authorized, performed, checked, and reversed when required | Show actor, approval, action time, target, result, exception, rollback, and follow-up owner |
| Notification support | Security facts and internal approvals can support the 24-hour, 72-hour, and final reporting stages | Generate a reporting pack with awareness time, current assessment, indicators, impact, mitigation, approvals, and submission record |
| Control review | Monitoring is maintained and tested instead of left unchanged after onboarding | Show source-health reviews, rule changes, tuning reasons, incident exercises, review findings, and closed corrective actions |
| Provider access and change trail | Provider personnel and administrators acted within approved authority | Export analyst and admin access, privileged actions, rule changes, configuration changes, approvals, and customer-visible exceptions |
Evidence starts with scope. An incident record is hard to defend if no one can show whether identity, endpoint, firewall, cloud-control, email, application, and critical business-system sources were present at the time. The source inventory should connect each feed to an asset owner, a monitoring purpose, a collection state, and a last-seen time.
Ask for records of collection gaps. A healthy status today does not explain a four-hour outage during the incident. The provider should preserve notices, investigation notes, recovery times, and any decision to accept a gap. This is also where the buyer can see whether asset inventory changes reach the monitoring scope.
A useful timeline depends on consistent timestamps, known time zones, and access to the underlying event. The SIEM should retain normalized fields for search while preserving enough raw detail to explain where the record came from. Changes to parsing, enrichment, detection logic, or retention should have their own history.
Retention is not one number copied from a vendor page. The organization needs a documented policy based on incident investigation needs, reporting duties, national or sector requirements, contract terms, and data-protection limits. The provider must be able to implement that policy by data class and show when records were archived or deleted. The GDPR remains relevant when logs contain personal data.
An alert is the start of a decision record. The evidence should include the detection name and version, triggering records, supporting context, severity, analyst, disposition, escalation path, and time spent waiting for customer input. If an alert is closed as expected activity, the record should explain why.
This detail supports later questions about when the organization became aware of an incident. A dashboard count cannot settle that question. The investigation history needs to distinguish a raw event, an automated alert, an analyst-confirmed security event, and a significant incident assessment.
The provider should be able to assemble a single chronology from SIEM searches, alert history, endpoint or cloud evidence, case records, response actions, and customer decisions. Each item needs a source and a timestamp. Updates should not erase earlier assessments; the record should show how confidence, scope, and impact changed.
The chronology should also record handoffs. If the provider notified the customer's incident lead at 02:14, the record needs the channel, recipient, delivery state, required decision, response, and next escalation. A service-level report can show whether the contract was met, but the incident record should explain what occurred.
Containment evidence needs more than a note that an account was disabled or a host was isolated. Record who approved the action, who performed it, the target, the exact time, the result, the validation step, any business exception, and the condition for reversal. If the provider lacked authority, preserve the request and the customer's decision.
This distinction matters in a managed service. A provider can investigate and recommend while the customer controls production changes. The contract, incident plan, and evidence record must describe the same operating model.
For a significant incident, the Directive uses a staged process: an early warning within 24 hours of awareness, an incident notification within 72 hours, and a final report within one month. The competent authority or CSIRT can request an intermediate report. National processes and sector rules still need to be checked.
Within 24 hours: preserve awareness and the first facts
Do not wait for perfect certainty before preserving the first assessment. Later evidence can correct it, but the record should retain what was known and why the team acted at that point.
Within 72 hours: support severity, impact, and indicators
Within one month: explain cause, handling, and improvement
IMPORTANT LIMIT: The SIEM can supply technical records and investigation context. Legal, business-impact, customer-communication, management-approval, and regulatory-submission records often live in case management, ticketing, governance, continuity, legal, or communications systems. The final evidence pack must connect them.
Check the responsibilities and records outside the SIEM
Review incident reporting, roles, processes, documentation, evidence gaps, and supervisory readiness across the wider organization.
Download the NIS2 Compliance Self-Assessment ToolkitRun the test with buyer data before signature or during a controlled pilot. A provider can use a safe detection, a tabletop scenario, or a sanitized prior case. The result should be an evidence pack the buyer can keep and review without the provider narrating every screen.
Record the time required for each test and every manual dependency. If a critical export needs a special services request, named engineer, or unavailable portal role, that constraint belongs in the contract and incident plan.
Commercial scope matters. The Managed SIEM pricing guide can help separate included monitoring and evidence work from ingestion, retention, incident response, custom reporting, or exit charges. The broader Managed SIEM services guide explains the operating work that sits behind the platform.
SIEM evidence can show selected controls operating. It cannot establish the complete NIS2 position of the organization. A wider review still needs scope and applicability, risk assessments, policies, management approvals, supplier records, continuity plans, training records, vulnerability work, asset ownership, legal analysis, notification submissions, and proof that corrective actions were completed.
A provider report can also overstate certainty. A rule that generated alerts does not prove the monitoring scope was complete. A closed ticket does not prove the response was effective. A month of retained logs does not prove the chosen retention policy is suitable. Evidence needs a defined control, an owner, an expected result, a record of operation, and a review of exceptions.
A managed SIEM service is valuable for NIS2 when the evidence survives outside the dashboard. Ask the provider to trace one source, one alert, one incident, one response decision, and one reporting pack before you depend on the service. Keep the exports and record the gaps.
Q-Sec's Q-SOC service supports monitoring and incident operations. Its NIS2 compliance service covers the wider assessment, implementation, documentation, and supervisory-preparation work that sits outside SIEM.
Check whether your monitoring records can support reporting and supervision
Q-Sec can review SIEM coverage, incident records, response evidence, provider responsibilities, and the wider NIS2 documentation path.
Talk to the Q-Sec teamNo. NIS2 does not prescribe a named SIEM product. An entity needs appropriate and proportionate measures for its risks and duties. SIEM can support monitoring, detection, investigation, incident handling, reporting, and evidence production when the operating model and coverage are suitable.
No. The service can contribute records and operational capability. The entity retains responsibility for risk management, governance, policies, reporting, management oversight, supplier management, and the legal position under national law.
The Directive does not give one universal retention period for every entity and log type. Set a documented policy based on incident investigation, reporting, national and sector rules, contractual duties, legal needs, and data protection. Ask the provider to show that the platform and export process can follow that policy.
A screenshot can illustrate a state at one moment, but it is weak as the main record. Prefer exports with source identifiers, timestamps, fields, case history, access trail, and enough raw context to reproduce the finding. Keep screenshots as supporting material when they explain a view that the export does not preserve.
The customer should retain contractual ownership and timely access to its data, cases, analyst notes, response records, reports, and configuration history. The provider can operate the systems and preserve records, but access and portability should not depend on goodwill or one portal account.
A provider can prepare technical facts and support the workflow. Submission authority, legal review, management approval, and communication with the CSIRT or competent authority need explicit assignment under applicable national rules. Do not infer notification authority from a monitoring contract.
Logs record events. Evidence connects selected records to scope, time, source, integrity, a control or incident question, analyst interpretation, decisions, actions, ownership, and review. The connection makes the record useful to an investigator, manager, auditor, or competent authority.