---
id: SOV06
pillar: sovereignty
title: SOV 6. How do you know the jurisdiction of every party that processes your data?
description: A sovereign provider with a non-sovereign dependency is not a sovereign chain. Location and jurisdiction are different questions, and the second is harder.
status: draft
services: []
tiers: [1, 2]
sidebar:
order: 15
label: Jurisdictional chain
source_url: "https://framework.stackit.cloud/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/"
source_file: "docs/architecture/pillars/sovereignty/sov-06-jurisdictional-chain.mdx"
---
[`SOV 2`](/architecture/pillars/sovereignty/sov-02-placement-and-residency/) asks where the data is. This question asks who the parties holding it answer to, and the
two give different answers more often than is comfortable.
A service can run in an EU data centre and be operated by a company subject to another
jurisdiction's legal reach. Whether that matters depends on the tier and on obligations that are
legal rather than technical. What is an architecture question is knowing the chain well enough
that somebody qualified can assess it.
## Best practices
- [`SOV 6.1`](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/#sov-61-maintain-a-current-inventory-of-every-party-that-processes-your-data) Maintain a current inventory of every party that processes your data
- [`SOV 6.2`](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/#sov-62-establish-jurisdiction-rather-than-only-location) Establish jurisdiction rather than only location
- [`SOV 6.3`](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/#sov-63-treat-third-party-and-marketplace-services-as-part-of-the-chain) Treat third-party and marketplace services as part of the chain
- [`SOV 6.4`](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/#sov-64-re-establish-the-chain-when-it-changes) Re-establish the chain when it changes
---
## SOV 6.1 Maintain a current inventory of every party that processes your data
**Risk if not established:** High
The inventory is the artefact. Without it, every assessment starts by rebuilding it, and each
rebuild reaches a different answer because it depends on who happened to remember which
integration.
It is the same enumeration [`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) produces, extended with the party rather than only the place.
For each entry: what data it receives, what it does with it, where it processes it, who operates
it, and under what agreement.
Include the parties who are not infrastructure. A support tool, an analytics service, a payment
processor, an email delivery service and a background-check vendor are all processors, and none of
them appear in an infrastructure inventory.
Keep it where it will be maintained rather than where compliance would prefer it. An inventory
that lives in the architecture repository next to the code has a chance of being updated by the
person adding the dependency; one in a separate system does not.
**On STACKIT.** The platform-side facts are the region and the operating entity, which are
documented and stable. Everything beyond the platform is yours to enumerate, and the platform
cannot see it.
For each party you need a jurisdiction and an assessment of it, and both have always been
obtainable by asking, reading the agreement and recording the answer. That is the work this best
practice describes, and most entries in your inventory will be filled in exactly that way.
Where a party carries a Sovereignty Maturity Level from ES³,
the entry gets shorter and more comparable: it has been asked these questions under audit against
published criteria, and the answer is a level rather than a description you have to interpret. Ask
for two things together, the level and which of ES³'s three control scopes it was assessed at,
since a result about an underlying service says nothing about the party operating on top of it.
The standard is new, so treat a level as a shortcut where it exists rather than as something to
wait for.
Its Approved Jurisdictions List is useful whether or not a party is assessed, because it is a
published list rather than a result. It names a core group, the EU and EEA plus Switzerland, and an
extended group of the United Kingdom, Canada, Israel, Andorra and Japan. Comparing against a
published list beats each team drawing its own line, and because the list is versioned, an
inventory entry can record which version it was checked against. Whether that list is the right
one for your obligations is a question for your own legal function, which is where it was before.
The exception worth stating is that the platform is a party in this inventory too, with its own
certification scope in [`SOV 8.1`](/architecture/pillars/sovereignty/sov-08-compliance-mapping/#sov-81-identify-which-frameworks-actually-apply) and its own subprocessor position, and those belong in the entry
rather than being assumed because it is the primary provider.
**Tradeoffs.** **Operational Excellence.** A maintained inventory is continuing work. It is also
the prerequisite for [`SOV 2`](/architecture/pillars/sovereignty/sov-02-placement-and-residency/), [`SOV 8`](/architecture/pillars/sovereignty/sov-08-compliance-mapping/) and any assessment, so the cost is shared across several
obligations.
**Verify.** Does a current inventory of your data processors exist? When was it last updated, and
by whom?
---
## SOV 6.2 Establish jurisdiction rather than only location
**Risk if not established:** High
Location is a fact about a building. Jurisdiction is a question about legal reach over the entity
operating it, and the two diverge.
The distinctions that produce different answers. **Where the data sits** is one thing. **Where the
operating company is incorporated** is another. **Who ultimately controls that company** is a
third. **Which legal regimes can compel disclosure** follows from the second and third rather than
the first.
This is legal analysis rather than architecture, and the architecture's job is to supply an
accurate chain to whoever performs it. What engineering can determine is which parties are
involved and what each receives; the assessment of what that means belongs to people qualified to
make it.
Record the assessment alongside the inventory. An entry that says a vendor was reviewed and
cleared by a named person on a date is usable; one that says the vendor is in the EU is a location
claim being used to answer a jurisdiction question.
**On STACKIT.** The reason the platform exists in this form is that the divergence between
location and jurisdiction is real for many providers, and a workload placed on STACKIT for that
reason should apply the same standard to everything it depends on. A chain is as strong as its
weakest party, and the sovereignty argument for the primary provider is weakened rather than
strengthened by an unexamined dependency.
**Tradeoffs.** **Operational Excellence.** Jurisdictional review takes time and legal input, which
is why it should be proportionate to the tier rather than applied uniformly.
**Verify.** For your three most critical processors, who owns the operating entity and which
jurisdictions can compel it? Who established that, and when?
---
## SOV 6.3 Treat third-party and marketplace services as part of the chain
**Risk if not established:** High
The most common gap is a service that felt like part of the platform because of where it was
purchased, and which is operated by somebody else entirely.
A marketplace is a procurement channel. It simplifies contracting and billing, and it does not
make the vendor's infrastructure into the platform's infrastructure. That distinction is easy to
lose because the purchase happens in the same console as everything else.
The same applies to any managed component obtained from a third party: an observability tool, a
security scanner, an identity service, a data pipeline. Each is a processor with its own location
and its own jurisdiction.
Assess before integrating rather than after. Once a service is embedded, an unfavourable
jurisdictional finding forces either an exception or a migration, and exceptions granted under
that pressure are the ones that persist.
**On STACKIT.** The Marketplace delivery
model
settles this. Products are delivered as software as a service, hosted and deployed in
the vendor's environment, with the customer using the software without managing the underlying
backend resources such as servers or databases.
The consequence for this question is explicit: a marketplace product processes your data on the
vendor's systems rather than in your STACKIT project. For Tier 3 that is usually unremarkable. For
Tier 1 it means each marketplace product is a [`SOV 6.2`](/architecture/pillars/sovereignty/sov-06-jurisdictional-chain/#sov-62-establish-jurisdiction-rather-than-only-location) assessment in its own right, and the
answer depends entirely on which vendor it is.
Additional delivery methods are under evaluation, including server and container images that would
deploy into the customer's own project. Those would place the workload
differently, and where a Tier 1 requirement depends on that distinction, the delivery method of
the specific product is what to confirm.
**Tradeoffs.** **Operational Excellence.** Assessing every third-party service before adoption
slows teams down and is the mechanism that prevents the finding, so the answer is to make the
assessment fast rather than optional.
**Verify.** List the third-party and marketplace services your workload uses. For each, where does
the vendor process your data, and who assessed that?
---
## SOV 6.4 Re-establish the chain when it changes
**Risk if not established:** Medium
The chain changes without any action from you. Vendors are acquired, subprocessors are added,
services are relocated, and corporate structures change. Each can alter a jurisdictional answer
that was correct when it was recorded.
Two mechanisms are needed and neither is sufficient alone. **Contractual notification**, so that a
vendor tells you when its subprocessors change, which depends on the agreement having asked for
it. **Periodic review**, because notification depends on the vendor and covers what the vendor
considers material.
Set the cadence by tier. Tier 1 dependencies warrant an annual review at minimum; Tier 3 rarely
warrants a scheduled one at all.
Watch the changes on your own side too. A new integration, a new region for an existing vendor,
and a new feature that enables a data flow are all chain changes originating from your
architecture, and they attach to the same trigger as [`SOV 2.4`](/architecture/pillars/sovereignty/sov-02-placement-and-residency/#sov-24-re-establish-residency-when-the-architecture-changes).
**On STACKIT.** No platform feature tracks your vendor chain. What the platform records is what
was created in your projects, through the audit log in [`SOV 7`](/architecture/pillars/sovereignty/sov-07-auditability/), which is the retrospective view of
when a dependency appeared.
The active mechanism is egress control from [`SEC 6.3`](/architecture/pillars/security/sec-06-network-controls/#sec-63-control-egress-because-that-is-how-data-leaves). A workload restricted to approved
destinations turns an undeclared new dependency into a blocked connection, which is the only
detection that does not rely on somebody remembering to declare it.
**Tradeoffs.** **Operational Excellence.** Reviews and notification clauses are both work, applied
proportionately to the tier rather than uniformly.
**Verify.** When did you last review your processor inventory for changes? Which of your contracts
require notification when a subprocessor changes?
---
## Related
- [`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) Dependency tracing, which supplies the list this assesses
- [`SOV 5.1`](/architecture/pillars/sovereignty/sov-05-operator-access/#sov-51-establish-who-can-technically-reach-the-data-including-the-provider) Access enumeration, which this extends beyond your organization
- [`SOV 8`](/architecture/pillars/sovereignty/sov-08-compliance-mapping/) Compliance mapping, which the chain is an input to
- [`SEC 6.3`](/architecture/pillars/security/sec-06-network-controls/#sec-63-control-egress-because-that-is-how-data-leaves) Egress control, the only systematic detection mechanism
- [`SOV 10`](/architecture/pillars/sovereignty/sov-10-open-interfaces/) Open interfaces, which decides what changing a party costs