How European Enterprises Can Maintain Microsoft 365 Productivity While Protecting Sensitive Data With Sovereignty

Microsoft 365 is deeply embedded in European enterprise operations. Teams drives daily communication. SharePoint hosts document libraries spanning departments and partners. OneDrive underpins hybrid work. Outlook connects employees to customers and regulators.

Replacing this infrastructure is not a realistic option — and it should not have to be. The question European IT and security leaders actually face is narrower: how do you preserve full Microsoft 365 productivity while ensuring that data privacy obligations under GDPR, Schrems II, the US CLOUD Act, and an increasingly assertive enforcement environment are genuinely met?

This post addresses that question, examining the sovereignty gap Microsoft’s own tools leave open and how a sovereignty overlay closes it without disrupting the workflows employees depend on.

Executive Summary

Main Idea: Microsoft 365 creates structural data sovereignty exposure for European enterprises. Microsoft is subject to US CLOUD Act demands and while Microsoft’s own sovereign cloud tools address some of these risks, it does not eliminate them. A sovereignty overlay — the Kiteworks Private Data Network deployed as a single-tenant layer across Microsoft 365 workflows — provides customer-controlled encryption, possessionless access controls, and comprehensive audit capabilities that close these gaps.

Why You Should Care: European DPAs are scrutinising US cloud arrangements with increasing intensity. TIAs that identify CLOUD Act exposure but rely on contractual mitigations alone will not satisfy regulators who have studied the post-Schrems II enforcement record. Organisations that cannot demonstrate technically effective supplementary measures — customer-controlled encryption keys held in EEA-controlled hardware, provider access to plaintext demonstrably eliminated — face fines, processing bans, and reputational damage.

5 Key Takeaways

1. EU data centre location does not resolve CLOUD Act exposure for Microsoft. Microsoft is a US corporation subject to US legal orders wherever its infrastructure sits. The CLOUD Act follows provider control, not data geography. Microsoft’s EU Data Boundary restricts data residency; it does not prevent US government access to that data via legal demand.
2. Microsoft’s customer-managed keys do not place keys outside Microsoft’s reach. Azure Key Vault and Purview Customer Key give customers control over key rotation — but keys remain within Microsoft’s Azure infrastructure. A CLOUD Act or FISA demand directed at Microsoft reaches that infrastructure. Genuine key control requires keys in customer-controlled HSM integration outside the provider’s environment entirely.
3. Microsoft 365 Copilot creates a distinct and unresolved sovereignty exposure. Copilot processes plaintext content — emails, documents, Teams conversations — to generate outputs. Encryption at rest does not protect data that must be decrypted for AI processing. Organisations need a governance layer that controls what data Copilot can access, not just where it is stored.
4. Multitenancy is an underappreciated risk factor. In Microsoft’s default multitenant architecture, encrypted data and encryption keys for thousands of organisations coexist in shared infrastructure. A single exploit can expose multiple customers simultaneously. Single-tenant deployment — the architecture Kiteworks provides — eliminates this commingling risk entirely.
5. A sovereignty overlay preserves full M365 productivity. Kiteworks integrates with Outlook, Teams, SharePoint, OneDrive, Word, Excel, and PowerPoint via native plugins. End users operate within familiar interfaces; access controls, key management, audit logging, and geofencing operate below the UX layer without disrupting workflows.

The Microsoft 365 Sovereignty Problem: What Microsoft’s Own Tools Do and Don’t Solve

Microsoft has invested significantly in tools aimed at European regulatory concerns: the EU Data Boundary restricts personal data processing to EU and EFTA infrastructure; Azure Key Vault and Purview Customer Key offer customer control over key rotation; Microsoft Cloud for Sovereignty adds policy guardrails for government customers. These are genuine capabilities. IT leaders should understand both what they provide and what they do not — because the gap is exactly what regulatory scrutiny is focused on.

What the EU Data Boundary Programme Does and Doesn’t Resolve

Microsoft’s EU Data Boundary restricts where personal data is stored and processed, satisfying data residency requirements and supporting the first layer of data sovereignty compliance. What it does not address is access. Microsoft is a US corporation. The US CLOUD Act requires US companies to produce data stored anywhere in the world upon a valid US government demand, regardless of storage location. GDPR Article 48 prohibits transfers to non-EU authorities on the basis of a foreign court order alone — but it does not prevent those orders from being issued, and it does not compel Microsoft to refuse them. The structural conflict between CLOUD Act obligations and GDPR Article 48 is not resolved by data residency commitments.

Why Customer-Managed Keys in Azure Are Not the Same as Customer-Controlled Keys

Azure Key Vault and Purview Customer Key give customers control over key rotation and revocation — meaningful capabilities. But keys managed within Azure remain within Microsoft’s infrastructure. A CLOUD Act or FISA Section 702 demand directed at Microsoft reaches that infrastructure. The EDPB’s Recommendations 01/2020 specify that customer-controlled encryption means the provider never has access to keys or unencrypted data. Keys held in Azure Key Vault do not meet this standard. Genuine key control requires keys in FIPS-validated hardware under the customer’s exclusive control, outside the provider’s environment entirely.

The Microsoft 365 Copilot Problem: AI Processing and Sovereignty

Microsoft 365 Copilot represents a separate and more acute sovereignty challenge. Copilot processes email content, SharePoint documents, and Teams conversation history to generate summaries, drafts, and responses — and for this to work, content must be available in plaintext. Encryption at rest provides no protection at the point of AI processing. Any data an employee has access to in M365 is potentially accessible to Copilot and through Copilot to Microsoft’s AI infrastructure. For European enterprises processing sensitive commercial data, regulated personal data, or legally privileged communications, this is a compounding exposure: the underlying data is subject to CLOUD Act reach, and AI-processed outputs derived from that data may be as well.

The governance challenge requires a layer that enforces what data Copilot can access — controlling inputs at the content level rather than relying on Microsoft’s internal access controls. An AI Data Gateway that intercepts and governs data flows to AI models — ensuring only appropriately classified content reaches AI processing — is the architectural response this exposure requires.

Sovereignty Requirements Under European Regulation: What the Law Actually Demands

GDPR Chapter V requires that transfers to third countries achieve essentially equivalent protection to that guaranteed within the EU. Schrems II confirmed that standard contractual clauses require supplementary technical measures where the recipient country’s law undermines their effectiveness. For transfers to US providers, CLOUD Act exposure means SCCs alone are insufficient. The EDPB has been direct: where US surveillance law creates risk that contracts cannot resolve, the only technically adequate supplementary measure is customer-controlled encryption, where the provider never has access to keys or plaintext.

The Regulatory Framework Beyond GDPR

For many European enterprises, the compliance spine extends well beyond GDPR. NIS 2 Directive obligations impose supply chain security requirements that cover cloud provider relationships. Financial services firms subject to DORA face concentration risk requirements around cloud providers and must demonstrate resilience in scenarios where a US cloud provider’s data becomes subject to foreign legal orders. Healthcare organisations, defence contractors, and professional services firms handling legally privileged communications all face sector-specific overlays on the GDPR baseline. A sovereignty architecture that satisfies GDPR’s supplementary measure standard will generally satisfy these frameworks, though documentation requirements vary and each regulatory context warrants specific assessment.

Transfer Impact Assessments remain the documentary foundation. A credible TIA for a Microsoft 365 deployment must identify CLOUD Act and FISA 702 exposure, assess how those laws impinge on SCCs’ effectiveness, and establish that the supplementary measures deployed — customer-controlled encryption with keys outside Microsoft’s infrastructure — achieve essentially equivalent protection. TIAs completed before deploying a sovereignty overlay must be updated to reflect the new architecture; that update is itself evidence of the accountability posture regulators expect.

The Sovereignty Overlay Architecture: How It Works Without Disrupting M365

A sovereignty overlay does not replace Microsoft 365. It wraps sensitive data workflows within a security and governance layer that sits between end users and Microsoft’s infrastructure, ensuring that data Microsoft handles has already been encrypted with keys the European organisation controls — so Microsoft processes ciphertext, not plaintext. Employees continue using the same applications; the sovereignty controls are largely invisible to them.

How Kiteworks Integrates With Microsoft 365 Without Replacing It

The Kiteworks Private Data Network integrates with each major Microsoft 365 application via native plugins and connectors, enforcing sovereignty controls at the point of data exchange rather than requiring application migration.

For Outlook, the Kiteworks plugin applies role-based policies governing forwarding permissions, expiration dates, and access controls before messages leave the organisation. Administrators set governance rules centrally; end users work within their normal Outlook workflow. Secure email flows without configuration burden on employees, and every send, receive, forward, and download is captured in an immutable audit log.

For Teams, the Kiteworks plugin enables secure file sharing with external parties through Kiteworks’ governed repositories, with role-based access control governing who can access files from SharePoint, OneDrive, and Windows file shares through the Teams interface, and automatic logging for every interaction.

For SharePoint and OneDrive, the Kiteworks Sovereign Access Suite provides a unified gateway to internal repositories without VPN dependencies. Its possessionless editing capability, powered by SafeEDIT, allows external parties to view and edit documents without the files ever leaving the organisation’s controlled environment — possessionless editing eliminates exfiltration risk during external collaboration without restricting the collaboration itself.

For Word, Excel, and PowerPoint, Kiteworks plugins enable secure document sharing directly from applications, saving files to enterprise repositories and Kiteworks shared folders under the same access and audit controls that govern all other sensitive data flows.

Single-Tenant Deployment and Customer-Controlled Key Management

The architectural foundation is single-tenant deployment — on-premises, customer-controlled private cloud, or dedicated hosted instance — combined with customer-managed encryption keys held in HSM integration under the European organisation’s exclusive control. In Microsoft’s default multitenant architecture, encrypted data and keys for thousands of organisations coexist in shared infrastructure. Kiteworks eliminates this commingling entirely: each deployment is isolated, and encryption keys never leave the customer’s controlled environment.

Kiteworks supports FIPS 140-3 Level 1 validated encryption — AES-256 for data at rest, TLS 1.3 for data in transit, with S/MIME and OpenPGP for email. Keys are generated and held by the European organisation. Kiteworks never accesses them, and neither does Microsoft when processing data that has already been encrypted before reaching M365 infrastructure. This is the architecture the EDPB’s supplementary measure standard requires, and it is what makes a Transfer Impact Assessment credible under regulatory scrutiny.

Kiteworks enforces data localization through geofencing — allow-lists and block-lists for IP address ranges ensuring data is stored only in specified jurisdictions. For German organisations under BDSG, French organisations with ANSSI obligations, Dutch organisations under AP enforcement priorities, or UK organisations under UK GDPR, jurisdiction-specific key deployment and geofencing provide the technically verifiable sovereignty documentation DPA responses require.

Governing AI: The Copilot Exposure and How to Address It

Microsoft 365 Copilot is becoming a standard enterprise productivity feature, and European organisations face business pressure to enable it. The governance challenge is to allow Copilot to deliver value while preventing it from processing content that should not enter Microsoft’s AI infrastructure — which requires a content governance layer, not a blanket disable.

The Kiteworks AI Data Gateway acts as an intermediary between content repositories and AI processing, enforcing AI data governance policies that determine which content categories can be surfaced to AI models. DLP scanning, data governance classification, and access policy enforcement are applied before content reaches Copilot — ensuring regulated personal data, commercially sensitive documents, and privileged communications are governed consistently regardless of which AI feature triggers the processing request. Organisations that deploy Copilot without a content governance layer effectively grant Microsoft’s AI infrastructure access to everything their employees can see — a compliance exposure DPAs are increasingly equipped to identify and act on.

The Compliance Documentation Case: TIAs, Audit Logs, and DPA Readiness

Technical sovereignty architecture is necessary but not sufficient. Regulators require documentary evidence — Transfer Impact Assessments, processing records, DPIAs for high-risk processing, and audit logs demonstrating continuous compliance. The Kiteworks CISO Dashboard provides centralised visibility across all sensitive data exchanges — who sent what to whom, when, from which application — creating the immutable audit trail GDPR Article 5(2)’s accountability principle requires.

For organisations subject to NIS 2 incident reporting or DORA operational resilience documentation requirements, Kiteworks’ comprehensive logging and reporting support the evidence package those frameworks demand. For organisations facing a DPA inquiry about Microsoft 365 arrangements, the combination of single-tenant deployment documentation, HSM key management records, geofencing evidence, and per-application audit logs makes a response credible rather than merely assertive.

How Kiteworks Enables Microsoft 365 Sovereignty Without Sacrificing Productivity

European enterprises do not have to choose between Microsoft 365 productivity and data sovereignty. The choice instead is between deploying M365 with a sovereignty overlay that closes the CLOUD Act, multitenancy, and AI exposure gaps — or accepting a compliance posture that DPA scrutiny will test. A sovereignty overlay built on customer-controlled encryption keys, single-tenant deployment, possessionless access controls, and AI content governance is what that standard looks like in practice — and it integrates with Microsoft 365 at the application level without requiring employees to change how they work.

Kiteworks provides the sovereignty overlay European enterprises need to operate Microsoft 365 in compliance with GDPR, Schrems II, NIS 2, and DORA. The Private Data Network deploys as a single-tenant instance — on-premises, private cloud, or Kiteworks-hosted — with customer-managed encryption keys in jurisdiction-controlled HSMs that Kiteworks never accesses. Native plugins for Outlook, Teams, SharePoint, OneDrive, and Office applications integrate directly into existing workflows. The Sovereign Access Suite provides possessionless access to internal repositories and SafeEDIT-powered external collaboration without data leaving the controlled environment. Comprehensive immutable audit logs and a centralised CISO Dashboard provide the documentary evidence DPA inquiries require. Kiteworks supports jurisdiction-specific deployment across Germany, France, the Netherlands, and the UK, with NIS2 compliance and DORA compliance documentation built in. To see how the architecture works in your environment, 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]