Data Sovereignty: What It Is and How to Keep Control

Data sovereignty is the principle that data is subject to the laws of the jurisdiction it belongs to, usually the country where it was collected or where the people it describes live. In practice it is a question of control: whose law can reach the data, who operates the systems that hold and process it, and what is allowed to leave.

That makes sovereignty broader than data residency, which only answers where the bytes are stored. Data can sit in Frankfurt and still be reachable by another country’s courts, because legal reach follows the company operating the system as well as the hardware. This guide covers the difference, the laws that create sovereignty obligations, what a sovereign cloud does and does not solve, and an edge-to-cloud way to keep control of the data path.

Sovereignty, residency, localization, and locality

Four terms get used interchangeably. They answer different questions.

The first three are legal and policy requirements. The fourth is an engineering technique, and it is the one that makes the other three cheaper: data that is processed where it originates, and reduced before it moves, creates fewer transfers to justify.

Residency is necessary for sovereignty but does not deliver it. A regional deployment keeps the primary copy in place, while logs, backups, support access, analytics exports, and vendor tools can still carry the data elsewhere. The data residency requirements guide covers the storage rules region by region. This article covers control.

Why location alone does not settle sovereignty

Three legal facts explain why location alone stopped being a sufficient answer.

US law reaches data held abroad. The CLOUD Act of 2018 added 18 U.S.C. § 2713, which requires a US communications or computing service provider to preserve or disclose data within its “possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States.” Storing data in an EU region of a US-headquartered provider does not, by itself, take it out of that reach.

EU courts judge transfers by who can access the data. In Schrems II (Case C-311/18, 16 July 2020), the Court of Justice invalidated the EU-US Privacy Shield because US surveillance law did not give protection essentially equivalent to EU law. It kept standard contractual clauses valid, but required the exporter to check that the destination’s law lets the importer honour them.

The penalties attach to transfer architecture. In May 2023, Ireland’s Data Protection Commission fined Meta EUR 1.2 billion for transferring EU users’ data to the US under standard contractual clauses that did not address the risks Schrems II identified, and ordered the transfers suspended. There was no breach. The finding was about where data went and whose law could reach it there.

The legal ground keeps moving. The EU-US Data Privacy Framework now provides an adequacy decision for certified US organizations, and the EU General Court upheld it on 3 September 2025 in Latombe v Commission. That judgment has been appealed to the Court of Justice. A transfer mechanism can change under you. What you can keep stable is control over which data moves at all.

Laws that create sovereignty obligations

These are the regimes that most often shape architecture. Each summary links to the primary text or the regulator’s own explanation.

The pattern across these laws is consistent. Each asks where data is processed, who can access it, and on what legal basis it crossed a border. None is satisfied by a storage setting alone.

What a sovereign cloud solves, and what it leaves to you

Hyperscalers now sell sovereign clouds aimed at the operator question. The AWS European Sovereign Cloud, generally available since 15 January 2026 with its first region in Brandenburg, Germany, is described by AWS as physically and logically separate from other AWS Regions and operated exclusively by EU residents.

A sovereign cloud addresses two of the questions above: where the infrastructure is and who operates it. Commentators have raised the open question of how far a US parent company’s legal obligations extend into such a separate entity. That is a legal assessment for your counsel.

What no cloud offering can answer for you is what your own pipelines send into it and out of it. A sovereign region protects the data that stays inside it. The collector on a factory floor, the observability agent on every server, the SaaS tool that receives an export, and the analytics job that copies a table to another region all sit on your side of the line.

A sovereignty operating model: six questions

Treat sovereignty as a set of controls you can answer for, per data flow. These six questions turn the legal principle into engineering work.

1. What is in scope, and whose law claims it? Classify data by origin jurisdiction and type: personal data, special categories, regulated sector data, and non-personal industrial data (now relevant under the EU Data Act).
2. Where is it processed, not only stored? Every hop counts: collectors, queues, stream processors, model endpoints, and dashboards.
3. Who operates the systems and holds the keys? Record the legal entity behind each operator and each key management service. Encryption keys held by the provider leave access with the provider.
4. What leaves the jurisdiction, and in what form? Decide per flow whether raw records, pseudonymised records, or aggregates may cross. Under GDPR Recital 26, pseudonymised data is still personal data; only information that is truly anonymous falls outside the regulation.
5. Who can compel access, and would you know? Map the legal exposure of every processor, including your vendors’ support staff and their parent companies.
6. What is the evidence? Regulators and customers ask how you know. Configuration in version control, explicit output lists, and records that carry where they were processed are evidence. A diagram is a claim.

An edge-to-cloud implementation path

The cheapest sovereignty control is the transfer that never happens. The path below moves processing to the data, so only what you decide may leave actually leaves.

1. Inventory flows, including operational data. Server logs contain IP addresses, and the EU Court of Justice held in Breyer (C-582/14) that even a dynamic IP address can be personal data. Traces and error messages carry user IDs and emails. Include every collector and agent in the inventory, not only the databases.
2. Write the release rule for each jurisdiction. For each flow, name the fields allowed to cross. Use an allowlist: a rule that builds the outbound record from named fields cannot leak a new field that someone adds upstream next quarter, while a denylist that deletes known sensitive fields can.
3. Run the reduction on machines inside the jurisdiction. Filtering, redaction, and aggregation happen before the network transfer, on nodes you control in that country or region.
4. Route by jurisdiction with explicit destinations. Full-fidelity records go to in-region storage. Reduced records go to central analytics. Nothing goes anywhere that is not written in the job.
5. Keep the control plane out of the data path, and review what it does receive. Orchestration needs health and status, not payloads. Document the metadata boundary as part of your assessment.
6. Prove it continuously. Stamp records with where they were processed, keep job definitions under review, and test that forbidden destinations receive nothing.

Example: full records stay in the EU, a reduced record leaves

Expanso runs data pipelines on nodes you choose, selected by label, so a job can process records on the machine or site where they originate and send only the outputs you configure. Pipeline payloads are processed on those nodes; Expanso Cloud receives operational metadata, including metrics, health, and logs, which belongs in your review. The security and governance page sets out that boundary. Where the orchestrator itself must sit inside the jurisdiction, edge nodes can connect to a self-hosted control plane instead, which is available in some configurations.

The job below reads application events on a node labelled jurisdiction: eu. It writes the complete records to local storage on that node and writes a second, reduced stream built from an allowlist of fields: no email, no user ID, and the client IP truncated to its /24 network. Both outputs are files so the example runs anywhere; in production the outbound output would be your central destination, such as aws_s3 or http_client.

name: sovereign-events
type: pipeline
selector:
  match_labels:
    jurisdiction: eu
config:
  input:
    file:
      paths: ["./events.jsonl"]
      scanner:
        lines: {}
  pipeline:
    processors:
      - mapping: |
          root = this
          root.jurisdiction = @node_label_jurisdiction
          root.processed_on = @node_id
  output:
    broker:
      pattern: fan_out
      outputs:
        - file:
            path: ./in-region/events.jsonl
            codec: lines
        - file:
            path: ./outbound/events.jsonl
            codec: lines
          processors:
            - mapping: |
                root.ts = this.ts
                root.event = this.event
                root.status = this.status
                root.latency_ms = this.latency_ms
                root.jurisdiction = this.jurisdiction
                root.client_net = this.client_ip.re_replace_all("\\.[0-9]+$", ".0/24")

Three details carry the sovereignty controls:

• selector places the job only on nodes whose labels match. Label the nodes you install in the EU, and the job runs there and nowhere else.
• @node_label_jurisdiction and @node_id are metadata the runtime attaches to every record. Each record carries the jurisdiction label and node that processed it, which is evidence produced by the executor rather than asserted by a document.
• The outbound mapping starts from an empty record and copies named fields. A field added to the source later does not reach the outbound stream unless someone adds it here, in a change you can review.

Run it locally

You can run this on one machine with local mode, which needs no account. Save the job as sovereign-events.yaml, then create a node config with the label and three sample events:

cat > edge.yaml <<'EOF'
name: eu-node-01
local_mode: true
labels:
  jurisdiction: eu
EOF

cat > events.jsonl <<'EOF'
{"ts":"2026-09-27T09:00:01Z","event":"login","status":200,"latency_ms":41,"user_id":"u-1842","email":"[email protected]","client_ip":"198.51.100.23"}
{"ts":"2026-09-27T09:00:02Z","event":"checkout","status":500,"latency_ms":913,"user_id":"u-2210","email":"[email protected]","client_ip":"203.0.113.77"}
{"ts":"2026-09-27T09:00:03Z","event":"search","status":200,"latency_ms":88,"user_id":"u-1842","email":"[email protected]","client_ip":"198.51.100.23"}
EOF

Start the node in one terminal:

expanso-edge run --local --config ./edge.yaml \
  --data-dir ./edge-data --api-listen 127.0.0.1:19010 --no-watch

Deploy the job from a second terminal in the same directory:

export EXPANSO_CLI_ENDPOINT=http://127.0.0.1:19010
expanso-cli job validate sovereign-events.yaml --offline
expanso-cli job deploy sovereign-events.yaml
expanso-cli job list

On expanso-edge v2.1.21 the job completes in a few seconds. The in-region file keeps every field and records where it was processed:

{"client_ip":"198.51.100.23","email":"[email protected]","event":"login","jurisdiction":"eu","latency_ms":41,"processed_on":"eu-node-01","status":200,"ts":"2026-09-27T09:00:01Z","user_id":"u-1842"}

The outbound file holds only the allowlisted fields:

{"client_net":"198.51.100.0/24","event":"login","jurisdiction":"eu","latency_ms":41,"status":200,"ts":"2026-09-27T09:00:01Z"}

What this example does not prove

Be precise about the boundaries, because sovereignty evidence is only as good as its weakest claim.

• Placement needs a workspace. Local mode runs every job on its one node and does not evaluate the selector. To test placement, deploy to an Expanso Cloud workspace with nodes in more than one location and check expanso-cli execution list --job-id JOB_ID: a job whose selector matches no connected node is stored but never executes.
• A label is a statement you make. Expanso’s documentation is explicit that node labels are metadata, not security boundaries. The jurisdiction: eu label is true only if the node is installed where it says. Keep installation records with the rest of your evidence.
• Truncating an IP reduces identifiability. It may not anonymise. Whether the outbound record is anonymous, and so outside the GDPR, depends on what else it can be combined with. That is a call for your data protection officer, made per flow.

For a longer treatment of redaction patterns, see Remove PII From Logs Before You Export Them. The Expanso recipes list further jobs that were run end to end, with the limits of each proof stated.

Common data sovereignty mistakes

Treating a cloud region as the answer. Global load balancers, cross-region replication, central logging, backups, and CDN caches all move data out of the region you chose. Each is a flow to justify.

Leaving operational data out of scope. Logs, metrics, and traces routinely carry IP addresses, user IDs, and emails. A central observability platform in another country ingesting them is a cross-border transfer.

Redacting with a denylist. Deleting the fields you know about fails open when a new field arrives. Build outbound records from an allowlist.

Routing through a central compliance gateway. A gateway in one country that inspects everyone’s data and forwards it to the right region has already moved the data before deciding where it may go. Enforce the rule at the source.

Assuming the mechanism is permanent. Privacy Shield was invalidated in 2020. The Data Privacy Framework has survived its first challenge and faces an appeal. India’s transfer rules can change by notification. Architecture that minimises what crosses borders keeps working when the legal basis changes.

Data sovereignty checklist

Inventory

• Every data source recorded with its location and governing jurisdiction
• Every flow mapped to every destination, including logs, traces, backups, and vendor tools
• Data classified: personal, special category, regulated sector, non-personal

Control

• Legal entity recorded for each operator, processor, and key holder
• Outbound fields defined per flow as an allowlist
• Processing for restricted data placed on nodes inside the jurisdiction
• Control-plane and vendor metadata reviewed and documented

Legal basis

• A transfer mechanism recorded for every flow that crosses a border
• Transfer impact assessments kept current where standard contractual clauses are used
• Regulatory change monitored in each jurisdiction you operate in

Evidence

• Job and pipeline definitions under version control and review
• Records stamped with where they were processed
• Tests that confirm forbidden destinations receive nothing

FAQ

What is data sovereignty in simple terms?

Data sovereignty means data is governed by the laws of the place it belongs to, usually where it was collected or where the people it describes live. For an organization, it means being able to say whose law can reach the data, who operates the systems holding it, and what is allowed to leave.

What is the difference between data sovereignty and data residency?

Data residency is about where data is stored. Data sovereignty is about whose law governs the data and who can access it. Data stored in the EU by a provider subject to US law satisfies an EU residency requirement, but may still be reachable under the US CLOUD Act, which is a sovereignty concern.

Is data localization the same as data sovereignty?

No. Localization is one strict way some countries enforce sovereignty: the data must stay in the country, and copies abroad are restricted or banned. Russia’s Federal Law 242-FZ is an example. Many sovereignty regimes, including the GDPR, allow transfers when a legal mechanism is in place.

Does a sovereign cloud make me compliant?

It can address infrastructure location and operator control for the data you place in it. It does not govern what your own collectors, pipelines, vendors, and exports send in or out, and your counsel still needs to assess the provider’s legal exposure. Compliance depends on the whole data path.

Does data sovereignty apply to logs and telemetry?

Yes, when they contain personal data or regulated information. Server logs usually contain IP addresses, and application logs often contain user identifiers. Under the EU Data Act, non-personal data held by cloud providers in the EU also has protections against unlawful third-country government access.

How does edge computing help with data sovereignty?

Edge processing runs filtering, redaction, and aggregation on machines inside the jurisdiction, before data crosses a network. Only the reduced output travels, so fewer flows need a transfer mechanism, and the job definition itself documents what may leave.

Related articles

• Data Residency Requirements: A Complete Guide for Distributed Teams
• GDPR-Compliant Data Storage: Architecture Guide
• Data Compliance: What It Is, Why It Matters, and How to Automate It
• Remove PII From Logs Before You Export Them
• What Is an Observability Pipeline?

If you have a specific sovereignty obligation and want to test whether processing at the source meets it, book a demo and bring the requirement. The edge data governance guide covers the governance model in more depth.