A 12-question sovereignty audit every DPO should run

Who this audit is for

This is written for DPOs and privacy leads who need to verify sovereignty claims from vendors, not just collect them. It is also useful for engineering leads who get pulled into procurement conversations because the DPO needs a technical answer about where data actually sits. If your organisation has committed to a no US subprocessor policy, whether for GDPR risk reduction, a public tender requirement, or a customer contract clause, the hard part is not writing the policy. The hard part is verifying that every vendor in the chain actually honours it.

Most vendor questionnaires ask yes or no questions that vendors answer optimistically. A proper sovereignty audit asks for evidence. The twelve questions below are the ones that tend to surface the gap between what a vendor's marketing page says and what their subprocessor list actually contains.

The 12 questions

1. 1. Does the vendor publish a current subprocessor list, and how often is it updated?

   A vendor claiming no US subprocessor status should have a public, dated subprocessor list, not a sales deck claim. Check the last update date. If it has not changed in over a year while the vendor has clearly added features or integrations, the list is probably stale rather than accurate.

2. 2. Who owns the parent company of every subprocessor, not just the entity signing the contract?

   This is where most audits fail. A subprocessor can be legally incorporated in Germany or the Netherlands and still be a wholly owned subsidiary of a US parent company, which brings it inside the reach of the CLOUD Act regardless of where the servers sit. Ask for the ultimate parent entity, not just the contracting entity.

3. 3. Is customer support, including L2/L3 escalation, handled by EU-based staff?

   Data residency rules in the main contract rarely cover support operations. If a US-based support engineer can remote into a production system to debug an issue, that is a data access path that bypasses your residency guarantees entirely. Ask specifically about support tooling and where support staff are employed.

4. 4. Does the vendor's monitoring, logging, or APM stack send data outside the EU?

   Error tracking and application performance monitoring tools often default to US regions even when the primary hosting is in the EU. Sentry, Datadog, and New Relic all have EU hosting options, but they are opt-in, not default. A vendor can be honest about their primary infrastructure and still leak telemetry data through a third-party monitoring integration. We cover this specific gap in more depth in our piece on data sovereignty in email, error tracking, and analytics.

5. 5. Which CDN or DNS provider is in front of the application, and where does it route traffic?

   A CDN is a subprocessor even when nobody thinks of it that way. If the origin is in Frankfurt but the CDN is a US hyperscaler's edge network, cached content and request metadata still pass through US-controlled infrastructure. Ask for the specific CDN vendor and whether EU-only routing is configured, not just available.

6. 6. What is the legal basis for any remaining international transfers?

   If a vendor cannot achieve zero international transfers, find out whether they rely on Standard Contractual Clauses, Binding Corporate Rules, or something else, and whether that mechanism has been tested against recent case law. Schrems II did not eliminate SCCs, but it raised the bar for supplementary measures. Ask what those measures actually are.

7. 7. Does the backup and disaster recovery environment match the production region claim?

   It is common to find EU-only production infrastructure paired with a backup target in a US region, often because the backup tooling defaulted there during initial setup and nobody revisited it. Ask explicitly where backups, snapshots, and DR replicas are stored, not just where the primary database lives.

8. 8. Can the vendor explain who technically has the ability to access unencrypted data, and from where?

   Encryption at rest is table stakes. The real question is who holds the keys and from which jurisdiction they can be compelled to act. If a US-based entity, parent company, or cloud provider holds the encryption keys, data residency in the EU does not prevent a lawful access request from reaching it.

9. 9. Is there a documented incident response process that specifies jurisdiction for any law enforcement request?

   Ask the vendor what happens procedurally if they receive a data request from a non-EU authority. A mature vendor will have a documented process: who reviews the request, whether it gets challenged, and whether the customer is notified before data is disclosed. If this process does not exist in writing, it does not exist operationally either.

10. 10. Does the infrastructure management partner itself run on sovereign infrastructure, or just resell it?

    Some managed infrastructure partner vendors present a sovereignty story built entirely on the underlying cloud provider's EU region, while their own operational tooling, ticketing system, or remote access infrastructure runs through US SaaS products. Ask about the vendor's own internal stack, not just the stack they sell you.

11. 11. What happens to data sovereignty guarantees during a migration or failover event?

    Sovereignty commitments are easiest to keep during steady state and easiest to lose during a zero downtime migration, a failover test, or a disaster recovery drill, when teams move fast and improvise. Ask the vendor to walk through a specific failover scenario and confirm the DR target still meets the same residency commitments as production.

12. 12. Is there a named technical contact who can answer these questions directly, without going through a ticket queue?

    This sounds procedural, but it is a genuine signal. Vendors who can answer sovereignty questions through a direct conversation with an engineer tend to actually understand their own subprocessor chain. Vendors who route every question through a support ticket and come back days later with a copy-pasted compliance statement usually have not looked closely at the question before.

Config and contract language that helps verification

A few concrete things to request or check during the audit, beyond the questions themselves.

Ask for the DPA's Annex with the actual subprocessor table, not a summary page. It should look something like this:

Subprocessor      | Purpose              | Entity location | Parent HQ
EU hosting partner | Infrastructure        | Netherlands      | Netherlands
EU email relay     | Transactional email   | Germany          | Germany
Monitoring vendor  | APM / error tracking  | EU region (opt-in) | United States

That third row is the one that fails a strict no US subprocessor policy even though the data is hosted in an EU region. The parent HQ column is the one most vendor-supplied tables omit.

If you manage DNS or CDN configuration yourself, you can verify routing claims independently rather than relying on vendor statements:

# Check which edge network is actually serving a domainndig +short CNAME cdn.example.comnn# Trace the resolved IP's registered locationnwhois $(dig +short cdn.example.com | tail -1)n

This will not give you a legal answer, but it will tell you quickly whether a CDN claim matches the DNS reality.

How to roll this out across an existing team

Running this audit once against a new vendor is straightforward. Rolling it out as a standing practice across an existing vendor estate takes more coordination, because most teams have ten to thirty vendors already under contract and nobody wants to re-open every one at once.

Start with a tiering exercise. Not every vendor needs the full twelve questions on day one. Rank vendors by how much personal data or regulated data they touch, and run the full audit against the top tier first, typically your core managed cloud infrastructure provider, your email and identity provider, and anything handling payment or health data.

Build the subprocessor table question into procurement from the start for new vendors, so it stops being a retrospective audit and becomes a gate. A single clause in the vendor onboarding checklist, requiring the Annex table with parent HQ column before signature, prevents most of the gaps described above from ever entering the contract.

For existing vendors, a short, direct email referencing these twelve questions usually gets a faster and more honest answer than a generic security questionnaire, because it signals you already know what to look for. Vendors who built genuine sovereignty into their architecture will usually answer within a day. Vendors who built a marketing claim on top of a US-owned stack tend to go quiet or escalate internally, which is itself useful information.

Keep a simple internal register, even a spreadsheet, tracking the audit date, the answers received, and a re-audit date twelve months out. Subprocessor chains change as vendors get acquired or add integrations, and a no US subprocessor claim that was true at signing is not guaranteed to stay true. Teams that have gone through tenders with hard sovereignty requirements have found this out the hard way, which is part of what we cover in our case study on what a GAIA-X label actually verified during a tender.

Close

This audit will not make a vendor relationship sovereign on its own. It will tell you, with evidence rather than a checkbox, whether a no US subprocessor claim holds up against the actual contract, infrastructure, and operational chain behind it. That is the difference between a policy that satisfies an internal audit and one that would hold up under a regulator's or a customer's scrutiny.

If implementing these yourself is not the best use of your engineering time, our managed services cover all of them by default.