SharePoint permissions rarely fail dramatically. They decay. Someone needs urgent access on a Thursday, inheritance gets broken to grant it, nobody documents why, and the exception outlives the reason. Repeat for three years across a growing business and you arrive at a tenant nobody can confidently describe.
Grant to groups, never to people
This is the single rule that prevents most permission problems. Access should follow the role, not the individual. When someone joins, changes team or leaves, you update group membership in one place rather than hunting through sites.
- Create groups that mirror how the business is actually organised, not the org chart as drawn
- Grant site and library access to those groups only
- Resist granting to an individual even once, because the first exception sets the pattern
- Where a genuine one-off is unavoidable, document it and set a review date
Keep inheritance intact
Breaking inheritance on a library or folder feels like a small local decision. It is not. Every broken inheritance point is somewhere permissions must be managed separately forever, and the total quickly exceeds what anyone can hold in their head.
A new site beats a broken folder
Before breaking inheritance, ask whether a separate site would be cleaner. A dedicated site with its own permissions is far easier to reason about than a deep folder with bespoke access inside a shared library.
Name an owner for every site
Unowned sites decay fastest. Every site needs a named business owner who is accountable for who has access, not just an IT administrator who technically can change it. IT should be executing decisions, not making them about content it does not understand.
The joiner, mover, leaver problem
| Event | Handled well | Handled badly |
|---|---|---|
| Joiner | Added to role groups, gets correct access automatically | Access copied from a colleague, inheriting their exceptions |
| Mover | Removed from old groups, added to new | Added to new groups, keeps the old ones |
| Leaver | Removed from all groups in one action | Account disabled but group memberships remain |
The mover case causes more sprawl than the leaver case, and it gets almost no attention. Someone who has moved between three departments in five years accumulates all three access sets unless somebody actively removes the old ones.
Review on a schedule, not on suspicion
- 1Quarterly or twice-yearly, depending on how fast your business changes
- 2Site owners confirm or revoke access for their own site, since IT cannot judge business need
- 3Report on broken inheritance points and ask whether each is still justified
- 4Flag sites with no owner, no activity, or external guests still holding access
- 5Record the outcome, because a review nobody documented did not happen
Permissions already sprawling?
We audit SharePoint access, rebuild it around groups and inheritance, and set up the review cycle that stops it happening again.
SharePoint consulting in DubaiIdentity and access management
