SharePoint Security Incident Response Playbook for 2026

Why SharePoint Needs Its Own Incident Playbook

When a security incident happens in SharePoint, the first 60 minutes determine the outcome. Incidents that are contained quickly limit the data exposure, reduce the forensic effort, and support the legal and regulatory obligations that follow. Incidents that are contained slowly become data breaches with significant legal, financial, and reputational cost.

Most enterprises have a general cybersecurity incident response plan. Few have a SharePoint-specific playbook that captures the tenant-level controls, the audit log queries, the containment commands, and the coordination points that make SharePoint incidents actually response-ready. This gap shows up in real incidents as confusion about who has what permissions, uncertainty about which audit logs capture the relevant events, and slow containment because the team is learning the commands under pressure.

This playbook provides the SharePoint-specific runbook. It covers detection, the containment actions for the most common incident types, the forensic queries that matter, and the recovery procedures. The target is a response framework that limits incident impact to the first 2 hours of detection for most scenarios.

The Common Incident Categories

SharePoint security incidents fall into six common categories, and each has specific response patterns.

• Data exfiltration through external sharing: An insider or compromised account shares sensitive content externally using anyone links or guest invitations.
• Ransomware infection: Malware encrypts SharePoint-stored files through a user's OneDrive sync client or direct SharePoint API access.
• Compromised privileged account: An administrator account is compromised and used to exfiltrate content, modify permissions, or deploy malicious extensions.
• Insider data theft: An employee downloads large volumes of content with intent to take it to a competitor or publish it externally.
• Business email compromise (BEC) escalation: A compromised user account is used to access SharePoint resources and perpetrate financial fraud.
• Misconfigured external sharing: A configuration change unintentionally exposes content to external users or makes it publicly accessible.

Each of these incident types has common detection signals and specific containment patterns.

Detection

Detection is where most organizations fall short. SharePoint generates extensive audit data, but translating that data into actionable detections requires deliberate investment.

Primary Detection Sources

Four detection sources feed incident identification.

• Microsoft Defender for Cloud Apps (MDCA): Primary cloud security monitoring. Detects anomalous activity, mass downloads, suspicious sharing, and integration with threat intelligence.
• Microsoft Purview Data Loss Prevention: Detects policy violations including sensitive content sharing externally.
• Microsoft 365 Unified Audit Log: Source of truth for all SharePoint, OneDrive, and Teams activity. Queryable via the compliance portal and PowerShell.
• Microsoft Sentinel (SIEM): Correlates signals across identity, endpoint, and cloud for higher-fidelity detections.

High-Value Detection Rules

The rules that consistently surface real incidents:

• User downloads more than 100 files from SharePoint in under 10 minutes
• User creates more than 20 external sharing links in under 1 hour
• User accesses SharePoint from a new country not in baseline
• Privileged account authenticates from a device not previously seen
• Mass permission change (100+ items) by a single user in a short window
• File rename or deletion burst consistent with ransomware behavior

These detections should fire as alerts to the security operations team with defined response times (typically within 15 minutes for high severity).

Containment Runbooks

Containment actions should be scripted and runbook-ready. Five core containment scenarios.

Containment 1: Disable a Compromised User

Disable the user's Azure AD account, revoke all sessions, and block sign-in.

```powershell

# Connect to Microsoft Graph with required scopes

Connect-MgGraph -Scopes "User.ReadWrite.All", "Directory.ReadWrite.All"

$upn = "[email protected]"

# Disable the user

Update-MgUser -UserId $upn -AccountEnabled:$false

# Revoke all sessions to force re-authentication

Revoke-MgUserSignInSession -UserId $upn

# Additional step: reset the password

$newPassword = "ComplexTempPassword-" + (Get-Random -Maximum 999999)

$passwordProfile = @{

Password = $newPassword

ForceChangePasswordNextSignIn = $true

}

Update-MgUser -UserId $upn -PasswordProfile $passwordProfile

```

Containment 2: Remove External Sharing Links

Identify and remove external sharing links created by a compromised account.

```powershell

# Connect to SharePoint Online PnP module

Connect-PnPOnline -Url "https://contoso-admin.sharepoint.com" -Interactive

# Get all sharing links created by the compromised user in a site

$siteUrl = "https://contoso.sharepoint.com/sites/suspected"

$compromisedUser = "[email protected]"

Connect-PnPOnline -Url $siteUrl -Interactive

$items = Get-PnPListItem -List "Documents" -PageSize 2000

foreach ($item in $items) {

$sharingInfo = Get-PnPFileSharingLink -Identity $item.FieldValues["FileRef"] -ErrorAction SilentlyContinue

foreach ($link in $sharingInfo) {

if ($link.CreatedBy -like "*$compromisedUser*") {

Remove-PnPFileSharingLink -Identity $item.FieldValues["FileRef"] -LinkId $link.Id -Force

}

}

}

```

Containment 3: Disable External Sharing Tenant-Wide

In severe incidents, disable external sharing entirely until the situation is controlled.

```powershell

# Capture current settings for restoration later

Connect-SPOService -Url "https://contoso-admin.sharepoint.com"

$currentSharingCapability = (Get-SPOTenant).SharingCapability

# Disable external sharing tenant-wide

Set-SPOTenant -SharingCapability Disabled

# Document the change and who authorized it

"Disabled external sharing at $(Get-Date -Format 'yyyy-MM-dd HH:mm:ss') due to incident INC12345. Previous setting: $currentSharingCapability" |

Out-File -FilePath "D:\IncidentResponse\INC12345_actions.log" -Append

```

Containment 4: Lock a SharePoint Site

Lock a specific site to prevent further changes during investigation.

```powershell

# Set site to read-only

Connect-SPOService -Url "https://contoso-admin.sharepoint.com"

$siteUrl = "https://contoso.sharepoint.com/sites/affected"

# ReadOnly prevents modifications but allows read access

Set-SPOSite -Identity $siteUrl -LockState ReadOnly

# NoAccess prevents all access

# Set-SPOSite -Identity $siteUrl -LockState NoAccess

# Document the lock

Get-SPOSite -Identity $siteUrl | Select-Object Url, LockState

```

Containment 5: Stop OneDrive Sync

Force a user's OneDrive sync client to stop syncing to prevent ongoing exfiltration or ransomware spread.

```powershell

# Disable OneDrive sync for the user

$upn = "[email protected]"

Connect-PnPOnline -Url "https://contoso-admin.sharepoint.com" -Interactive

# Block the user's sync sessions

# Note: OneDrive sync session management typically flows through Conditional Access

# and Intune. The specific PowerShell commands depend on tenant configuration.

# For immediate containment, revoking Azure AD sessions (Containment 1) also

# terminates active OneDrive sync sessions.

Revoke-MgUserSignInSession -UserId $upn

```

Forensic Queries

Once the incident is contained, forensics establish what happened.

Query 1: All Activity by a Specific User

```powershell

Connect-IPPSSession

# Retrieve all activity for the user in the suspected window

$userUpn = "[email protected]"

$startDate = (Get-Date).AddDays(-7)

$endDate = Get-Date

$activity = Search-UnifiedAuditLog -StartDate $startDate -EndDate $endDate -UserIds $userUpn -ResultSize 5000

$activity | Select-Object CreationDate, Operations, ObjectId, UserIds, @{N='AuditDetails';E={$_.AuditData | ConvertFrom-Json}} |

Export-Csv -Path "D:\Forensics\UserActivity_$userUpn.csv" -NoTypeInformation

```

Query 2: External Sharing Events Created in an Incident Window

```powershell

$incidentStart = (Get-Date "2026-04-15 09:00:00")

$incidentEnd = (Get-Date "2026-04-15 17:00:00")

Search-UnifiedAuditLog -StartDate $incidentStart -EndDate $incidentEnd -Operations "SharingSet","AnonymousLinkCreated","SecureLinkCreated","AddedToSecureLink" -ResultSize 5000 |

Select-Object CreationDate, UserIds, Operations, @{N='AuditDetails';E={$_.AuditData | ConvertFrom-Json}} |

Export-Csv -Path "D:\Forensics\ExternalSharing_INC12345.csv" -NoTypeInformation

```

Query 3: Mass File Downloads

```powershell

$incidentStart = (Get-Date).AddDays(-3)

$incidentEnd = Get-Date

Search-UnifiedAuditLog -StartDate $incidentStart -EndDate $incidentEnd -Operations "FileDownloaded" -ResultSize 5000 |

Group-Object UserIds | Where-Object { $_.Count -gt 50 } |

Sort-Object Count -Descending |

Select-Object Name, Count |

Export-Csv -Path "D:\Forensics\MassDownloads.csv" -NoTypeInformation

```

Query 4: Permission Changes

```powershell

Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) -Operations "AddedToGroup","RemovedFromGroup","GroupAdded","PermissionsAdded","PermissionsRemoved" -ResultSize 5000 |

Select-Object CreationDate, UserIds, Operations, ObjectId |

Export-Csv -Path "D:\Forensics\PermissionChanges.csv" -NoTypeInformation

```

Recovery

After containment and forensics, recovery restores the environment to a known-good state.

Ransomware Recovery

SharePoint Online has version history enabled by default, which lets administrators restore documents to pre-encryption versions. For widespread encryption, use the Restore this library feature in SharePoint admin or the OneDrive Restore feature for user-level recovery.

```powershell

# Restore a SharePoint library to a point in time

# (The UI workflow is typically preferred for ransomware recovery at scale)

# The admin center Restore feature is available at:

# https://contoso-admin.sharepoint.com/_layouts/15/online/AdminHome.aspx

# Programmatic restoration uses the SharePoint Restore API

Connect-PnPOnline -Url "https://contoso.sharepoint.com/sites/affected" -Interactive

# Get the list of files affected (example for a specific library)

$affectedFiles = Get-PnPListItem -List "Documents" -PageSize 2000 |

Where-Object { $_["Modified"] -gt (Get-Date "2026-04-15 09:00:00") -and $_["Modified"] -lt (Get-Date "2026-04-15 12:00:00") }

# For each affected file, roll back to the version before the incident

foreach ($item in $affectedFiles) {

$fileUrl = $item["FileRef"]

$versions = Get-PnPFileVersion -Url $fileUrl

$goodVersion = $versions | Where-Object { $_.Created -lt (Get-Date "2026-04-15 09:00:00") } | Select-Object -First 1

if ($goodVersion) {

Restore-PnPFileVersion -Url $fileUrl -Identity $goodVersion.Id -Force

}

}

```

External Sharing Rollback

After removing the incident-specific sharing links (Containment 2), review all sharing in the affected site to ensure nothing else was exposed. Reset the tenant sharing settings to pre-incident state when the investigation is complete.

User Account Recovery

Rehydrate the disabled user account only after confirming the incident is fully contained, the root cause is identified (phishing, malware, credential theft), and remediation is complete (device rebuild, credential reset, MFA reset, Conditional Access review).

Coordination and Communication

Technical response is one part of incident handling. The coordination and communication piece is equally important.

Incident Commander

Every incident has a designated incident commander (typically from the security operations team) with authority to make containment decisions. The incident commander maintains the incident log, coordinates across teams, and communicates with leadership.

Notification Chain

Define the notification chain in advance. For a P1 SharePoint incident, notify the CISO within 30 minutes, the CIO within 1 hour, and the legal and communications teams within 2 hours. Regulatory notifications follow the applicable regulatory timelines (72 hours for GDPR, variable for other regulations).

Post-Incident Review

Every incident, regardless of severity, gets a post-incident review within 5 business days. The review identifies the root cause, the containment effectiveness, and the improvements needed for the playbook, detections, and preventive controls.

Getting Started

A working SharePoint incident response capability requires the playbook, the detections, the containment scripts, and regular tabletop exercises to maintain response readiness. Our SharePoint security specialists build and test incident response capabilities for enterprises in regulated industries. Contact our team to scope an incident response engagement, or review our SharePoint consulting services for the full security methodology.