You're Encrypting Your Data. But Who Controls the Keys?
Why key sovereignty is the compliance gap most organisations never see coming — and how to close it.
Most organisations handling regulated data have done the obvious things. They've encrypted their databases. They've signed data processing agreements. They've ticked the GDPR, FINMA, or HIPAA boxes their legal teams handed them.
And yet, enforcement actions keep rising. Fines keep landing. Auditors keep finding gaps.
The reason is almost always the same: organisations confuse data sovereignty with key sovereignty — and assume that encrypting data is enough to prove they control it.
It isn't.
First, Understand the Difference
Data sovereignty is about where your data physically lives and which legal jurisdiction governs it. It's the question regulators ask first: is this data stored in an approved country, under an approved legal framework?
Key sovereignty is about who holds the cryptographic keys that make that data readable. It's the question most organisations forget to ask: even if the data is stored in the right place, who can actually unlock it?
Here's why this distinction matters: encrypted data without key sovereignty is not truly controlled data. If a third-party cloud provider holds your encryption keys — even under a shared responsibility model — they can technically access your data. So can their government, under subpoena. So can a misconfigured IAM policy. So can a rogue insider.
You haven't protected your data. You've protected the appearance of protecting your data.
The Compliance Numbers Are Getting Harder to Ignore
Regulatory enforcement around encryption and key management has grown significantly across all three major frameworks.
Under GDPR, the European Data Protection Board has increasingly cited inadequate technical measures — including poor key management practices — in enforcement decisions. According to the CMS GDPR Enforcement Tracker, total recorded fines have exceeded €5.65 billion, with 2,245 fines issued as of early 2025. The single largest fine — €1.2 billion against Meta in 2023 — was specifically rooted in the unlawful transfer of personal data to the United States without adequate protections. The lesson for key management is direct: if your data can be accessed under a foreign legal jurisdiction, you may not have adequate protections — regardless of encryption.
Under FINMA, Swiss financial supervisors have raised the bar on operational resilience requirements through Circular 2023/1, which entered into force on 1 January 2024. The regulator has placed particular scrutiny on outsourced IT arrangements. In its 2024 cyber risk and outsourcing report, FINMA noted that as of 2024, one in five banks or insurance companies was outsourcing significant data or functions to public cloud providers — and flagged the concentration risk this creates. Where Swiss institutions have stored encryption keys with third-party providers outside Switzerland, regulators have questioned whether client confidentiality obligations under Swiss banking law can be meaningfully upheld.
Under HIPAA, the US Department of Health and Human Services regulates encryption under 45 CFR §164.312, which specifies encryption and decryption as addressable implementation specifications — meaning organisations must implement them unless they can justify why not, and must document compensating controls if they don't. HHS has consistently found that encryption alone does not constitute an adequate safeguard if key management controls are absent or delegated to a vendor without appropriate contractual protections.
The pattern is consistent: regulators are moving beyond "is the data encrypted?" to "who controls the keys, where are they stored, and under what legal jurisdiction?"
How Cross-Border Key Storage Creates Real Compliance Risk
Scenario 1: The EU Bank Using a US Cloud Provider
A German retail bank moves its customer data to a hyperscale cloud platform. The data is encrypted at rest. Compliance signs off.
What the bank didn't fully account for: the cloud provider manages the encryption keys from infrastructure based in the United States. Under the US CLOUD Act — formally the Clarifying Lawful Overseas Use of Data Act (2018) — American authorities can compel US-based providers to produce data stored anywhere in the world, provided the provider has possession, custody, or control of it. As the DOJ's own white paper confirms, the Act applies regardless of where the data is physically stored.
From a GDPR perspective, this creates a problem. Article 32 requires appropriate technical measures to ensure data security. Article 44 restricts transfers of personal data to third countries. If the key management infrastructure effectively enables access by US authorities, regulators may find that the bank has failed on both counts — even though the data never left Frankfurt.
Scenario 2: The Swiss Healthcare Provider and FINMA Outsourcing Rules
A Swiss private clinic partners with a cloud-based patient records platform. The platform is hosted in Switzerland. Everything looks correct on paper.
But the platform's encryption keys are managed by a key management service operated from Ireland. When FINMA auditors examine the arrangement — applying the outsourcing principles of Circular 2018/3 alongside the operational resilience requirements of Circular 2023/1 — they find that the clinic cannot demonstrate sole control over access to patient data. The key management provider could, under certain legal compulsions, facilitate access without the clinic's knowledge or consent.
Swiss banking secrecy and healthcare confidentiality laws require that access to sensitive client information remains firmly within the institution's control. A key management dependency on a foreign-operated service creates a gap that no data processing agreement can fully paper over.
Scenario 3: The Multinational Corporation Trying to Comply Everywhere at Once
A global professional services firm operates across the EU, Switzerland, and the United States. It uses a centralised cloud platform with a single key management service, because that's what the platform vendor recommended and it's operationally simpler.
The problem: GDPR requires that EU personal data be accessible only under EU-approved conditions. FINMA requires Swiss financial data to remain under Swiss-controlled access. HIPAA requires documented controls over protected health information. A single, centralised key management service subject to one legal jurisdiction cannot simultaneously satisfy all three frameworks — and attempting to use it as though it can is a compliance fiction waiting to be exposed.
What Industry Experts Are Watching
The direction of regulatory travel is clear to those working at the intersection of encryption standards and compliance frameworks.
The Cloud Security Alliance, in its Top Threats to Cloud Computing 2024 report — based on a survey of over 500 industry experts — identified identity and access management (IAM) weaknesses as the second-highest cloud security concern for the second consecutive year. Poor cryptographic management was explicitly cited as a persistent failure within the IAM category. The CSA has long maintained that many organisations unknowingly delegate control over their most sensitive data by accepting default key management arrangements from cloud vendors.
Legal practitioners advising on cross-border data transfers have flagged that regulatory bodies in the EU and Switzerland are beginning to scrutinise not just where data is stored, but where access to that data can be compelled — which is determined by where the keys are managed, not where the data sits.
The emerging regulatory consensus is that key residency — the legal and physical jurisdiction of encryption key infrastructure — will become an explicit compliance requirement, not merely a best practice, within the next regulatory cycle.
The Sovereignty Paradox
Here is the core problem, stated plainly.
An organisation encrypts its data, believing this demonstrates control and security. It then hands key management to a third-party cloud provider because it's convenient and the vendor's documentation says it's secure. The data is encrypted. The organisation has lost control of it.
This is the sovereignty paradox: the technical act of encryption is being used to satisfy a regulatory requirement for control, while simultaneously the practical ability to exercise that control has been delegated away.
Regulators are starting to see through it. The question is no longer whether data is encrypted. It is whether the organisation holding responsibility for that data has genuine, demonstrable, legally robust control over who can access it — including control over the cryptographic keys that govern access.
If the answer is "our cloud provider manages the keys and we trust them," that is not sovereignty. That is dependency dressed up as security.
A Framework for Getting This Right
Here is how to close the gap systematically.
Step 1: Map your key management dependencies
Audit every system handling regulated data. For each one, identify: who manages the encryption keys, where that key management infrastructure is physically located, and under which legal jurisdiction it operates. This is frequently an uncomfortable exercise. Do it anyway.
Step 2: Assess jurisdictional exposure
For each key management dependency, assess what legal mechanisms could compel access to those keys without your organisation's explicit consent. This includes CLOUD Act requests, local government compulsion orders, and the contractual terms your provider has agreed to with their own governments.
Step 3: Understand your regulatory obligations precisely
GDPR Article 32 and Recital 83 require appropriate technical and organisational measures. FINMA Circular 2023/1 sets explicit requirements for outsourced arrangements. HIPAA's Security Rule at 45 CFR §164.312 specifies encryption and decryption as addressable implementation specifications. Read what your specific regulator requires — not what your vendor's compliance team tells you it requires.
Step 4: Separate data storage from key management
The most robust architectures store encrypted data with one provider and manage encryption keys entirely independently — preferably with infrastructure under the organisation's direct control, or with a specialist key management provider whose jurisdiction and legal exposure is appropriate for the regulatory framework in question. This is what a genuine Bring Your Own Key (BYOK) or Hold Your Own Key (HYOK) architecture achieves.
Step 5: Establish key residency policies
Define explicitly where encryption keys for each category of regulated data must reside. EU personal data under GDPR should have keys managed within EU jurisdiction. Swiss financial and healthcare data should have keys managed within Swiss jurisdiction. Document this policy, implement technical controls to enforce it, and audit compliance regularly.
Step 6: Review third-party contracts with key management in mind
Your data processing agreements probably address data location and access controls. They probably do not address key management jurisdiction and access mechanisms with sufficient specificity. Close this gap contractually, and where a vendor cannot provide the necessary guarantees, treat that as a material compliance risk — because it is.
Step 7: Prepare for the audit question you haven't been asked yet
Regulators are moving toward asking: "Demonstrate that no party other than your organisation can access this data without your explicit authorisation." Prepare your answer now. If you cannot give a clear, technically substantiated response, you have work to do.
The Regional Landscape at a Glance
| Framework | Jurisdiction | Compliance Obligations | Implications |
|---|---|---|---|
| GDPR | European Union | Article 32 technical measures; Article 44 transfer restrictions | Keys must not be accessible under non-EU legal compulsion |
| FINMA | Switzerland | Outsourcing circulars; banking secrecy; operational resilience | Keys must remain under Swiss-controlled access; foreign key managers create outsourcing risk |
| HIPAA | United States | Security Rule encryption and decryption specifications; Business Associate Agreements | Key management vendors must be covered as Business Associates; access controls must be documented and auditable |
The Bottom Line
Data sovereignty without key sovereignty is a compliance fiction. Encrypting data while delegating key management to a third party under a foreign jurisdiction does not give you control. It gives you the appearance of control — which will satisfy a checkbox audit and fail a serious regulatory investigation.
The organisations that will navigate the next wave of regulatory scrutiny are those that treat key sovereignty as a first-class compliance requirement, not an afterthought. They will be able to demonstrate, technically and legally, that access to their regulated data is governed entirely by their own policies and infrastructure.
Everyone else will be explaining their key management dependencies to a regulator.
DuoKey provides organisations with the infrastructure to achieve genuine key sovereignty across GDPR, FINMA, and HIPAA environments — including multi-party key management that ensures no single provider, including DuoKey, can access your data unilaterally.
