Handling an accidental external-sharing exposure

The report comes in one of two ways: a user says "I think I shared the wrong folder", or an outside party says "why can I see this?". Either way, the first hour is about breadth, not blame. An accidental share is rarely just one link. The folder was shared, then a subfolder had its own link, then the recipient was added as a guest to the site, and the Everyone-except-external group was granted on a library three years ago. You need all of it.

Step 1: cut the obvious access, without destroying evidence

Get the exact item: the site URL and the folder or file path. Then, as a SharePoint admin or a site collection admin:

• Open the item's Manage access panel. Remove the specific link or person reported. If it is an Anyone link, deleting it invalidates it for everyone who has it; there is no way to know who.
• Do not yet wipe all sharing on the item, delete the folder, or remove the user from the site. You want the audit trail intact, and the recipient may have legitimate access to other content that the panic will remove.

If the share went to an external account (a guest, or a specific external email), note the address. If it was an anonymous link, note the link's creation time from Manage access — you will need it to match audit events.

Step 2: find every path

This is the part people skip. Check all four.

Sharing links and direct grants on the item and everything under it. In the site, use the Shared with external users filter in the library's Manage access → Sharing links view, or run:

Connect-PnPOnline -Url https://contoso.sharepoint.com/sites/Finance -Interactive
Get-PnPFileSharingLink -Identity "/sites/Finance/Shared Documents/Board" 
Get-PnPFolderSharingLink -Folder "Shared Documents/Board"

Walk subfolders. Sharing links on children survive removal on the parent.

Site-level membership. Site settings → Site permissions → check every group, including the default Members and Visitors, for external accounts. Guests added to the site's Microsoft 365 group are members of the whole Team, not just the folder.

Tenant-wide reports. SharePoint admin center → Reports → Data access governance lists sites by volume of sharing links and external sharing activity, and the Content shared with Everyone except external users report covers over-broad internal sharing. If you have SharePoint Advanced Management, the sharing links report by site is the fastest way to see the whole surface. See SharePoint Advanced Management for what that licence adds here.

Copies elsewhere. If the recipient was a guest, they may have synced the folder or copied files to their own OneDrive. The audit log tells you (FileDownloaded, FileSyncDownloadedFull); you cannot retrieve those copies, but you need to know for the reporting decision.

Step 3: establish what was actually accessed

The Unified Audit Log is where the incident becomes a set of facts. Search on the site URL for the window from link creation to now, and pull:

• SharingSet, AnonymousLinkCreated, SecureLinkCreated, SharingInvitationCreated, AddedToSecureLink — the creation events. These give you who shared, when, and to whom.
• AnonymousLinkUsed, SecureLinkUsed — whether the link was ever opened, from which IP.
• FileAccessed, FilePreviewed, FileDownloaded, FileSyncDownloadedFull — what was opened or taken, by which account (external accounts appear with their #EXT# UPN; anonymous access shows as urn:spo:anon#...).

Export to CSV. The question your leadership and possibly your regulator will ask is not "was it shared?" but "was it opened, and what was in it?" A link created and never used is a near-miss. A link used from an unknown IP to download 400 files is a breach.

Audit log retention is 180 days by default in the current Purview audit offering (longer with Audit Premium), so the trail is there for anything recent. If the share is older than your retention, the honest answer is that you will not know what was accessed.

Step 4: remove the remaining access

Now remove everything found in step 2:

• Delete or expire the sharing links on every item.
• Remove the external account from any site groups and from the Microsoft 365 group.
• If the guest has no legitimate reason to be in the tenant at all, delete the guest object in Entra ID (which invalidates their tokens) — but check what else they are a member of first. Deleting a guest who is also a legitimate partner on another project turns one incident into two.
• If content was synced or downloaded, there is no technical remedy. For a known partner, a written request to delete is the normal step and it goes in the record.

Step 5: decide whether it must be reported

This is not an IT decision, and the runbook's job is to give the people who decide the facts they need in one page: what was exposed (with sensitivity labels, if you use them, noted per file), to whom, for how long, whether it was accessed, and what was done. Under GDPR-style regimes the clock for a personal-data breach notification starts from awareness, so hand the facts over the same day.

If the data carried a sensitivity label with encryption, the story is different — an external recipient without rights cannot open the file even with the link, and the exposure is of the file's existence, not its contents. This is the strongest argument for labelling the content that would hurt.

What to fix so it does not recur

The pattern behind almost every accidental exposure is a default that was too permissive for the site in question. Sensible corrections, in order of impact:

• Default link type at the tenant and site level: People with existing access or Specific people, never Anyone as a default. Users can still choose Anyone where it is allowed; they just have to mean it.
• Anyone link expiry (tenant-wide setting) so forgotten links die on their own.
• Per-site external sharing set to Only people in your organisation on sites holding sensitive content. This is a site property, and you can enforce it through a sensitivity label on the site.
• Domain allow or block lists for guest invitations if you work with a fixed set of partners.
• An alert policy on external sharing from designated sites, or the Defender for Cloud Apps file policy equivalent, so the next one is caught in minutes.
• A quarterly pass over the Data access governance reports, with the site owners in the room.

None of this requires Microsoft support. It does require that someone owns SharePoint sharing settings as a control, rather than as whatever the tenant was set to on day one.