Why EU data sovereignty changes the threat intelligence build
An EU entity that is essential or important under NIS2 wants a threat intelligence platform, but cannot send indicators, logs or member data to infrastructure outside EU control. For that situation, a self-hosted MISP or OpenCTI deployment inside the EU, with sharing configured through distribution levels and sharing groups, is the usual fit. The sovereignty question does not end at the database location. It covers where the platform runs, who can administer it remotely, which support staff can see its data, where backups are stored, and which feed connectors send data out and receive data in. Treat each of those as a separate control point. Remote administration from a third country is a transfer under the EDPB's reading of GDPR Chapter V when personal data is visible on screen, so vendor support sessions and managed-service access need the same scrutiny as storage. Backups often leave the primary region without anyone deciding that they should. Feed connectors can push data to a SaaS endpoint or pull enrichment from a service that logs queries. Write down each path before the first deployment, and ask any implementation partner to show the network routes, administrator accounts and backup targets as built.
On platforms, the short answer is this. MISP fits community sharing: it is licensed under AGPL-3.0, it is built around sharing groups and synchronization among instances, and its licensing model is not changed by a single vendor. OpenCTI fits structured, STIX-based analysis of relationships between actors, campaigns and indicators. Its Community Edition is licensed under Apache License 2.0, but some operational features sit in the Enterprise Edition under a separate proprietary license, so confirm which capabilities your team needs before you choose the edition. Many teams run both, with MISP as the sharing hub and OpenCTI as the analysis layer, and each of those components needs its own sovereignty review.
Which obligations shape the design, and what each means for the build
This table maps each obligation to the design decision it forces: where data and admin access can sit, which providers are viable, and how the team exits. Read each row as a requirement to confirm with counsel and your data protection officer, then trace it to hosting, access and exit choices. The main takeaway is that the hosting location alone does not settle transfer exposure, because remote administration and provider jurisdiction also count.
| Obligation | What it requires | What it means for the build |
|---|---|---|
| GDPR Article 44 and Chapter V transfers | Every transfer of personal data to a third country, including onward transfers, must meet Chapter V conditions. EDPB Guidelines 05/2021 treat remote access from a third country, even display-only support access, as a transfer, and so is storage in a cloud outside the EEA. | Host the MISP or OpenCTI instance and its backups in the EEA, restrict administrator and support sessions to EEA locations, and map every remote access path before go-live. |
| GDPR Article 48 and third-country disclosure orders | A third-country court judgment or administrative order requiring disclosure of personal data is recognized or enforced only if based on an in-force international agreement, such as a mutual legal assistance treaty. | Check whether the hosting provider or support vendor could receive foreign orders, and record how the controller would respond. Contract terms should require notice and challenge of requests. |
| US CLOUD Act reach under 18 U.S.C. 2713 | US electronic communication and remote computing service providers must preserve or disclose data in their possession, custody or control, wherever it is stored. | For US-linked hosting, managed services or support providers, EU location does not remove exposure. Assess provider control of keys and logs, and confirm with counsel whether the provider has such control. |
| EU Data Act Article 32 for non-personal data | Data processing service providers must take technical, organisational and legal measures to prevent third-country governmental access to non-personal data held in the Union where it would conflict with Union or national law. | Indicator sets without personal data still need provider-level safeguards. Ask providers how they handle foreign government requests for non-personal data and document the answer in the supplier file. |
| NIS2 Article 29 voluntary sharing arrangements | Essential and important entities may exchange cybersecurity information within trusted communities under arrangements that protect the sensitive nature of shared information. | Sharing groups, distribution levels and TLP markings in MISP or OpenCTI are the controls you configure. Confirm the membership rules and the information-handling terms of each community before you publish or synchronize events. |
| Data Act switching rights from 12 September 2025 | Customers may switch from a data processing service to another provider or to on-premises ICT infrastructure, with a maximum two-month notice period and a 30-day transition (Articles 25, 29 and 50). | Write exit steps into the design: export MISP JSON or STIX data, keep configuration as code, and keep a tested path to an on-premises instance. Confirm each provider's switching terms in the contract. |
| Data Act switching-charge ban from 12 January 2027 | Switching charges for data processing services are banned from 12 January 2027. | Recurring exit or egress fees in provider contracts will change after this date. Ask providers to state in writing which switching or data egress charges apply before and after that date. |
What counts as a transfer when indicators contain personal data
An indicator becomes personal data when a person can be identified from it, either directly or with reasonable means. An email address tied to a named employee, a username that maps to a staff member, or an IP address that a provider can link to a subscriber usually qualifies. Many indicators do not: file hashes, malicious domains, campaign-level IP addresses and malware signatures typically identify no one. Before you decide where the platform and its data can sit, classify your indicator types, record which fields carry personal data (often the Attribute value, the comment field or the reporter and contact metadata), and decide whether those fields should be stripped or pseudonymized before sharing.
Storage location is only part of the question. Under the EDPB Guidelines 05/2021, remote access from a third country is a transfer even when the person only sees data on a screen, so a vendor support engineer in a third country who views a MISP or OpenCTI database during troubleshooting triggers Chapter V. Storage in a cloud outside the EEA is also a transfer. Example 12 of the same guidelines says that using an EU processor subject to third-country law with extraterritorial effect is not in itself a transfer, but complying with a third-country authority request would be. The practical test is whether a foreign authority could compel that processor to hand over data it holds, so assess this exposure before engaging a support provider, and write support access limits into the contract.
Schrems II invalidated the Privacy Shield in July 2020 but kept standard contractual clauses valid, provided the transfer offers an essentially equivalent level of protection. The EU-US Data Privacy Framework decision, Commission Implementing Decision (EU) 2023/1795, is under appeal as Case C-703/25 P, so any reliance on it should be reviewed with counsel and not treated as settled. Where a provider must access data in the clear and the destination's public authority powers go beyond what is necessary and proportionate, EDPB Recommendations 01/2020 state that the EDPB cannot envision an effective technical supplementary measure. Confirm with the provider whether it can operate without clear-text access, and if not, keep the platform inside the EU.
Where the MISP or OpenCTI instance can run, and who can reach it
Running MISP or OpenCTI in an EU region of a cloud account that the entity itself controls keeps the platform, its databases and its object storage under the entity's own tenancy. Hosting jurisdiction is set by the region and the provider's contracted processing locations, not by the platform's license. Administrative access sits with the entity's own identities, but the cloud provider's staff and support channels still form part of the access picture, so the entity needs to know what the provider can see and when.
- Region selection: Choose a region inside the EU for compute, the Elasticsearch or OpenSearch cluster, Redis, RabbitMQ and S3-compatible storage, and confirm that backups and snapshots stay in the same region or another EU region.
- Provider support access: Ask who at the provider can reach customer data during support cases, from which countries, and under what approval process.
- Key ownership: Determine whether the entity holds the encryption keys for disks and object storage, or whether the provider does, and who can rotate them.
- Third-country exposure: Ask whether the provider's parent company is subject to non-EU law that could compel disclosure, since that exposure is separate from where the data physically sits.
- Logging and telemetry: Confirm which provider logs, metrics and diagnostics leave the account and where they are stored.
Before signing, ask the provider to confirm residency, support locations and government access handling in writing, and do not rely on marketing summaries or certifications you have not reviewed yourself.
Hosting MISP or OpenCTI in a facility the entity owns, or in a colocation or sovereign data center in the EU, gives the most direct control over physical location and hardware access. Jurisdiction is limited to the country where the racks sit and the legal entity that operates them. The trade-off is that the entity, or its managed service partner, carries patching, capacity and backup duties that a cloud provider would otherwise share.
- Physical access control: Define who can enter the room or cage, how visits are logged, and whether the colocation operator's staff can reach hardware without escort.
- Administrative accounts: Limit root and database access to named staff, with privileged sessions recorded and reviewed, and document any vendor remote access path.
- Backup location: Store backup copies in a separate EU site or a second data center, and keep an offline copy that is tested by restore.
- Network paths: Restrict synchronization and feed traffic to the sharing partners and public feeds you have approved, and log outbound connections.
- Contract terms: For colocation, confirm the operator's legal seat, subcontractors, incident notification and data deletion terms at exit.
Confirm the facility's location, operator and support model in writing, because a colocation contract can change who has hands on the hardware without the entity noticing.
A sector information-sharing community may host a shared MISP instance on behalf of its members, run by an ISAC, CSIRT or similar trusted EU body. The entity then connects its own instance or uses the hub for sharing, and the hub's operator controls the central data. Sovereignty here depends on the hub's governance, its legal seat and how membership rules restrict who sees what, rather than on a single cloud account.
- Operator and governance: Confirm the legal entity running the hub, its membership rules, and who approves new members and sharing groups.
- Administrative access: Ask which hub staff hold administrator rights, whether members can see one another's events, and how member administrators are separated from hub operators.
- Backup and retention: Ask where hub backups are stored, how long events remain, and how deletion is handled when a member leaves.
- Synchronization boundaries: Limit what your instance pushes to the hub by distribution level and sharing group, so that restricted indicators never leave your environment.
- Exit terms: Agree how your data is exported and removed from the hub if you withdraw.
Request the hub's written terms covering operator identity, hosting location, access roles and backup handling before you share anything, and keep a copy of what you contributed.
Which platform fits an EU sovereignty requirement, and why
For EU data sovereignty, the platform choice matters less than where the instance runs, who administers it and which sharing communities it connects to. The cards below cover the two threat intelligence platforms, the licensing lines that affect a sovereignty decision, and the sensors and consumers that receive exported indicators.
MISP for community sharing
MISP is licensed under AGPL-3.0, and its repository notes that interlocking copyright among contributors prevents any single entity from changing the license model. The project is associated with CIRCL in Luxembourg. Sharing groups and distribution levels can be set down to individual attributes, and events synchronize automatically with trusted instances. Check which community you need to join and whether its hub accepts a self-hosted node in your jurisdiction.
OpenCTI Community Edition
The Community Edition is licensed under Apache License 2.0 and uses a knowledge schema based on STIX2 with a GraphQL API. Its deployment depends on Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage such as MinIO, so every one of these components must sit inside the same sovereign boundary. Confirm that each connector you enable pulls data from sources you are permitted to hold and that no enrichment call leaves the EU.
OpenCTI Enterprise Edition licensing
The Enterprise Edition falls under the proprietary OpenCTI Enterprise Edition License, and LTS releases require a specific LTS license key. Before you choose it, ask the vendor in writing which features need the Enterprise Edition, where the license server or key validation runs, and whether a fully offline deployment can receive LTS updates. Those answers decide whether the sovereignty design depends on a third party.
Suricata and Zeek as sensors
Suricata is licensed under GPL-2.0 and Zeek under a BSD-style license, and both can consume indicators that MISP exports in Suricata and Zeek formats. Keeping the sensors in your own network means indicator matches stay inside the EU boundary. Test that the rule pipeline and any Zeek intelligence files update on your own schedule, without a dependency on a cloud service.
Wazuh and Security Onion as consumers
Wazuh and Security Onion receive threat intelligence rather than produce it. Wazuh is licensed under GPL version 2, and Security Onion under the Elastic License 2.0, so review the license terms that apply to your deployment before you rely on either. Confirm which indicator fields your SIEM or monitoring tool can ingest, and whether matches are logged where your data residency rules require them to be.
Rollout phases and the output of each
This sequence moves from deciding which data may leave the organization's control to running recurring evidence collection, so that each phase hands the next one a documented decision or artifact. Sovereignty questions are settled before any feed is connected or any indicator is shared.
Scope data classes and the transfer map
Start by listing every class of data the threat intelligence platform will hold: internal alerts, indicators from feeds, shared indicators that may contain personal data, analyst notes and user accounts. For each class, record where it is stored, which systems and people can read it, and every point where it could reach a third country, including remote support sessions and backups. The output is a data map and a transfer map that a privacy lead and counsel have reviewed. The step is done when every data flow has an owner and a documented location.
Decide hosting and the admin access model
Choose where the instance runs, such as an EU data center or a cloud region the organization controls, and who holds administrative access, including vendors who may need remote sessions. Record which processors and sub-processors touch the stack and whether any of them are subject to third-country law with extraterritorial reach. The output is a hosting decision record and an access model that states who can view data in the clear and under which conditions. Counsel should use this record as the input to any transfer assessment before a processor is engaged.
Select the platform and license tier
Compare MISP and OpenCTI against the sharing model and the features the team needs, and confirm the license position for each. MISP is licensed under AGPL-3.0, while OpenCTI Community Edition is Apache 2.0 and some capabilities sit in the Enterprise Edition under a separate license. Confirm with the vendor which features the team requires and whether they are included in the Community Edition. The output is a written platform decision with its license tier, version and support plan, confirmed against the current license documents.
Build and harden the instance
Install the platform on the chosen infrastructure using the vendor's supported method, then configure transport encryption, authentication with multi-factor sign-in, role separation, logging of administrative actions and backup encryption. For OpenCTI, this includes its dependencies such as the search engine, Redis, RabbitMQ and S3-compatible storage, each placed inside the agreed boundary. The output is a hardened build record and a configuration baseline that can be rebuilt from code. The step is done when a test restore has been completed and the access controls match the access model.
Define TLP, distribution and personal data screening rules
Write the rules that govern how each indicator is labeled, which distribution level it receives and which sharing groups may see it. Include a screening step that flags indicators containing personal data, such as email addresses, account identifiers or names tied to individuals, before they leave the instance. Set the retention and deletion rules that apply to personal data within indicators. The output is an approved handling standard with examples and a named owner who can approve exceptions. The step is done when test events have passed through the screening path and the results are recorded.
Connect feeds, SIEM and SOAR
Configure the feeds the organization has approved, then connect the platform to the SIEM and SOAR tools so that indicators reach detection without manual copying. Confirm which data is pushed outward, to which tools, and whether those tools are themselves hosted inside the approved boundary. Record any feed whose terms restrict onward sharing. The output is an integration map with each connection, its data direction and its owner. The step is done when a test indicator has traveled from feed to detection and the flow is logged.
Join sharing arrangements after governance approval
Before connecting to any sharing community, confirm the arrangement with the legal and governance function, including the membership terms, the obligations on the organization and any notice that a competent authority requires. Under NIS2 Article 29, sharing arrangements are voluntary and must be set up with defined conditions, so the approval should record what the arrangement covers and what is excluded. Only then configure synchronization and sharing groups for the approved community. The output is a signed-off governance decision and a configured sharing group list. The step is done when the first outbound event has been reviewed against the handling standard.
Run evidence collection on a schedule
Set up recurring collection of the artifacts that show the sovereignty and handling controls work as designed: the data map, the transfer assessment, access reviews, screening logs, sharing group changes and restore tests. Assign an owner for each artifact and a review cadence agreed with the compliance lead. The output is a runbook that tells operators what to collect, where it is stored and who signs it off. This evidence is what the organization gives to its auditors and regulators, since DeployOpen prepares the evidence but independent auditors and certification bodies issue any assessment outcome.
Evidence a regulator or auditor will ask for, and which component produces it
This table maps the records a regulator or auditor is likely to request for a self-hosted MISP or OpenCTI deployment to the component that produces each record. Read each row as a question to answer before the first sharing event, and confirm the exact export or log format with your own platform version. DeployOpen prepares this evidence, while auditors and regulators assess whether it is sufficient.
| Evidence item | Component that produces it | What to confirm or prepare |
|---|---|---|
| Records of processing and transfer mapping | Documented process, supported by a data flow inventory of MISP or OpenCTI hosts, sync peers and connectors | Where each instance, backup and enrichment connector runs, and whether any remote access originates outside the EEA |
| Admin access logs | MISP audit log and authentication logs, forwarded to the SIEM; OpenCTI platform logs forwarded to the SIEM | Retention period, who can read logs, and whether logs are kept in the EU |
| Sharing-group and distribution configuration exports | MISP sharing groups and distribution settings exported from configuration; OpenCTI marking definitions and access policies | Dated exports taken before and after each change, with approvals recorded in a change process |
| Personal data screening records | Documented screening process, with review notes attached to events before synchronization | Rules for what indicators may contain personal data, and who signs off before an event leaves the instance |
| Backup location records | Documented process listing backup targets for databases, object storage and configuration | Confirmation that every backup copy sits in the EU, including any copies held by a managed storage provider |
| Data Act switching and exit documentation | Documented exit plan covering MISP or OpenCTI data export in STIX or MISP JSON, plus configuration export | Export tests on a schedule, and the notice and transition steps a customer would follow if moving to another provider or on-premises |
| NIS2 sharing membership notices | Documented process, with membership records held by the entity and copies of notices filed with the competent authority | The authority's notification requirements for the sharing arrangement, and the dates your entity must meet |
Questions to put to an implementation partner before signing
Start with the data map. Ask the partner for the written scope and a data flow diagram that shows every place a copy of intelligence or sharing data can exist: the MISP or OpenCTI database, Redis, the search index (Elasticsearch or OpenSearch for OpenCTI), RabbitMQ message queues, S3-compatible object storage, backups, replicas, and application and reverse proxy logs. Each location should have a named region, a named operator, a retention period and an encryption method. Then ask who can read the search index and logs, because indicators tied to a named victim or an employee mailbox are personal data in the same way the primary store is. A diagram that omits backups or logs is incomplete, and the scope should say so.
Next, establish who can reach the system and from where. Ask for a list of every account with administrative, root, database or vendor support access, the country each session originates from, and whether support sessions are recorded. Under EDPB Guidelines 05/2021, remote access from a third country counts as a transfer even when the support engineer only views data on a screen, so a non-EU support desk is a transfer question for your controller obligations. Ask how connectors that call non-EU APIs (commercial feed providers, enrichment services, cloud lookups) are configured, which data they send out, and whether the partner can disable them or route them through an EU-hosted proxy. Ask the partner to name each connector and its destination in the diagram.
Finally, settle the licensing and exit questions in writing. If your design uses OpenCTI features that sit in the Enterprise Edition, ask which ones, where the Enterprise license key is stored, who holds it after handover, and what happens to the deployment if the subscription lapses. Confirm how personal data is screened before indicators are shared, including who approves an event and which fields are stripped. For exit, require a documented procedure for export to another platform or to on-premises infrastructure, covering data formats (MISP JSON or STIX), configuration, sharing group definitions and synchronization partners. Under the Data Act, customers have switching rights, so ask the partner to show how that procedure would be executed in practice.
Questions buyers ask about EU self-hosted threat intelligence
What drives the cost of a self-hosted MISP or OpenCTI deployment?
Software licensing is rarely the largest line. MISP is licensed under AGPL-3.0 and OpenCTI ships a Community Edition under Apache License 2.0, so the cost sits in infrastructure, integration work, feeds and people. For OpenCTI, the documented sizing calls for a platform node with 2 cores and at least 8 GB RAM, Elasticsearch or OpenSearch with 2 cores, 8 GB RAM and 16 GB SSD, plus Redis, RabbitMQ and S3-compatible storage, with at least one platform node for every 3 workers. Infrastructure is recurring, while the initial build, connector configuration and SIEM or firewall integration are one-time. Analyst curation time recurs for as long as the platform runs. Ask any quote to split one-time build from recurring operation, and to state which OpenCTI features require an Enterprise Edition subscription.
Can our team run a self-hosted threat intelligence platform alone?
A capable security or platform team can run MISP or OpenCTI alone if it has Linux, database, search and queue administration skills, and someone who owns intelligence curation. The harder work is usually operational: keeping dependencies patched, managing synchronization with sharing partners, maintaining connectors as upstream versions change, and tuning how indicators reach detection tools. Teams that lack these skills in-house often bring in an implementation partner for the initial build, then keep operations internal or under a support retainer. DeployOpen implements, hardens, backs up, upgrades and documents self-hosted platforms inside the client's own infrastructure, and most engagements are fixed-scope with the scope agreed in writing before work starts.
How long does a self-hosted threat intelligence deployment take?
The duration depends on the number of feeds and sharing communities, the integrations into the SIEM, firewalls and SOAR, the size of the required infrastructure, and how many approvals the change process needs. The supplied material does not establish a standard timeline, so this page does not state one. Ask the implementation partner for a written plan that lists phases, deliverables, dependencies on your teams (identity, network, hosting and change approval) and the points where your sign-off is needed. A fixed-scope agreement should tie the timeline to that written scope before work begins.
Does self-hosting threat intelligence alone satisfy GDPR?
No. Self-hosting reduces transfer exposure but does not by itself make processing compliant. GDPR Article 44 applies to every transfer of personal data to a third country, including onward transfers. EDPB Guidelines 05/2021 state that remote access from a third country, even only displaying data on a screen, and storage in a cloud outside the EEA are transfers. Keeping the platform and its hosting inside the EU removes many of these paths, but support access, backups, managed services and vendor telemetry must be checked. Indicators that contain personal data, such as email addresses or account identifiers, still need a lawful basis, minimization and retention rules. Confirm the data map with your data protection officer and counsel before go-live.
Does NIS2 require us to join an information-sharing arrangement?
No. NIS2 Article 29 describes cybersecurity information-sharing arrangements as voluntary. An essential or important entity may choose to join a sharing community, and if it does, the arrangement must meet the conditions the article sets, including how members share and handle information. Whether to join is a governance decision that should weigh sector relevance, legal review of sharing terms and the handling rules for each indicator. A self-hosted MISP or OpenCTI instance can support participation through sharing groups and distribution levels, but the decision and its terms belong to your organization and your legal advisers, and they should be confirmed against the national transposition in each Member State where you operate.
Is MISP or OpenCTI better for EU data sovereignty?
Both can be deployed in EU infrastructure, so sovereignty depends mainly on hosting, operations and data handling, not on the platform choice alone. On licensing, MISP is AGPL-3.0 software with CC0 or BSD-licensed taxonomies and galaxies, and the repository notes that interlocked copyright among contributors prevents any single entity from changing the license model. OpenCTI's Community Edition is Apache License 2.0, while the Enterprise Edition uses a proprietary OpenCTI Enterprise Edition License and LTS releases require a specific license key. If you need OpenCTI LTS support or Enterprise features, review that license in procurement. Confirm with each vendor which features your architecture depends on before you choose.
Which parts of the platform does an implementation partner usually handle?
A typical fixed-scope engagement covers the parts that most often stall internal teams: installation, hardening, identity integration, sharing group design, synchronization with partner instances, connector configuration, export to detection tools, backup and restore testing, and documentation. For OpenCTI, the partner also sets up the supporting services and confirms worker and connector topology. For compliance, DeployOpen prepares systems, controls and evidence for assessments, but it does not issue audit reports, attestations or certifications, which come from independent auditors and certification bodies. Ask the partner to list in writing which items are in scope and which remain with your team.
What should a quote for this work include?
A useful quote states the scope in writing, the deliverables, the assumptions about your environment, and the responsibilities split between the partner and your team. It should separate one-time build work from recurring items such as infrastructure, upgrades, feed subscriptions, support retainers and analyst time. Ask for the sizing assumptions behind the infrastructure, the list of connectors and integrations, the licence tier assumed for OpenCTI, and what happens if a feed, partner or integration changes during the project. DeployOpen does not publish a price list, and a quote follows from the written scope.
How DeployOpen scopes and builds this in your environment
DeployOpen plans, implements, hardens and documents self-hosted MISP or OpenCTI inside your own cloud accounts, data centers or air-gapped networks, so intelligence and sharing infrastructure stays where your data-residency decisions put it. Engagements start with a written scope that fixes the sharing model, data locations and deliverables before any build work begins.
How we scope
- Map which indicators may contain personal data and where each data type is stored, processed and accessed from.
- Confirm which sharing communities, NIS2 Article 29 arrangements or national hubs you will join, and the distribution and TLP rules they require.
- Agree in writing the hosting regions, administrator locations, third-country access paths and the platform choice between MISP and OpenCTI.
How we build
- Deploy MISP or OpenCTI in your EU hosting environment, with sharing groups and distribution levels configured before any event is created.
- Connect feeds, enrichment and detection exports such as Suricata and Zeek rules, and confirm each external connector's data flow against your transfer register.
- Test access controls, synchronization behavior and data handling against the written scope, and record the results as evidence.
How we hand over
- Document architecture, data flows, sharing rules, retention settings and the upgrade path for your team.
- Deliver runbooks for onboarding partners, reviewing indicators and handling false positives, plus the compliance evidence agreed in scope.
- Train your analysts and administrators on daily operation, then transfer administrative control to your team.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Plan version upgrades against the MISP or OpenCTI release and life cycle information published for your chosen edition.
- Review sharing configurations and connector changes periodically, with any changes to scope agreed in writing.
