--- type: principles pillar: sovereignty code: SOV title: "Sovereignty & Compliance: design principles" description: "Five principles behind Sovereignty & Compliance: sovereignty as an architectural property, and why you are not sovereign if you cannot leave." status: draft sidebar: label: "Design principles" order: 1 source_url: "https://framework.stackit.cloud/architecture/pillars/sovereignty/principles/" source_file: "docs/architecture/pillars/sovereignty/principles.mdx" --- ## 1. Sovereignty is an architectural property, not a contract clause A contract states who is permitted to access your data. Architecture determines who is *able* to. When those diverge, the second one is what an incident, a legal order, or an auditor will actually engage with. The distinction is not academic. Two workloads can sit under the same agreement with the same provider in the same region, and one of them holds its own keys while the other does not. One of them ships logs to a service outside the boundary while the other does not. One of them runs on open interfaces while the other cannot be moved without a rewrite. The contract is identical. The sovereignty is not. Contractual guarantees are necessary. They are also the part you did not build, cannot verify yourself, and will not be able to enforce quickly. Design as though the technical properties are the ones that will be tested, because they are the only ones you control. ## 2. Know where your data is, and who can technically reach it Two separate questions, and the second is the one that gets skipped. Residency is answerable from a region setting. Reachability requires tracing every path to the data: which identities, which provider processes, which support tooling, which third-party integration, which backup destination, which log pipeline. Most organizations can answer the first question immediately and need weeks for the second. The reachability answer is also the one that changes without anyone deciding it changed. A new monitoring integration, a support ticket that involves shared diagnostics, a managed service that added a feature, each can extend the set of parties who can reach the data, and none of them arrives labelled as a sovereignty decision. ## 3. Classification precedes placement You cannot decide where data should live, how it should be encrypted, who should hold the keys, or how long it must be kept, until you know what the data is and what regulation applies to it. This is the same discipline as [`SEC 3`](/architecture/pillars/security/sec-03-data-classification/), asked with a different lens. Security classification asks how bad a leak would be. Sovereignty classification asks which legal regime governs this data, which supervisory authority cares, and what that constrains. Personal data under GDPR, health data, financial records under sector regulation, and ordinary operational telemetry have different answers, and a system that treats them uniformly is over-constrained in most places and under- constrained where it counts. Classify first. Every downstream decision in this pillar takes the classification as input. ## 4. Compliance evidence should be a by-product of the design Compliance evidence is either generated continuously by the architecture or assembled by people under time pressure once a year. The second is expensive, error-prone, and produces a snapshot that says nothing about the other eleven months. Design so that the evidence falls out: activity records that are complete because logging is not optional, key usage history that exists because keys are centrally managed, access reviews that are possible because entitlements are queryable, data placement that is provable because it is declared in infrastructure code rather than clicked into a console. The test is simple. When an auditor asks who accessed a given data set in March, is that a query or a project? ## 5. You are not sovereign if you cannot leave Reversibility is the dimension of sovereignty that is easiest to ignore, because nothing goes wrong until the day it matters entirely. A workload that cannot be moved has surrendered a form of control regardless of where it runs or who holds the keys. The dependency does not need to be exploited to be real: it changes your negotiating position, it constrains your response to a provider's strategic decisions, and it means that a risk you accepted as reversible is not. This favours open interfaces (the S3 API, Kubernetes, standard database engines, open formats) over proprietary equivalents that are frequently more convenient. That convenience is a real benefit and this principle is a real cost against it. The point is to make the trade knowingly, at design time, and to know how large it is. And as with backups: an exit plan that has never been exercised is an assumption. [`SOV 11`](/architecture/pillars/sovereignty/sov-11-exit-plan/) exists because untested reversibility and no reversibility look identical right up until the test. --- ## Related - [Overview](/architecture/pillars/sovereignty/): the questions this pillar asks - Tradeoffs - [Security principles](/architecture/pillars/security/principles/): the adjacent pillar; read both for anything touching regulated data