Region Labels Are Marketing, Not Treaties

The Map That Lied Politely

The diplomatic incident began with a screenshot.

A vendor’s pricing page displayed a reassuring label: “Region: Europe.” They spoke as if a region were a treaty—stable borders, predictable law, sovereign control. Our procurement team smiled. The project timeline moved forward.

Then we read the contract.

Support could be provided “from any location.” Subprocessors were “subject to change.” The governing law was not ours. Telemetry and diagnostics could be processed on foreign infrastructure. Encryption keys were “managed by the service.” The vendor’s corporate headquarters sat under a foreign compelled-access regime.

The region label was a flag on a brochure. The power lived elsewhere.

We paused the procurement. This is unacceptable to the municipality. We cannot negotiate on theatrical sovereignty.

The Dependency: Treating region labels as protection.

The Sovereign Choice: Demanding enforceable guarantees on jurisdiction, access, disclosure, and exit.

Why Region Labels Fail as a Governance Signal

A “region” usually describes where compute and storage are intended to run. It does not, by itself, answer:

Which courts can compel the provider? If the provider is subject to the US CLOUD Act, a region label does not neutralize that.
Who operates the system? Privileged support access often crosses borders, especially during incidents.
Where do logs and diagnostics go? Many systems keep primary data in-region while exporting metadata, logs, and analytics elsewhere.
Who controls the keys? “Encryption at rest” is not sovereignty if the provider holds the key custody and can be compelled.
Which subcontractors touch the data? Subprocessors are often the real empire: monitoring, ticketing, analytics, CDN, email, identity.

Region labels are not lies. They are incomplete statements, presented as conclusions.

The Dependency: When we accept a label in place of a treaty, we become dependent on the vendor’s narrative.

The Questions That Convert Geography Into Sovereignty

If we want an answer we can defend to auditors and the public, we must interrogate power, not maps.

Here is the checklist we use.

1) Jurisdictional Reality (Not Marketing Geography)

Identify the legal entity we contract with and the legal entities that process data.
Confirm governing law and dispute venue.
List all jurisdictions that can compel the provider or subprocessors.
Explicitly state exposure to foreign compelled-access laws (e.g., US CLOUD Act) and how the provider responds.

If the vendor cannot answer this clearly, the region label is decorative.

2) Privileged Access Borders

Where are support engineers located?
What tools allow them access (console, shell, database, ticket exports)?
What approvals are required for break-glass access?
Are privileged actions logged immutably, and can we export those logs in open formats?

We do not accept “global support” without strict boundaries. Borders without border control are a myth.

3) Key Custody and Cryptographic Independence

Who holds encryption keys?
Can the vendor rotate, recover, or escrow keys without municipal approval?
Is customer-managed key custody possible under municipal control?
Are backups encrypted under the same key regime, and are keys segregated per tenant?

If the vendor holds the keys, the vendor holds power. Power is what foreign courts compel.

4) Metadata and Telemetry Escape Routes

Define what “data” includes: content, metadata, logs, diagnostics.
Identify every outbound flow: monitoring, crash reports, analytics, email, SMS, identity events.
Default telemetry must be off or strictly minimized for municipal tenants.

A system can keep files in Europe while exporting the story of the Citizen’s life elsewhere. That is not acceptable.

5) Exit as a Sovereignty Test

Export within 30 days, including content, metadata, and audit logs.
Open formats and documented APIs.
Deletion verification after exit.
No punitive fees to retrieve our own records.

If we cannot leave, the region label is a trade slogan over a closed border.

The Sovereign Choice: We accept “region” only when it is paired with enforceable controls and a credible exit.

A Simple Diagram We Use Internally


Map vs. Power
┌───────────────────────┐     ┌──────────────────────────┐
│ Region label (map)     │     │ Jurisdiction (power)      │
│ "EU / Nordic"          │     │ Courts & compelled access  │
└─────────┬─────────────┘     └──────────┬───────────────┘
│                                │
▼                                ▼
Where data may sit                Who can reach it

What We Put in the Contract

We do not “trust” region labels. We translate them into treaty language:

Named legal entities and named subprocessors (with change controls).
Governing law aligned with municipal requirements.
Clear restrictions on cross-border support access.
Key custody commitments.
Telemetry minimization commitments.
Audit rights and log export obligations.
Exit obligations with timelines and formats.

When the vendor says, “Our region is Europe,” we respond: “Then write the borders into the agreement.”

The Sovereign Decision

We returned to the vendor with a simple message:

“We acknowledge your region offering. Now declare your jurisdictional posture, privileged access model, key custody, telemetry flows, and exit plan in writing. Otherwise, we will treat the region label as marketing.”

They asked for a call.

We asked for a document.

In municipal IT, sovereignty is not a feeling. It is a paper trail, enforceable controls, and the ability to walk away with the city’s history intact—within 30 days.

That is the difference between a label and a treaty.

FAQs

Is an “EU region” enough for municipal compliance?

No. It may help, but it does not define jurisdictional power, privileged access, or legal compulsion over the provider.

What should we ask instead of “where is the data stored”?

Who can access it, under which law, with which keys, via which subprocessors, and how we leave with complete records.

How do we respond to vague “data residency” claims?

We request written guarantees and architecture details. If they cannot be stated plainly, we treat the claim as marketing.