Copilot Surfaced Salary Data - What to Fix First

Copilot did not grant anyone access. It removed the effort of finding content people already had access to.

• Copilot honours the signed-in user's existing permissions. Every pilot user could already have opened both files through search, a link, or by browsing the site. Nothing new was exposed; the exposure was discovered.
• Disabling Copilot hides the detector and leaves the exposure in place: the same 120 users, and the other 680, can still find both files today through search.
• Copilot content stays inside the Microsoft 365 compliance boundary - sensitivity labels, DLP and retention apply, and prompts and responses are not used to train foundation models. The incident is a permissions incident, not a Copilot data-handling incident.
• Say the quiet part plainly: the pilot produced a finding that would otherwise have surfaced in the next audit or, worse, from a journalist. That is a result, not a failure.

What to actually do: treat the pilot as a discovery instrument, prioritise the sites it flagged, and keep the pilot live so more findings surface.

It is a plausible-sounding action that addresses a fraction of the actual access paths and breaks collaboration.

Why it falls short:

• The claim at issue is not a sharing link, it is an inherited site permission (Everyone except external users). Deleting links does nothing to inherited permissions.
• Access also flows from site Owners/Members groups, direct grants, Microsoft 365 group membership, and site collection administration. Links are one of at least five paths.
• Collateral damage is immediate and visible: links pasted into emails, Teams chats and intranet pages go dead. Users lose trust in the platform and rebuild the same links within a month.

Targeted alternative:

1. Remove the broad claim from the site's permission inheritance and re-scope to a defined security group.
2. Disable the Everyone except external users claim at tenant level so it cannot be recreated on the next migration.
3. Review the site's Owners and confirm who can grant access, since Owners can undo any cleanup.

Measure twice: a permission change on a live site can lock out a team mid-quarter. Stage it with the site owner and communicate before the change, not after.

Prioritise by exposure, cap the blast radius while cleanup runs, and put a control on the sensitive content itself.

Days 1-30 - find and contain:

• Use SharePoint Advanced Management (included in E5) data access governance reporting to rank sites by broad sharing and by inactive ownership. Do not sort alphabetically.
• Apply Restricted SharePoint Search / Restricted Content Discovery so Copilot and org-wide search are limited to a curated allow-list of sites plus sites users have recently interacted with. This is the one control that reduces Copilot's reach immediately without touching individual files. Accept and communicate the trade-off: users will report Copilot cannot find content outside the allowed set.
• Fix the flagged sites: remove the broad claim, assign a real owner, run an access review.

Days 31-60 - control the crown jewels:

• Apply sensitivity labels with encryption to HR, finance and legal libraries. Encryption protects the file wherever it is copied to, which address-based permission cleanup does not.
• Turn on DLP for the highest-risk sensitive information types.

Days 61-90 - make it stick:

• Block the broad claim tenant-wide, add a site-provisioning template that omits it, and report on residual risk to the sponsor.

The defensible position is not 'no broad sharing exists.' It is 'broad sharing is measured, capped, and being reduced against a plan.'