Why a self-hosted SIEM is a sovereignty decision, not only a tooling decision
Self-hosting a SIEM inside EU infrastructure keeps security log data and the personal data it carries out of third-country transfer chains, and Wazuh and OpenSearch-based stacks are the usual starting points. Picture an EU security lead who must move logs off a US-hosted SIEM service: the question is not only which product to run, but where every copy of the logs, every backup and every support session touches data.
Security logs are personal data more often than teams expect. Authentication events carry user names, endpoint and firewall records carry IP addresses, and alerts often quote email subjects, file paths or customer identifiers. That makes the SIEM itself a processing system under GDPR, with its own lawful basis, retention limits and records of processing. The GDPR text on EUR-Lex is the natural starting point for mapping those obligations to the logs you collect.
The platform choice follows the controller's own exposure, not the software alone. A vendor's support staff who view a screen from a third country, a cloud region outside the EEA, or a provider subject to foreign disclosure orders can each create a transfer or a risk that needs assessment. Before choosing a deployment, confirm with counsel which of your log sources hold personal data, where administrators and support vendors sit, and which provider entities could be compelled to disclose data. Those answers decide whether self-hosting in your own EU accounts is the right control, and they shape the design that follows.
Which requirements drive EU-hosted log management
This table maps each legal requirement that shapes where security logs can live and who can touch them to a concrete build decision. Read the first column for the rule, then the second for what it changes in your SIEM design. The main takeaway is that remote support access and storage location count as transfers, so the constraint applies to the SIEM's operations as well as its data.
| Requirement | What it means for the build | Evidence to ask for |
|---|---|---|
| GDPR Article 44 and Chapter V transfer conditions | Every transfer of personal data to a third country, including onward transfers, must meet Chapter V. Log events often contain usernames, IP addresses and device identifiers, so they count as personal data. | Data flow diagram showing every system, backup and support path that touches log data |
| Remote access and EEA-external storage as transfers (EDPB Guidelines 05/2021) | Vendor engineers in a third country viewing dashboards, even only on screen, is a transfer. Cloud storage outside the EEA is also a transfer. Support sessions and backup targets must be scoped to EEA locations. | Written support access procedure with locations, session logging and approved backup regions |
| GDPR Article 48 limits on third-country disclosure orders | A foreign court or authority order to disclose personal data is recognized only where an international agreement such as a mutual legal assistance treaty applies. Your processor contract should require notice and challenge before any disclosure. | Processor contract clauses on government access requests and the notification process |
| CLOUD Act reach under 18 U.S.C. 2713 | US-headquartered providers must preserve or disclose data in their possession, custody or control, wherever it is stored. Hosting a SIEM in an EU region of a US provider does not remove this exposure, so ask the provider directly. | Written answer from the provider on US control over the data and support staff |
| Data Privacy Framework status (Decision 2023/1795 and pending Case C-703/25 P) | Transfers to a US importer rely on it only if that importer is on the Data Privacy Framework List. An appeal against the General Court's September 2025 judgment is pending, so the basis could change. Plan a fallback that does not depend on it. | Current DPF List entry for the vendor and legal review of the appeal's status |
| EU Data Act Article 32 and switching rights (Articles 25, 29 and 50) | Providers must take measures against third-country governmental access to non-personal data held in the EU. Customers have a right to switch to another provider or to on-premises infrastructure, with a maximum two-month notice period, a 30-day transition, and no switching charges from 12 January 2027. | Exit plan and export format for indices, rules and archived logs, plus the provider's Article 25 terms |
| NIS2 logging and monitoring expectations (see the NIS2 logging page) | NIS2 expects in-scope entities to produce logs, retention and detection evidence for incident handling. The SIEM must hold these logs in a form national authorities can review without relying on a foreign-hosted service. | Retention schedule, log source inventory and incident records mapped to the NIS2 measures |
How license terms change what you can run in your own EU estate
The GNU General Public License version 2 is a copyleft license, so distributing modified copies of the covered code generally means making the corresponding source available under the same terms. Wazuh is distributed under GPL-2.0 with an exception that permits linking with the OpenSSL library, and Suricata is licensed under GPL-2.0 as well. For a sovereignty project that runs these tools inside your own estate, the license does not restrict where you host them or which EU data centers you use. The obligations mostly appear when you modify the code and redistribute it, or when you ship a derivative to other organizations.
- Hosting: Running unmodified Wazuh or Suricata in your own EU infrastructure does not create a transfer or a license conflict by itself.
- Modification: Internal changes to rules, decoders or configuration are different from patched binaries you distribute to third parties. Ask counsel where your changes fall.
- Enterprise add-ons: Commercial support or managed services are separate contracts. Confirm which Wazuh features are in the core repository and which come from other offerings.
- Sensor and agent distribution: If you push agents to subsidiaries or vendors, confirm how the copyleft terms apply to those distributions.
- Exception terms: Read the Wazuh LICENSE file for the OpenSSL linking exception rather than relying on a summary.
Have counsel confirm the obligations for your specific modifications and distribution model before you rely on them in a sovereignty design.
The Apache License 2.0 is permissive. You can run, modify and redistribute the code, including in closed products, provided you keep notices and follow the license terms. All software in the OpenSearch project is released under Apache-2.0, and the OpenSearch FAQ does not describe any paid edition. Keycloak is also Apache-2.0. OpenCTI ships a Community Edition under Apache-2.0, but its Enterprise Edition falls under a separate OpenCTI Enterprise Edition License, so the two editions must be treated differently.
- Hosting: Apache-licensed components can run in any EU data center, private cloud or air-gapped network without a license barrier to location.
- Modification: Changes to OpenSearch or Keycloak are permitted, but a fork creates your own maintenance obligations for patches.
- Enterprise add-ons: For OpenCTI, the Community Edition and Enterprise Edition are different licenses. Features in the Enterprise Edition require a separate agreement.
- Foundation governance: The OpenSearch Software Foundation is a Linux Foundation project, and it is not involved in technical oversight of the project, so your upgrade planning should not assume foundation-led release decisions.
- Supporting services: Vendor support contracts are separate from the license, so price them in your quote.
Confirm which OpenCTI features you need are in the Community Edition before you design around them.
Security Onion is licensed under the Elastic License 2.0, which is a source-available license and not an OSI-approved open source license. It allows you to use, copy and modify the software for most internal purposes, but it restricts providing the software to third parties as a managed service and circumventing license key functions. Security Onion bundles Suricata, Zeek, osquery and the Elastic stack, so the license terms of the bundle need review alongside Security Onion's own license. In a sovereignty project, the main question is whether your operating model fits the restrictions, especially if a partner or managed provider operates the platform for you.
- Hosting: Self-hosting inside your own EU infrastructure for your own security operations is the usual pattern the license is written around. Confirm this against the license text.
- Modification: Internal modification is generally allowed, but removing license key protections is restricted. Check any custom work against the terms.
- Managed service delivery: If a third party runs Security Onion as a hosted service for your organization, have counsel confirm whether that arrangement is permitted.
- Bundled components: Suricata and Zeek carry their own licenses, which apply separately to those components.
- Release tracking: Release 3.3.0-20260911 was published on September 11, 2026. Confirm the release you deploy and its bundled versions.
Have counsel review the Elastic License 2.0 text against your operating model and any partner delivery model before selecting Security Onion.
The GNU Affero General Public License version 3 extends copyleft to software used over a network. If you modify AGPL-3.0 software and let users interact with it remotely, you generally must offer those users the corresponding source of your modified version. MISP, ZITADEL and Shuffle are all licensed under AGPL-3.0. For a sovereignty project, this matters most when you customize an identity provider, threat intelligence sharing platform or SOAR workflow engine that staff or partner organizations access through a web interface.
- Hosting: Running unmodified AGPL-3.0 platforms on EU infrastructure is not restricted by location. The network clause matters only when you change the code.
- Modification: Custom connectors, theming or patches to ZITADEL, MISP or Shuffle can trigger source offer obligations when users reach them over a network.
- Sharing communities: MISP sharing with external communities is a data governance question as well as a license question. Check the data handling terms agreed with each community.
- Enterprise features: Confirm which features each vendor reserves for paid or separately licensed editions, since the core license alone does not settle that.
- Version tracking: MISP v2.5.50, ZITADEL v4.19.5 and Shuffle v2.3.0 were the versions supplied for this topic. Confirm the release you deploy.
Have counsel confirm how the network clause applies to your planned customizations before you change any of these platforms.
The Mozilla Public License 2.0 is a file-level copyleft license. Modified MPL-covered files must stay under MPL-2.0 when distributed, but you can combine the covered code with proprietary code in a larger work. OpenBao manages, stores and distributes secrets, certificates and keys, is licensed under MPL-2.0, and is hosted under the OpenSSF. For sovereignty projects, that combination of file-level scope and open governance often suits a secrets platform that holds key material, because you can keep your own integration and deployment code private.
- Hosting: OpenBao can run in your own EU data centers or air-gapped networks. The license does not restrict location.
- Modification: Changes to OpenBao source files must remain available under MPL-2.0 if you distribute them, but your separate integration modules may stay proprietary.
- Key custody: Where keys are held is an operational and regulatory decision, not a license question. Confirm key custody requirements with your regulator or auditor.
- Governance: OpenSSF hosting describes the project's governance, not your support contract. Price vendor or partner support separately.
- Version tracking: OpenBao v2.7.1 was published on October 1, 2026. Confirm your upgrade path before the pinned version falls out of support.
Have counsel confirm how MPL-2.0 file-level obligations apply to your internal modifications and integrations.
HashiCorp Vault version 1.15.0 and later is licensed under the Business Source License 1.1, with IBM named as licensor. The Business Source License is not an OSI-approved open source license. It makes source code visible and allows certain uses, but it restricts other uses, including some commercial offerings, and it converts to an open source license after a set period. Vault versions before 1.15.0 are a different case, so the version you run matters. For sovereignty projects, the license question is whether your use of Vault and any partner delivery model fall within the permitted uses.
- Version boundary: Vault 1.15.0 and later fall under BSL 1.1. Older versions may carry different terms, so confirm the version you already run.
- Permitted use: Internal use within your own organization is the usual pattern. Confirm whether your planned operating model, including partner-operated instances, is permitted.
- Not open source: Do not describe Vault as open source in procurement documents or sovereignty assessments.
- Ownership changes: The named licensor is IBM. Note the licensor in your vendor register and track any changes to the license.
- Alternatives: OpenBao, covered in the previous tab, is a separately licensed project. Compare the licenses directly rather than assuming equivalence.
Have counsel confirm the BSL 1.1 terms and the permitted uses for your deployment before you adopt or continue running Vault.
How transfer exposure reaches your SIEM logs
Personal data enters the SIEM at the first hop, not at the dashboard. In a Wazuh deployment, Wazuh agents on Linux, Windows and macOS endpoints forward events to the Wazuh server, which decodes them and applies rules. Firewalls and other devices that cannot run an agent send syslog to the server, and the server stores alerts in the Wazuh indexer, an OpenSearch-based store, before analysts read them in the Wazuh dashboard. Usernames, IP addresses, hostnames and email addresses appear in nearly every one of these hops, so each component is a place where personal data is stored or displayed. Map each hop to a physical location, an operator and an access path in your own records before you decide what is in scope.
Transfers happen through access and control planes, not only through storage. Under EDPB Guidelines 05/2021, remote access from a third country, even only displaying data on a screen for support, is a transfer, and so is storage in a cloud outside the EEA. A vendor support session that opens the dashboard or indexer from outside the EEA, a remote upgrade tool that reads logs, or a US-hosted SaaS control plane that receives alert content each creates an exposure point even when the data itself stays in an EU data center. Ask every party with administrative reach over the stack where its engineers sit, and record how support access is granted, logged and time-limited.
An EU processor is not automatically outside third-country law. EDPB Guidelines 05/2021 (Example 12) say that using an EU processor subject to third-country law with extraterritorial effect is not itself a transfer, but complying with a third-country authority request would be. Before you engage an implementation partner or a managed service, assess whether that party, its parent company or its sub-processors could be compelled to disclose logs under laws such as the US CLOUD Act (18 U.S.C. 2713), and document the answer. Confirm with the partner which entities hold administrative credentials and where backups of the indexer are kept.
Which platforms fit an EU sovereignty SIEM and why
A sovereignty SIEM keeps every log, index and key inside EU infrastructure, so each component must be self-hostable and its license must allow the deployment you plan. The cards below cover the core platforms and the license or operational checks each one needs before you commit.
Wazuh as the collection and analysis core
Wazuh is the most common starting point because its core repository is licensed under GPL-2.0, and its server, indexer, dashboard and agents all run inside your own network. Agents cover Linux, Windows, macOS, Solaris, AIX and HP-UX, and agentless syslog covers firewalls and other devices that cannot run an agent. Its offline installation guide matters for sovereign sites with no outbound connectivity. Confirm which components you redistribute, since the license terms apply per component and your integrator should document the split.
OpenSearch as the search and analytics layer
OpenSearch is released under Apache-2.0 and stores the alerts and events that Wazuh's indexer or a Graylog deployment produces. Its Security plugin provides role-based access control, document-level and field-level security, field masking and audit logs, so SOC analysts see only the log fields they need. Confirm that your chosen authentication backend (SAML, OpenID Connect, LDAP or Kerberos) matches your directory, and plan version maintenance because each release line leaves maintenance on a fixed schedule.
Security Onion and its Elastic License
Security Onion bundles Suricata, Zeek, osquery and the Elastic stack into one monitoring distribution, which suits a team that wants sensors and log management delivered together. Its release line is licensed under the Elastic License 2.0, which contains terms on providing the software as a managed service and on removing license notices, so legal review is needed before you offer it to a third party or rebuild it for internal distribution. Confirm the terms with your counsel rather than assuming open source freedoms apply.
Suricata and Zeek for network sensors
Suricata (GPL-2.0) provides intrusion detection and network security monitoring, while Zeek (BSD-style license) produces structured network metadata such as connection and protocol logs. Both run on sensors you place inside your network, so no traffic leaves the EU. Sensor placement decides what you see, and in a sovereignty design the sensors and their storage should sit in the same jurisdiction as the logs. Confirm throughput needs with your integrator before selecting hardware.
Keycloak for workforce SSO into the SIEM
Keycloak is licensed under Apache-2.0 and supports OpenID Connect, SAML 2.0 and LDAP or Active Directory federation, so analysts can sign into the dashboard with the same workforce identity used elsewhere. Central sign-on keeps the SIEM from becoming a separate account store that auditors must review. Check that multi-factor authentication is enforced at the identity provider, since the SIEM holds security events that attackers would target. Keycloak is an incubation project under the Cloud Native Computing Foundation, so confirm its support expectations with your partner.
OpenBao for key material
Encryption keys, certificates and service credentials for the SIEM, such as TLS keys for indexer nodes and API tokens for log sources, should be stored in a secrets system you control. OpenBao is licensed under MPL-2.0 and hosted under the OpenSSF, which avoids the Business Source License that applies to HashiCorp Vault 1.15.0 and later. Ask your integrator how keys are rotated, who holds unseal material and how key access is logged, since those answers become evidence during an assessment.
How the migration off a US-hosted SIEM is phased
The sequence moves logs and their personal data into EU infrastructure in stages, so that every source is mapped, every transfer is assessed, and the old tenant is shut down only after the new stack has proven its retention and access controls.
Map log sources and personal data locations
Start by inventorying every log source that feeds the current SIEM, including endpoints, identity providers, cloud control planes and SaaS applications. For each source, record which fields contain personal data such as usernames, IP addresses, email addresses and device identifiers, and where the current provider stores raw events, indexes, backups and support copies. Your security engineers and the data protection lead should sign off the map together. The step is done when every source has an owner, a field-level personal data note and a documented storage location, including any region in which the provider or its subprocessors hold data.
Run the transfer and vendor access assessment
Assess each transfer path against Chapter V of the GDPR, using the EDPB guidance on what counts as a transfer. Include remote administrative access from outside the EEA, support staff who can view data on screen, and any storage outside the EEA. Review the provider's contract, subprocessor list and its exposure to third-country legal requests, and document whether the provider could be compelled to disclose data under provisions such as 18 U.S.C. 2713. Legal counsel decides the outcome. The step closes with a written transfer assessment that lists each finding and the decision taken, which becomes input to the migration plan and to your records of processing.
Stand up the EU stack beside the old tenant
Deploy the self-hosted SIEM inside your EU infrastructure, using the components chosen for the job, such as Wazuh with its indexer, server and dashboard, or an OpenSearch-based platform. Configure identity-based access to the dashboard, TLS for node and client traffic and role-based access to the indexes. In parallel, enable dual forwarding so the same events reach the old service and the new stack. The step is done when both paths receive the same sample of events from each source, and the team can show that ingest, parsing and alerting work on the EU side without relying on the old tenant.
Onboard sources and tune detection rules
Move each mapped source to the EU stack in priority order, starting with identity and endpoint telemetry, then network and cloud logs. Rebuild correlation rules, alert thresholds and compliance dashboards on the new platform, and compare alert output with the old service for a defined review period agreed in your project plan. Tuning should remove noise and close gaps, and each rule change should be recorded with its reason. The step is done when every mapped source reports to the EU stack, the detection content has been reviewed by the SOC, and the differences in alerting have been explained and approved.
Cut over with retention and access verified
Switch alert routing and the SOC's working view to the EU stack, while keeping dual forwarding available for a rollback window agreed in advance. Before cutover, verify retention settings against your policy, confirm that index lifecycle rules delete or archive data on schedule, and test access controls by checking that only named roles can search sensitive indexes or view personal data fields. Confirm that audit logs of SIEM access are being written. The step is done when retention, role-based access and audit logging have each been tested with recorded results and signed off by the security and compliance owners.
Export historical logs from the old tenant
Export the historical data you need to keep, in a documented format, and load it into the EU platform or an EU archive tier, with hashes or checksums recorded so that integrity can be shown later. Confirm the export is complete by comparing event counts and time ranges per source. Ask the provider about its export tooling and the format it uses, and check whether any charges or notice periods apply. The Data Act gives customers the right to switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transition, and bans switching charges from 12 January 2027 (Articles 25, 29 and 50). Confirm how those articles apply to your contract. The step is done when the export is verified and the retained data sits inside EU infrastructure.
Decommission the old tenant with deletion evidence
Close the old tenant in the order the contract and your transfer assessment require: stop forwarding, revoke API keys and service accounts, remove access for staff and integrations, and then request deletion of stored data, including backups and subprocessor copies. Ask the provider for written confirmation of deletion, the scope it covers and the date it applies. File this with the transfer assessment and the export checksums. The step is done when the provider's deletion confirmation, the revocation record and the final export verification are stored together as evidence for your auditors and data protection authority.
Integration points that keep logs and admin access inside the EU
How do I keep SIEM identity and SSO inside the EU?
The SIEM's login path is a data flow too, because authentication events and user attributes are personal data. Wazuh's dashboard supports single sign-on, so the identity provider you connect it to decides where those attributes travel. If your workforce directory is Active Directory or LDAP on EU infrastructure, you can federate to a self-hosted broker such as Keycloak, which is licensed under Apache-2.0 and supports SAML 2.0, OpenID Connect and LDAP or Active Directory federation. Confirm with your team which identity provider is in use, where it runs, whether any SaaS identity service sits in the login chain, and which accounts keep a local break-glass login if the IdP is unavailable.
Can Wazuh agents and server upgrades run without vendor cloud access?
Yes, the Wazuh server manages agent configuration and upgrades remotely, so the control path between the server and endpoints should stay on your own network. Agents on Linux, Windows and macOS report to the server you host, and nothing in that design requires a vendor-hosted endpoint. Before go-live, confirm which upgrade packages your team pulls from the internet and which mirror or internal repository they come from. Also confirm which agent versions your fleet runs, because the current 4.14 patch line changes frequently and agents and server must stay compatible. Plan the upgrade cadence with your change board, not with the vendor's release calendar.
Where should SIEM backups and their encryption keys be stored?
Backups of the indexer and server hold the same personal data as the live cluster, so they fall under the same transfer rules. Store snapshots in an EU-located object store or on-premises storage that you control, and confirm that no replication target sits in a third country. Encrypt backups at rest and in transit, and keep the keys in a key manager you operate, such as a self-hosted OpenBao instance, rather than in the backup tool's own configuration. Ask your provider how restores are tested, who holds the keys, and whether the backup vendor or any cloud operator can read the data.
How do syslog relays keep log traffic in EU zones?
Most log sources reach the SIEM through syslog relays, and a relay placed in a cloud region outside the EEA turns every forwarded event into a transfer. Put relays in the same EU zone as the SIEM or on the network segment that produces the logs, and restrict which hosts can send to them. Firewalls and network devices often send to the SIEM through Wazuh's syslog collection, so confirm the destination address and protocol for each device class. Ask for a data flow diagram that lists every hop, its location and its operator, and check it against your own network inventory during the rollout.
How should vendor remote access to a self-hosted SIEM be controlled?
Remote access from outside the EEA is a transfer under EDPB Guidelines 05/2021, even when a person only views data on a screen for support, so vendor sessions need the same scrutiny as data storage. Require named accounts for every engineer, time-limited access approved by your team, session recording where your policy requires it, and access over a path you control. Confirm where any support staff sit, whether they can see indexed log content, and how their access is removed after a ticket closes. Treat the access record as evidence in its own right.
How do air-gapped sites update Wazuh without internet access?
Wazuh documents an offline installation guide for systems without internet connectivity, and vulnerability detection can use an offline vulnerability repository instead of the Wazuh Cyber Threat Intelligence platform. Plan a media-based path: a controlled staging network receives signed packages and vulnerability data, which are then carried into the isolated enclave under your transfer procedure. Confirm which Wazuh packages, rules and vulnerability feeds you need, how often you will refresh them, and who verifies integrity before import. Each import is also a change that should be logged and reviewed.
Does a self-hosted SIEM still need a legal transfer assessment?
Hosting inside the EU lowers transfer exposure but does not remove it, because a non-EU vendor or operator with access to the data can still bring the data into scope. Under the US CLOUD Act provision at 18 U.S.C. 2713, a provider subject to US jurisdiction may have to preserve or disclose data it controls, wherever it is stored. Ask every vendor, operator and support contractor which legal jurisdiction they fall under, whether they hold keys or access, and how they handle government requests. Your legal team should document this as part of the transfer assessment before the design is approved.
Evidence a regulator or auditor will ask for
This table maps each piece of evidence a data protection authority, NIS2 competent authority or auditor is likely to request to the component that produces it. Read it as a starting inventory: DeployOpen prepares the systems, controls and records, while auditors and authorities decide whether the evidence is sufficient.
| Evidence item | Component that produces it | What to confirm before go-live |
|---|---|---|
| Data processing map and transfer assessment | Written records kept by the controller, informed by the log source inventory | Which personal data appears in each log source, where each copy is stored, and whether any administrator or vendor can view it from outside the EEA |
| Log source inventory | Wazuh dashboard agent and module views, plus syslog and API collection configuration | Every host, device and cloud feed sending logs, with the region where each one is ingested and indexed |
| Access logs for SIEM administrators | OpenSearch audit logs and Wazuh dashboard user activity | That audit logging is enabled for the indexer and dashboard, and that logs are forwarded to storage the SIEM administrators cannot edit |
| Retention configuration | OpenSearch index lifecycle policies and Wazuh indexer retention settings | The retention period in each jurisdiction's rules, and that exported configuration files are kept as dated evidence |
| Hosting location records | Infrastructure records from the client's cloud account, data center or air-gapped site, and backup location settings | Named regions or facilities, data center operator contracts, and confirmation that no replica or backup leaves the EEA |
| Vendor access logs | Remote support session records from the client's privileged access tooling and identity provider events from Keycloak | Whether vendor sessions run from inside the EEA, who approved each session, and how long the records are kept |
| Deletion records after migration | Backup records, retention job logs and decommissioning tickets from the source SaaS SIEM | Written confirmation from the former provider covering deletion of copies, plus proof that backups holding the old data expired or were destroyed |
What to ask an implementation partner about EU hosting
Ask the partner to name, in writing, the physical location of every SIEM component and backup: the Wazuh indexer, the Wazuh server and cluster nodes, the dashboard, the agent manager traffic path, the snapshot repository, and any off-site copy. Each location should be a named EU region or data center in the client's own cloud account or facility, with the provider and legal entity that operates it. Ask whether any component, log index, cached vulnerability data or support ticket attachment ever leaves that footprint. Wazuh's vulnerability detection can use an offline repository instead of the Wazuh Cyber Threat Intelligence platform, so confirm which feed the partner will use and where it is fetched from. Support tooling, monitoring SaaS and email alerting are the places where log fragments often leak, so ask for a complete list of external services that can receive any log field.
Ask for a named roster of everyone who can administer the SIEM, the operating system, the hypervisor and the backup system, with each person's employer, citizenship or country of residence, and the country they connect from. Under the EDPB guidelines, remote access from a third country, even only viewing data on a screen, is a transfer, so this roster is part of the transfer analysis, not an HR detail. Ask how each remote session is brokered, whether it is recorded, where the recordings are stored, and how access is blocked from outside the EEA, for example through geo-restricted network policy, conditional access on the identity provider, or a jump host inside the EU. Ask how the partner proves the block works and how the client is alerted when it is bypassed.
Ask for the partner's written procedure for a third-country legal request, including who receives it, how it is assessed against Article 48 of the GDPR, and whether the client is notified where the law permits. Ask whether the partner or its parent company is subject to the US CLOUD Act provision at 18 U.S.C. 2713, and how that exposure is handled for any component that holds the logs in the clear. Then ask for the license position of each component: Wazuh is under GPL version 2 with an OpenSSL linking exception, OpenSearch is under Apache-2.0 with no paid edition described in its FAQ, Security Onion is under the Elastic License 2.0, and Vault's Business Source License is not open source. Confirm each license with the vendor's repository before signing, and ask who is responsible for tracking license changes on upgrade. Finally, ask the partner to document the exit path under Articles 25 and 29 of the Data Act: the data export format, the timeline for moving indices and configuration to another provider or to on-premises infrastructure, and the switching charges, which the Data Act bans from 12 January 2027.
What a self-hosted EU SIEM migration involves
What drives the cost of moving a SIEM to EU infrastructure?
The cost is driven mainly by log volume, retention period, number of log sources and the amount of detection content to rebuild, not by the license of the platform itself. Wazuh's core is GPL-2.0 and OpenSearch is Apache 2.0, so the software line is usually small compared with infrastructure and engineering. Expect one-time costs for the design, source onboarding, parser and rule migration, and testing, plus recurring costs for compute, storage, backups, patching and support. Ask any partner for a written scope that separates these, names who pays for hardware or cloud accounts, and states what happens to the old SaaS contract's notice period and data export.
How long does a self-hosted SIEM migration take?
The timeline depends on how many log sources must move, how much existing detection logic must be translated, and how long the old SaaS service must run in parallel. Parallel running is the usual way to avoid gaps in monitoring, so the old and new platforms overlap until the new alerts are validated. No duration is set here; ask for a phased plan in the written scope with milestones for source onboarding, rule migration, validation, cutover and decommissioning. The EU Data Act also sets switching rules for customers leaving a data processing service, including a maximum two-month notice period and a 30-day transition, which should be checked against your current contract.
What does our team need to provide for the migration?
Your team typically supplies the inventory of log sources, access to the systems that produce logs, network paths from sources to the collectors, EU hosting accounts or data center capacity, and named owners who can approve detection and alert changes. Security and compliance staff must confirm which events regulators and auditors expect to see and how long each log type must be kept. Legal or the data protection officer should confirm where personal data in logs may be stored and who may access it. Ask the partner to list these inputs in writing so that gaps are visible before work starts.
Can our own team migrate the SIEM without a partner?
A capable internal team can do it, but the work is more than installing software. Wazuh has four components (the indexer, the server, the dashboard and agents), and the server can run as a cluster and manage agent configuration and upgrades remotely, so the platform itself is manageable. The harder parts are parsing and normalizing sources, translating detection rules, proving retention and access controls to an assessor, and keeping patch releases current. Wazuh shipped 4.14 patch releases on six dates in 2026, roughly every one to two months, so someone must own that cycle. Decide whether your team has capacity for a fixed-scope project and ongoing operations before choosing between self-service and a partner.
Is Wazuh or OpenSearch the better base for an EU SIEM?
Wazuh is usually the better starting point when you need endpoint agents, file integrity monitoring, vulnerability detection and prebuilt compliance views in one platform, because its server, rules and dashboard are built for security monitoring. OpenSearch is a stronger choice when you want a general search and analytics layer with your own detection content, dashboards and integrations. Wazuh's indexer is built on the OpenSearch project, so the two are closely related. Wazuh's core is licensed under GPL-2.0 and OpenSearch under Apache 2.0, and both can be self-hosted. Compare them against your log sources, team skills and the compliance views you need, and ask a partner to show how each would be deployed in your EU environment.
Does self-hosting a SIEM remove our GDPR obligations?
No. Self-hosting keeps logs out of a third country, which reduces transfer risk under GDPR Chapter V, but it does not remove your obligations as a controller. Logs often contain personal data such as usernames, IP addresses and email content, so you still need a lawful basis, a retention limit, access controls, security of processing and records of processing. Article 44 applies to every transfer, including onward transfers, and remote access from a third country counts as a transfer even when data is only displayed. Check that support staff, backup providers and any cloud host do not access logs from outside the EEA. Your data protection officer should review the design, and the written scope should state how each obligation is addressed.
What does a written scope for this migration need to cover?
A written scope should name the log sources in scope, the platform and version, the hosting location, the detection and compliance content to be migrated, the cutover and decommissioning steps, and the acceptance tests for each. It should also state what the partner does not cover, such as legal review, audit preparation and staffing of the security operations center. Ask for the handover of configuration, runbooks and documentation, and for the retention period of exported data from the old service. Deliverables and timelines agreed in writing before work starts are how this kind of engagement is normally scoped at DeployOpen, and a quote follows from that scope.
How DeployOpen scopes an EU-hosted SIEM
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For an EU-hosted SIEM, that means the Wazuh indexer, server and dashboard, and any OpenSearch or Security Onion components, run in the EU cloud accounts, data centers or on-premises networks you choose. Before any work starts, the scope is written down: which log sources are onboarded, which regions and accounts hold the indexer and archive tiers, who holds administrative access, and which compliance views and alert routes are delivered. Most engagements are fixed-scope, so deliverables and timelines are agreed in writing first, and a quote follows from that document.
Scoping for data sovereignty usually covers the points a buyer cannot easily retrofit: the hosting location of every component that stores or displays log content, the administrative paths used for remote support (since remote access from a third country can count as a transfer under the EDPB guidance), and the change control for the agent and server versions. DeployOpen also runs security testing against the SIEM itself, including its dashboard, API and access controls on the logs, and offers ongoing support and upgrade retainers so patch releases, such as the Wazuh 4.14 line, are applied on a schedule your team agrees. Confirm with any partner whether a support retainer covers out-of-hours response and where support engineers connect from.
DeployOpen prepares systems, controls and evidence for compliance assessments, such as retention settings, access reviews, configuration baselines and test results. It does not issue audit reports, attestations or certifications. Your data protection officer, legal counsel and an independent auditor or certification body make those determinations, and the scope document should name who owns each piece of evidence. Ask for a written list of evidence artifacts and the owner of each before signing, and confirm how the partner will hand over documentation and runbooks so that your team can operate the SIEM without the partner after go-live.
