Copilot rollout exclusion list

A GitHub Copilot rollout is mostly easy. The seats are bought, the IDE plugin is installed, the team is on it within a week. The piece that gets skipped, almost every time, is the content exclusion list. The team that skips it discovers the problem the first time something sensitive — a credential, a customer record, an API key in a fixture — ends up in a suggestion or a code completion that another developer accepts without thinking.

What content exclusions actually do

Content exclusions tell Copilot which paths in which repositories should never be used as context for suggestions. The exclusion is enforced at the GitHub side, not in the editor, so it survives a developer ignoring a setting. There are two layers: organisation-level exclusions that apply across every repo, and repository-level exclusions that apply to a single repo.

The model is straightforward. The work is in deciding what goes on the list.

What belongs on the list

A useful starting frame: anything that, if it appeared in a code completion suggestion to a different developer in your org, would be a problem. That set is usually larger than people first think.

Common categories worth excluding:

1. Secret material. Test fixtures with real-looking credentials. Keys committed during a rotation. Anything in a .env.example that was copy-pasted from a real .env.
2. Customer-identifiable data. Sample data files that came from production. Anonymised exports that were not anonymised carefully enough. Test data with real email addresses.
3. Compliance-sensitive logic. Code paths that implement contractual obligations specifically tailored to one customer. Audit-relevant routines whose internals should not be inferred by suggestions in unrelated repos.
4. Generated proprietary content. Vendor-supplied SDK code under restrictive licences. AI-generated code from other tools where the licence terms are unclear.

The list does not have to be exhaustive on day one. It has to be honest about the highest-risk paths and growable as the team learns where the edges are.

What does not need to be on the list

A surprising amount does not. Most application code is fine to include. Most internal libraries are fine. The exclusion list is for the genuinely sensitive paths, not for everything that someone might prefer to keep private. Over-exclusion has its own cost: the rollout becomes painful, the team works around it, and the exclusion stops being trusted.

The policy that makes the list legible

The most important artefact is not the list itself; it is the short written policy that explains what the rule is and why. One paragraph per category, with an example. New paths get added to the list because they fit a category, not because someone felt nervous on a particular Tuesday.

When the list is legible, junior engineers can make the call about whether a new file goes in scope without escalating. When it is not, every decision becomes a meeting.

How this fits Cyber Essentials Plus

Copilot is a cloud service, so it sits inside the cloud services scope of a Cyber Essentials Plus assessment. The exclusion policy is part of the evidence: it shows that the team has thought about the data Copilot can see and made a defensible decision. Assessors do not ask for the file contents; they ask for the policy and a sample. Both should be ready before the assessment date, not invented under pressure.