A permissions state where a SharePoint site, list, or library no longer follows permissions from its parent object and instead uses unique role assignments. This can be necessary for exceptions, but it also increases administrative complexity and makes access reviews harder.
What Broken Inheritance Means in SharePoint Permissions
Broken inheritance is the point at which a SharePoint site, list, or library stops inheriting permissions from its parent and begins using unique role assignments. That creates an exception to the normal access model and should be treated as a deliberate change, not a default state.
Why Broken Inheritance Changes the Security Model
Inheritance keeps access predictable because a parent permission change flows to child objects. Once inheritance is broken, the child object becomes its own access boundary, which can be useful for exceptions but also makes it easier for access to drift away from the intended model.
That shift matters because a unique-permissions object no longer benefits from parent-level cleanup. Administrators must understand which items are exceptions, which users still need access, and where a later parent change will no longer reach.
Administrative and Governance Implications
Broken inheritance is often created to solve a real collaboration need, but each exception adds another place where ownership, review, and revocation must be tracked separately. The more often inheritance is broken, the more likely access reviews become slower, less complete, or dependent on tribal knowledge.
In practice, broken inheritance is less about a technical fault and more about governance discipline. A large number of uniquely secured sites, lists, or libraries can make it harder to prove who has access, why they have it, and whether that access still matches the business need.
Common Misunderstandings and Operational Consequences
A common mistake is to treat broken inheritance as harmless because it is a normal SharePoint feature. It is normal, but it is not neutral: every break creates a fork in the permissions model and a new place where unexpected access can persist.
Another misconception is that parent permissions can still be relied on for cleanup. Once inheritance is broken, revoking access at the parent does not necessarily remove access from the child object, so stale permissions can survive longer than expected.
Risk and Threat Considerations
Broken inheritance increases the chance of overexposure, especially when exceptions accumulate without regular review. The main security concern is not the feature itself, but the drift, stale access, and review blind spots it creates across nested content.
Failure mechanism: A child object with unique permissions stops receiving parent updates, so old role assignments, ad hoc exceptions, or delegated access can remain in place after the original need has passed.
Impact: Users may retain access to sensitive sites, documents, or lists longer than intended, and administrators may miss inherited-versus-unique permission differences during recertification or incident review.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Broken inheritance can preserve broader access than needed on child objects. |
| AC-2 — Account Management | Unique role assignments require ongoing ownership and cleanup as accounts change. | |
| Recommendation — Review unique permissions and remove excess access from broken-inheritance objects. Track ownership of uniquely secured SharePoint objects and revoke stale access promptly. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Broken inheritance is an access-control exception that must be governed consistently. |
| A.5.18 — Access rights | Permission changes on broken-inheritance objects need periodic review and removal of obsolete rights. | |
| Recommendation — Define when unique permissions are allowed and require approval for each exception. Recertify unique SharePoint permissions and remove rights that no longer match need. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Broken inheritance creates access exceptions that must be inventoried and reviewed. |
| Recommendation — Inventory unique-permission SharePoint objects and review them on a recurring schedule. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
