A Practical Guide to Data Sovereignty in Third-Party Data Sharing: Vendors, Subcontractors, and Multinational Environments

Data sovereignty is manageable when data stays within a single organisation and jurisdiction. It becomes a governance problem the moment data is shared — with a vendor, a subcontractor, a regional subsidiary, or a partner operating under a different legal regime.

Most organisations manage their primary compliance layer reasonably well and lose sovereignty at the edges: in the vendor chain, in internal cross-border transfers within multinational structures, and in the email and file sharing channels that carry the majority of sensitive content outside formal sovereignty control frameworks.

This guide covers the regulatory obligations that travel with data into third-party relationships, the sovereignty risks of centralised multinational data models, the overlooked sovereignty surface of unstructured data in motion, what vendor contracts must include and cannot substitute for, and the encryption architecture that makes third-party sovereignty technically enforceable.

Executive Summary

Main Idea: The data controller remains liable for how processors and sub-processors handle data regardless of contractual chain depth. Most sovereignty failures occur not at the primary cloud provider but in the vendor chain, in multinational internal transfers, and in unstructured data channels — email, file sharing, and MFT — that carry significant sensitive content outside formal sovereignty controls. The technical foundation is customer-owned encryption keys: when the data owner holds keys the vendor never possesses, the vendor cannot access or disclose readable content regardless of legal compulsion — closing the gap that contracts alone cannot close.

Why You Should Care: GDPR Article 28 processor obligations, DORA’s ICT third-party risk requirements (operational since January 2025), and NIS 2’s supply chain security mandate create overlapping accountability obligations with penalties reaching 4% of global revenue and personal management liability. These obligations apply equally to unstructured data in email and file sharing as to structured data in databases — a distinction most organisations have not operationalised.

Key Takeaways

1. The data controller is liable for the entire processing chain. GDPR Article 28 makes the controller responsible for processor and sub-processor compliance regardless of how many contractual layers separate them. A breach or sovereignty violation by a fourth-tier subcontractor is the controller’s regulatory exposure.
2. Internal transfers within multinationals are international transfers under GDPR. A centralised data store in the U.S. accessed by European subsidiaries is a third-country transfer subject to Chapter V requirements. Corporate ownership does not create jurisdictional exemption.
3. Email and file sharing are subject to the same sovereignty obligations as structured data. GDPR, NIS 2, and DORA do not distinguish by data format. The enforcement gap is organisational — most sovereignty programs focus on databases and ignore the channels where sensitive data actually moves.
4. Customer-owned encryption keys are the technical control that makes vendor sovereignty enforceable. When the data owner holds keys the vendor never possesses, the vendor cannot access or disclose readable content regardless of legal demand — eliminating the need to trust the vendor’s internal access controls or sovereignty commitments.
5. BYOK and customer-managed key schemes offered by major cloud providers are not equivalent to customer-owned keys. In BYOK/BYOE arrangements, the provider’s infrastructure handles decryption operations and retains technical access capability. A valid subpoena yields readable data. Customer-owned keys, where the provider never possesses decryption capability, are architecturally distinct — and the only arrangement that genuinely closes CLOUD Act and government access exposure.

Why Third-Party Data Sharing Is the Highest-Risk Sovereignty Event

When data leaves direct organisational control, sovereignty risk multiplies. The data controller retains full regulatory liability under GDPR Article 28 for how data is processed across the entire vendor chain — but no longer controls the infrastructure, access policies, or legal jurisdiction of the entity handling it. The gap between liability and control is where most sovereignty failures occur.

The CLOUD Act problem is particularly acute in vendor chains. An EU organisation with carefully architected sovereign infrastructure may share sensitive data with a U.S.-headquartered vendor whose infrastructure is fully subject to CLOUD Act compulsion. The sovereignty architecture stops at the organisation’s boundary; the vendor’s U.S. corporate structure creates the access exposure the EU organisation thought it had eliminated. Effective third-party risk management for sovereignty requires either auditable technical evidence of equivalent vendor controls — or an architecture where the vendor never possesses readable data in the first place.

The Regulatory Framework: Obligations That Travel With the Data

GDPR Article 28 requires processing by a processor to occur only under a binding contract imposing GDPR-equivalent obligations, including on sub-processors. Controllers must authorise sub-processor use, flow obligations through the chain, and remain fully liable if sub-processors fail to meet them. A vendor that cannot provide audit-ready evidence of its sovereignty controls is not meeting Article 28 requirements regardless of what its contract says.

DORA Article 30 requires EU financial entities to include specific ICT contract provisions covering data localisation, data residency, encryption key management, incident accessibility, and exit strategies. DORA explicitly requires assessment of whether ICT providers can demonstrate protection against third-country government access — a direct reference to CLOUD Act exposure. Vendors that cannot demonstrate compliant key management create active DORA non-compliance for the financial entity.

NIS 2 Article 21 requires operators of essential services to implement supply chain security measures addressing the sovereignty posture of direct suppliers and service providers — and to document that assessment. The obligation travels through the chain: a vendor whose subcontractor introduces sovereignty risk creates NIS 2 exposure for the essential service operator at the top.

Multinational Centralised Storage: The Hidden Sovereignty Problem

Multinationals frequently centralise data storage — a single data warehouse, unified CRM, centralised HR platform — accessed by subsidiaries across multiple countries. Every access of EU personal data from a centralised non-EU store is an international transfer subject to GDPR Chapter V. Corporate ownership does not create an exemption: an EU subsidiary accessing data in a U.S. parent’s centralised store is a transfer requiring an adequacy decision, SCCs with TIAs, or another valid mechanism. The CLOUD Act exposure applies to the centralised store’s U.S. provider regardless of which subsidiary’s data is held there.

Centralised models also concentrate risk: a single CLOUD Act demand or regulatory enforcement action reaches all subsidiaries’ data simultaneously. For multinationals subject to NIS 2 or DORA across multiple member states, a single centralised sovereignty failure triggers regulatory exposure in multiple jurisdictions at once. The sovereignty-compliant solution is not necessarily to abandon centralisation — it is to apply customer-owned encryption at the data layer, so the centralised store holds only ciphertext while decryption keys remain with data-owning entities in their respective jurisdictions.

Email and File Sharing: The Overlooked Sovereignty Surface

Data sovereignty programs overwhelmingly focus on databases and structured data — missing the channels through which the majority of sensitive data actually moves: email attachments, file sharing platforms, and MFT workflows. A contract emailed to a vendor, a financial report shared through a collaboration platform, a due diligence file transferred overseas — each is a cross-border data transfer subject to the same GDPR, NIS 2, and DORA obligations as a database replication.

GDPR applies to any processing of personal data regardless of format — including email transmission. The enforcement gap is organisational: sovereignty controls applied to databases but not to the email and file sharing channels connecting them to the outside world leave significant perimeter gaps. The practical sovereignty requirements for unstructured data in motion are identical to structured data: encryption in transit and at rest, access controls on cross-border transmission, audit trails for every transfer event, and policy enforcement preventing transmission to non-compliant destinations — applied at the platform level, because the data leaves the organisation’s infrastructure entirely when shared with a third party.

What Vendor Contracts Must Include — and Cannot Substitute For

Vendor contracts for sovereignty-sensitive data must include: processing purpose and instruction limitations; encryption standards and key management architecture (specifying whether the vendor retains decryption capability); sub-processor authorisation and obligation flow-through; breach notification timelines; audit rights with specific scope; data return or deletion on termination; and — for DORA-regulated entities — data localisation, key management, and exit provisions per Article 30.

What contracts cannot do is equally important. A contract requiring a U.S. vendor to protect EU data from government access does not change the vendor’s legal obligation to comply with a valid CLOUD Act demand. A data residency clause creates liability if violated — it does not technically prevent data from leaving a jurisdiction. Contracts document obligations; they do not create technical controls. The central question is therefore not whether the contract is complete, but whether the vendor can demonstrate architecturally that EU data is protected against compelled disclosure regardless of legal demand.

Customer-Owned Encryption Keys: The Technical Foundation

Customer-owned encryption keys resolve vendor chain sovereignty risk at its source. The data owner holds keys the vendor never possesses — making the vendor technically incapable of accessing or disclosing readable content regardless of legal demand. This is architecturally distinct from BYOK/customer-managed key schemes, where the provider’s infrastructure handles decryption operations and retains access capability. In a BYOK arrangement, a valid subpoena yields readable data. With customer-owned keys, the provider holds only ciphertext it cannot decrypt.

Applied to vendor data sharing, this means sensitive data reaches the vendor already encrypted with keys the vendor never holds. The vendor can store, transmit, and process it — but cannot read it, disclose it, or comply with a government demand for its readable contents. Sovereignty is maintained not because the vendor has made appropriate promises, but because the vendor has no technical capability to violate them. This also simplifies vendor sovereignty assessment: rather than auditing each vendor’s access controls, jurisdiction, and sub-processor chain, the data owner maintains sovereignty through a single architectural control applied before data leaves its own infrastructure.

How Kiteworks Closes the Third-Party Sovereignty Gap

The Kiteworks Private Data Network delivers third-party data sovereignty across every channel sensitive data uses to leave an organisation — email, file sharing, MFT, web forms, and APIs — under a single unified policy framework. Customer-controlled encryption keys, held exclusively by the data owner and never accessible to Kiteworks, mean Kiteworks cannot access customer data, cannot respond to a subpoena with readable content, and cannot be compelled by any government to produce decrypted data.

The sovereignty guarantee is architectural: it holds regardless of what legal demands are served on Kiteworks or which vendor receives the shared data. Single-tenant deployment in the customer’s chosen location places data under the data owner’s jurisdiction and infrastructure control. Zero trust security architecture governs all vendor and subcontractor access with every event captured in immutable audit trails through the CISO Dashboard — providing the Article 28 audit cooperation, DORA operational documentation, and NIS 2 supply chain evidence regulators require. Pre-configured compliance reporting for GDPR, NIS 2, DORA, and ISO 27001 supports the accountability documentation that no vendor contract can generate on its own.

To see how Kiteworks secures your organisation’s third-party data sharing across every channel and jurisdiction, schedule a custom demo today.

Additional Resources

• Blog Post
  Data Sovereignty: a Best Practice or Regulatory Requirement?
• eBook
  Data Sovereignty and GDPR
• Blog Post
  Avoid These Data Sovereignty Pitfalls
• Blog Post
  Data Sovereignty Best Practices
• Blog Post
  Data Sovereignty and GDPR [Understanding Data Security]