Digital Sovereignty

Ask most infrastructure teams whether their observability data is sovereign and you get a datacentre location. “It’s in the Zurich region.” That answer is about residency, and residency is the easy half. Sovereignty is a harder question: who can compel access to this data, who operates the system that holds it, and what happens if that relationship ends?

For a Swiss bank, insurer, hospital or federal office, those questions have concrete legal weight — and telemetry is a category that tends to escape the review entirely. Nobody classifies application logs as a data asset until an incident report shows a client name in a stack trace that was shipped to a US-owned SaaS platform.

Residency, jurisdiction, and operational control

Three different things get collapsed into the word “sovereignty”, and separating them is most of the analysis:

• Residency — where the bytes physically sit. The easiest to satisfy, the easiest to verify, and on its own the weakest guarantee. A Swiss region is a storage location, not a legal shield.
• Jurisdiction — whose courts can compel production of the data. This follows the provider’s corporate structure, not the disk’s postcode. A US-parented provider operating a Swiss region remains subject to US legal process for data under its control, which is why “hosted in Switzerland” and “outside foreign reach” are not the same claim.
• Operational control — who can technically read, change or stop the system. If the vendor’s support engineers hold the keys to your workspace, they are in your trust boundary regardless of where the storage lives.

A useful test: for each of the three, name the entity. If you cannot name it, that is the finding.

Why telemetry is the blind spot

Databases get classified. Document stores get classified. Telemetry usually does not, because it feels like exhaust rather than content. In practice it is a rich, poorly governed copy of what your systems do:

• Logs contain whatever was in scope at the log statement. Exception handlers dump request bodies. Debug lines print user objects. A URL with a token in the query string ends up in an access log. Nobody planned it and it happens continuously.
• The volume makes review impractical. You cannot manually classify a billion records a day, which is why the control has to be structural rather than a review process.
• The regulated category is narrower than “PII”. In Swiss banking, the harder category is client-identifying data — a corporate client’s name is not personal data under revDSG, but it is very much covered by banking secrecy, and no generic scanner reliably finds it. That distinction is the whole subject of PII vs CID.

So the question is not just where your observability backend runs. It is what left your network to get there.

The layer where the decision actually lives

Sovereignty for telemetry is decided at the point of egress, and there are only really two designs:

Design A — the backend decides. Agents ship everything to a platform; the platform offers regional storage, retention settings and access controls. Your sovereignty position is whatever the provider’s contract and architecture allow, negotiated after the fact, and it resets every time you change providers.

Design B — you decide before egress. A collection layer you operate sits between the systems and any backend. Sensitive fields are masked on the host. Records are routed by classification: client-identifying data to on-premises storage, anonymous operational metrics wherever is cheapest. The backend becomes a consumer of data you already governed, rather than the place governance happens.

Design B is more work. It is also the only one where the answer to “who controls this data” does not change when a vendor is acquired.

What OpenTelemetry does and does not give you

OpenTelemetry matters here, but it is worth being precise about why — the marketing around it overreaches.

What it gives you: collection and transport become an open standard rather than a vendor’s agent. Instrumentation you own, a wire format (OTLP) nobody licenses to you, and a collector you can point anywhere. That is a genuine exit path, and an exit path is a prerequisite for sovereignty — a stack you cannot leave is a stack someone else controls. The scope is covered honestly in the end of vendor lock-in.

What it does not give you: OpenTelemetry is not a governance system. A collector will happily ship unredacted client data to a foreign SaaS backend; the standard has no opinion about that. Nor does it operate itself — an OTel fleet still needs a control plane, and where that control plane runs is itself a sovereignty question. A cloud-hosted management layer that holds your configuration and your fleet inventory is a third party in your trust boundary, even if the telemetry technically flows elsewhere.

Four questions worth putting in the next vendor review

• Which legal entity operates the service, and where is its parent? Not the region — the company.
• Can the provider’s staff access our data, and is that access technically prevented or contractually promised? Those are very different controls.
• Does the management plane see our telemetry, or only our configuration? For a control plane, the honest answer should be configuration only, with data flowing directly from your collectors to your destinations.
• What is the exit? Concretely: if we terminate, what do we re-instrument, what do we rebuild, and how long does the collection layer keep working. If the answer is “replace every agent”, the lock-in is structural.

Where to start

You do not need a sovereignty programme to make progress. Three steps move the position materially:

1. Inventory egress. Which agents ship what, to which company, under which contract. This is usually a one-day exercise that surprises everyone.
2. Mask at the source for the sensitive fields you already know about, so they never cross the boundary — masking PII in logs.
3. Split the stream by classification, so regulated records have an on-premises destination and the rest can go wherever is economical — routing by attribute.

None of that requires changing backends. It changes who decides. The full reference design — agent, Swiss gateway tier, split destinations, self-hosted control plane — is in how to build a Swiss sovereign telemetry architecture.