WOPI Data Residency and Geo-Fencing: A Compliance Guide for UK Businesses

When your SaaS platform embeds Microsoft 365 document editing through the WOPI protocol, every file open, every keystroke, and every save operation passes through a Microsoft regional data centre. For most of the protocol’s history, hosts had limited control over which data centre handled those operations. That changed with the introduction of CSPP Plus and its ComplianceDomainPrefix property, which gives WOPI hosts explicit control over the geographic region where documents are processed.

For UK businesses operating under post-Brexit data sovereignty requirements, this is not a minor protocol enhancement. It is a fundamental compliance capability that determines whether embedded document editing can be offered to regulated customers at all.

This guide explains how WOPI data residency and CSPP Plus geo-fencing work at a technical level, why UK businesses need to pay attention, and the practical steps required to implement data residency controls in your WOPI integration.

Why Data Residency Matters for WOPI Hosts

The WOPI protocol enables cloud storage platforms to embed Microsoft Office editing directly into their web applications. When a user opens a document, the host application communicates with Microsoft’s Office for the web (formerly Office Online Server) through a series of WOPI operations: CheckFileInfo, GetFile, PutFile, and others. Each of these operations involves data transfer between the host and a Microsoft-operated service endpoint.

The critical question is: where does that Microsoft endpoint reside?

Prior to geo-fencing capabilities, Microsoft’s infrastructure would route WOPI operations to whichever regional data centre was most appropriate based on internal load balancing and proximity heuristics. For many use cases, this was perfectly acceptable. But for organisations subject to data residency regulations, the inability to guarantee that document content remained within a specific geographic boundary created a compliance gap.

The Regulatory Landscape for UK Businesses

Post-Brexit, the United Kingdom operates under its own data protection regime, the UK GDPR (retained from the EU General Data Protection Regulation) and the Data Protection Act 2018. While the UK has maintained adequacy decisions with the EU, the regulatory trajectory is increasingly independent.

Several factors make data residency particularly relevant for UK ISVs and SaaS platforms:

Financial services regulation. The Financial Conduct Authority (FCA) and the Prudential Regulation Authority (PRA) have published guidance on cloud outsourcing that explicitly addresses data location. Firms must be able to demonstrate where data is processed and stored, and must ensure that regulatory access to data is not impeded by cross-border arrangements.

Government and public sector. The National Cyber Security Centre (NCSC) cloud security principles require organisations to understand data residency implications. Government contracts frequently include data sovereignty clauses mandating that data remains within the UK or specified jurisdictions.

Healthcare and legal. NHS Digital’s cloud security guidance and the Solicitors Regulation Authority’s technology guidance both reference data location as a consideration. While neither imposes a blanket geographic restriction, both require organisations to demonstrate that data handling meets appropriate standards, which is significantly easier when data remains within a known jurisdiction.

Client contractual requirements. Beyond regulation, many enterprise procurement processes include data residency clauses. If your SaaS platform embeds document editing, your customers may require contractual assurance that document content is processed within the UK or EEA.

How CSPP Plus Geo-Fencing Works

The Cloud Storage Partner Program Plus (CSPP Plus) is Microsoft’s framework for ISVs who want to embed Office for the web document editing into their applications. It extends the standard WOPI protocol with additional capabilities, including the geo-fencing mechanism that enables data residency controls.

The ComplianceDomainPrefix Property

At the heart of WOPI geo-fencing is the ComplianceDomainPrefix property, which the host includes in the CheckFileInfo response. This property tells Microsoft’s Office for the web infrastructure which regional data centre should handle document processing for this specific file.

When a user opens a document, the WOPI host responds to the CheckFileInfo call with file metadata. By including the ComplianceDomainPrefix property, the host instructs Microsoft to route all subsequent WOPI operations for that document through the specified regional endpoint.

The value of ComplianceDomainPrefix corresponds to Microsoft’s regional deployment identifiers. For UK data residency, the host would specify the identifier that maps to Microsoft’s UK data centre region.

The Technical Flow

The geo-fencing mechanism operates within the standard WOPI discovery and file access flow:

1. WOPI Discovery. The host retrieves the WOPI discovery XML from Microsoft, which lists available actions and their corresponding URLs across regions. The discovery document includes regional endpoint information.

2. Action URL Construction. When a user requests to open a document, the host constructs an action URL. With geo-fencing, this URL incorporates the regional prefix, ensuring that the initial request reaches the correct regional endpoint.

3. CheckFileInfo Response. The host returns the ComplianceDomainPrefix property in the CheckFileInfo response. This confirms to Microsoft’s infrastructure which region should handle the session.

4. Subsequent Operations. All subsequent WOPI operations for that file session (GetFile, PutFile, Lock, Unlock, and others) are routed through the specified regional data centre.

5. Co-authoring Sessions. When multiple users collaborate on the same document, the geo-fencing setting from the host’s CheckFileInfo response governs where the co-authoring session is managed. All participants’ edits are processed within the specified region.

Important Technical Considerations

Per-file granularity. The ComplianceDomainPrefix is set per file in the CheckFileInfo response, not globally for the entire WOPI host. This means a single host application can serve documents with different data residency requirements. A multi-tenant SaaS platform could route UK customer documents through the UK data centre while routing EU customer documents through a European data centre.

Discovery endpoint alignment. The WOPI discovery XML must include the regional endpoints that your ComplianceDomainPrefix values reference. During CSPP Plus onboarding, Microsoft provisions access to the appropriate regional discovery endpoints.

Proof key validation. WOPI proof key validation, which verifies that incoming WOPI requests genuinely originate from Microsoft, must account for regional keys. Each regional deployment may use different proof keys, which the host must validate correctly.

Latency implications. Geo-fencing may introduce additional latency if the specified regional data centre is not the closest to the user. For a UK-based user accessing a UK-fenced document, this is unlikely to be noticeable. However, if a user in Asia accesses a document fenced to the UK region, the document editing experience may be slower than if routing were optimised purely for performance.

Implementing Data Residency Controls: A Practical Guide

For ISVs implementing WOPI data residency controls, the process involves both technical integration work and organisational decisions about data classification.

Step 1: Determine Your Data Residency Requirements

Before writing any code, establish which data residency rules apply to your platform and your customers.

Map your customer base by regulatory jurisdiction. Identify which customers require UK data residency, which require EEA residency, and which have no specific geographic requirements. This mapping will drive your implementation of per-file ComplianceDomainPrefix logic.

Review your existing data processing agreements and terms of service. If you currently make no data residency commitments regarding embedded document editing, adding geo-fencing controls allows you to strengthen your compliance posture and differentiate your platform in regulated markets.

Step 2: Complete CSPP Plus Onboarding

Geo-fencing capabilities are available through the CSPP Plus programme. If you are currently on the standard CSPP programme, you will need to engage with Microsoft to upgrade.

The CSPP Plus onboarding process includes domain allow-listing, which typically takes four to five weeks. Plan your timeline accordingly. Microsoft will provision access to the regional discovery endpoints and provide documentation on available ComplianceDomainPrefix values.

Step 3: Update Your CheckFileInfo Implementation

Modify your WOPI host’s CheckFileInfo endpoint to include the ComplianceDomainPrefix property. The logic for determining the correct value should reference your data residency mapping from Step 1.

A typical implementation pattern is:

• Identify the tenant or customer associated with the file being opened.
• Look up the data residency requirement for that tenant.
• Set the ComplianceDomainPrefix accordingly.
• Return the property in the CheckFileInfo JSON response.

For multi-tenant platforms, this is most cleanly implemented as a tenant-level configuration setting. When onboarding a new customer, their data residency preference is recorded and automatically applied to all WOPI operations for their documents.

Step 4: Update WOPI Discovery Handling

Ensure your WOPI discovery client can retrieve and cache discovery XML from multiple regional endpoints. Your action URL construction logic must use the correct regional base URL that corresponds to the ComplianceDomainPrefix you intend to set.

Step 5: Validate Proof Keys per Region

Update your proof key validation logic to handle regional proof keys. Each regional deployment may publish different public keys for request signing. Your validation should:

• Retrieve proof keys from the regional discovery endpoint.
• Cache keys appropriately (they rotate periodically).
• Validate incoming WOPI requests against the correct regional key set.

Failure to handle regional proof keys correctly will result in valid WOPI requests being rejected, breaking document editing for users.

Step 6: Test Across Regions

Thorough testing must cover:

• Document open, edit, and save operations for each configured region.
• Co-authoring sessions where all participants are in the same region.
• Co-authoring sessions where participants are in different geographic locations but the document is fenced to a specific region.
• Proof key validation for each regional endpoint.
• Graceful handling of regional endpoint unavailability.

Step 7: Document Your Compliance Posture

Once implemented, update your platform’s data processing documentation to reflect the geo-fencing capability. This documentation should specify:

• Which regional data centres are available.
• How data residency is configured (per-tenant, per-folder, or per-file).
• What data is covered by the geo-fencing (document content during editing sessions).
• What data is not covered (for example, WOPI discovery metadata).

This documentation supports your customers’ own compliance assessments and due diligence processes.

Common Pitfalls and How to Avoid Them

Having worked with numerous ISVs implementing WOPI integrations, McKenna Consultants has identified several common pitfalls in data residency implementations.

Assuming geo-fencing covers all data flows. The ComplianceDomainPrefix controls where document editing operations are processed. It does not necessarily govern every data flow in your application. Ensure you understand exactly which operations are covered and communicate this clearly to customers.

Hardcoding a single region. While tempting for simplicity, hardcoding a single ComplianceDomainPrefix value removes the flexibility to serve customers with different residency requirements. Design for per-tenant configuration from the outset, even if you initially only support one region.

Neglecting proof key rotation. Proof keys rotate periodically. If your validation logic caches keys indefinitely without checking for updates, you will eventually reject valid WOPI requests after a key rotation.

Underestimating the onboarding timeline. CSPP Plus onboarding involves domain allow-listing, which takes four to five weeks. Factor this into your project plan, particularly if you are working toward a regulatory deadline.

Overlooking co-authoring scenarios. Geo-fencing in co-authoring sessions introduces complexity. All co-authoring participants for a given document will be routed through the same regional data centre, regardless of their physical location. Test this thoroughly and document the behaviour for your support team.

The Commercial Value of Data Residency Controls

Beyond compliance, WOPI data residency controls create tangible commercial advantages for SaaS platforms.

Access to regulated markets. Financial services, healthcare, and government sectors represent high-value customer segments that require demonstrable data residency controls. Geo-fencing removes a procurement blocker.

Competitive differentiation. Many SaaS platforms that embed document editing cannot offer data residency guarantees. This capability differentiates your platform in competitive evaluations.

Reduced compliance overhead. Proactive data residency controls simplify your response to data protection impact assessments, security questionnaires, and audit processes. Rather than explaining why you cannot guarantee data location, you can demonstrate precisely how you control it.

Customer trust. In an era of increasing data awareness, the ability to assure customers that their documents are processed within their preferred jurisdiction builds trust and supports retention.

How McKenna Consultants Can Help

McKenna Consultants are recognised experts in WOPI protocol implementation, with deep experience across the Cloud Storage Partner Program and CSPP Plus. Our team has implemented WOPI integrations for ISVs across Europe and North America, including clients in regulated sectors where data residency is a mandatory requirement.

We provide WOPI integration consultancy that covers the full scope of a Microsoft 365 document editing SaaS integration, from initial CSPP Plus onboarding through to production deployment and ongoing support. Our expertise spans the technical protocol implementation, the Microsoft relationship management involved in domain allow-listing, and the compliance documentation that regulated customers require.

If your platform embeds or plans to embed Microsoft Office document editing and you need to address data residency requirements, contact McKenna Consultants to discuss your specific situation. We combine protocol-level technical depth with practical experience of the regulatory landscape that UK businesses must navigate.

Conclusion

WOPI data residency and CSPP Plus geo-fencing represent a significant maturation of the embedded document editing ecosystem. For UK businesses operating under post-Brexit data sovereignty requirements, these capabilities transform WOPI from a technology with a compliance gap into one with a compliance advantage.

The technical implementation, centred on the ComplianceDomainPrefix property in CheckFileInfo, is well-designed and offers per-file granularity. However, a successful implementation requires careful planning across regulatory mapping, CSPP Plus onboarding, regional proof key handling, and thorough testing.

For ISVs that invest in this capability, the reward is access to regulated market segments, competitive differentiation, and a stronger trust relationship with customers who care deeply about where their data is processed.