How to Remove Inheritance from a SharePoint File
Breaking inheritance is sometimes necessary — but it’s the equivalent of opening the bonnet on your permission model. Do it carefully, document why, and use it sparingly.
What it is
By default, a file or library in SharePoint inherits its permissions from the parent site or library. Breaking inheritance means cutting that connection — making the item’s permissions independent. From that point, changes at the parent level no longer affect the item; you have to manage its permissions directly.
There are legitimate reasons to do this: a single sensitive file in an otherwise open library, a library that needs to be visible to a different group than the rest of the site, a project area that needs cross-team access. In each case, breaking inheritance is the right answer.
The risk is creating chaos. Each break is a permission island that has to be managed separately. A site with dozens of broken-inheritance items becomes nearly impossible to audit, and changes that should propagate naturally end up forgotten in disconnected corners.
The maintenance cost of breaking inheritance
Breaking inheritance is easy. Maintaining the resulting permission islands is expensive. Each unique-permissioned item needs its own audit, its own membership management, its own change process. Multiply that across a site with 50 broken items and you’ve created a permissions full-time job. Use unique permissions only when the alternative is genuinely worse.
When to use this
- When a single document or folder needs different access from the rest of the library.
- When a sensitive file lives within a more open site.
- When a sub-area of a site genuinely serves a different audience.
- Almost never for individual files.
How to do it
- Open the file or library.
- Go to permissions settings (Manage access > Advanced, or library settings > Permissions).
- Click Stop inheriting permissions.
- Confirm.
- Adjust permissions for the item independently.
- Document the reason for the break — for future maintainers.
Best practices
- Use the parent site’s permissions before breaking inheritance. If the existing permissions can be made to work, leave inheritance alone.
- Break at the library level, not file level. Library-level uniqueness is manageable; file-level isn’t.
- Document every break. ‘This library has unique permissions because…’ belongs in the site’s documentation.
- Audit broken-inheritance items separately. They don’t show up in normal site permission reviews.
Common mistakes
- Breaking inheritance for one-off file access. Just share the file directly; don’t permanently change the permission model.
- Breaking inheritance and forgetting about it. Now you have a permissions island nobody knows about.
- Breaking inheritance casually. It feels like a small action; the long-term cost is significant.
The Copilot Readiness Guide gives you the 25-question scorecard, the 4-category risk audit, and the 30-day plan to fix permissions, content quality, and sensitive content before go-live.
Get the Copilot Readiness Guide — $39 →FAQ
How do I break permission inheritance in SharePoint?
Open the file, folder, or library’s permission settings (Settings → Permissions). Click Stop inheriting permissions. SharePoint copies the current inherited permissions as a starting point. From that point, the item has independent permissions you can modify without affecting (or being affected by) the parent.
Should I break inheritance to restrict a SharePoint folder?
Sometimes yes, but consider the alternatives first. Separate library is usually cleaner — restricted content in its own library with independent permissions is more auditable than broken inheritance buried in a folder. Broken inheritance is a tool, not a default; reach for it only when separate libraries genuinely won’t work.
How do I restore inheritance after breaking it in SharePoint?
Open the item’s permission settings. Click Delete unique permissions. SharePoint warns that this discards the independent permissions and re-inherits from the parent. Anyone who only had access via the unique permissions will lose access. Test in a staging library first if the change is large-scale.
Why is broken inheritance a Copilot risk?
Because broken inheritance creates ‘invisible’ access that’s hard to audit. A folder might appear restricted in the library’s main view but actually be wide open via inherited group access elsewhere. Copilot honours the actual permissions exactly — including ones you’ve forgotten you set. Audit broken inheritance before turning Copilot on.