Every site, library, list, and item in SharePoint inherits its permissions from its parent by default — that’s what keeps permission management manageable. Breaking that inheritance lets you set unique permissions at a specific level instead, for the cases where “everyone who can see the parent can see this too” isn’t the right answer. For the broader permissions picture, see SharePoint Permissions: A Comprehensive Guide — this post is specifically about the break/restore mechanics.
In this post: Where you can break it · The real tradeoff · Breaking inheritance with PowerShell · Restoring inheritance · Best practices · When would you actually use this? · Related reading
Where you can break it
- Site level: the broadest break — common for a sub-site holding department-restricted content (an HR sub-site, say) that shouldn’t inherit the parent site’s broader membership.
- Library or list level: for a specific collection of content that needs its own audience — a salary-tracking list, a not-yet-announced campaign’s asset library — without restructuring the whole site.
- Item level: the most granular option, restricting a single file or list item — an individual performance review, a specific contract — to just the people who need it.
The real tradeoff
Breaking inheritance gets you real, specific access control — exactly who can see or edit a given piece of content, independent of the parent. It costs you three things in return, and they’re the actual reasons to default to inherited permissions unless there’s a specific need not to: management overhead (every unique-permission scope is one more thing that has to be tracked, documented, and eventually re-reviewed — nothing does this for you automatically), performance (a library or list with thousands of items carrying individual unique permissions genuinely slows down, since SharePoint has to evaluate access per-item rather than checking one shared rule), and human error (a manually-configured unique permission is exactly the kind of thing that quietly grants the wrong person access and goes unnoticed until an audit finds it). None of these mean “don’t break inheritance” — they mean don’t do it as a default habit when a SharePoint group at the parent level would solve the same problem.
Breaking inheritance with PowerShell
For a document library:
Connect-PnPOnline -Url "https://yourtenant.sharepoint.com/sites/yoursite" -UseWebLogin
$library = Get-PnPList -Identity "Library Name"
# Break inheritance, keeping a copy of the parent's current permissions as the starting point
Set-PnPList -Identity $library -BreakRoleInheritance:$true -CopyRoleAssignments:$true
Write-Host "Permission inheritance broken for the document library."For a single list item:
$list = Get-PnPList -Identity "List Name"
$item = Get-PnPListItem -List $list -Id 1
$item.BreakRoleInheritance($true, $true)
$roleDefinition = Get-PnPRoleDefinition -Identity "Contribute"
$user = Get-PnPUser -Identity "user@yourdomain.com"
$item.RoleAssignments.Add($user.LoginName, $roleDefinition)
$item.Update()
Write-Host "Unique permissions applied to the list item."Restoring inheritance
Just as commonly needed and often missed: undoing a break once the reason for it no longer applies (a project wrapped up, a temporary restriction is no longer needed). This discards the unique permissions and goes back to inheriting from the parent:
$library = Get-PnPList -Identity "Library Name"
if ($library.HasUniqueRoleAssignments) {
Set-PnPList -Identity $library -ResetRoleInheritance
Write-Host "Inheritance restored -- unique permissions removed."
} else {
Write-Host "This list already inherits permissions from its parent."
}Checking HasUniqueRoleAssignments first avoids an unnecessary call on something that was never broken in the first place — useful when running this across a batch of lists rather than one you already know the state of.
A library or list with thousands of items carrying individual unique permissions genuinely slows down — SharePoint has to evaluate access per-item instead of checking one shared rule.
Best practices
- Document why, not just where — the break itself is easy to find later; the reason it was necessary usually isn’t, unless someone wrote it down.
- Assign to SharePoint groups, not individual users — even in a broken-inheritance scope, group-based assignment scales; per-user assignment doesn’t.
- Review periodically — a break made for a since-completed project is exactly the kind of thing that outlives its reason and never gets cleaned up.
- Avoid item-level breaks at scale — one or two exceptions are fine; hundreds of individually-permissioned items in the same list is a sign the content should be split into a separate, properly-scoped library instead.
When would you actually use this?
- A confidential project (an unannounced product launch, an active legal matter) needs a library visible only to the people directly working on it, not the whole parent site’s membership.
- HR content — salaries, contracts, performance reviews — needs to stay restricted regardless of who else has access to the surrounding site.
- An external partner or auditor needs access to one specific document or library, without being added to the parent site at all.
Related reading
- All About SharePoint Permission Roles — what each of the ten built-in permission levels actually grants, useful once you’re deciding what to assign after breaking inheritance.
- SharePoint Permissions: A Comprehensive Guide — the fuller picture beyond just the break/restore mechanics covered here.
That covers breaking it and undoing it. Got a script or scenario worth adding? Drop it in the comments.