A partner at a tax advisory firm asks Copilot to summarize recent client communications. Copilot delivers. In the summary: an email thread between two other partners discussing a salary dispute. The partner had never seen those emails. Never searched for them. Never knew they existed.
But his SharePoint permissions said he could.
Someone shared that folder with “All Partners” years ago. Maybe three years back, maybe five. Nobody noticed because nobody ever searched for it manually.
Copilot searches. That is literally what it does. And it is very good at it.
What oversharing means
Copilot searches everything a user can access in Microsoft 365. SharePoint, OneDrive, Exchange, Teams. It doesn’t create new permissions. It doesn’t invent access. It uses exactly the permissions that already exist.
That sounds reasonable until you realize that existing permissions in most organizations are way too broad.
Files shared with “Everyone” years ago. Teams channels that were never locked down. SharePoint sites with inherited permissions that haven’t been touched since initial setup. Project folders created for a specific engagement, now forgotten, still accessible to half the company.
When people search manually, this stays invisible. Nobody types “salary dispute partner” into SharePoint search. But Copilot works differently. It scans a user’s entire accessible data to assemble the best possible answer. And it surfaces things that were never meant to be surfaced.
Microsoft calls this oversharing. And Microsoft ranks it as the number one risk category for Copilot deployments.
Microsoft says so themselves
In the official Copilot deployment guides, Microsoft explicitly recommends a permissions audit before rollout. This isn’t buried in a footnote. It’s in the main guidance, with emphasis.
Most companies skip this step. Copilot licenses get activated, the pilot group starts using it, and the permissions cleanup gets scheduled for “later.” Or never.
I don’t see this as negligence. It makes sense. Permissions audits are unglamorous work. No executive gets excited about a week of reviewing SharePoint access. But with Copilot, this isn’t optional anymore. It’s a prerequisite.
The logic is simple: without a permissions audit, you don’t know what Copilot can see. And what you don’t know, you can’t control. Microsoft provides the tools. The configuration is on you.
The SharePoint problem in detail
SharePoint permissions grow organically. And organically here means: messy.
A typical scenario: The firm had eight employees when SharePoint was set up. Now it has 25. New hires got added to groups with broad access because it was faster than configuring individual permissions. Former employees got disabled, but their shared folders stayed the same. Project folders that were accessible to all participants still exist, even though the project wrapped up two years ago.
The result is a patchwork where nobody can say with certainty who can access what.
There’s another detail people miss: sharing links. When someone sends a SharePoint link via email and picks “Anyone with the link,” that link stays active until someone manually revokes it. In a firm with ten years of SharePoint usage, there can be hundreds of these links floating around. Many of them point to documents that should have stopped being shared a long time ago.
I’ve done permissions audits where an intern technically had read access to executive payroll data. Not because anyone intended that. Because the “All Employees” group had read access to a SharePoint library that nobody ever restricted. In another case, a trainee had access to active client correspondence because she’d been added to a team created for a project that wrapped up months earlier. The team still existed. So did the files.
Copilot doesn’t cause this problem. It makes it visible. Fast.
What actually happened
Oversharing isn’t a theoretical risk. There are documented incidents showing that even protective measures don’t always hold.
EchoLeak (June 2025): A security incident where Sensitivity Labels could be bypassed. Files classified as “Confidential” with access restrictions could still be processed by Copilot under certain conditions. Microsoft confirmed and patched the issue.
CW1226324 (January 2026): Another documented label bug. Similar pattern: labels were correctly applied, but enforcement didn’t work as expected in specific scenarios.
This doesn’t mean Sensitivity Labels are useless. They’re a critical building block. But they’re one layer, not the only layer. If you rely solely on labels without cleaning up the underlying permissions, you’re building protection on top of a mess.
What a permissions audit actually involves
A permissions audit sounds like a massive undertaking. In practice, it’s methodical work that takes two to three days for a firm with 15 to 30 employees.
Review SharePoint sites
In the SharePoint Admin Center, export the list of all active sites. For each site containing client data or confidential information, check:
- Who are the members and owners?
- Which M365 groups have access?
- Are there groups like “Everyone” or “Everyone except external users”?
Every site with the “Everyone” group is an oversharing candidate. Not all of them are problems. But every one of them needs a deliberate review.
Identify “Everyone” shares
This is the most common finding. At some point, someone shared a file or folder with “Everyone” because it had to happen fast. In that moment, it might have even made sense. Three years later, it’s an open door.
In the SharePoint Admin Center under “Policies” > “Sharing,” you can set the default sharing level to “Only people in your organization.” That prevents new “Everyone” shares. Existing ones need manual review and cleanup. This is the most time-consuming part of the audit, but also the most important.
Review Teams channels
Teams channels have their own permissions. Standard channels are accessible to all team members. Private channels have separate member lists. But here too: team membership rarely gets reviewed on a regular basis.
A team created for a client project might still include members who moved to different departments long ago. The files in the team channel are still accessible to them. This also applies to files shared directly in chat. A lot of people forget that Teams chats with file attachments create their own SharePoint folders, subject to the same permission rules.
Configure Sensitivity Labels
After cleaning up permissions, labels come next. A practical structure for regulated firms has four tiers: “Public” for marketing material and general documents where Copilot can access freely. “Internal” for work documents without client reference, access restricted to employees. “Confidential” for client-related documents, contracts, and tax assessments, only for assigned staff, with encryption active. And “Highly Confidential” for particularly sensitive data where Copilot is locked out completely.
Add auto-labeling rules for tax identification numbers, IBAN numbers, and client reference codes. Documents matching these patterns automatically get the “Confidential” label. This doesn’t replace manual review, but it catches the cases that would otherwise slip through. Especially for older documents created before labels were set up, auto-labeling is often the only realistic way to get broad classification coverage.
Set up DLP policies
Data Loss Prevention policies are the third layer. They prevent confidential content from being shared externally, even accidentally. A DLP rule can, for example, block documents labeled “Confidential” from being emailed to external recipients.
For client data covered by Section 203 of the German Criminal Code, DLP policies aren’t optional. They’re part of the documented safeguards that a firm must demonstrate during an audit.
The sequence matters
The most common question I see in forums and LinkedIn discussions: “We activated Copilot. What do we need to do now?”
The honest answer: the sequence should have been reversed.
- Permissions audit before rollout. Who can access what?
- Cleanup of overly broad permissions. Remove “Everyone” shares, trim groups.
- Sensitivity Labels configured and deployed.
- DLP policies for client data and confidential content.
- Then activate Copilot.
If Copilot is already running, it’s not too late. But the cleanup should happen in parallel, not “someday.”
I do these audits regularly. For a firm with 20 employees, the inventory takes a day. Cleaning up permissions takes another one to two days depending on the state of things. Label configuration takes one more. This isn’t a quarter-long project. It’s a working week. After that, you know who can access what, and Copilot runs on clean permissions instead of the mess that grew over years of “just add them to the group.”
How this connects to the 5 GDPR questions
Oversharing is the practical core behind several of the five questions that need answers before a Copilot rollout. The DPIA has to assess the oversharing risk. The permissions structure has to be documented. The Sensitivity Labels have to be configured.
If you don’t know your permissions, you can’t write a meaningful DPIA. And if you don’t have a DPIA, you have a problem when the data protection authority comes asking. The oversharing risk belongs in the DPIA’s risk assessment, and the countermeasures (permissions cleanup, labels, DLP) belong in the documented technical and organizational measures.
Next step
If you’re using Copilot or planning to deploy it, start with permissions. Not labels, not the DPIA. First the inventory: who can access what in SharePoint?
The Copilot Compliance Audit covers exactly this. I review your SharePoint permissions, configure Sensitivity Labels, and set up DLP policies before Copilot goes live.
Book a 30-minute intro call. No sales pitch. Just an honest assessment of where your environment stands.
Jose Lugo is a CISSP-certified AI compliance consultant with M365 Endpoint Administrator certification. He configures SharePoint permissions, Sensitivity Labels, and DLP policies for regulated firms in Germany.