--- type: pillar pillar: sovereignty code: SOV title: Sovereignty & Compliance description: Do you control your data, and can you prove it? Residency, key ownership, operator access, auditability and reversibility. status: draft sidebar: label: "Overview" order: 0 hideLinkCard: true source_url: "https://framework.stackit.cloud/architecture/pillars/sovereignty/" source_file: "docs/architecture/pillars/sovereignty/index.mdx" --- > **Do you control your data, and can you prove it?** For many customers on this platform, sovereignty is the reason the platform was chosen, and on STACKIT the questions this pillar asks have real architectural answers. Sovereignty is often discussed as a procurement matter: a clause in a contract, a certificate on a website, a data processing agreement. Those matter, and they are not what this pillar is about. This pillar is about the decisions you make while designing, where a database goes, which key encrypts it, where its logs are shipped, which third-party service processes a copy, and whether you could move the whole thing somewhere else if you had to. Every one of those has alternatives, and every one is a place where sovereignty is either preserved or quietly given away. ## Three kinds of sovereignty Treating them as one concept is the most common source of confused requirements. **Data sovereignty**, where data resides, which law governs it, and who can technically reach it. The most discussed and the most frequently reduced to residency alone, which is the necessary part and not the sufficient part. Data in Frankfurt that a party outside the EU can technically decrypt is resident, not sovereign. **Operational sovereignty**, who can affect your ability to operate. Not just who holds your data but who could stop you running, deny you support, or be compelled to withdraw a service. This is the dimension sanctions and extraterritorial legal orders act on. **Software sovereignty**: whether you are technically able to leave. A workload built entirely on one provider's proprietary interfaces is dependent regardless of where it is hosted or who holds the keys. Reversibility is a sovereignty property, and an untested one is an assumption. ## What this pillar covers - Classifying data by regulatory exposure, not only by security sensitivity - Deliberate placement of workloads, data, and their dependencies - Telemetry residency, logs, metrics, traces, and backups are data too - Key ownership, and knowing precisely who can technically decrypt - Reducing provider and operator access, including to data in use - The jurisdictional chain: subprocessors, third-party and marketplace services - Auditability as an architectural property rather than a retrofit - Mapping to the frameworks you are actually assessed against, and the responsibility split - Identity federation without importing a non-EU dependency - Reversibility and a tested exit path ## What it does not cover Defence against attackers belongs to [Security](/architecture/pillars/security/). The two pillars overlap mechanically (both discuss encryption, access control, and audit logs) while asking different questions. Security asks whether an adversary can reach your data. Sovereignty asks who can reach it *by design*, under whose legal authority, and whether you would know. Encryption at rest with provider-managed keys satisfies most of [`SEC 7`](/architecture/pillars/security/sec-07-encryption/). It does not satisfy [`SOV 4`](/architecture/pillars/sovereignty/sov-04-key-ownership/), because the provider remains technically able to decrypt. Same control, different question. ## Why STACKIT changes the answers Much sovereignty guidance written for hyperscale platforms is about mitigating a structural problem: the provider, or its parent, is subject to a non-EU legal regime, so customers build elaborate compensating controls. STACKIT starts from a different position, and states the specifics rather than leaving them to be inferred. All regions are hosted exclusively in Germany (`eu01`) and Austria (`eu02`). Those data centres are the group's own, development of the cloud takes place in Germany, and the platform is certified against BSI C5 Type 2, ISO 27001, ISO 27017, ISO 27018, and SOC 2. That each of those is published and attributable matters as much as the facts themselves, and it is the standard this pillar goes on to ask you to hold your own dependencies to. ## Where ES³ fits, and where this pillar does ES³, the European Sovereign Stack Standard, measures whether a *service* is sovereign. Its Sovereignty Maturity Level framework assesses a service together with its provider across nine dimensions, from corporate ownership and jurisdiction through to supply chain, on binary questions that each demand a named piece of evidence. An independent auditor checks it, and the result is one of four levels: Initial, Managed, Advanced or Future-Proof. This pillar asks the next question. **A workload assembled from sovereign services is not automatically a sovereign workload.** A service assessed at the highest level, configured to ship its logs to an analytics tool outside the boundary, has not stopped being sovereign; your workload has. That gap is architecture, and it is what the eleven questions here are about. The two meet at the point where you have to know something about a dependency, and this is where ES³ makes the work shorter rather than possible. Establishing what a third party does with your data has always been answerable: you ask, you read the agreement, you check the certifications, you record what you found. That is what the questions here describe and it does not depend on anybody having been assessed. What an SML changes is the effort and the comparability. A party that carries one has been asked these questions already, under audit, against published criteria, and the answer is a level rather than a description you have to interpret. Where one exists, take it. It is a new standard, so for most parties one will not exist yet, and the questions below are how you establish the same thing yourself. | Where you need to know | If an SML exists | If not | |---|---|---| | Where a dependency sits, and under whose law | Its level, and which of ES³'s three control scopes it was assessed at | [`SOV 6.1`](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/#sov-61-maintain-a-current-inventory-of-every-party-that-processes-your-data): ask, and record what you were told | | Whether a party meets the bar you need | Its level, compared against the bar | [`SOV 6`](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/): assess the specific controls that matter to you | | Which jurisdictions count as acceptable | ES³'s Approved Jurisdictions List, as a published starting point | Your own legal function, which is where the answer came from before | Three scales are now in play and they answer three different questions. The **sovereignty tier** says how much sovereignty this workload needs, and comes from the Advisory Framework. The **SML** says how much a service delivers, and comes from an audit. The **coverage** of your own answer says how much of your workload a practice is actually true for. A tier is a requirement, a level is a property of somebody else's service, and coverage is a measurement of yours. ES3 relocates the work rather than removing it. The questions stop being "how do we compensate for the provider's jurisdiction" and become sharper ones that are genuinely yours to answer: which of your dependencies quietly sit outside that boundary, where your telemetry actually goes, who holds the keys, and whether the compliance evidence an auditor will ask for exists as a by-product of your design or has to be assembled by hand every year. The platform gives you a sovereign foundation. What you build on it can still leak. ## Where to start 1. Design principles 2. Tradeoffs ## How the sovereignty tiers bind these questions This pillar takes the workload's **sovereignty tier** as input. The tiers are defined by the Advisory Framework (Tier 1 sovereignty-mandatory, Tier 2 sovereignty-preferred, Tier 3 flexible) and settled during provider selection, before architecture begins. [`SOV 1`](/architecture/pillars/sovereignty/sov-01-sovereignty-tier/) is about establishing and recording which one applies; the rest read it to decide how strictly they bind. | | Tier 1 | Tier 2 | Tier 3 | |---|---|---|---| | [`SOV 1`](/architecture/pillars/sovereignty/sov-01-sovereignty-tier/) sovereignty tier | mandatory | mandatory | record the result | | [`SOV 2`](/architecture/pillars/sovereignty/sov-02-placement-and-residency/) placement and residency | mandatory | mandatory | not applicable | | [`SOV 3`](/architecture/pillars/sovereignty/sov-03-telemetry-residency/) telemetry residency | mandatory | mandatory | not applicable | | [`SOV 4`](/architecture/pillars/sovereignty/sov-04-key-ownership/) key ownership | mandatory | recommended | provider-managed sufficient | | [`SOV 5`](/architecture/pillars/sovereignty/sov-05-operator-access/) operator access to data in use | mandatory | assess | not applicable | | [`SOV 6`](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/) jurisdictional chain | strict | review | not applicable | | [`SOV 7`](/architecture/pillars/sovereignty/sov-07-auditability/) auditability | mandatory | mandatory | as your obligations require | | [`SOV 8`](/architecture/pillars/sovereignty/sov-08-compliance-mapping/) compliance mapping | mandatory | mandatory | as your obligations require | | [`SOV 9`](/architecture/pillars/sovereignty/sov-09-identity-sovereignty/) identity sovereignty | mandatory | assess | not applicable | | [`SOV 10`](/architecture/pillars/sovereignty/sov-10-open-interfaces/) open interfaces | recommended | recommended | recommended | | [`SOV 11`](/architecture/pillars/sovereignty/sov-11-exit-plan/) tested exit plan | mandatory | recommended | not applicable | Two rows are deliberately not tier-bound. [`SOV 7`](/architecture/pillars/sovereignty/sov-07-auditability/) and [`SOV 8`](/architecture/pillars/sovereignty/sov-08-compliance-mapping/) follow the obligations the workload is actually subject to rather than its sovereignty tier, and those are frequently independent: a Tier 3 workload in a regulated sector is assessed like any other. [`SOV 10`](/architecture/pillars/sovereignty/sov-10-open-interfaces/) applies everywhere because reversibility is an engineering and commercial property before it is a regulatory one. A best practice that does not apply at your tier is a recorded, justified answer, not a gap. ## Questions Eleven questions. Numbers follow the order the decisions are usually made in and do **not** indicate priority. --- ### [`SOV 1`](/architecture/pillars/sovereignty/sov-01-sovereignty-tier/): How do you establish and record the workload's sovereignty tier? Determine which of the Advisory Framework's three sovereignty tiers applies (mandatory, preferred, or flexible) and record the reasoning rather than only the result. Every other question in this pillar reads that tier to decide how strictly it binds, which is why it comes first. The tier is defined by the Advisory Framework and settled during provider selection. This question is about establishing it deliberately and writing it down, not about inventing a classification. → [Best practices](/architecture/pillars/sovereignty/sov-01-sovereignty-tier/) ### [`SOV 2`](/architecture/pillars/sovereignty/sov-02-placement-and-residency/): How do you decide where workloads and data are placed, and how do you know? Choose regions and availability zones as an explicit decision recorded against the classification, not as a deployment default. Then trace every dependency (managed services, integrations, CDN, DNS, identity, support tooling) and establish where each one actually processes data. → [Best practices](/architecture/pillars/sovereignty/sov-02-placement-and-residency/) ### [`SOV 3`](/architecture/pillars/sovereignty/sov-03-telemetry-residency/): How do you keep telemetry and backups within the same boundary as the data? Logs, metrics, traces, error reports, and backups routinely contain the data they describe, and routinely travel to destinations nobody classified. Apply the same residency, retention, and access rules to them as to the primary data set. → [Best practices](/architecture/pillars/sovereignty/sov-03-telemetry-residency/) ### [`SOV 4`](/architecture/pillars/sovereignty/sov-04-key-ownership/): How do you decide who is technically able to decrypt your data? Determine per data set who is technically able to decrypt it. Where the classification requires that the provider is not, manage the keys yourself with defined generation, rotation, and revocation, and understand what that costs you in availability and operational burden. → [Best practices](/architecture/pillars/sovereignty/sov-04-key-ownership/) ### [`SOV 5`](/architecture/pillars/sovereignty/sov-05-operator-access/): How do you limit provider and operator access, including to data in use? Encryption protects data at rest and in transit; during processing it is generally in cleartext in memory. Where the classification warrants it, close that gap with confidential computing, and constrain the support and operations paths that can reach a running system. → [Best practices](/architecture/pillars/sovereignty/sov-05-operator-access/) ### [`SOV 6`](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/): How do you know the jurisdiction of every party that processes your data? A sovereign provider with a non-sovereign dependency is not a sovereign chain. Maintain a current inventory of every party that processes your data, including third-party and marketplace services you added yourself, with its jurisdiction, and review it when the architecture changes. → [Best practices](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/) ### [`SOV 7`](/architecture/pillars/sovereignty/sov-07-auditability/): How do you produce the evidence an auditor or investigator will ask for? Activity records must cover the actions an auditor or investigator will ask about, be protected against modification by the parties they record, and be retained for the period your regulation and your investigation needs require. Retrofitted audit trails have gaps exactly where they matter. → [Best practices](/architecture/pillars/sovereignty/sov-07-auditability/) ### [`SOV 8`](/architecture/pillars/sovereignty/sov-08-compliance-mapping/): How do you map your controls to the frameworks you are assessed against? Identify which frameworks apply (GDPR, BSI C5, ISO 27001, sector-specific regulation, DORA, NIS2) and map your controls to them explicitly. For each, establish which part the provider satisfies and which part remains yours. Most compliance failures occur on the customer side of a boundary the customer did not know existed. → [Best practices](/architecture/pillars/sovereignty/sov-08-compliance-mapping/) ### [`SOV 9`](/architecture/pillars/sovereignty/sov-09-identity-sovereignty/): How do you federate identity without importing a dependency you did not intend? Identity is a control plane: whoever operates it can, in principle, grant access to everything behind it. Trace the authentication chain and establish who operates each link, because a workload placed carefully for sovereignty reasons and authenticated through a provider outside that boundary has a dependency at its most privileged point. Federation through open standards means that dependency is a choice rather than a given. → [Best practices](/architecture/pillars/sovereignty/sov-09-identity-sovereignty/) ### [`SOV 10`](/architecture/pillars/sovereignty/sov-10-open-interfaces/): How do you preserve the ability to move the workload elsewhere? Prefer standard, portable interfaces (S3-compatible object storage, Kubernetes, standard database engines, open data formats) over proprietary equivalents. Where you choose a proprietary capability for good reasons, record the decision and the estimated cost of undoing it. → [Best practices](/architecture/pillars/sovereignty/sov-10-open-interfaces/) ### [`SOV 11`](/architecture/pillars/sovereignty/sov-11-exit-plan/): How do you know your exit plan works? Document what leaving would involve: which data, in which formats, over which paths, in what time, at what cost. Then extract a representative data set and verify it is complete and usable elsewhere. Untested reversibility and no reversibility are indistinguishable until the day they are not. → [Best practices](/architecture/pillars/sovereignty/sov-11-exit-plan/) ## Related - Design principles - Tradeoffs - [Security](/architecture/pillars/security/), where three pairs should be read together - [`SOV 1`](/architecture/pillars/sovereignty/sov-01-sovereignty-tier/) with [`SEC 3`](/architecture/pillars/security/sec-03-data-classification/): the sovereignty tier and the data classification that feeds it - [`SOV 4`](/architecture/pillars/sovereignty/sov-04-key-ownership/) with [`SEC 7`](/architecture/pillars/security/sec-07-encryption/): key ownership and encryption, the same mechanisms from two directions - [`SOV 7`](/architecture/pillars/sovereignty/sov-07-auditability/) with [`SEC 11`](/architecture/pillars/security/sec-11-detection-and-response/): audit evidence and detection, which draw on the same records