Most conversations about managed SIEM start in the same place: detection coverage, alert volumes, and mean time to respond. Those are reasonable things to evaluate. They are not what creates problems when an auditor walks in.
Audits focus on documentation. Whether an incident was detected quickly matters less than whether the organization can show what happened, what decisions were made, and what records support those conclusions. A managed SIEM that produces excellent alerts but incomplete evidence documentation can pass every security benchmark and still generate audit findings.
This article covers what auditors request under NIS2 and DORA, why detection capability and evidence capability are different things, and how to assess whether your current setup supports both.
What you'll learn:
Need to assess your evidence readiness now?
Download the Managed SIEM Compliance Evidence Checklist for NIS2 and DORA.
Download the checklistCompliance evidence is not the same as security data. Security data is what your SIEM collects: logs, alerts, event records. Compliance evidence is the subset of that data that can be located, organized, and presented to an auditor or regulator in a way that answers their specific questions.
An auditor asking for evidence of incident investigation does not want to see a raw log export. They want an investigation record showing what was detected, when it was detected, what analysis was performed, what the severity classification was, what actions were taken to contain and recover, and who was involved in those decisions.
That is a documentation requirement, not a detection requirement. And it is one that many managed SIEM deployments are never specifically configured or evaluated against.
The exact requests vary by framework and by the auditor, but the pattern is consistent. Across NIS2 and DORA assessments, the evidence requests that most commonly surface gaps fall into five categories.
Incident timelines. A reconstructed sequence of events from initial detection through containment and recovery. Auditors want to verify that the organization understood what happened and in what order. A SIEM needs to support this with searchable, timestamped records that can be retrieved for incidents from months earlier.
Investigation records. Documentation of the analysis performed during an incident. Who investigated. What they found. What they ruled out. What conclusions they reached. This is distinct from the alert itself. Many organizations discover during audits that their analysts investigated thoroughly but documented nothing.
Impact assessments. A documented evaluation of the business and operational impact of the incident. Under DORA, this is an explicit requirement for ICT incidents. Under NIS2, it informs whether the incident meets notification thresholds. If the assessment was not documented at the time, producing it later is difficult and creates credibility problems.
Containment and recovery documentation. Records of the specific actions taken to stop the incident and restore normal operations. Timelines, decision points, and outcomes. Auditors use these to assess whether the organization followed its own procedures and whether those procedures were adequate.
Evidence exports. The ability to produce the above records quickly, in a format that can be reviewed externally. This is where many organizations discover that evidence exists somewhere in their systems but cannot be easily assembled or exported when requested.
Detection and evidence production are configured separately. A managed SIEM can be fully operational from a security standpoint and still have significant evidence gaps because evidence configuration was never specifically addressed.
The most common patterns that surface during audits:
Logs retained but not organized for retrieval. Data exists. Finding the right records for a specific incident from six months ago takes hours rather than minutes. During an audit or regulatory review, that delay is itself a finding.
Investigation activity not documented. Analysts investigated the incident and resolved it. The alert was closed. Nothing in the SIEM or incident management system shows what the investigation actually involved. The security control worked. The evidence trail did not.
Incident classifications applied inconsistently. Some incidents were classified by severity. Others were not. DORA requires documented classification criteria. NIS2 requires severity assessment to inform notification decisions. Inconsistent classification makes it difficult to demonstrate that the organization applied a structured process.
Evidence cannot be exported in a usable format. Records exist but are locked in a platform that does not support clean export. Producing an evidence package requires manual extraction and formatting, which takes time the organization does not have when a regulatory request arrives with a deadline.
None of these are detection failures. They are evidence management failures, and they are common in organizations that evaluated their managed SIEM on security performance without separately evaluating its compliance evidence capabilities.
Read also: NIS2 Supplier Risk Assessment: how to evaluate third-party cybersecurity risk
NIS2 does not require a specific SIEM platform. Article 21 requires essential and important entities to implement appropriate measures for incident handling, including detection, analysis, containment, and recovery. The evidence requirement follows from that: organizations need to be able to demonstrate that those measures were applied.
Article 23 requires significant incident notification within 24 hours of awareness, followed by a detailed report within 72 hours. That report needs to be grounded in actual records. An organization that cannot quickly retrieve incident timelines and impact assessments from its SIEM will produce that report under significant pressure, with an increased risk of inaccuracy.
The evidence areas NIS2 assessments typically examine:
Organizations that have a managed SIEM and believe they are covered for NIS2 often discover during a readiness review that detection coverage is solid and evidence documentation is not. The gap is usually not in the technology. It is in the processes and configuration around how incidents are documented as they are investigated.
DORA applies to financial entities regulated under EU law. Article 18 and the related Regulatory Technical Standards (RTS 2024/1772) set specific requirements for ICT incident classification, documentation, and reporting.
The evidence standard under DORA is more prescriptive than NIS2. Classification criteria must be documented and consistently applied. Business and operational impacts must be assessed and recorded. Investigation activities must be retained. Audit trails for critical systems and administrative actions are mandatory.
The evidence areas DORA assessments typically examine:
Financial entities under DORA face a specific additional challenge: the classification step. An incident that crosses certain thresholds triggers mandatory major incident reporting. If classification was not applied consistently or the criteria were not documented, demonstrating that the organization correctly identified which incidents required reporting becomes difficult.
Detection metrics and evidence metrics measure different things. A managed SIEM optimized for one is not automatically capable of the other.
| What detection capability measures | What evidence capability measures |
|---|---|
| Alert generation from security events | Incident timeline reconstruction |
| Threat identification speed | Investigation record completeness |
| Log collection coverage | Evidence retrieval speed |
| Response time to active threats | Audit trail availability |
| Rule and use case coverage | Classification consistency |
A managed SIEM can score well on every metric in the left column and still fail an audit on the right. Evaluating your managed SIEM only on detection performance leaves the evidence side untested until a review forces the issue.
A structured evidence readiness review covers six areas. Work through each and document where gaps exist.
Log retention. Are security logs retained according to defined policy and regulatory requirements? Is the retention period formally documented and consistently applied across all relevant log sources?
Audit trails. Can user activity, administrative actions, and security events be reconstructed from SIEM data? Can you trace what happened during a specific incident using records that already exist?
Incident documentation. Are investigations, timelines, decisions, and response activities documented as incidents are handled, or would producing them require reconstruction after the fact?
Reporting readiness. Can incident records support regulatory notification preparation under NIS2 or DORA timelines? Could your team produce the required information within 24 hours of a significant incident?
Evidence accessibility. Can required records be located and exported within a reasonable timeframe when requested? Is the process documented and tested?
Evidence gaps. Are there systems, services, or processes where required evidence is missing or would be difficult to produce quickly?
The most useful test is also the most direct one: select a real security incident from the past 12 months and attempt to produce the full evidence package, including incident timeline, investigation record, severity classification, impact assessment, containment actions, and supporting logs. How long it takes, and what you cannot find, tells you more than any checklist item.
Assess your evidence readiness before the next review
The Managed SIEM Compliance Evidence Checklist for NIS2 and DORA includes a NIS2 and DORA evidence checklist, a log retention worksheet, a compliance evidence gap inventory, and a scoring worksheet that rates your readiness from High risk to Audit-ready.
Download the checklistThe gap between detection capability and evidence readiness is real and common. Most organizations with a managed SIEM in place have the underlying data. What they often lack is the documentation structure, retention policy, and retrieval process to convert that data into evidence when a review requires it.
NIS2 and DORA both create specific, practical documentation obligations. Meeting them is not primarily a technology challenge. It is a configuration, process, and documentation challenge that requires explicitly evaluating your SIEM against an evidence standard, not just a security performance standard.
Identifying gaps before an audit is straightforward. Addressing them under audit pressure is not.
Read also:
Does NIS2 require a specific SIEM?
No. NIS2 requires outcomes: incident detection, documentation, and the ability to support regulatory reporting. How an organization achieves those outcomes is its own decision. A managed SIEM is the most common source of that evidence, but the regulatory standard is about what the organization can demonstrate, not which tool it uses.
What is the difference between a security log and compliance evidence?
A security log is raw event data collected by your SIEM. Compliance evidence is the organized, retrievable documentation that answers a specific question during an audit or regulatory review. The log is the source material. The evidence is what you can produce from it, in a usable format, within a reasonable timeframe.
How quickly does DORA require incident evidence to be available?
DORA does not specify a retrieval speed, but the major incident reporting timeline puts practical pressure on it. Initial notification is required within 4 hours of classification as a major incident. An intermediate report follows within 72 hours. Final report within one month. Organizations that cannot quickly retrieve investigation records and impact assessments will struggle to meet those timelines accurately.
What is the most common evidence gap in managed SIEM deployments?
Investigation records. Analysts investigate incidents and close them. The alert record shows the incident was resolved. Nothing shows what the investigation involved, what was ruled out, or what decisions were made. Detection worked. Documentation did not.
How do we test our evidence readiness without waiting for an audit?
Pick a real incident from the past 12 months. Attempt to produce the full evidence package: timeline, investigation record, severity classification, impact assessment, containment and recovery actions, and supporting logs. Measure how long it takes and what you cannot find. That exercise surfaces the actual gaps more reliably than any theoretical assessment.