Where Your Data Lives: Jurisdictional Sovereignty in Enterprise File Sharing

For regulated organizations in the EU, “where does the data live?” is no longer a question that IT answers alone. Legal counsel, DPOs, and procurement teams are now routinely in the room — because the answer has direct implications for GDPR compliance, NIS 2 obligations, DORA third-party requirements, and exposure to extraterritorial legal reach from non-EU jurisdictions.

This post breaks down what jurisdictional sovereignty actually means for enterprise file sharing: where data physically resides, who has legal authority to access it, what happens when a government asks, and how cross-border transfers are governed. It covers the questions EU organizations should be asking every vendor — and examines how Kiteworks approaches each, based on its contractual structure and documented compliance posture.

Executive Summary

Main idea: Jurisdictional sovereignty in enterprise file sharing has three dimensions: where data physically sits, who has legal authority to compel access, and what technical and contractual safeguards prevent unauthorized disclosure. These three questions are often treated separately in procurement — but they are interdependent, and a gap in any one of them can undermine the other two.

Why you should care: NIS 2 and DORA both require organizations to demonstrate that they understand and have mitigated their vendor’s jurisdictional exposure. Schrems II made cross-border transfer mechanisms a procurement-critical item. And with the CLOUD Act extending US government reach to data held by US-parent companies anywhere in the world, the question of who you actually contract with — and under which law — has become one of the most consequential decisions in a vendor relationship.

5 Key Takeaways

1. Data residency and data sovereignty are not the same thing. Residency is where data physically sits. Sovereignty is who has legal authority to access or compel it. A vendor can store data in Frankfurt and still be subject to US legal reach through their corporate structure. Both questions need answers — separately.
2. The contracting entity matters as much as the product. Who you sign with determines which legal system governs the relationship and what extraterritorial laws the vendor is subject to. Signing with a US-incorporated entity exposes you to CLOUD Act reach even if the servers are in Amsterdam.
3. HYOK encryption is a transfer safeguard, not just a security feature. Hold Your Own Key architecture — customer-held keys outside vendor control — converts data from legally compellable to technically inaccessible. The EDPB recognizes HYOK-style encryption as a valid supplementary measure for cross-border transfers when specific conditions are met — a strong algorithm, keys held outside the third country, and no importer access to the keys under any legal compulsion — under both the Schrems II framework and the current EU–US Data Privacy Framework, where supplementary measures remain advisable given the pending appeal (C-703/25 P).
4. Government access disclosure is a procurement requirement, not a courtesy. NIS 2 and DORA require organizations to understand what vendors will do when a government demands access. “We comply with applicable law” is not an answer. Ask for the challenge procedure and customer notification policy.
5. Sub-processor jurisdiction is a hidden risk in most file sharing deployments. Your vendor’s data protection commitments are only as strong as their sub-processor chain. A sub-processor in a high-surveillance-risk jurisdiction can expose data that your primary vendor agreement nominally protects.

Data Residency: Where Does the Data Actually Sit?

The answer to “where does the data live?” depends fundamentally on deployment model — and it’s a question where on-premises and SaaS give very different answers. Getting this right matters not just for compliance but for the operational resilience picture. If data residency isn’t contractually locked, it can shift with vendor infrastructure decisions you never consented to.

On-Premises Deployment: Customer Controls the Geography

In an on-premises deployment, the customer operates the Kiteworks appliance on infrastructure they own or control — in a data center of their choosing, in a jurisdiction of their choosing. The vendor has no access to that infrastructure and plays no role in determining where data sits. For regulated organizations in Germany, France, the Netherlands, or other EU member states that require data to remain within specific jurisdictional boundaries, this model provides the clearest possible answer: the data is where you put it, under your physical and operational control.

Kiteworks’ hardened appliance model reinforces this. The appliance is self-contained and operates independently of Kiteworks’ cloud infrastructure. There is no mandatory connection to vendor-operated systems that would route data outside the customer’s chosen geography. Combined with Hold Your Own Key (HYOK) architecture — where the customer holds and operates the encryption keys independently of Kiteworks — the on-premises model provides both physical residency control and cryptographic independence.

SaaS Deployment: A Different Conversation

SaaS deployment involves data residing in vendor-operated infrastructure. For EU customers, this means verifying which regions are available, whether data remains within those regions under all operational conditions, and whether there are any fallback mechanisms that could route data to non-EU infrastructure. Kiteworks offers EU-region SaaS options — the specific regions, their certification posture, and the contractual commitments around data remaining within those regions are questions that belong in any EU procurement conversation about SaaS deployment.

The honest point is that on-premises deployment gives EU organizations the strongest possible answer on data residency. SaaS deployment introduces vendor-side geography decisions that require explicit contractual commitment to manage.

The Contracting Entity: Who Do You Actually Sign With?

This question matters more than most procurement teams realize. The legal entity you contract with determines the governing law of the relationship, the jurisdiction for disputes, and — critically — which governments can compel the vendor to produce data or provide access. There are two distinct aspects: the primary contracting entity, and the parent company question that sits behind it.

Kiteworks Europe AG: The EU Contracting Entity

For EMEA customers, the contracting entity is Kiteworks Europe AG, incorporated at Bahnhofstrasse 29, Zug, Switzerland. This is the entity named in the EMEA License Agreement, and it matters for two reasons.

First, Switzerland is not an EU member state, but it maintains an adequacy decision for data transfers from the EU, and Swiss law is generally recognized as providing strong data protection. Second, and more practically, Swiss incorporation provides meaningful insulation from the US CLOUD Act. The CLOUD Act requires US-incorporated entities to produce data held anywhere in the world when served with a valid US legal order. A Swiss-incorporated entity is not directly subject to CLOUD Act jurisdiction in the same way — it is subject to Swiss law, which includes its own legal process requirements and mutual legal assistance treaty (MLAT) framework before compliance with foreign orders.

This does not mean a Swiss entity is immune from all foreign legal reach. It means the legal pathway is more constrained, better-defined, and more likely to involve a process that allows the customer to be notified and to challenge the order. That’s a materially better position than contracting directly with a US-incorporated entity for whom CLOUD Act compliance is a domestic legal obligation.

What to verify: Ensure your license agreement names Kiteworks Europe AG as the contracting entity. If your agreement was signed some years ago, confirm that entity name references are current — legacy agreements in this market sometimes carry predecessor entity names that warrant updating. Ask your Kiteworks account team to confirm the current contracting entity for your jurisdiction.

Kiteworks USA, the UK Intermediate Holding, and the Parent Company Question

Kiteworks Europe AG operates within a broader corporate structure that includes a UK intermediate holding company as the immediate parent of the Swiss entity. This introduces a second jurisdictional vector that EU organizations should map explicitly: the UK Investigatory Powers Act 2016 (IPA) and the UK–US Data Access Agreement (2022).

The UK IPA grants UK authorities powers to issue technical capability notices, bulk warrants, and data retention notices to UK-connected providers. The UK–US Data Access Agreement (2022) — a bilateral agreement under the CLOUD Act framework — enables UK and US authorities to make direct requests to service providers in each other’s jurisdiction. This means the UK intermediate holding company introduces a compulsion pathway that is distinct from, and in some respects more direct than, the Swiss MLAT route discussed above.

What this means in practice: The Swiss contracting entity (Kiteworks Europe AG) reduces direct US CLOUD Act exposure for EU customers. The UK intermediate holding introduces UK IPA and UK–US Data Access Agreement exposure as a second vector. As with CLOUD Act exposure, the operative answer for data protection is that HYOK architecture converts any successful legal compulsion into production of ciphertext — the UK holding company, like the US parent, cannot produce readable data it does not hold the keys to. Organizations whose risk assessment requires mapping the full corporate chain should request confirmation of the holding structure from their Kiteworks account team.

For most regulated EU organizations, the Swiss entity structure and the technical safeguards (HYOK, on-premises deployment) remain sufficient to address their sovereignty requirements. For organizations with the most stringent requirements — those requiring EU ownership and governance influence over the technology itself — both the US ultimate parent and the UK intermediate holding are honest limitations worth documenting.

Government Access: What Happens When a State Asks?

This is the question Schrems II made unavoidable. The Court of Justice of the EU invalidated Privacy Shield in 2020 specifically because US surveillance law — CLOUD Act, FISA 702, Executive Order 12333 — gives US authorities access to personal data in ways EU data subjects cannot effectively challenge.

Since July 2023, the EU–US Data Privacy Framework (DPF) has replaced Privacy Shield as the adequacy mechanism for transfers to DPF-certified US organizations. The General Court confirmed DPF adequacy in September 2025 (Latombe, T-553/23), though an appeal is pending before the Court of Justice (C-703/25 P). The DPF therefore represents the current legal mechanism for EU-US transfers — but its continued validity is not guaranteed, and organizations relying on DPF as their primary transfer mechanism should maintain supplementary measures as a contingency against a further invalidation.

Any organization with a US-parent vendor needs a credible answer to the surveillance law question regardless of which transfer mechanism applies. Two things matter: understanding the exposure map, and having a technical safeguard that makes legal compulsion practically irrelevant.

The CLOUD Act Exposure Map

The CLOUD Act applies to US-incorporated entities and their subsidiaries. For EU customers contracting with Kiteworks Europe AG under Swiss law, the direct CLOUD Act exposure is reduced — US authorities would need to pursue a Swiss MLAT process to compel Kiteworks Europe AG, rather than serving a domestic warrant. That process is slower, more visible, and more easily challenged.

However, understanding the full exposure requires understanding the sub-processor landscape. If any Kiteworks sub-processor that handles EU customer data is US-incorporated, CLOUD Act reach may extend through that sub-processor even where the primary contracting entity is Swiss. This is why sub-processor jurisdiction is not a theoretical concern — it is part of the transfer impact assessment that Schrems II requires.

HYOK as a Technical Safeguard Under Schrems II

The EDPB Recommendations on supplementary measures (Recommendations 01/2020) specifically contemplates encryption where the data importer has no access to the keys as a valid technical safeguard for data transfers. Kiteworks’ HYOK architecture is designed precisely for this scenario.

Under HYOK, the customer holds the encryption keys in their own infrastructure. Kiteworks — and any government that compels Kiteworks — cannot decrypt the data because Kiteworks does not have the keys. The data, as held by Kiteworks or any sub-processor, is cryptographically inaccessible without the customer’s participation. This converts a legal compulsion risk into a technical impossibility, which is as strong a supplementary measure as currently exists in the market.

Kiteworks documents its legal exposure across CLOUD Act, FISA 702, and the multi-jurisdictional framework relevant to its operations. These mechanisms are not equivalent on notification: a CLOUD Act law-enforcement order may permit customer notification and a challenge, whereas FISA 702 directives carry statutory gag provisions that legally prohibit notifying the affected customer. Kiteworks provides a notification posture and challenge procedure for the access types where notification is legally permitted, as part of its government access documentation. The combination of HYOK architecture and customer-operated on-premises HSM — with FIPS 140-3 validated cryptography — provides the technical basis for extraterritorial access prevention that regulated organizations need to document in their transfer impact assessments.

Export Controls and Multi-Jurisdictional Compliance

For organizations operating in defence, aerospace, or dual-use technology sectors, export control compliance adds another layer to the jurisdictional question. Kiteworks holds IRAP PROTECTED classification under the Australian Information Security Manual — a framework with direct relevance for defence-sector organizations in NATO-aligned countries. The platform also addresses ITAR compliance requirements, relevant for organizations handling controlled technical data.

The multi-jurisdictional certification portfolio — BSI C5 Type 2, ISO 27001, Cyber Essentials Plus, IRAP PROTECTED, FedRAMP High In Process, SOC 2 Type II — provides the compliance evidence base that procurement teams in regulated sectors need to document in their third-party risk assessments.

Cross-Border Transfers: Maintaining GDPR Compliance

For any transfer of personal data from the EU to a third country, GDPR Chapter V requires either an adequacy decision for the destination country or an appropriate safeguard — most commonly Standard Contractual Clauses. Since Schrems II, SCCs alone are not sufficient for transfers to the US. Organizations must conduct a transfer impact assessment and, where the destination country’s legal framework does not provide equivalent protection, implement supplementary measures.

For transfers to the US specifically, the EU–US Data Privacy Framework (DPF), in force since July 2023 and confirmed by the General Court in September 2025 (Latombe, T-553/23), provides an adequacy mechanism for DPF-certified organizations. However, with an appeal pending before the Court of Justice (C-703/25 P), organizations relying on DPF adequacy should maintain supplementary measures as a contingency. For transfers routed through Kiteworks’ Swiss entity, Swiss adequacy — separately maintained under Swiss data protection law — provides an additional transfer mechanism that does not depend on DPF’s continued validity.

Standard Contractual Clauses and the Kiteworks DPA

Kiteworks’ Data Processing Agreement (DPA) is structured around the SCC framework, covering the controller-processor relationship and the transfer mechanisms for any data that moves outside the EU. The DPA includes the Article 46 GDPR transfer mechanisms required for lawful processing.

For organizations conducting a TIA — as Schrems II requires — the relevant factors are the legal framework of the data importer’s jurisdiction, the nature of the data transferred, and the technical and organizational measures in place. The Swiss entity structure is a relevant factor in that assessment: Swiss adequacy decision combined with Swiss legal process requirements for foreign access orders creates a different risk profile than a direct transfer to a US entity.

HYOK as the Schrems II Answer

For organizations that need the strongest possible position on cross-border transfer legality, HYOK is the most defensible supplementary measure available. If the data is encrypted with keys the customer holds and Kiteworks cannot access, then even if a transfer of encrypted data occurs, the transfer does not constitute a meaningful exposure of personal data — the recipient cannot read it.

This is not a workaround. It is precisely the architecture the EDPB contemplated in its supplementary measures recommendations. Organizations using Kiteworks with HYOK and on-premises deployment have a well-grounded position for their transfer impact assessments.

Sub-Processors: The Jurisdictional Risk You May Not Have Mapped

A vendor’s data protection commitments are only as strong as their sub-processor chain. Every sub-processor that handles or could access EU customer data introduces its own jurisdictional exposure — its incorporation jurisdiction, its legal obligations under local law, and the government access risk that flows from those obligations.

Kiteworks’ DPA includes a sub-processor list (Appendix 1) covering entities that process EU customer data. This is the foundation of a compliant Article 28 GDPR framework — a vendor that cannot name its sub-processors is a vendor that cannot credibly commit to data protection compliance.

Current state of sub-processor transparency: The DPA Appendix 1 list documents current sub-processors, but a real-time, customer-facing sub-processor register with automated change notification is not yet published. This is an acknowledged gap. For organizations that need ongoing visibility into sub-processor changes — as GDPR Article 28 envisions through the right to object to new sub-processors — raising this with Kiteworks directly and establishing a notification arrangement in the contractual relationship is the current path.

For procurement teams, the question to ask is not just “who are your sub-processors today?” but “how will you notify us when that changes, and what notice period do we receive before a new sub-processor becomes active?” GDPR Article 28(2) gives customers the right to object, but only if notification arrives in time to exercise it.

Jurisdictional Sovereignty: What to Ask Your Vendor

Use this table in procurement conversations, DPA negotiations, and third-party risk assessments. The questions are structured to surface the distinctions that matter for EU regulatory compliance.

Jurisdictional Due Diligence: Implementation Checklist

Knowing what the right answers look like is one thing. Systematically verifying them during procurement — and maintaining that verification over the life of the contract — is another. Jurisdictional due diligence has two phases: the work done before signature, and the ongoing monitoring that keeps the picture current. Both are required; most organizations are better at the first than the second.

At Contract Stage

• Verify the contracting entity explicitly. Don’t assume. Check the signature block and the definition of “Kiteworks” in your agreement. Confirm it names the EU or Swiss entity, not a US parent. If your agreement predates a corporate restructuring, request confirmation of the current contracting entity in writing.
• Require a transfer impact assessment annex or representation. Ask the vendor to provide their standard TIA, or to represent in the DPA that a TIA has been conducted and supplementary measures are in place. “We have SCCs” is not sufficient without a TIA for the relevant transfer routes.
• Negotiate advance notification of sub-processor changes. GDPR Article 28 entitles you to object to new sub-processors. That right is only exercisable if you receive advance notice. Specify the notification period in the DPA — 30 days is a reasonable starting position.
• Document the HYOK architecture in your risk register. If you are deploying HYOK, record it explicitly in your transfer impact assessment and your DPIA as an EDPB-recognised supplementary measure. This creates an auditable record that the risk was identified and addressed.

Ongoing Monitoring

• Review the sub-processor list at least annually. Changes to sub-processors are a change to your risk profile. Build a calendar reminder tied to your vendor’s notification cadence, and assign ownership of reviewing changes within your legal or compliance function.
• Track legal developments in vendor-jurisdiction law. Swiss and EU law both evolve. Adequacy decisions can be challenged (Schrems II being the obvious precedent). Monitor material changes to the legal landscape in the jurisdictions relevant to your vendor relationships.
• Re-run your TIA if the vendor changes corporate structure. An acquisition, merger, or parent company change can materially alter the jurisdictional exposure map. Include a contractual trigger requiring vendor notification of corporate structure changes that affect the contracting entity.

The Business, Financial, and Reputational Cost of Getting Jurisdiction Wrong

Jurisdictional sovereignty failures have a different character to most security failures. They’re rarely discovered through an incident — they surface during an audit, a regulatory inquiry, or a legal proceeding, at which point the gap has already existed for some time. The consequences span regulatory, operational, and reputational dimensions, and they tend to compound.

Regulatory and Legal Risk

GDPR Article 46 compliance for cross-border transfers is a hard legal requirement, not a best practice. Transferring data to a third country without an adequate safeguard — or with SCCs that aren’t backed by a TIA and supplementary measures — creates direct regulatory exposure under GDPR. Supervisory authorities have issued substantial fines for inadequate transfer mechanisms, and the enforcement environment has become materially more active since Schrems II.

NIS 2 Article 21 requires appropriate supply chain security measures. A vendor relationship where the jurisdictional exposure of the sub-processor chain hasn’t been mapped is a supply chain security gap — one that a supervisory authority reviewing NIS 2 compliance would be entitled to ask about. DORA extends similar requirements to financial entities, with specific ICT third-party oversight obligations that include understanding where vendor operations are legally domiciled.

Business and Operational Risk

A government access order that results in disclosure of customer data — or a service denial order that takes a platform offline — can have catastrophic operational consequences for organizations that depend on file sharing for regulated processes. Contracts, clinical trial data, defence procurement documents, financial records: the data typically flowing through enterprise file sharing platforms is exactly the data governments with broad surveillance authority would find most valuable. Understanding and mitigating this risk is not a compliance checkbox — it is operational continuity planning.

Reputational Risk

For organizations that make sovereignty claims to their own customers — banks assuring clients their data doesn’t leave the EU, healthcare organizations committing to patient data residency, government contractors asserting compliance with security frameworks — a jurisdictional failure in their vendor stack can invalidate those assurances. The downstream reputational damage from “we didn’t realize our file sharing vendor had US parent company exposure” is not recoverable through a press release.

Why Kiteworks for Jurisdictional Sovereignty

Kiteworks’ position on jurisdictional sovereignty is distinguishable from most US-headquartered software companies by the combination of its Swiss contracting entity, its HYOK architecture, and the breadth of its independently validated compliance portfolio.

The Swiss entity structure (Kiteworks Europe AG, Bahnhofstrasse 29, Zug, Switzerland) provides a contractually meaningful barrier to direct CLOUD Act reach for EU customers — not an absolute shield, but a materially more defensible position than contracting with a US entity. HYOK converts that legal insulation into a technical guarantee: even where legal reach exists, the data is cryptographically inaccessible without the customer’s participation. That combination — Swiss entity plus HYOK plus on-premises deployment — is the strongest currently available jurisdictional sovereignty posture in the enterprise file sharing market.

The compliance portfolio spans frameworks across multiple jurisdictions: BSI C5 Type 2 and ISO 27001 for EU-relevant independent assessment, Cyber Essentials Plus for the UK market, IRAP PROTECTED classification for the Australian market, FedRAMP High In Process for the US federal market, and SOC 2 Type II as the baseline cross-market attestation. For procurement teams conducting third-party risk assessments under NIS 2 or DORA, this breadth of independent attestation reduces the evidential burden compared to vendors requiring bespoke security questionnaires without certification backing.

The honest limitations are worth stating: the parent company is US-headquartered; and the sub-processor register is currently a DPA Appendix rather than a public real-time register. Both are productive conversations to have with Kiteworks’ legal and contract teams before signature.

Conclusion

For EU regulated organizations, jurisdictional sovereignty in file sharing is no longer a legal department concern that gets resolved once during initial procurement. It is an ongoing operational and compliance discipline — covering contracting entity, data residency, government access exposure, transfer mechanisms, and sub-processor chain — that requires active management over the life of the vendor relationship.

Kiteworks provides a documented, independently validated starting point for that discipline: Swiss contracting entity, HYOK architecture as a Schrems II supplementary measure, SCC-backed DPA, and a multi-jurisdictional certification portfolio that spans the frameworks EMEA regulated organizations are assessed against.

Frequently Asked Questions