Permissions are where most SharePoint implementations quietly start to fall apart, not because SharePoint permissions are broken, but because we keep asking them to solve problems they were never designed to handle.

Permissions control access, while governance defines behavior. Confusing the two is how environments become difficult to manage, difficult to explain, and eventually difficult to trust.

I have seen tenants with thousands of broken permission inheritance chains, dozens of SharePoint groups, and a steady stream of “can you just give this person access” tickets. On paper, everything looked secure. In reality, no one could confidently explain who had access to what or why.

That is not governance. That is anxiety disguised as control.

Permissions feel productive because they are visible. You can click them, tweak them, deny something, and feel like progress was made. Governance is harder. It requires decisions about ownership, intent, and lifecycle, and it rarely gives immediate relief.

So organizations lean on permissions instead.

Modern SharePoint actually tries to push us away from this instinct. Microsoft’s guidance on sharing and permissions in the modern experience emphasizes simplicity, group-based access, and avoiding unnecessary complexity. The platform has learned from its own history, even if many tenants have not.

Old habits, however, die hard. Anyone who lived through classic SharePoint remembers the era of custom permission levels. Contribute but not delete. Edit but not really edit. Entire security models built on one-off permission levels that only one person understood, until they left.

Those setups were fragile then, and they are even more dangerous now.

The moment this became painfully obvious for many organizations was the introduction of Delve. Delve did not invent new access. It simply surfaced documents users already had permission to see. When it launched, people panicked.

Admins scrambled, users blamed SharePoint, and the tool took the heat. What Delve actually did was expose years of poor permission decisions that had been hidden behind sites, folders, and navigation most people never browsed. In other words, it did not break security. It revealed it.

Delve is now retired, as Microsoft explains in the Delve retirement notice, but the problem it exposed never went away. If anything, it has become more visible.

Poor permissioning is now amplified by Copilot. Copilot surfaces content users technically have access to, whether or not anyone remembers granting it. If Delve made people uncomfortable, Copilot is going to make them nervous.

The same patterns still show up today when permissions are pushed too far down the hierarchy. Item-level permissions, folder-level permissions, and broken inheritance everywhere. Microsoft documents the risks clearly when explaining how to manage permission scope, but many environments continue to ignore the guidance.

The more granular permissions become, the harder they are to reason about, audit, and maintain. Every exception adds cognitive load, and every broken inheritance becomes technical debt.

I have also seen the opposite extreme, where everything is wide open in the name of collaboration with the promise that it will be cleaned up later. Later rarely comes, and open access without guardrails is just chaos with good intentions.

The goal is not to lock everything down or open everything up. The goal is clarity.

Good governance starts earlier and higher up the stack. It defines where content belongs, who owns it, how access is granted, and what happens when people leave or projects end.

When those decisions are clear, permissions stop being dramatic. They become predictable. Fewer custom groups. Fewer exceptions. Less reliance on hero admins to clean things up at the last minute.

Permissions should support governance, not replace it.

If your governance strategy is a long list of permission rules, you do not have a governance strategy. You have a maintenance problem.

---

This post is part of my 25 days of SharePoint series, created to celebrate SharePoint’s 25th anniversary and lead up to the SharePoint at 25 digital event on March 2.

Each post reflects on what actually made SharePoint last 25 years, the wins, the mistakes, and the lessons learned from building, breaking, and rebuilding it in real organizations.

You can find all posts in this series here.

If there’s a topic you think I should cover next, a SharePoint mistake you keep seeing, or a question no one ever answers straight, leave a comment. This series is shaped by real experiences, not marketing slides.