Sovereign SIEM Audit Logging and Forensic Readiness for NIS-2 and DORA

Sovereign SIEM audit logging and forensic readiness describe the practice of collecting, preserving, and protecting security telemetry and incident evidence within infrastructure that remains under the exclusive legal control of the operating organisation, free from the reach of foreign jurisdiction. For European entities subject to the NIS-2 Directive (EU) 2022/2555 and the DORA Regulation (EU) 2022/2554, this is not merely a technical preference: it is a compliance requirement with direct regulatory consequences.

The Jurisdictional Problem with US-Controlled SIEM Services

Routing security telemetry through a US-controlled SIEM or cloud-native logging service creates a structural legal conflict that undermines the evidentiary value of the very logs regulators will request during an incident investigation.

The US Clarifying Lawful Overseas Use of Data (CLOUD) Act of 2018 empowers US law enforcement agencies to compel any US-incorporated provider to produce data stored anywhere in the world, regardless of where that data physically resides. FISA Section 702 extends this to foreign intelligence collection, without requiring prior judicial approval in the traditional sense. The European Data Protection Board has stated explicitly that the CLOUD Act allows US authorities to compel US-based providers to disclose data stored anywhere in the world, regardless of the data protection laws of the country where the data is located.

For a CISO or compliance officer at a European bank, hospital, or government body, this creates a specific scenario: during or after a serious cybersecurity incident, national competent authorities, the ECB, or EIOPA will request the organisation’s incident logs as primary evidence of what happened and whether controls were adequate. If those logs are held by a US-controlled vendor, a parallel US government request for the same data, issued without notice to the European organisation, cannot be excluded. The chain of custody is broken before the evidence reaches a regulator.

Microsoft received and responded to 2,640 national security orders in the second half of 2022 alone, according to its own transparency reporting. This is not a theoretical risk.

What the Regulations Actually Require

NIS-2, DORA, and GDPR each impose distinct but overlapping obligations on log retention, integrity, and chain of custody that collectively define the minimum standard for sovereign audit logging.

NIS-2 Directive Article 21 and Article 23

Article 21 of NIS-2 Directive (EU) 2022/2555 requires essential and important entities to implement technical and organisational measures that include logging and monitoring as a baseline security control. Article 23 requires incident notification to national CSIRTs within 24 hours of awareness of a significant incident, with a detailed report within 72 hours. Both obligations assume the organisation can produce a reliable, tamper-evident log record to support those notifications. The Directive does not prescribe a specific retention period, but the ENISA Good Practice Guide on Incident Reporting makes clear that logs must be retained long enough to support post-incident analysis and regulatory follow-up, typically interpreted as a minimum of 12 months for active logs and 24 months in cold storage for critical infrastructure sectors.

DORA Articles 17 to 19

DORA Regulation (EU) 2022/2554 is more prescriptive. Articles 17 to 19 require financial entities to classify ICT-related incidents according to a defined taxonomy, maintain records of all major ICT incidents for at least five years, and submit structured reports to competent authorities including the ECB and national supervisors. The five-year retention obligation is not optional: it must be enforced architecturally, not through manual processes that can fail or be overridden. Logs must be sufficient to reconstruct the full timeline of an incident, which implies event-level granularity, not summarised or aggregated records.

GDPR Article 5(2) Accountability

GDPR Article 5(2) imposes the accountability principle, requiring controllers to demonstrate compliance, not merely assert it. For processing activities that produce security logs containing personal data (IP addresses, user identifiers, access records), the organisation must be able to show that those logs are processed lawfully, stored securely, and accessible only to authorised parties. A log that has transited a foreign jurisdiction, or that cannot be proven to be unmodified, fails this test.

Deploying a Sovereign Open-Source SIEM Stack

Sovereign SIEM deployments built on open-source platforms eliminate the foreign-jurisdiction problem at its root by placing every component of the logging pipeline under the control of the organisation or a trusted national or Swiss host.

Wazuh as the Detection and Correlation Layer

Wazuh is an open-source SIEM and XDR platform that can be self-hosted on-premises or in a Swiss-hosted private cloud environment with no data leaving the defined security perimeter. It provides host-based intrusion detection, file integrity monitoring, log aggregation from Windows, Linux, and network infrastructure, and pre-built rule sets mapped to regulatory frameworks including GDPR and PCI-DSS. Importantly, Wazuh’s architecture separates the indexer (where logs are stored) from the manager (where detection rules run) and the dashboard, allowing organisations to implement storage-layer controls such as write-once volumes and cryptographic signing independently of the detection logic.

To meet NIS-2 and ISO/IEC 27037:2012 forensic readiness standards, Wazuh deployments must be supplemented with: cryptographic hash chaining on log files, timestamping via a trusted time authority (RFC 3161), role-based access controls that enforce separation between log writers and log readers, and documented procedures for evidence packaging when responding to a regulatory request.

OpenSearch and Elastic as the Aggregation and Retention Layer

OpenSearch (the open-source fork maintained independently of AWS commercial services) and Elastic (self-hosted, not Elastic Cloud) serve as the log aggregation and long-term retention back-ends. Both support index lifecycle management policies that can enforce the five-year DORA retention requirement automatically, moving data from hot to warm to cold storage tiers without manual intervention. Deployed in a Swiss-hosted environment under the revised Federal Act on Data Protection (revFADP, in force September 2023), these stacks are not subject to CLOUD Act compelled disclosure, because Swiss-law entities have no obligation to respond to US government requests.

IBM’s 2023 Cost of a Data Breach Report found that the average total cost of a breach reached USD 4.45 million, the highest in the report’s 18-year history. The same report found that approximately 40% of breaches had a mean time to identify exceeding 200 days, a figure directly linked to inadequate log visibility. Sovereign SIEM deployments address both the detection gap and the evidence preservation requirement simultaneously.

Forensic Readiness: ISO/IEC 27037 and ENISA Standards

Forensic readiness means that an organisation can respond to a regulatory investigation or legal proceeding by producing digital evidence that meets standards of authenticity, integrity, and provenance without needing to reconstruct or reconstruct its logging infrastructure after the fact.

ISO/IEC 27037:2012 defines the principles for digital evidence identification, collection, acquisition, and preservation. Applied to SIEM environments, it requires that: evidence be collected in a manner that does not alter the original; a documented chain of custody records every person who accessed the evidence and when; copies used for analysis are cryptographically verified against the original; and the collection process itself is documented and reproducible.

ENISA’s Good Practice Guide on Incident Reporting extends this to the regulatory context: organisations that cannot demonstrate the integrity and provenance of their incident logs during a supervisory inspection are, in effect, unable to prove their own compliance. This statement directly addresses the situation where logs exist but their evidentiary value is compromised by jurisdictional or custodial issues.

Practically, this means sovereign SIEM deployments should implement: append-only log storage with write-once enforcement at the storage layer; automated hash generation per log batch with hashes stored in a separate, independently controlled repository; timestamping using a qualified trust service provider recognised under eIDAS; and a named evidence custodian role with documented handover procedures.

Separating Security Telemetry from Operational Metrics

In multi-tenant or hybrid sovereign environments, combining high-sensitivity security telemetry (authentication events, privileged access logs, network anomaly alerts) with general operational metrics (application performance data, infrastructure utilisation) in a single log stream creates unnecessary exposure. If the operational metrics layer is managed by a third-party provider with weaker sovereignty guarantees, co-mingled logs contaminate the entire dataset.

The correct architectural pattern is to route security telemetry (classified as high sensitivity) through a dedicated, access-controlled index in the sovereign SIEM stack, with separate retention policies, access control lists, and encryption keys. Operational metrics can flow to a separate monitoring layer, which may have different sovereignty requirements. This separation must be documented in the organisation’s data classification policy and reflected in the SIEM’s index configuration, not simply assumed.

For financial entities under DORA, this separation also supports the requirement to classify incidents by severity and report only major ICT incidents to supervisors, without disclosing operational performance data that is outside the regulatory scope.

What Regulators Examine During On-Site Inspections

National competent authorities under NIS-2, the ECB under its SREP framework, and EIOPA under its DORA supervisory convergence work have begun to specify concrete audit evidence expectations during on-site inspections. Based on published supervisory guidelines and the ENISA Good Practice Guide, inspectors typically request demonstration of six capabilities: complete audit trails for privileged access events covering the full retention period; cryptographic proof of log integrity through hash chains or signed records; evidence that retention periods are enforced architecturally; documented incident classification using the DORA Article 18 taxonomy; the ability to produce a forensic timeline within a defined recovery time objective; and evidence that the logging infrastructure itself is protected against tampering, including access logs for the SIEM management layer.

Gaps in any of these areas are treated as material control deficiencies, not minor findings. For organisations in scope for both NIS-2 and DORA, a single sovereign SIEM deployment that is properly configured and documented can satisfy the evidentiary requirements of both regulatory regimes simultaneously, provided the architecture excludes foreign-jurisdiction components from the security telemetry pipeline.

FAQ

Does using a US-headquartered SIEM vendor automatically violate GDPR if logs are stored in an EU data centre?

Not automatically, but the risk is structural. Under the CLOUD Act, a US parent company can be compelled to produce data held by its subsidiaries worldwide, including EU-based infrastructure. If security logs contain personal data or incident evidence, that compelled transfer would lack a valid GDPR legal basis. Storing logs with a US-controlled vendor in an EU data centre does not remove this exposure.

What minimum log retention period does DORA require for ICT incident records?

DORA Articles 17 to 19 require financial entities to maintain ICT-related incident records for a minimum of five years. This includes logs sufficient to reconstruct the timeline of a major incident, supporting both internal post-incident review and submission to competent authorities such as the ECB or national supervisors.

Is Wazuh genuinely audit-ready, or does it require significant additional configuration to meet NIS-2 forensic standards?

Wazuh provides a solid open-source foundation, including file integrity monitoring, log aggregation, and alert correlation. To meet NIS-2 Article 21 and ISO/IEC 27037 forensic readiness, organisations must additionally configure cryptographic log signing, immutable storage back-ends, and documented chain-of-custody procedures. These are configuration and governance tasks, not product gaps.

How does Swiss hosting under the revised FADP reduce jurisdictional risk compared to EU-based hosting under a US-controlled provider?

Switzerland is not subject to the CLOUD Act or FISA 702 because those laws apply to US persons and US-incorporated entities. A Swiss hosting provider incorporated under Swiss law and with no US parent has no legal obligation to respond to US government data requests. The revised FADP, in force since September 2023, aligns Swiss data protection with GDPR-equivalent standards, satisfying EU adequacy requirements for cross-border transfers.

What specific evidence do EIOPA and national competent authorities expect during a DORA on-site inspection of a financial institution’s logging infrastructure?

Based on published EIOPA supervisory convergence guidelines and ECB SREP frameworks, inspectors typically request: complete audit trails for privileged access events, cryptographic proof of log integrity (hash chains or signed log records), evidence that retention periods are enforced automatically rather than by manual process, documented incident classification under the DORA Article 18 taxonomy, and the ability to produce a forensic timeline within a defined recovery time objective. Gaps in any of these areas are treated as material control deficiencies.