Knowing who's sharing what with whom is one of the fundamental requirements of Teams governance. It's also, frankly, one of the harder things to do well. External sharing in Teams can happen through guest access, through file sharing in SharePoint (which underlies Teams file storage), through screen sharing in meetings, or through external access federation. Each mechanism leaves a different footprint in the audit logs.
This article covers how to find and interpret the key audit events that indicate external sharing activity, and how to build a regular external sharing review into your governance routine.
Where the Audit Logs Live
Microsoft 365 audit logs are centralised in the Microsoft Purview compliance portal under Audit > Search. You can also query them via PowerShell using the Search-UnifiedAuditLog cmdlet, which is better for bulk queries and automated reporting.
The audit log captures events from across Microsoft 365 services, including Teams, SharePoint, and Entra ID. For external sharing purposes, the most relevant event sources are:
- SharePoint and OneDrive: File sharing events, permission changes, guest user activity on shared files
- Microsoft Teams: Guest addition events, external message events, meeting participant events
- Azure Active Directory: Guest account creation and deletion, B2B invitation events
- Teams membership changes: Member added or removed, including guests, captured as directory and Teams audit events rather than as SharePoint sharing events.
- Cross-tenant access changes: Updates to partner settings that widen or narrow B2B direct connect, which will not appear in a file-sharing query at all.
Key Audit Events for External Sharing
Guest user added to team. The Teams audit event TeamCreated and MemberAdded capture when a new member is added to a team. Filter for guest user additions by looking for MemberAdded events where the added user has a #EXT# suffix in their UPN (the standard format for guest accounts in Entra ID: user_externaldomain.com#EXT#@yourtenant.onmicrosoft.com).
File shared with external user. SharePoint audit events capture file sharing. The SharingInvitationCreated event fires when a sharing invitation is sent to an external user; AnonymousLinkCreated fires when an anonymous sharing link is created. Filter for events where the TargetUserOrGroupType is "Guest" or "External."
External user accessed a file. The FileAccessed SharePoint event, filtered for guest user activity, shows which files external users have accessed and when. This is useful for post-incident investigation ("did the departed guest access the sensitive project folder?") and for general external activity monitoring.
Meeting with external attendees. Teams meeting events capture attendance, but distinguishing external attendees from internal ones requires filtering by UPN suffix or user type. The MeetingParticipantDetail event (available through the Teams Admin Center's meeting reports, rather than the unified audit log) provides per-meeting attendance details including whether attendees were internal, guests, or anonymous.
Querying the Audit Log with PowerShell
For regular external sharing audits, PowerShell queries against the unified audit log are more efficient than the Purview UI search. A few useful examples:
# Find all guest user additions to Teams in the last 30 days
$results = Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) `
-RecordType MicrosoftTeams -Operations "MemberAdded"
$results | Where-Object { $_.AuditData -like '*#EXT#*' } | Select-Object -ExpandProperty AuditData | ConvertFrom-Json# Find external file sharing events in the last 30 days
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) `
-RecordType SharePoint -Operations "SharingInvitationCreated","AnonymousLinkCreated" `
-ResultSize 5000Building a Regular External Sharing Review
An external sharing review should be a standard part of your Teams governance cadence — monthly or quarterly depending on your organisation's risk tolerance and the volume of external collaboration.
A practical monthly review includes:
- New guest accounts added in the past month: verify each addition was intentional and follows your guest access policy
- Guest accounts with no activity in 90+ days: flag for review by team owners, with removal for accounts that can't be justified
- Anonymous sharing links created in the past month: ensure these are appropriate (some organisations prohibit anonymous links entirely)
- Files shared externally from high-sensitivity teams: review whether the sharing was authorised and consistent with the team's sensitivity classification
Automated Alerts for External Sharing Events
Rather than relying solely on periodic manual audits, consider setting up alert policies in the Microsoft Purview compliance portal for high-risk external sharing events. For example: an alert when an anonymous sharing link is created from a site associated with a "Confidential" sensitivity label, or when a guest is added to a team that's been classified as a restricted workspace.
Alert policies are configured under Microsoft Purview > Policies > Alert policies. They can send email notifications to specific recipients when matching events are logged, enabling near-real-time awareness of potential policy violations without requiring constant manual log review.
An Alert That Fires So Often It Is Ignored
An external-sharing alert is only as good as its threshold. Microsoft Teams and SharePoint can emit a large volume of sharing and membership events in a tenant that collaborates on purpose. An alert on every guest add will train the mailbox owner to delete the mail. An alert that never fires will be praised in a slide and will miss the one share that mattered.
A university IT group with 8,000 accounts set an alert for any anonymous link created on a site labelled internal. The first week produced a manageable handful, because the label was only on a subset of sites and anonymous links were already discouraged. A second alert, copied from a template, fired on every guest invitation in the whole tenant. Student-project teams invite guests constantly. The second alert was muted within days, and the muted state was never written down. Six weeks later a bulk invitation of personal mail addresses into a staff team produced events that nobody saw.
Design alerts around the exception, not around the permitted path. If guest add is allowed for owners, alert when a guest is added to a team with a label that forbids guests, or when one actor adds more than a set number of guests in an hour. If anonymous links are forbidden on labelled sites, alert on that link type and that label, not on every share. Test the alert with a deliberate action and confirm the mail arrives in a mailbox that is staffed.
The audit log retention window is part of the review design. A monthly review that starts after the log has rolled off is a review of nothing. Know how far back the licence keeps audit data, and pull the export on a schedule inside that window. PowerShell searches that "worked last year" fail quietly when the date range is older than the retention of the log.
Keep a small set of saved queries: guests added in the last 30 days, anonymous links on labelled sites, and forwarding or sharing of the team's SharePoint site to a new external domain. Three queries that someone runs are worth more than a catalogue of thirty that nobody opens. Attach the result, even an empty result, to the review note so the empty month is visible.
Name the person who triages the alert and the person who covers their leave. An alert to a shared mailbox still needs a rota. Suppress known automation. A flow that invites a partner every Monday will dominate the alert unless its app id is excluded and reviewed on its own. Distinguish a guest add from an external share link. They are different events and different responses. If the alert destination is email, check that mail is not itself filtered into a folder nobody expands. Record muted or disabled alerts as findings. A disabled alert is a control that has been switched off. Rehearse one alert each quarter by performing the action in a test team. A query that has not been proven will fail during the week you need it. An empty result is still a result. File it, or the next month will look like the review was skipped. Thresholds belong in the alert description. A future analyst should not have to guess why this alert is quieter than the log. Test alerts during working hours so the person who should receive them is there to confirm. Guest adds by an app and guest adds by a person should be separate alerts if the volumes differ by an order of magnitude. The audit log search that backs the monthly review should be saved, not reconstructed from a screenshot of the filter pane. If the licence shortens audit retention, the review frequency has to shorten with it. A sharing event on a site that backs a team is still a Teams issue for the owner of that team. Route it to them. Mute rules need an expiry. A mute without an expiry is how the important alert stays silent. Compare the alert count to the raw event count once. A large gap means the filter is wrong or the mail is dropping. Document the test team used for drills so production alerts are not confused with the drill. New labels should be added to the alert filter in the same change as the label, or the first weeks are unwatched. Keep the KQL or the portal filter text in the runbook. A review that depends on clicking through the same blades from memory will miss a checkbox.
