SOV 1. How do you establish and record the workload's sovereignty tier?

This question comes first because everything after it takes the answer as input. Whether you hold your own keys, whether telemetry may leave a boundary, whether a marketplace service is acceptable and whether an exit plan needs testing all depend on which tier the workload sits in.

The tier itself is not defined here. The Advisory Framework classifies workloads into three sovereignty tiers, and this pillar adopts that classification unchanged rather than inventing a second one. Two schemes for the same question in one framework would be a defect, and whichever is better in isolation, having one is worth more than having the better one.

Best practices

• SOV 1.1 Determine which tier applies, using the Advisory Framework definition
• SOV 1.2 Record the reasoning rather than only the result
• SOV 1.3 Classify per data set, because a workload rarely sits at one tier
• SOV 1.4 Revisit when the data, the regulation or the business changes

---

SOV 1.1 Determine which tier applies, using the Advisory Framework definition

Risk if not established: Medium

The three tiers separate on regulatory exposure rather than on sensitivity, which is a distinction SEC 3.1 also draws and which is worth keeping.

Tier 1, sovereignty-mandatory, covers data under a regulatory or contractual obligation for local storage and processing, data that creates severe liability if reached by foreign authorities, and special categories of personal data. The provider requirement is exclusive.

Tier 2, sovereignty-preferred, covers data with no hard regulatory veto but elevated protection needs, where compromise would cause reputational or competitive damage.

Tier 3, flexible, covers data with no personal content and no sensitivity, where speed and reach outweigh strict sovereignty.

Determining the tier is a legal and business judgement rather than a technical one. Engineering supplies what the data actually contains and where it flows; somebody who understands the obligations decides which tier follows.

On STACKIT. The tier decides provider selection, which happens during Advisory and before architecture. By the time this pillar applies, the workload is on STACKIT and the tier is known.

That sequencing is worth stating because it changes what this pillar is for. It does not argue that you should be on a sovereign cloud. It takes that decision as made and asks how the sovereignty is actually implemented, and whether you could demonstrate it.

Tradeoffs. None between pillars. The cost is a conversation with people outside engineering, and the answer constrains the architecture rather than the reverse.

Verify. Which tier does your workload sit in, and who determined that? Where is it written down?

---

SOV 1.2 Record the reasoning rather than only the result

Risk if not established: Medium

A tier recorded as a label cannot be defended, revisited or applied consistently. What makes it usable is the reasoning: which data drove it, which obligation applies, and who agreed.

That record does three jobs. It lets a future reader tell whether the classification still holds when the workload changes. It is the first thing an auditor asks for under SOV 7. And it is what allows an exception to be discussed rather than assumed.

Record who agreed as well as what was agreed. Sovereignty decisions carry cost, and a tier without an owner will be questioned during the first cost review that reaches the controls it justifies. COST 7.4 describes what happens when it cannot be defended.

Keep it with the architecture decisions rather than in a compliance system nobody reads during design. The people who need it are the ones choosing a service, and it has to be where they are looking.

On STACKIT. No platform feature records this. It belongs wherever your architecture decisions live.

What the platform does supply is the evidence that the decision was implemented, which is SOV 7. The tier is the requirement; the audit records are what shows the requirement was met.

Tradeoffs. Little beyond the discipline of writing it down. The alternative is re-deriving the same judgement every time somebody questions a control.

Verify. For your workload’s tier, can you produce the reasoning, the data it was based on, and the name of whoever agreed it?

---

SOV 1.3 Classify per data set, because a workload rarely sits at one tier

Risk if not established: Medium

Applying one tier to a whole workload is wrong in one direction or the other. A single system frequently holds customer records under Tier 1, operational telemetry at Tier 3, and something in between.

Classifying the workload by its highest tier is the safe default and an expensive one, because Tier 1 controls apply to everything including the data that never needed them. Classifying by the average is worse, because the part that mattered is under-protected.

The alternative is to separate the data sets so that each carries its own tier, which is the same decision SEC 2.1 describes as choosing an isolation boundary from the protection need. Where the separation is real, the controls follow the data rather than the system.

Where separation is impractical, the highest tier governs and that is a legitimate outcome. What makes it a decision rather than a default is recording that the cheaper option was considered and why it was rejected.

On STACKIT. The mechanisms for separating data sets within a workload are the ones in SEC 2.1, from a separate project down to a service’s own access model. Which of them is sufficient depends on the tier, and Tier 1 data is where the stronger boundaries earn their cost.

Tradeoffs. Cost Optimization and Operational Excellence. Separation costs consolidation and adds boundaries to manage, which is exactly the trade SEC 2.1 describes and the reason it is a decision rather than a rule.

Verify. List your data sets and the tier of each. If they all carry the same tier, is that because they genuinely do, or because nobody separated them?

---

SOV 1.4 Revisit when the data, the regulation or the business changes

Risk if not established: Medium

A tier is a judgement about data and obligations, and both change. What does not change is the architecture built on the old judgement, unless somebody notices.

Set triggers rather than a calendar. A new data type entering the system, a new market or customer segment, a regulatory change, an acquisition, or a change in what the workload is used for should each prompt the question.

The direction that gets missed is upward. A tier reduction is noticed because somebody wants to remove a control. A tier increase happens quietly when a new field starts carrying personal data, and nothing about that change looks like a sovereignty decision.

Watch what enters through integrations. Data arriving from another system carries its own classification, and a workload that was Tier 3 becomes Tier 1 the first time somebody connects a feed that includes customer records.

On STACKIT. No platform feature detects a classification change. The closest signal is the telemetry and log content question from SOV 3.4: if regulated data starts appearing in places that were not designed for it, something upstream changed.

Tradeoffs. Operational Excellence. Another review with an owner, and one where nothing breaks when it is skipped, which is why the triggers matter more than the cadence.

Verify. When was your tier last reviewed, and what prompted it? What would have to change for somebody to look at it again?

---

Related

• SEC 3 Data classification, the security-sensitivity counterpart to this question
• SOV 2 Placement, the first decision the tier constrains
• SOV 8 Compliance mapping, which establishes which obligations apply
• SEC 2.1 Isolation strength, which the tier informs
• Sovereignty tradeoffs, which sets out what each tier costs