GitHub Copilot Enterprise data residency: what's actually committed in writing

Published 2026-04-11 by Owner

I’ve helped two organizations evaluate GitHub Copilot Enterprise from a compliance perspective. The marketing pages and the actual contract terms differ in interesting ways. This is what’s worth knowing before your legal team gets the contract.

This is not legal advice. Talk to your own lawyers. The point of this post is to surface questions you should ask, not to answer them for your specific case.

What the marketing says

GitHub’s Copilot Enterprise pages emphasize:

• Code never used to train the model
• Enterprise plan includes audit logs
• SOC 2 compliance
• Data processed in specific regions on request
• Indemnification for IP claims

These are real and meaningful. They’re also packaged in marketing prose that papers over the precise meaning.

What the contract actually says (paraphrased)

I read the actual MSA and Copilot-specific addenda for both engagements. The relevant points:

“Code is not used to train the model” is true for Copilot Enterprise tier. It is not unconditionally true for individual or business tiers. The exact language about training varies; Enterprise has the cleanest language.

Data residency is region-selectable but the underlying processing happens in Microsoft Azure regions, not GitHub-only regions. The data flow involves Azure OpenAI Service for the model calls. Your data residency choices are bounded by which Azure regions support the model variants Copilot uses.

This matters for organizations that have specific data residency requirements written into other contracts. “EU only” in your customer contract may be incompatible with Copilot’s actual data flow if any processing transits a non-EU Azure region.

Audit logs are available but the granularity differs from on-prem audit logs. You can see who has Copilot active, what models they have access to, and aggregated usage statistics. You typically can’t see individual prompts or completions in audit logs (they’re not retained by design — see “data retention” below).

SOC 2 applies to GitHub’s organizational controls. The model providers (OpenAI, Anthropic, Google) have their own SOC 2 reports. Your compliance review needs to consider the chain.

IP indemnification has carve-outs. The standard one: indemnification doesn’t apply if you’ve configured the tool to suggest code that’s clearly copied (matching public code). The “duplicate detection filter” is enabled by default; turning it off changes the indemnification picture.

Data retention

This is the part most organizations under-investigate. The relevant questions:

• How long is prompt data retained?
• How long is completion data retained?
• Where is the data stored during retention?
• What happens after the retention period?

For Copilot Enterprise, my reading: prompts and completions are retained for a short period (measured in days, varying by region) for abuse detection and service quality, then deleted. The retention is shorter than typical SaaS audit log retention.

This is generally good for privacy. It’s complicated for incident response. If a developer suspected they pasted secrets into a Copilot prompt last week, you can’t go look at the prompt logs to confirm — they’re already deleted.

Cross-border data transfer

If your organization has cross-border data transfer concerns (GDPR for EU data, SCC obligations, China data localization), the Copilot architecture introduces several relevant flows:

1. Code from your editor → GitHub’s Copilot API (in your region)
2. GitHub’s Copilot API → model provider (in their selected region, may not match yours)
3. Model output → back to your editor

Step 2 is where your data leaves your region in the typical case. The contract addenda usually have language about this. Get the specific language for the Azure region pair your contract specifies, not the marketing summary.

For organizations under FedRAMP, GovCloud, or similar regulated environments: there’s a separate Copilot SKU that runs in regulated environments. It’s not the same product as commercial Copilot Enterprise. The features are roughly comparable, but you should not assume parity.

Customer-provided context

Copilot Enterprise can index your organization’s repositories and use them as context for completions. The repos are not used to train the public model, but they are used to ground completions for your users.

The question to ask: how is the index stored, and what’s the retention story for the index versus the source repos? If you delete a repository, does the index get deleted?

In practice: the index is stored in encrypted form, and deletion of source repos triggers index deletion. There’s a delay (measured in hours, possibly days) between source deletion and index removal. This matters if you have aggressive data deletion requirements.

Third-party model access

Copilot Enterprise’s model picker (Claude, Gemini, GPT-4o) routes to those providers via Microsoft Azure. The data goes to Azure OpenAI for OpenAI models, to a Microsoft-Anthropic integration for Claude, etc.

Each model provider has their own data handling commitments. The chain matters: your data passes through GitHub’s controls, then through Microsoft Azure’s controls, then through the model provider’s controls. A non-conformance at any step affects you.

For organizations with strict provider controls (e.g., “approved providers only” lists), expect to add Microsoft Azure and any model provider whose model is exposed to your users. The list grows as Copilot adds more model options.

What I’d ask in negotiation

Based on the engagements I’ve worked on, the questions worth raising explicitly:

1. What is the data retention policy for prompts and completions in our specific region?
2. Which Azure regions does our data transit during a model call, and is that contractually constrained?
3. What is the indemnification coverage if we keep duplicate detection enabled?
4. How does customer-side audit logging differ from our normal SaaS audit logging?
5. If we delete a repository, what’s the SLA on index deletion?
6. What is the SOC 2 coverage for the model provider chain, and how does it intersect with our compliance program?

The answers may not change your decision. But getting them in writing reduces the chance of unwelcome surprises during your next compliance review.

The pragmatic take

For most organizations, Copilot Enterprise’s compliance posture is acceptable. The carve-outs and details I’ve described are the kinds of things that come up in the second compliance conversation, not the first. The first conversation typically gets a yes.

For organizations in highly regulated industries (banking, healthcare, defense), the details matter and the answers are organization-specific. Don’t rely on the marketing pages or general advice. Read the contract addenda your specific engagement gets, not the general terms.

The terms also change. The version I read 18 months ago has been revised twice since. If you negotiated terms then, your team should re-review the current version periodically — it’s typically been getting better, not worse, but you want to know which way.