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.
Frequently asked questions
Why did our SharePoint permissions get so complicated?
Because exceptions accumulated and nobody reviewed them. Each individual grant and each broken inheritance point was reasonable at the time. Without a review cycle they persist indefinitely, and after a few years the total exceeds what anyone can describe.
Should we ever break permission inheritance?
Sparingly, and with documentation. Before breaking inheritance, ask whether a separate site would be cleaner. A dedicated site with its own permission set is much easier to reason about than a folder with bespoke access buried inside a shared library.
How often should we review access?
Quarterly for fast-changing businesses, twice yearly otherwise. Site owners should confirm or revoke access for their own sites, because IT cannot judge whether someone in finance still needs a particular contract folder.
What is the most commonly missed case?
The mover. Staff who change departments usually get added to new groups while keeping the old ones, so access accumulates silently. It attracts far less attention than the leaver case and causes more sprawl over time.
Can external clients have access safely?
Yes, if external sharing is enabled per site rather than tenant-wide, guests are limited to specific libraries, and links expire. We usually recommend a dedicated client-facing site so an internal document cannot be shared by accident.
Usman K.
· IT Support LeadIT support lead at Azizi Technologies. Manages 24/7 helpdesk, Microsoft 365 migrations, server administration, and managed IT contracts for Dubai SMBs. Microsoft Certified. Mentioned by name in client reviews for fast resolution.
Need a quote for SharePoint Consulting Dubai?
WhatsApp this article plus your device or site. We reply with next steps and a written quote.