Microsoft Copilot Data Residency: A Firm Policy Template

Microsoft 365 Copilot runs inside the same tenant as your firm's Word, Outlook, and SharePoint data, but data residency for AI grounding is not the same problem as data residency for email. Microsoft launched expanded enterprise data protection commitments through 2025-2026 that extend the EU Data Boundary, UK, and Switzerland coverage to Copilot prompts and responses (per Microsoft's data residency documentation). The default Microsoft 365 Copilot enterprise add-on costs $30/user/month annual on E3/E5 (per Microsoft 365 enterprise pricing). For a multi-jurisdiction firm, the policy work isn't pricing: it's mapping where your data physically processes when an attorney prompts Copilot from London, Frankfurt, or Sao Paulo. This guide describes the framework, not a fill-in-the-blanks template.

Why Copilot residency is harder than M365 residency

Microsoft 365's core data residency story has been stable for years. Mailboxes, OneDrive folders, SharePoint sites, each gets assigned a home region, and the storage stays there. Copilot adds three new data paths that don't always follow the same residency rules:

• The prompt itself. When an attorney types a prompt into Copilot, that prompt has to be processed by a foundation model. The model lives in specific Azure regions. Microsoft's documentation specifies which regions handle Copilot processing for which tenant home regions, but the mapping is not 1-to-1.
• The grounding query. Copilot grounds its responses in the user's tenant data: SharePoint, Exchange, OneDrive content the user has access to. The grounding query traverses the model layer, which means even if your SharePoint stays in Germany, the question routed against it may transit a model in a different region.
• The Bing search component. Some Copilot features include real-time web grounding via Bing. Bing search is a global service. If your Copilot prompt triggers a web search, that search may execute outside your home region regardless of your tenant settings.

For a firm with offices in the US, UK, EU, and APAC, that's three independent residency questions per prompt. The policy framework needs to address each.

The framework: six clauses every multi-jurisdiction firm policy should cover

A firm-side data residency policy for Copilot covers six clauses. These aren't model contract terms: they're internal governance language that operations and IT execute against. The clauses describe necessary commitments, not specific text:

1. Tenant geography declaration. Name the home region for each tenant your firm operates. Most firms run a single global tenant with multiple country domains; some run regional tenants. Document which is which. The Copilot processing region inherits from this.

2. Authorized prompt geography clause. Specify which physical user locations are authorized to use Copilot for matter work. A litigation associate logging in from a country outside your tenant geography may trigger residency concerns regardless of license. Travel-and-prompt scenarios need explicit handling.

3. Grounding source restrictions. Identify SharePoint sites, Exchange folders, and OneDrive locations whose content cannot be used as Copilot grounding under any circumstance. Apply Microsoft Information Protection sensitivity labels to enforce this at the platform layer. Pair with the privilege framework for content-level restrictions.

4. Bing grounding kill-switch. Decide whether Copilot is allowed to use real-time web grounding for matter work. For most firms doing privileged work, the answer is no: disable web grounding at the policy level and document the configuration.

5. Cross-border transfer logging clause. Maintain a log of any Copilot prompts that crossed a residency boundary, with timestamp, user, and matter context. This is what client RFPs and regulator inquiries will ask for. Microsoft's audit logs provide the raw data; the policy provides the review cadence.

6. Client-engagement disclosure clause. Define when and how the firm discloses Copilot use to clients, including residency considerations. Some clients (especially regulated industries: banking, healthcare, defense) require disclosure of every AI tool in the data path, including residency mapping.

EU Data Boundary, UK, Switzerland: what's in and what's not

Microsoft's EU Data Boundary is a contractual and technical commitment to keep specified Microsoft 365 customer data and personal data within EU/EFTA member states for EU-resident customers. The boundary expanded over 2024-2025 to include Copilot prompts, responses, and processing for in-scope features.

What the boundary covers for Copilot:

• Prompt and response data for core Copilot features
• Personal data processed during Copilot interactions
• Telemetry data Microsoft uses for service operation

What it does not automatically cover:

• Bing-grounded search queries (Bing is a global service)
• Customer-initiated data exports outside the EU
• Some preview or experimental Copilot features (check feature-by-feature)

The UK and Switzerland have parallel commitments aligned to UK GDPR and Swiss data protection law respectively. The mapping is substantively similar but legally distinct. For a firm with offices in London and Zurich, that's two independent compliance assessments, not one. Verify your tenant's current Copilot region assignment in the Microsoft 365 Admin Center data location report before relying on these defaults.

Practical residency map by office location

For a hypothetical AmLaw firm with offices in New York, London, Frankfurt, Singapore, and Hong Kong, the residency map looks like this. The numbers are the operational pattern, not specific Microsoft commitments:

• New York attorneys prompting Copilot: data processes in US Azure regions per default M365 US tenant assignment. No cross-border issue for purely US matters.
• London attorneys: data processes inside the UK Data Boundary if the tenant is configured for UK residency. Cross-border risk arises only if a London attorney prompts about US-resident client data stored in a US-region SharePoint site.
• Frankfurt attorneys: data processes inside the EU Data Boundary. Same cross-border consideration as London for non-EU matters. Plus stricter local legal-ethics rules in Germany about cloud-based legal work.
• Singapore attorneys: outside the EU/UK boundary structure. Microsoft offers Asia-Pacific data residency for some M365 services; check current Copilot coverage. Often falls back to a default Microsoft global region.
• Hong Kong attorneys: similar APAC coverage status. Many global firms route Hong Kong tenant data through Singapore for regulatory simplicity.

The operational rule: a multi-jurisdiction firm cannot rely on a single tenant configuration to satisfy all offices. Either segment by tenant or document the residency footprint explicitly per practice group. The conflict-check isolation guide covers the parallel issue for cross-matter work.

Client RFP language: what regulated clients now ask

Banking, insurance, defense, and healthcare clients have started adding Copilot-specific residency questions to their outside counsel RFPs and engagement letters. The recurring questions:

• Where does the foundation model that processes our matter prompts physically run?
• Does the firm use Bing web grounding when prompting Copilot for our matter? If so, how is that disclosed to us?
• Does the firm log all Copilot prompts touching our matter? What's the retention period?
• Has the firm reviewed its Copilot configuration against the EU Data Boundary, UK Data Boundary, or relevant residency framework? Is the review documented?
• Who at the firm is the named contact for Copilot residency questions?

Answering these questions cold during an RFP cycle is operationally expensive. Answering them with a pre-built residency map is cheap. The Bing AI Performance dashboard guide covers the visibility audit; this policy framework covers the procurement-readiness audit. Both are worth running before the next RFP cycle.

Recommendations by firm size

Solo and small firms (2-10 attorneys), single-jurisdiction. A 1-page residency declaration suffices. Identify your tenant's home region, confirm Copilot processes there, document the configuration, and note any client-specific disclosure obligations. Annual review at policy renewal.

Mid-size firms (10-50 attorneys), domestic with occasional cross-border work. Add the cross-border transfer logging clause. Run quarterly audit-log reviews. If your practice mix includes regulated clients, build the RFP-response language now, not the day before the proposal is due.

Multi-jurisdiction firms (50+ attorneys, multiple countries). Full six-clause framework. Designate a residency owner, typically the CIO, the GC, or a dedicated AI governance lead. Run the residency map per office, refresh quarterly. Tie the residency framework to your existing GDPR, UK GDPR, and any local data protection compliance work. Don't run Copilot residency as a separate program; it's a component of the existing privacy posture.

BigLaw and AmLaw 100. Plus everything above, plus a Microsoft Premier engagement to scope custom Data Loss Prevention rules, plus a documented relationship with Microsoft's compliance team for region-specific commitments. Compare your residency posture against Claude Cowork's residency story and ChatGPT Enterprise's posture before adding new tools to the stack.

The bottom line. My take: Copilot residency is a 6-clause policy problem the vendor can't solve for you. Microsoft provides strong defaults inside the EU and UK Data Boundaries; the firm provides the per-office, per-matter mapping. Build the framework before regulated clients ask. The RFP cycle is when this gets tested.