SOV 6. How do you know the jurisdiction of every party that processes your data?

SOV 2 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 Maintain a current inventory of every party that processes your data
• SOV 6.2 Establish jurisdiction rather than only location
• SOV 6.3 Treat third-party and marketplace services as part of the chain
• SOV 6.4 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 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 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, SOV 8 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 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.

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, which is the retrospective view of when a dependency appeared.

The active mechanism is egress control from SEC 6.3. 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 Dependency tracing, which supplies the list this assesses
• SOV 5.1 Access enumeration, which this extends beyond your organization
• SOV 8 Compliance mapping, which the chain is an input to
• SEC 6.3 Egress control, the only systematic detection mechanism
• SOV 10 Open interfaces, which decides what changing a party costs