Observability and digital sovereignty

Reading mode

EngineerDecision-maker

An engineer’s reading, not legal advice

The regulations cited are read from the point of view of an observability team. For a purchasing or compliance decision, have the analysis validated by your legal department. Legal and political statuses (FISA, Data Privacy Framework, CADA) change fast: each statement points to its source and the page is reviewed every two months.

A platform can be hosted in a qualified cloud, encrypted with keys held by the customer and operated by European teams, while sending its logs, traces and metrics every second to a vendor subject to foreign law. In most sovereignty projects, that outgoing flow is the one nobody has inventoried.

This article looks at digital sovereignty from the point of view of observability. It explains why observability data is a sovereignty topic in its own right, how the classic risks apply to it, what the regulatory framework says, what a sovereign observability architecture looks like and how to assess an offer. It argues that observability is both a blind spot of sovereignty and the best instrument to demonstrate it.

1. Sovereignty in brief

An operational definition

Applied to an organization, digital sovereignty is the ability to decide alone on the access, continuity and evolution of its digital assets while being able to demonstrate it. Transposed to observability, each term becomes a concrete question:

1. Access: who can read the logs, traces and metrics, including the tool vendor, its support and a foreign authority?
2. Continuity: does the team keep visibility on its systems if the observability tool is cut off in the middle of an incident?
3. Evolution: can it change backends without re-instrumenting all its applications or losing its dashboards and alerts?
4. Demonstration: can it prove the three previous points to an auditor or a customer?

Sovereignty is not autarky, not a binary state and not a label. It means controlling your dependencies, dimension by dimension. The European framework measures it in levels.

Related notions

Two words come up in this table and in the rest of the article. The backend is the tool that stores logs, traces and metrics and lets you query them. SaaS means software rented online and run by the vendor on its own servers.

Notion	Question it answers	Observability example
Data residency	In which country are logs and metrics stored?	A SaaS backend hosted in a European region
Processing location	Where is data indexed, analyzed, enriched?	An AI analysis feature that runs outside Europe despite European storage
Data sovereignty	Which law covers the data and who can read it?	The law that applies to the parent company of the tool vendor
Digital sovereignty	Who controls access, continuity and evolution of the observability chain?	The ability to operate and evolve your stack without the vendor
Trusted cloud	Is the hosting qualified (SecNumCloud, the qualification issued by the French security agency ANSSI)?	A self-hosted backend on qualified infrastructure
Autarky	Is everything produced in-house?	An unrealistic goal: even a self-hosted stack relies on global open source projects

2. Why is observability a sovereignty topic?

Observability signals are a copy of the system

Each signal reproduces part of what it observes:

• Logs contain identifiers, IP addresses, fragments of requests and sometimes personal or business data that escaped masking.
• Distributed traces, which follow the path of a request from one service to the next, reveal services, their dependencies, entry points and critical paths: they are a map of the architecture.
• Metrics show volumes, peaks, schedules and incidents: they are a portrait of the activity.
• Execution profiles, records of what the code does function by function, increasingly collected continuously, expose the structure of the code and its hot spots.

Accessing logs, traces and metrics gives a detailed view of the system without ever touching the production database.

An outgoing flow by design

Most observability tools on the market work as SaaS: agents installed on every machine continuously push their data to an external service. This model has three consequences that sovereignty reviews often forget.

1. Wide network openings. Firewall rules often allow a whole vendor domain, which makes it impossible to know precisely what leaves.
2. Highly privileged components. An observability agent reads every log file, queries the interface of the orchestrator (the software that drives containers), sometimes runs with extended rights on the operating system kernel and often accepts updates and configurations pushed remotely. It is software driven from outside, present on every host.
3. A permanent flow. Unlike a backup or a one-off export, this data leaves every second, in volume. It is often kept longer than the data it describes.

An organizational blind spot

The observability tool is usually chosen by operations teams as a tool, not as hosting. It therefore escapes the architecture reviews that examine databases and applications. The market reinforces this: most of the large SaaS observability vendors fall under US law.

Finally, observability is the tool you need most when everything goes wrong. Depending on an external service to see your systems is a dependency at exactly the moment you cannot afford to suffer it.

3. What has changed since 2018

Three developments have moved sovereignty from talk to operations: foreign laws with extraterritorial reach, sanctions that directly hit digital services and European criteria entering purchasing. Each one has a direct consequence for the observability chain.

Date	Fact	Consequence for observability
June 2026	FISA Section 702, the US law on foreign intelligence surveillance, expires on 12 June for lack of reauthorization, yet collection remains authorized until March 2027 thanks to the March 2026 certifications	The exposure of logs and traces entrusted to a US vendor depends on a political debate you have no grip on
June 2026	The Commission proposes the Cloud and AI Development Act, which also covers remotely hosted AI systems	The AI-assisted analysis features of observability tools will fall within the scope of risk assessments
April 2026	The Commission awards its sovereign cloud tender with a minimum SEAL-2 level (a sovereignty scale from 0 to 4, see section 6)	A public buyer can now assess an observability service with the same grid as a cloud service
January 2026	AWS opens the AWS European Sovereign Cloud, separate from the other regions	A platform hosted in a separate cloud loses that benefit if its logs and traces go to a SaaS that is not separate
December 2025	S3NS obtains the SecNumCloud 3.2 qualification for its PREMI3NS offer	Qualified platforms multiply; their observability has to follow the same level
October 2025	Publication of the Cloud Sovereignty Framework	The assessment extends to subcontractors and technical layers: the observability tool is one of them
September 2025	The Data Act, the EU regulation on data, applies; the EU General Court upholds the Data Privacy Framework, which is under appeal	Switching tools becomes a right, though logs containing personal data remain exposed to the fragility of transfers
June 2025	Before the French Senate, the head of legal affairs of Microsoft France states under oath that he cannot guarantee that French citizens’ data will never be passed on to US authorities	What applies to a hyperscaler (a very large cloud provider) applies to any observability vendor subject to the same law
May 2025	It is revealed that the prosecutor of the International Criminal Court (ICC), under US sanctions since February, lost access to his Microsoft email; Microsoft later denies having cut the service	An observability tool can be cut off too: the team goes blind
2020	The Schrems II ruling of the EU Court of Justice invalidates the Privacy Shield, the arrangement that then governed data transfers to the United States	Logs exported to the United States can become non-compliant overnight
2018	Adoption of the US CLOUD Act	A US vendor can be compelled to hand over its customers’ observability data, wherever it is stored

4. The three dependency mechanisms

Behind the word sovereignty lie three distinct risks. Encrypting your logs does not protect against the tool being cut off. Changing hosting region does not protect against lock-in through agents.

Mechanism 1: extraterritorial legal access

A state can compel a company subject to its law to hand over data, even when stored abroad. In the United States, the CLOUD Act allows demanding data held or controlled by a US provider wherever it is stored. FISA Section 702 and Executive Order 12333, a US presidential order, govern intelligence collection targeting non-US persons. Other countries have comparable mechanisms, such as China’s 2017 intelligence law.

Exposure points: the SaaS backend, the diagnostics agents send back to the vendor, support access during a ticket, AI features that send log excerpts to a model hosted elsewhere.

What protects: a backend under European law or self-hosted, masking of sensitive data before any export, encryption keys held by the customer and a gateway that controls and logs every destination.

Mechanism 2: service cut-off

An observability tool can stop working without any data being read: vendor outage, sanctions, account suspension, an exceeded ingestion quota that leads to dropped data, end of support for a self-hosted version. The case of the ICC prosecutor’s email made this scenario concrete.

Consequence specific to observability: the team loses sight of its systems, often at the worst moment. A platform whose alerting depends on an external service stops alerting when that service goes down.

What protects: collectors that keep a local buffer, a minimal backend inside the perimeter for critical signals and alerting; dual export to a second backend when the stakes justify it.

Mechanism 3: economic and technical lock-in

This is the most frequent risk. Proprietary agents and SDKs (the code libraries supplied by the vendor), specific query languages, dashboards and alerts in a closed format, ingestion-based pricing that pushes to reduce collection: leaving ends up costing more than staying.

The Data Act removes switching charges, including data egress charges, from 12 January 2027 (Article 29). For observability, that is only part of the problem: the real cost of a migration lies less in transferring data than in re-instrumenting applications and rewriting dashboards and alerts.

What protects: OpenTelemetry instrumentation independent of any vendor, transport over OTLP (the standard OpenTelemetry protocol), dashboards and alert rules managed as code (described in versioned files rather than set up by hand in the tool) and regular switch-over tests to another backend.

5. The dimensions of sovereignty applied to observability

There is no official list of “types” of sovereignty: analyst firms retain three, some providers four, the European Commission framework eight objectives. Rather than look for the right number, it is better to look at what each dimension controls in an observability chain. The table reads both ways: the observability chain appears as a risk to control, but also as the means to prove the sovereignty of the whole platform.

Dimension	Key question	Risk for the observability chain	What observability can prove
Strategic	Who owns and runs the vendor or the project?	Acquisition of the vendor, license change of an open source project	Verified governance of the components: neutral foundation, ability to maintain a fork (an independent copy of the project)
Legal	Which law applies to the vendor and its subcontractors?	SaaS backend subject to non-European law; agents sending back diagnostics	List of the destinations actually contacted, recorded on a single collection gateway
Data	Where are logs and traces, who reads them, for how long?	Unclassified logs, kept longer than the source data, indexed elsewhere	Masking at the source in the collector, measured: attributes removed, location of indexes
Cryptographic	Who holds the keys?	Internal flows in clear text, encryption at rest with the provider’s keys	mTLS coverage (mutual encryption of internal exchanges), certificate rotations, access to the customer’s KMS or HSM (its key vaults)
Operational	Who operates and troubleshoots the chain? From where?	Logs and traces read by the vendor’s support	Log of every read request on the backend, alerts on out-of-perimeter access
Technological	Can you change backends?	Proprietary agents, SDKs tied to a vendor, closed query language	OpenTelemetry instrumentation, OTLP transport, measured switch-over test
Supply chain	Where do agent and collector binaries come from?	Agent downloaded without verification, unnecessary components, updates pushed remotely	Distribution built with the OpenTelemetry Collector Builder, SBOM (inventory of components), signed images, internal registry
Compute and AI	Where does AI-assisted analysis run?	Log excerpts sent to an external model	Traces of model calls following the OpenTelemetry GenAI conventions
Infrastructure and energy	Is capacity enough to absorb the volumes collected?	Volumes that grow faster than activity	Volume per service, sampling, measured consumption of the stack (for example with Kepler, an open source tool that estimates power consumption)
Skills	Can the team operate its stack on its own?	Know-how locked in the vendor’s tool	Configuration as code, degraded-mode operating exercises
Assurance	Can you prove all of the above?	Audit evidence stored with a third party	Immutable audit logs inside the perimeter, indicators computed continuously

Two reading rules:

1. The weakest link sets the level. The European framework applies this principle: the overall level of an offer is the lowest one obtained across its objectives. An exemplary collection chain does not make up for an AI feature that exports log excerpts.
2. The dimensions stack up. The table below shows how the layers rest on one another and what each one means for observability.

Observability sovereignty stacks up, framed by law and proof. Each layer rests on the one below; the two cross-cutting dimensions apply to all of them.

Layer (from top to bottom)	What it means for observability
Data and cryptography	Masking at the source, backend keys held by the customer
Compute and AI	Where AI analysis of logs and traces runs
Operations and skills	Who operates the backend, who reads logs and traces
Technology	OpenTelemetry, OTLP, interchangeable backend
Supply chain	Origin of agents and collectors, SBOM, signatures
Infrastructure and energy	Storage and energy to absorb the volumes collected
Cross-cutting: legal and strategic	Vendor’s law, shareholding, licenses
Cross-cutting: assurance	Access logs, immutable audit, continuous measurement

A weakness in a lower layer spreads upward: perfectly masked logs protect nothing if the agent that collects them accepts updates pushed by a third party.

6. The regulatory framework read by an observability team

No text mentions observability explicitly. Yet almost all of them concern it, either because logs contain protected data, because the observability tool is a provider or because the signals collected serve as evidence.

GDPR: logs are personal data

IP addresses, user identifiers, email addresses in error messages: logs almost always contain personal data. Their export to the United States relies on the Data Privacy Framework, the European Commission decision that governs those transfers. It is the third arrangement after Safe Harbor (struck down in 2015) and the Privacy Shield (struck down in 2020). It was upheld by the EU General Court in September 2025, though an appeal is pending before the Court of Justice.

Takeaway: an observability chain whose compliance relies on a transfer mechanism can become non-compliant overnight. Masking at the source reduces that exposure; it does not remove it.

NIS2 and DORA: observability as evidence and as a provider

NIS2, the EU cybersecurity directive, requires detecting and quickly notifying significant incidents: without reliable logs and traces, there is no detection and no defensible timeline. DORA, applicable to the financial sector since January 2025, requires a register of ICT providers, a concentration analysis (dependence on a small number of providers) and exit strategies. A SaaS observability vendor is an ICT provider like any other: it goes into that register and needs an exit plan.

Data Act: the right to change tools

The switching obligations have applied to data processing services since September 2025. Switching charges will disappear on 12 January 2027. That right is only worth something if the instrumentation actually allows changing backends, which brings us back to OpenTelemetry.

Cloud Sovereignty Framework: the observability tool is assessed

The Commission framework assesses a cloud service on eight objectives and assigns a SEAL level per objective, from 0 to 4. It also computes a weighted sovereignty score used to rank offers. Its assessment extends to subcontractors and technical layers, not only to the company that bids. An operator aiming for a high level therefore cannot entrust its observability data to a service that would pull it down.

Level	Meaning (source)	Observability example
SEAL-0	Exclusive control by non-European actors	Non-European SaaS hosted outside Europe
SEAL-1	European law formally applicable, limited effective enforcement	Non-European SaaS in a European region
SEAL-2	European law applicable and enforceable, significant non-European dependencies	Service operated by a European entity on a technology controlled by a non-European vendor
SEAL-3	Strong European influence, marginal external control	Open source stack self-hosted or operated by a European player, on European infrastructure
SEAL-4	Technology and operations entirely under European control	Rarely achievable: it assumes a European chain from chips to software

The examples column is an indicative reading, not an official classification: the SEAL level is assigned case by case, on the basis of the evidence provided.

CADA: observability AI within scope

The Cloud and AI Development Act, proposed on 3 June 2026, would create a single sovereignty assessment framework for cloud and AI. It would require public bodies to carry out a risk assessment before using a service. It includes remotely hosted and operated AI systems, which covers the assisted analysis features of observability tools. The text is only at the start of the legislative process.

SecNumCloud: the qualified platform and its observability

The SecNumCloud 3.2 qualification from ANSSI, the French national cybersecurity agency, adds protection against extraterritorial laws to the security requirements. The up-to-date list of qualified providers is published by ANSSI. A qualification covers a precise scope: if the application runs on a qualified service while its logs and traces go to a tool that is not qualified, the benefit of the qualification stops at the border of that flow.

7. Reference architecture for sovereign observability

Sovereign observability is not just a choice of backend. It relies on an architecture whose central principle is simple: logs, metrics and traces all go through a single control point, inside the perimeter, before going anywhere. This architecture relies on six building blocks.

1. Neutral instrumentation. Applications are instrumented with the OpenTelemetry SDKs and auto-instrumentation (measurements added automatically, without changing the code), never with a vendor’s SDK. That is what makes the backend interchangeable.
2. Two-tier collection. Agents close to the sources (one collector per host or per node) forward to a central gateway. Agents stay simple; the intelligence is concentrated in the gateway.
3. A gateway that acts as the control point. It masks sensitive data with the collector’s redaction processors (which erase or mask sensitive fields) and transformation processors, samples traces, enriches and routes signals. Above all, it is the only exit: its logs are the enforceable list of everything that leaves the chain.
4. A backend inside the perimeter. Storage, queries and alerting stay under control, on qualified or self-hosted infrastructure. Critical alerting depends on no external service.
5. A controlled control plane. Agent and gateway configuration is managed as code in Git and deployed through OpAMP, the OpenTelemetry fleet management protocol. Binaries come from a distribution built in-house with the OpenTelemetry Collector Builder, signed and served from an internal registry.
6. Meta-observability and audit. The observability chain is itself observed: rejected data, saturated queues, failed exports. Every read on the backend is logged.

An export to an external service remains possible, though it becomes an explicit decision: filtered, aggregated where possible, limited to authorized destinations and traced by the gateway. AI-assisted analysis features follow the same rule: a model hosted inside the perimeter preferably, each call traced following the OpenTelemetry GenAI conventions.

This architecture also works in the most constrained environments, isolated from the network or with restricted egress. The external export disappears; collectors store locally and transmit as soon as an exit window opens.

The collection gateway is the control point of sovereignty. Everything that leaves the perimeter goes through it and leaves a trace there.

flowchart LR
    subgraph P["Sovereign perimeter"]
        CP["Control plane: OpAMP and Git<br/>Configuration as code,<br/>signed distribution, internal registry"]
        APP["Applications<br/>OpenTelemetry SDK<br/>per-host agents"]
        GW["Gateway<br/>Masking at the source<br/>Sampling<br/>Exit log"]
        BE["Backend<br/>Storage<br/>Queries<br/>Local alerting"]
        META["Meta-observability<br/>Backend access logged<br/>Data loss measured"]
        CP -- configuration --> APP
        CP -- configuration --> GW
        APP --> GW
        GW --> BE
        BE --> META
    end
    EXT["Export<br/>optional, filtered<br/>and aggregated"]
    GW -. filtered exit .-> EXT

The dotted line that crosses the perimeter is the only possible exit: it starts from the gateway, never directly from an agent or an application.

8. Observability deployment models

There is no right model in absolute terms: each one moves the cursor on some dimensions. The choice depends on the sensitivity of the data collected and on the level targeted for the observed platform.

Model	What it brings	What it does not solve
SaaS from a non-European vendor	Fast start, rich features	Applicable law, support access, cut-off, lock-in through agents
Same SaaS in a European region	Data stored in Europe	Law that applies to the parent company, ancillary processing (support, AI)
Service managed by a European player	European law and operations	Possible dependency on an underlying non-European technology
Vendor software, self-hosted	Observability data inside the perimeter	License, updates and roadmap decided by the vendor
Open source stack self-hosted on qualified infrastructure or on premises	Maximum control, reversibility, compatibility with a high SEAL	Skills and capacity to plan; governance and license of each component to check
Hybrid: critical backend inside the perimeter, filtered export to a SaaS	Alerting and sensitive data under control, advanced tools for the rest	Discipline about what leaves; two chains to operate
Isolated or restricted-egress environment	No exit, maximum sovereignty	Heavier operations, updates to organize offline

Two remarks complete this table:

• Free software is not sovereign by nature. Several observability projects have changed license in recent years. A component whose maintainers, roadmap and binary distribution depend on a single company can evolve against its users’ interest. The governance of a neutral foundation (the CNCF, Cloud Native Computing Foundation, for OpenTelemetry and Prometheus) and the ability to maintain a fork matter as much as the license.
• Models can be combined. Thanks to OpenTelemetry, the same instrumentation can feed a sovereign backend for sensitive signals and an external service for aggregated metrics. The choice is no longer frozen at instrumentation time: it is made in the gateway and can evolve.

The players and offers available for each of these models are detailed in the article The state of the sovereign observability market.

9. Questions to ask an observability vendor

The word sovereign has become a sales argument. Observability vendors are no exception. Labels multiply without always resting on the technical and legal prerequisites, as shown by the analysis of the ZenDiS white paper on sovereign washing in Germany, the practice of presenting an offer as sovereign without the corresponding guarantees. The following questions help sort things out.

Vendor claim	Question to ask	What a serious answer contains
“Your data stays in Europe”	Which entity operates the service and which law does its parent company fall under?	The name of the entity, its chain of ownership, the applicable law
“Support does not access your data”	How does a support engineer read logs and traces during a ticket? From which country?	An approval mechanism by the customer, access that is logged and visible to the customer
“End-to-end encryption”	Who generates, stores and can use the storage keys?	Keys in the customer’s KMS or HSM, revocable by the customer
“AI features that respect your data”	Where does the model run and which log or trace excerpts are sent to it?	The location of inference (where the model runs), the list of data sent, a way to turn it off
“Lightweight and secure agent”	Which destinations does the agent contact? Are updates pushed remotely?	The exhaustive list of domains, a mode without automatic updates, signed binaries
“OpenTelemetry compatible”	Can you use only standard OpenTelemetry SDKs and collectors, with no proprietary agent?	Native OTLP ingestion with no loss of essential features
“Easy migration”	Can dashboards and alerts be exported in a format usable elsewhere?	A documented export, a widespread query language, an example of a real migration
“Qualified” or “certified”	On which exact scope of services? Until when?	The reference of the qualification and its precise scope

A simple rule helps decide: a promise the customer cannot verify on their own does not count as a guarantee. That is precisely what the collection gateway allows: verifying by measurement what actually leaves, instead of believing what is announced.

10. A six-step method

The following approach applies to an existing platform as well as to a new project. It starts with an inventory, because you cannot control a flow you have not seen.

1. Inventory the observability flows. List every installed agent, every configured destination and every domain allowed outbound. Cross-check with the firewall logs: forgotten flows (a security vendor’s agents, browser-side application monitoring SDKs, plugins) almost always show up at this step.
2. Classify the data collected. Apply to it the same classification level as the data it contains. Application logs from a healthcare system are health data; aggregated infrastructure metrics rarely are.
3. Set a target level per class and assess the gap. For each class, choose a target level (the SEAL scale can serve as a reference), then assess the current chain dimension by dimension with the table in section 5. The actual level is that of the weakest link.
4. Install the control point. Deploy the collection gateway, make every flow converge on it, set up masking there, then close outbound everything that does not go through it. This is the step that brings the most control for the least effort.
5. Make the backend reversible. Move instrumentation to OpenTelemetry, manage dashboards and alerts as code, choose the deployment model suited to each class (section 8), then test a switch-over to a second backend and measure how long it takes.
6. Measure and demonstrate continuously. Track the destinations actually contacted, backend access, the masking rate and data loss. Review the assessment at least once a year: the status of FISA Section 702 or of the Data Privacy Framework can change within a few months.

Step 6 turns the work of the five previous steps into evidence. It is also the step that lets the observability team become the provider of sovereignty evidence for the whole platform.

To choose the deployment model in step 5, the players map gives a first list of self-hostable open source tools, with the headquarters and the group of each vendor.

Glossary

Term	Definition
Agent	Software installed on a host that collects local logs, metrics and traces and forwards them
CADA	Cloud and AI Development Act, a proposed European regulation from June 2026
CLOUD Act	US law of 2018 allowing authorities to demand data from a US provider wherever it is stored
Cloud Sovereignty Framework	Framework for assessing the sovereignty of cloud services published by the European Commission in October 2025
OpenTelemetry Collector	Component that receives, transforms and exports logs, metrics and traces; used as an agent or as a gateway
Data Act	European regulation that notably requires cloud switching and removes switching charges on 12 January 2027
Data Privacy Framework	Adequacy decision of July 2023 governing transfers of personal data to the United States
DORA	European regulation on the digital operational resilience of the financial sector, applicable since January 2025
Sampling	Selecting part of the traces to keep, at the head (at creation) or at the tail (once the trace is complete)
FISA Section 702	US provision authorizing surveillance of non-US persons abroad with the assistance of providers
HSM / KMS	Hardware security module / key management service: where encryption keys are kept
Meta-observability	Observing the observability chain itself: losses, queues, failed exports, access
NIS2	European directive on the cybersecurity of essential and important entities
OpAMP	Open Agent Management Protocol: the OpenTelemetry protocol for remotely managing a fleet of agents and collectors
OpenTelemetry	Open CNCF standard for producing and transporting logs, metrics and traces
OTLP	OpenTelemetry Protocol: the standard protocol for transporting logs, metrics and traces
Gateway	Central collector through which every signal passes before storage or export
SBOM	Software Bill of Materials: an inventory of a software’s components
SEAL	Sovereignty Effectiveness Assurance Level: a sovereignty level from 0 to 4 assigned per objective in the European framework
SecNumCloud	ANSSI qualification for cloud services, which since version 3.2 includes protection against extraterritorial laws
Sovereign washing	Presenting an offer as sovereign without the corresponding legal and technical guarantees

Conclusion

Logs, traces and metrics form a copy of the system, produced continuously and sent outside by default. As long as they stay out of the scope of sovereignty projects, these projects stop halfway: the database is protected, while its detailed description goes to a third party every second.

There is no need to bring everything back. The task is to take back control of the flow: neutral instrumentation with OpenTelemetry, a gateway that controls and logs everything that leaves, a backend you can change and continuous measurement. Built this way, observability stops being a blind spot and becomes the instrument that demonstrates the sovereignty of the whole platform.

Sources

• Cloud Sovereignty Framework, application guide (European Commission)
• Commission advances cloud sovereignty through strategic procurement (European Commission, April 2026)
• EU CSF: Assessing Cloud Sovereignty (arc42)
• Cloud Sovereignty Framework and public procurement (cosinex, in German)
• European Commission Publishes Proposal for Act to Reduce Reliance on Foreign Cloud and AI (Wilson Sonsini, June 2026)
• Section 702 of the Foreign Intelligence Surveillance Act, Explained (Brennan Center)
• Microsoft backs EU Commission in EU court case on transatlantic data flows (Insight EU, June 2026)
• European Court of Justice to Review Challenge to EU-U.S. Data Privacy Framework (WilmerHale)
• Regulation (EU) 2023/2854, Data Act, Article 29 (EUR-Lex)
• Record of the hearing of Microsoft France (French Senate, 10 June 2025, in French)
• Microsoft confirms potential access to EU data by US authorities (it-daily)
• Microsoft’s email block a wake-up call for digital sovereignty and Microsoft’s denial (heise, May and June 2025)
• AWS Launches AWS European Sovereign Cloud (Amazon, January 2026)
• Section 702 expiration (Axios, June 2026)
• Bleu vs S3NS vs Scaleway (Qovery, October 2026)
• Sovereign Washing (ayedo, on the ZenDiS white paper)

BridgesWhat this page changes beyond the technical team.

BusinessValue, cost, risk

The real cost of leaving lies less in transferring data than in re-instrumenting and rewriting dashboards and alerts. See OpenTelemetry and reversibility.

OrganizationWho decides, who owns

The observability tool is chosen as a tool, not as hosting: it has to enter architecture reviews, the DORA register of ICT providers and data classification.

PeopleTeams, on-call, skills

A team that can only operate its stack through a vendor's tool loses control on the day the tool is cut off. Degraded-mode exercises keep that skill alive.

Business linesProduct, finance, risk, customer

Logs from a healthcare system are health data: the business owners of the data have to approve what is collected and where it goes.

Why bridges matter →