What is broken inheritance?
Also known as
Definition
By default, everything inside a SharePoint site follows the same permissions as its parent. When you give someone access to a site, they automatically get access to everything underneath it: libraries, folders, files. That's inheritance, and it's why permissions in SharePoint are manageable at scale instead of a thousand individual settings.
Broken inheritance is what happens when that chain stops. An item gets pulled out and starts with a copy of its parent's permissions, then someone edits that copy independently.
Example: Someone shares a single folder with outside consultants, which breaks inheritance automatically. That item now manages its own permissions, separate from whatever happens to the parent next.
Why it matters
One broken inheritance is fine. A hundred of them means nobody knows who has access to what anymore. Each one probably made sense at the time, but add them up over a few years and you end up with a permissions model nobody can actually explain.
- Migration: Unique permissions don't move the same way inherited ones do. Each item with broken inheritance needs its own check during a migration — what's there, whether it should carry over, and whether the destination is set up to receive it.
- Governance & security: Too many exceptions make access reviews difficult. Nobody can tell you why a folder has the access it has or whether it still should. That's also the kind of gap Copilot can turn into an oversharing risk.
- Day-to-day operations: Permissions inheritance problems are one of the most common issues IT teams run into, and broken inheritance is usually the reason behind them.
Commonly confused with: Unique permissions
Breaking inheritance is the action. Unique permissions are the result: the specific access settings that now apply at that level instead of the parent's. They're closely linked but not interchangeable. You can have unique permissions without ever having broken inheritance yourself, if you inherited the break from something further up the chain.
What we see out there
Nobody remembers who to ask.
Broken inheritance rarely comes with documentation. By the time someone finds it, the person who created it has usually moved on and the original reason is long gone.
Unique permissions found by accident.
Most organizations don't know where unique permissions exist until something forces them to look: a migration, an audit, or a Copilot rollout.
Frequently asked questions
Is broken inheritance bad?
Not on its own. Breaking inheritance to lock down a sensitive folder inside an otherwise open site is a normal, deliberate move. It becomes a problem at scale: when there are so many unique permissions that nobody can audit them, explain them, or confirm they're still needed.
When should unique permissions be used?
Unique permissions should be used sparingly and for a specific reason. Typically sensitive content that needs tighter access than the rest of the site. If you're assigning unique permissions to a lot of content, it's a sign the site structure itself might need rethinking.
How do I find where broken inheritance exists?
Manually, you'd need to check permission settings at every level of every site, which isn’t realistic past a handful of sites. ShareGate Protect can identify which sites or site collections have broken inheritance somewhere within them, so you know where to start looking instead of checking everything blind. If you’re migrating with ShareGate Migrate, you can also restore inheritance directly on sites, lists, libraries, folders, or documents.
What happens to broken inheritance during a migration?
If the source item has broken inheritance, the destination needs the same custom permissions or broken inheritance configured, or the item will inherit the destination's permissions instead, which usually isn't what you want. This is exactly the kind of detail that gets missed without a deliberate permissions plan going into the move.
