---
id: SOV02
pillar: sovereignty
title: SOV 2. How do you decide where workloads and data are placed, and how do you know?
description: Placement is the first decision the tier constrains, and the part that gets missed is not the main data store but the dependencies nobody drew on the diagram.
status: draft
services: [kubernetes-engine]
tiers: [1, 2]
sidebar:
order: 11
label: Placement and residency
source_url: "https://framework.stackit.cloud/architecture/pillars/sovereignty/sov-02-placement-and-residency/"
source_file: "docs/architecture/pillars/sovereignty/sov-02-placement-and-residency.mdx"
---
Placement is the most visible sovereignty decision and the easiest to believe you have made. The
primary compute and the primary database are chosen deliberately. What surrounds them frequently
is not, and a residency claim is only as strong as the dependency nobody checked.
The question is therefore less about choosing a region than about being able to demonstrate, for
every component that touches the data, where it runs.
## Best practices
- [`SOV 2.1`](/architecture/pillars/sovereignty/sov-02-placement-and-residency/#sov-21-choose-region-and-availability-zone-deliberately-against-the-tier) Choose region and availability zone deliberately, against the tier
- [`SOV 2.2`](/architecture/pillars/sovereignty/sov-02-placement-and-residency/#sov-22-trace-the-processing-location-of-every-dependency-not-only-the-obvious-ones) Trace the processing location of every dependency, not only the obvious ones
- [`SOV 2.3`](/architecture/pillars/sovereignty/sov-02-placement-and-residency/#sov-23-watch-the-paths-that-are-not-obviously-data-paths) Watch the paths that are not obviously data paths
- [`SOV 2.4`](/architecture/pillars/sovereignty/sov-02-placement-and-residency/#sov-24-re-establish-residency-when-the-architecture-changes) Re-establish residency when the architecture changes
---
## SOV 2.1 Choose region and availability zone deliberately, against the tier
**Risk if not established:** High
Region choice usually happens once, quickly, and by default. For Tier 3 that is fine. For Tier 1
it is the decision the whole classification exists to drive, and it deserves to be recorded
alongside its reasoning under [`SOV 1.2`](/architecture/pillars/sovereignty/sov-01-sovereignty-tier/#sov-12-record-the-reasoning-rather-than-only-the-result).
Two separate concerns sit behind the same choice, and mixing them produces bad decisions. **Where
the data legally resides** is a sovereignty question. **How the workload survives a zone failure**
is [`REL 4`](/architecture/pillars/reliability/rel-04-redundancy/). They are answered with the same controls, which is why they get conflated, and they
can pull in different directions when a jurisdiction has one region.
State the constraint as a boundary rather than as a specific region. "This data stays in the EU"
and "this data stays in Germany" are different requirements with different available answers, and
the architecture should record which one applies.
**On STACKIT.** The platform states that it hosts all
regions exclusively in Germany, as `eu01`, and
Austria, as `eu02`, with at least three physically separate availability zones per region. Both
are within the EU, which means an EU-boundary requirement is satisfied by either while a national
requirement narrows the choice to one.
Where the requirement is broader than a single country, ES³
publishes an Approved Jurisdictions List: a core group of the EU and EEA plus Switzerland, and an
extended group of the United Kingdom, Canada, Israel, Andorra and Japan. It is a published starting
point rather than a verdict on your obligations, and comparing against one beats each team drawing
its own line from scratch. Recording which group a placement decision was made against, and which
version of the list, is what makes the decision re-checkable when the list is updated.
The property that matters for design is that parity is maintained across locations but not
guaranteed at every moment, because specialized services and newer features may be released in
specific regions first. A residency constraint that forces a particular region
can therefore constrain which services the architecture can use, and that is worth checking before
the design depends on it rather than afterwards.
The Metro availability zone, written as `-m`, is a further case of the same pattern. It
applies to the services that support synchronous replication at the storage level rather than
being universally available, which [`REL 4`](/architecture/pillars/reliability/rel-04-redundancy/) uses from the reliability side and which here means a
placement option is service-dependent.
**Tradeoffs.** **Reliability** and **Performance Efficiency.** A narrow residency boundary reduces
the placement options available for redundancy and for proximity to users. That is the cost the
tier is accepting rather than a problem to solve.
**Verify.** Which region does each component of your workload run in, and who decided that? Is the
residency requirement recorded as a boundary or as a region name?
---
## SOV 2.2 Trace the processing location of every dependency, not only the obvious ones
**Risk if not established:** High
The primary data store is almost never where a residency claim fails. It fails at a dependency
that was added for a good reason and never assessed, because it did not look like a data decision.
Enumerate what actually touches the data. The application and the database are on the diagram. The
cache, the message broker, the search index, the object store, the CDN, the backup destination,
the log pipeline, the metrics store, the error tracker, the notification service and the analytics
integration frequently are not, and every one of them holds or transports the same data.
Distinguish storage from processing. Data that is only in transit through a component still gets
processed there, and a component that holds it for milliseconds is still a processing location for
the purpose that matters here.
Produce the list as an artefact rather than as an exercise. It is the input to [`SOV 6`](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/), which asks
the harder question about jurisdiction, and it is the first thing an assessment will ask for.
**On STACKIT.** The most consequential case is the STACKIT
Marketplace.
The delivery model is software as a service: products are hosted and deployed in the vendor's
environment rather than in your project, and the customer uses the software without managing the
underlying resources.
That is a normal and useful model, and it has a direct consequence here: a marketplace product
processes your data on the vendor's infrastructure. Being purchasable through STACKIT does not
place the vendor where STACKIT is. Whether it is acceptable is a [`SOV 6`](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/) question about that
vendor specifically, and for Tier 1 data it is a question that has to be asked before the
integration rather than after.
Other delivery methods are under evaluation, including images deployed into the customer's own
project. Those would sit differently, so the delivery model of the specific product is what to
check rather than carrying this one forward.
**Tradeoffs.** **Operational Excellence.** Maintaining a dependency inventory is continuing work,
and it is the same inventory [`SEC 6.3`](/architecture/pillars/security/sec-06-network-controls/#sec-63-control-egress-because-that-is-how-data-leaves) and [`SOV 6`](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/) need, so it is paid once.
**Verify.** List every component that stores or transports your data. For each, where does it run,
and how do you know rather than assume?
---
## SOV 2.3 Watch the paths that are not obviously data paths
**Risk if not established:** Medium
Some dependencies carry data without looking like they do, and those are where a carefully placed
architecture leaks.
The recurring cases. **Support and diagnostic channels**, where a stack trace or a database dump
attached to a ticket travels wherever the ticketing system is. **Developer tooling**, where an
error tracker or a debugging session pulls production data to a workstation. **Third-party
libraries** that phone home with telemetry. **Content delivery and edge services** that cache
responses. **Email and notification services** that render personal data into a message.
None of these appear on an architecture diagram, and each has produced a residency finding
somewhere.
The pattern is that operational convenience creates data paths that the design review never saw,
because the tool was adopted by a team rather than architected in.
Address it by making the question part of tool adoption rather than by auditing afterwards.
Anything that can receive production data is in scope for [`SOV 6`](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/), whether or not it is
infrastructure.
**On STACKIT.** The platform-side control is egress restriction, which [`SEC 6.3`](/architecture/pillars/security/sec-06-network-controls/#sec-63-control-egress-because-that-is-how-data-leaves) describes: a
workload that cannot reach an unapproved destination cannot leak to one, and the attempt becomes
visible rather than silent.
That is the only mechanism that finds these paths systematically, because it does not depend on
somebody having remembered the dependency. What it will not cover is data leaving through a person
rather than through the workload, which is process rather than architecture.
**Tradeoffs.** **Operational Excellence.** Restricting egress and reviewing tool adoption both
slow teams down, which is the cost of knowing where the data is.
**Verify.** In the last incident, what data left your environment through a support ticket, a
debug session or an error report? Where did it go?
---
## SOV 2.4 Re-establish residency when the architecture changes
**Risk if not established:** Medium
A residency assessment describes the architecture on the day it was done. Architectures change
weekly, and nothing about adding a cache or an integration looks like a sovereignty event.
Tie the check to change rather than to a calendar. A new dependency, a new integration, a new
region in the design, a new backup destination and a new managed service each warrant the
question, and each is a discrete moment where somebody can be asked.
The cheapest place to put it is the change process that [`OPS 5`](/architecture/pillars/operational-excellence/ops-05-safe-deployment/) already governs. A single question
about whether a change adds a processing location costs nothing when the answer is no, which is
most of the time.
Watch for changes made by the provider rather than by you. A service gaining a new region or a
managed component changing where it runs is outside your change process, which is one of the
things the shared responsibility split in [`SOV 8.3`](/architecture/pillars/sovereignty/sov-08-compliance-mapping/#sov-83-establish-the-responsibility-split-per-control) should make explicit.
**On STACKIT.** No platform feature detects a residency change in your architecture. What the
platform supplies is the record of what was created and when, through the audit log in [`SOV 7`](/architecture/pillars/sovereignty/sov-07-auditability/),
which is what makes a retrospective answer possible when somebody asks how a component arrived.
**Tradeoffs.** **Operational Excellence.** One more question in a review that already has several.
It is cheap in proportion to how rarely the answer is interesting.
**Verify.** When did your residency assessment last get updated, and how many architecture changes
have shipped since?
---
## Related
- [`SOV 1`](/architecture/pillars/sovereignty/sov-01-sovereignty-tier/) Tier, which sets how strictly this binds
- [`SOV 3`](/architecture/pillars/sovereignty/sov-03-telemetry-residency/) Telemetry residency, the case most often missed
- [`SOV 6`](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/) Jurisdictional chain, which asks who rather than where
- [`REL 4`](/architecture/pillars/reliability/rel-04-redundancy/) Redundancy, the reliability side of the same placement choice
- [`SEC 6.3`](/architecture/pillars/security/sec-06-network-controls/#sec-63-control-egress-because-that-is-how-data-leaves) Egress control, which surfaces undeclared destinations