Log Data Sovereignty: Who Can Actually Reach Your Logs?

Your logs tell the whole story of your IT environment: its architecture, its access paths, its weaknesses, its incidents. To an attacker or a foreign authority, they are a complete map of where you can be broken. Log data sovereignty is therefore not a matter of principle. With NIS2 and DORA, it has become a compliance issue in its own right.

The question is no longer just “Where are my logs stored?” but “Who, ultimately, can compel access to them?” And the answer depends far less on where your servers sit than on which law your provider answers to.

Here is why hosting in Europe is not enough, and what to ask your log management provider, whether it runs as SaaS or on-premises.

Why Log Data Sovereignty Is Now a Compliance Issue

For years, log management tools were chosen on technical and economic criteria. NIS2 and DORA add one that many IT operations teams never had to consider: control over their supply chain.

What NIS2 and DORA Require of Your Providers

NIS2 lists supply chain security among its mandatory risk-management measures, including the security practices of the suppliers and service providers that host and process your data (Article 21 of Directive (EU) 2022/2555). DORA goes further for financial entities: Regulation (EU) 2022/2554 requires them to assess ICT concentration risk before signing (Article 29) and to state in the contract the regions or countries where data is processed and stored (Article 30).

In other words, the provider that stores and processes your logs is part of your compliance perimeter. You need to be able to explain who it is, where it processes your data, and which law it answers to.

Logs Are Among the Most Sensitive Data You Hold

An authentication log reveals your privileged accounts. A network log maps your traffic flows. An application log can contain IP addresses and user IDs, which makes it personal data under the GDPR. Centralized, these logs add up to a full picture of your IT environment: an asset to protect, just like your business data.

Key takeaway: log data sovereignty is not a preference. NIS2 and DORA expect you to control the providers that host and process your data, logs included.

“Hosted in Europe” Does Not Mean “Protected by European Law”

This is the most common misunderstanding. Many vendors now offer European hosting regions. That answers the question of where the data lives. It does not answer the question of which law applies to it.

The CLOUD Act: Jurisdiction Matters More Than Geography

Passed in the United States in 2018, the CLOUD Act (Clarifying Lawful Overseas Use of Data Act) allows US authorities to require any provider subject to US law to hand over data it holds, wherever that data physically sits. That includes a data center in France or Germany, and it can happen without prior notice to the customer whose data it is, or to any European regulator.

A company incorporated in the United States, or the European subsidiary of a US group, can therefore be compelled to produce your logs even when they are “hosted in Europe.” A European data center does not remove the legal exposure. It moves it.

A Direct Conflict With the GDPR

This collides with the GDPR. Its Article 48 provides that a third-country authority may only require the transfer of personal data through an international agreement, such as a mutual legal assistance treaty. A European customer of a provider subject to the CLOUD Act can end up caught between two conflicting laws, and logs, which often contain personal data, are directly affected.

Contractual vs. Structural Sovereignty: The Distinction That Changes Everything

Faced with this risk, two approaches coexist, with very different levels of assurance.

Contractual Sovereignty: A Promise

The provider commits, by contract, to host your data in Europe and to resist foreign requests. That helps, but it remains a promise: a contract cannot override the legal obligations the provider is itself subject to.

Structural Sovereignty: An Architecture

Here, the entire value chain sits under European law: the vendor, the host, the subprocessors, right down to the AI components. There is no entry point for a non-European order, because no link in the chain is subject to one.

For an organization under NIS2 or DORA, which has to demonstrate control over its logs and the integrity of what they contain, only structural sovereignty offers a guarantee that does not depend on a third party’s goodwill.

Key takeaway: contractual sovereignty is a promise; structural sovereignty is an architecture.

On-Premises or SaaS: Sovereignty Doesn’t Depend on the Deployment Model

The instinct is to bring logs back in-house and take the third party out of the loop. The reasoning is understandable but incomplete: an on-premises deployment rarely runs on fully self-contained infrastructure. Three links deserve a closer look.

• The infrastructure. If the servers holding your logs are leased from a host or private cloud operator that answers to US law, even as a pure infrastructure supplier, the CLOUD Act can still reach that link.
• The software layer. The hypervisor and the operating system raise the same question when they come from a vendor under the same law.
• The support channel. If your log management vendor keeps remote access to support or maintain the instance running in your data center, that channel becomes an exposure of its own.

On-premises is therefore not a guarantee of sovereignty in itself: like SaaS, it is judged link by link. The question worth asking is not “SaaS or on-premises?” but “Who, across the whole chain, answers to a law that can compel disclosure?” A structurally European SaaS log management solution can offer stronger guarantees than an on-premises deployment that depends on a host, software, or support subject to non-European law.

Inside the EU or Beyond, the Same Question of Strategic Autonomy

Log data sovereignty is not about protectionism. It is about strategic autonomy: keeping control over your IT, your data, and your future, wherever you operate.

If you operate in the European Union, the stakes are twofold: showing your national competent authority (ANSSI in France or BSI in Germany, for example) that you control your supply chain, and protecting logs that fall under the GDPR from any request that would bypass European law.

If you operate outside the European Union, in the UK, Switzerland, the US, Canada, or Asia-Pacific, for example, the same test applies: know which jurisdiction governs each link in your logging chain. And if you have EU subsidiaries or serve EU customers covered by NIS2 or DORA, these texts concern you too: an EU subsidiary can be in scope in its own right, certain non-EU digital service providers must appoint a representative in the EU, and your customers’ requirements reach you through the contract.

Either way, the logic is the same: sovereignty you can verify, rather than sovereignty you are asked to take on trust.

How to Assess Your Log Management Provider’s Sovereignty

Sovereignty is not something you read off a spec sheet; it is verified link by link. Here are three questions to ask your provider first, whether it runs as SaaS or in your own data center.

Which Law Governs the Vendor?

A parent company outside the EU is enough to expose your logs to that country’s law, even if the subsidiary that invoices you is European.

Which Subprocessors Handle Your Logs?

Support, backup, telemetry, AI components: a single subprocessor subject to an extraterritorial law is enough to reopen the gap. Ask for the full list, and the jurisdiction of each.

What Happens if a Non-European Authority Demands Your Data?

Can the provider refuse as a matter of law, or only promise to in a contract? Don’t count on a label to answer this for you. The EU cloud certification scheme (EUCS) is stalled, and the sovereignty criteria it was meant to carry were dropped in favor of a simple declaration of jurisdiction by the provider. Some national schemes, such as SecNumCloud in France, include protections against non-European laws, but the verification remains yours to do.

The guide NIS2 & DORA: What EU Regulators Now Expect You to Prove From Your Logs includes the full seven-question checklist to put to your current provider.

Sovereignty and Portability: The Other Side of Control

Controlling your logs also means being able to change providers. Proprietary agents and formats create a dependency that narrows your options. Collection built on an open standard such as OpenTelemetry keeps your data in a format any compatible tool can read: portability becomes a property of the architecture, not a clause in a contract.

How Centreon Log Management Supports Your Strategic Autonomy

Centreon Log Management, delivered as SaaS, was designed for structural sovereignty, not just contractual sovereignty, so you keep control over your logs wherever you operate. It rests on:

• A European vendor in control of its own value chain, with a European ecosystem end to end, from AI with Mistral AI to security with CrowdSec.
• Data hosted in the European Union.
• Native OpenTelemetry collection, so portability is guaranteed by the architecture rather than promised in a contract.

On top of this come the capabilities NIS2 and DORA require: retention configurable by log type, protection against tampering and deletion, role-based access control, and encryption.

Are Your Logs Truly Sovereign?

NIS2 and DORA have brought log data sovereignty into the scope of compliance. The question is no longer only whether your logs are safely kept, but who, ultimately, can reach them. The answer lies in the law that governs each link in your chain: vendor, host, subprocessors, support.

The good news: one thorough review protects both your compliance and your strategic autonomy.

Download the guide NIS2 & DORA: What EU Regulators Now Expect You to Prove From Your Logs and put your current provider to the seven questions in Chapter 4.

This article is informational and does not constitute legal advice. For compliance decisions, refer to the official texts and the competent authority in your jurisdiction.