By default, everything in SharePoint inherits its permissions from the container above it. Break that link on a single item and it stops listening to its parent: from then on it carries its own unique permissions, and changes made upstream no longer reach it. Broken inheritance isn't an exposure in itself — it's a governance signal, and one worth being able to see.
How inheritance normally works
Files inherit from folders, folders from libraries, libraries from the site. One grant near the top flows down to everything beneath it, and one cleanup near the top removes access from everything beneath it. That predictability is the whole point: you reason about access at the container level and trust it to cascade.
What breaking it does
The moment someone grants or removes access on a single item in a way that differs from its parent, SharePoint "breaks inheritance" on that item and gives it unique permissions. From then on:
- The item keeps its own access list. Upstream changes stop touching it — it answers only to itself.
- Cleanups can skip it. Remove a guest from the parent folder and a broken-off child that was separately granted keeps its own copy of the access.
- It's invisible unless you look. Nothing on the item announces "I stopped inheriting" — you have to inspect the permission topology to know.
Worth saying plainly: broken inheritance can be entirely legitimate — a deliberately restricted subfolder, a single file shared more widely than its neighbours. It is a fact about structure, not a verdict.
Why it matters for an audit
Broken inheritance is where stale access hides. When you fix a problem at the parent and assume it cascaded, the items with unique permissions are exactly the ones that didn't get the fix. Knowing where inheritance is broken tells you where "I already removed that" might not be true — and it's often the reason a guest still reaches something you thought you'd cleaned up. The exposure itself, when there is one, shows up as inherited guest access; broken inheritance is the structural fact underneath it.
How TRACER365 flags it
TRACER365 emits broken inheritance as its own finding type at INFO severity. INFO is deliberate: it's a governance flag, not a security finding. It doesn't assert that anything is over-shared — it tells you where the permission topology diverges from its parent, so the items that won't respond to an upstream cleanup are visible instead of assumed. The flag resolves on its own when inheritance is re-established, and that resolution is recorded in the finding's history.
Because it's INFO, it sits below the severity-ranked external findings — context for the ones that matter, not a klaxon. But when you're working out why access lingers after a cleanup, "this item has unique permissions" is frequently the answer.
What to do about it
- Treat it as a map, not an alarm: broken inheritance shows where item-level review is needed because container-level review won't reach.
- When you remediate a parent grant, check the broken-off children separately — they kept their own copy.
- Re-scan after changes — re-established inheritance clears the flag, so the list reflects your current structure rather than a past one.