Understanding who can see what, and why it matters more than you think.
SharePoint is the backbone of document management for most organisations running Microsoft 365. It underpins every Teams channel, every shared document library, every intranet page. And at the heart of SharePoint sits a permissions model that is both powerful and, when mismanaged, genuinely dangerous.
The problem is not that SharePoint permissions are inherently complex. At the top level, they are straightforward: Owners manage the site, Members contribute content, Visitors read it. The problem is what happens over time. People share documents with individuals rather than groups. Permissions get broken at the folder level to accommodate a one-off request. External links are generated and never revoked. Somebody adds “Everyone except external users” to a sensitive library because it was the quickest way to resolve a support ticket.
After twelve months of this, your SharePoint environment does not have a permissions model. It has a permissions archaeology. Layers upon layers of ad-hoc decisions, each one reasonable in isolation, collectively forming a structure that nobody understands and nobody can audit. This guide is about preventing that outcome, or recovering from it if you are already there.
The three permission levels
Every SharePoint site is built around three default permission groups. These groups map to distinct roles within the organisation, and understanding the boundaries between them is the foundation of every good permission strategy. Most of the problems we see in client environments stem from a misunderstanding of what each level actually permits and, just as importantly, what it does not.
Owner
Owners have full control over a SharePoint site. They can change the site’s structure, modify its settings, manage navigation, apply branding, and, most critically, grant or revoke access for everyone else. In a well-governed environment, the Owner group should be extremely small. One or two people at most, typically the site creator and an IT administrator. When the Owner group expands beyond this, accountability becomes diffuse. Everyone assumes someone else is keeping things in order, and nobody actually is. The Owner role is not a status symbol. It is an operational responsibility, and it should be treated as one.
Member
Members can create, edit, and delete content within a site. They can upload documents, modify list items, and create new document libraries. What they cannot do is change site settings, manage permissions, or alter the site’s structure. For most collaborative teams, this is the appropriate level of access. The sales team working on proposals, the project team sharing deliverables, the HR department maintaining policy documents. Members can do their work without the risk of accidentally reconfiguring the site itself. The distinction between Member and Owner is the single most important boundary in SharePoint governance.
Visitor
Visitors have read-only access. They can view pages, download documents, and browse lists, but they cannot edit, upload, or delete anything. This level is ideal for stakeholders who need visibility without the ability to alter content. A board member reviewing quarterly reports, an external auditor examining compliance documentation, or a new starter who needs to read company policies before beginning work. Visitor access is underused in most organisations. The default assumption tends to be that everyone needs edit rights, which is rarely true and often dangerous.
“SharePoint permissions don’t become unmanageable overnight. They decay slowly, one shortcut at a time, until the day someone asks who has access to a sensitive document and nobody can answer with confidence.”
Why permissions become tangled over time
No organisation sets out to create a chaotic permission environment. It happens incrementally, through hundreds of small, well-intentioned decisions made under time pressure. A new starter needs access to a project library today, so someone adds them directly rather than waiting for group membership to be updated. A manager wants to restrict a subfolder to their direct reports, so they break inheritance and set unique permissions. A document needs to be shared with an external partner urgently, so someone generates an “Anyone with the link” URL and emails it across.
Each of these decisions solves an immediate problem. None of them is unreasonable in the moment. But they accumulate. After a year of this, a single document library might have permissions inherited from the site level, unique permissions on a dozen folders, individual user permissions on specific files, and sharing links that nobody remembers creating. The effective access to any given document becomes a function of all these layers combined, and working out what that effective access actually is requires forensic investigation rather than a simple check.
Staff turnover accelerates the problem. When someone leaves and their replacement arrives, the replacement is granted new permissions but the leaver’s permissions are not always fully revoked. When teams are restructured, the old team’s SharePoint groups may persist with outdated membership. When projects end, their sites and shared links often remain active indefinitely. The entropy is relentless, and without deliberate governance, it only ever moves in one direction.
Best practices for SharePoint permissions
Good SharePoint governance is not about imposing rigid rules that slow people down. It is about establishing sensible defaults that make the right thing the easy thing. When your permission model is well designed, users can collaborate freely without creating security risks, because the structure itself prevents the most common mistakes.
Use security groups, not individuals
This is the single most important habit in SharePoint permission management, and it is the one most consistently ignored. When you grant access to an individual user, you create a one-off permission entry that exists independently of any structure. Do this a few dozen times and you have a permission landscape that nobody can audit, nobody can understand, and nobody can manage at scale. Security groups, whether Microsoft 365 Groups, Azure AD security groups, or SharePoint groups, give you a single point of control. When someone joins the marketing team, you add them to the Marketing group. When they leave, you remove them. Every site, library, and resource that the Marketing group has access to updates automatically. No chasing individual permissions across dozens of sites.
Set permissions at the site level
SharePoint permissions are designed to flow downward. A site has permissions. Libraries within that site inherit those permissions. Folders within those libraries inherit from the library. Documents within those folders inherit from the folder. This inheritance model is elegant and manageable, right up until someone breaks it. The moment you set unique permissions on a folder or a document, you have created a management burden that will persist for as long as that item exists. The correct approach is to design your site architecture around your access requirements. If the finance team needs access to budget documents but the wider business does not, create a separate finance site. Do not put budget documents in a shared site and then try to lock them down at the folder level.
Create separate sites for distinct access needs
Many organisations make the mistake of trying to house everything in a single SharePoint site and then using granular permissions to control who sees what. This approach is seductive because it feels simpler. One site, one place for everything. In practice, it creates a tangled web of broken inheritance, unique permissions, and exceptions that becomes impossible to audit. A better model is to create purpose-built sites for distinct workstreams or teams, each with clean, group-based permissions set at the site level. A site for HR, a site for finance, a site for each major project. This is how SharePoint was designed to be used. Site provisioning is free and virtually unlimited. There is no good reason to avoid it.
Review permissions quarterly
Permissions decay over time. People change roles, leave the organisation, or move between projects. Contractors finish their engagements. External collaborators complete their work. Without regular review, these stale permissions accumulate. The person who left six months ago still has Member access to your contracts library. The agency that delivered a campaign last year can still see your marketing strategy documents. A quarterly review does not need to be onerous. Export the permission report for each site, compare it against current team membership, and remove anything that no longer makes sense. If you do this consistently, each review takes minutes rather than hours.
The security implications of oversharing
Oversharing in SharePoint is not just an inconvenience or an organisational untidiness. It is a genuine security risk with real consequences. When permissions are too broad, the blast radius of any security incident increases dramatically. A compromised user account that has access to three sites is a containable problem. A compromised account that has Member access to every site in the tenant, because someone used the “Everyone except external users” group liberally, is a data breach.
The risk is not limited to external attackers. Insider threats, whether malicious or accidental, are amplified by excessive permissions. An employee going through a difficult departure who has access to the HR site, the finance site, and the executive strategy documents presents a very different risk profile from one who can only access their own team’s project files. Excessive permissions also increase regulatory exposure. Under GDPR, the principle of data minimisation extends to access controls. If personal data is accessible to people who do not need it for their role, that is a compliance finding, regardless of whether anyone actually accessed it.
Perhaps most importantly, oversharing undermines trust. When employees discover that their personal development records are visible to their peers, or that confidential commercial negotiations are accessible to the entire sales team, the damage to organisational trust is significant and hard to repair. People stop using SharePoint for sensitive work. They revert to email attachments, personal OneDrive folders, or, worse, consumer file-sharing services. The platform that was supposed to centralise and secure your information becomes a tool that people actively work around.
Common mistakes to avoid
These are the issues we encounter most frequently when auditing SharePoint environments for our clients. Every one of them is avoidable, and every one of them is remarkably common. The pattern is almost always the same: a quick fix that solved a short-term problem and was never revisited, quietly expanding the organisation’s attack surface for months or years.
"Everyone" and "Everyone except external users" sharing
These two groups are the most dangerous permission shortcuts in SharePoint. When someone shares a document or a library with “Everyone except external users,” they are granting access to every single person in the organisation. Every employee, every contractor, every service account with a mailbox. This happens more often than most IT teams realise. A well-meaning manager wants to share a policy document widely and selects the broadest group available. A project lead wants to make sure nobody is excluded and grants organisation-wide access to a project site. The result is that sensitive information, from salary data to strategic plans, ends up accessible to people who have no business seeing it. Auditing for these groups should be a standing item in every quarterly review.
Breaking inheritance without a governance plan
Permission inheritance is the mechanism that keeps SharePoint manageable. When you break inheritance on a folder or a document, you sever its connection to the parent library’s permissions and create a standalone permission set. This is sometimes necessary, but it should be treated as an exception, not a routine practice. The problem with broken inheritance is that it is invisible at scale. You cannot see, from the site level, which folders and documents have unique permissions unless you actively audit them. Over time, a site that started with clean, group-based permissions at the site level develops dozens or even hundreds of unique permission entries buried deep in folder structures. When someone asks “who has access to this document?” the honest answer becomes “we don’t know without checking.” That is not a tenable position for any organisation that handles sensitive data.
"Anyone with the link" sharing
SharePoint and OneDrive offer several sharing link types, and the most permissive is “Anyone with the link.” This creates an anonymous access link that works for anyone who possesses it, inside or outside the organisation, with no authentication required. Once generated, these links are nearly impossible to track. They get forwarded in emails, pasted into chat messages, saved in browser bookmarks, and shared in ways that are entirely outside your control. For internal documents, this sharing type should be disabled entirely at the tenant level. For external collaboration, “Specific people” links are always preferable because they require the recipient to authenticate. If your organisation has not configured its sharing policies in the SharePoint admin centre, the default settings may allow anyone-links, and your users may be generating them without even realising the implications.
Not revoking access when people leave
This is a governance failure rather than a technical one, but it is remarkably common. When an employee leaves the organisation, their Azure AD account is typically disabled or deleted as part of the offboarding process. This removes their direct access to SharePoint. However, if they were added to SharePoint groups directly (rather than through Azure AD security groups), or if they generated sharing links during their tenure, those access paths may persist. External users present an even greater risk. Guest accounts are often created for specific collaborations and then forgotten. The external auditor who needed access to the compliance site two years ago may still have it. The former agency partner may still be able to browse your brand assets. A clean offboarding process, one that explicitly addresses SharePoint and OneDrive access, is essential.
“The question is never whether your SharePoint permissions have drifted. They have. The question is whether you know how far, and whether you have a plan to bring them back under control.”
How to audit and clean up existing permissions
If your SharePoint environment has been running for more than a year without structured governance, an audit is not optional. It is essential. The process is not glamorous, but it is the only way to establish a clear picture of who has access to what and to bring your environment back to a manageable state. Here is a practical, step-by-step approach.
Export a full permissions report
Start with the SharePoint admin centre. Run a sharing report across your tenant to identify externally shared content, sites with guest access, and files shared via anonymous links. For individual sites, use the Site Permissions panel to review group membership and any unique permissions. If you have a Microsoft 365 E5 licence or a compliance add-on, the Data Access Governance reports in the SharePoint admin centre provide a more granular view, including sites with oversharing risk and files shared with large numbers of users. For larger environments, PowerShell scripts using the PnP module can extract detailed permission data across hundreds of sites in minutes.
Identify broken inheritance
This is the most labour-intensive part of a permissions audit, and the most important. Broken inheritance at the folder or item level is where the worst oversharing hides. Use the SharePoint site contents page to browse each library, and look for the “Manage Access” indicators that show unique permissions. In large libraries, manual inspection is impractical. PnP PowerShell or the Microsoft Graph API can enumerate items with unique permissions programmatically. Flag every instance of broken inheritance and document the reason it exists. If nobody can explain why a folder has unique permissions, it is almost certainly a mistake that should be corrected.
Clean up stale access
Cross-reference your permission data against your current HR records or Azure AD directory. Remove any user who no longer works for the organisation. Remove any external guest whose collaboration has concluded. Review every security group to ensure its membership reflects current team structures. Pay particular attention to the Owner group on each site. If there are more than two or three Owners, reduce it. If an Owner has left the organisation, replace them. Stale Owner accounts are a particular risk because they represent full-control access that nobody is monitoring.
Reset and simplify where necessary
For sites where permissions have become too tangled to remediate incrementally, the most efficient approach is often to reset. Restore inheritance across the entire site, then rebuild permissions from the site level using groups. This sounds drastic, but it is faster and more reliable than trying to unpick years of ad-hoc permission changes. Before resetting, document the current state and communicate the change to site users. The goal is not to remove access that people need, but to provide it through a clean, auditable structure rather than a mess of one-off entries.
Document and establish ongoing governance
An audit is only valuable if it leads to sustained good practice. Document your permission model: which groups exist, what access they provide, who is responsible for each site, and how often permissions are reviewed. Publish this as an internal standard. Configure SharePoint sharing policies at the tenant level to prevent the most common mistakes. Disable anonymous sharing links if they are not needed. Restrict the ability to create “Everyone” shares. Set default link types to “Specific people.” These technical controls reduce your reliance on user behaviour, which is always the weakest link in any governance framework.
Practical governance for SMEs
Enterprise governance frameworks often assume dedicated security teams, compliance officers, and tooling budgets that most SMEs simply do not have. That does not mean governance is out of reach. It means it needs to be proportionate, practical, and built into existing workflows rather than bolted on as a separate overhead.
The following principles are designed for organisations with 20 to 250 users. They require no additional licensing, no specialist tooling, and no dedicated headcount. They do require commitment and consistency.
Designate site owners with clear accountability
Every SharePoint site should have a named owner, someone who is responsible for its content, its structure, and its permissions. This is not necessarily an IT role. For a project site, the project manager is the natural owner. For a departmental site, the department head or their delegate. The key is that someone specific is accountable. When a permission request comes in, the site owner decides whether to grant it. When the quarterly review happens, the site owner validates the access list. Without this accountability, permissions drift because nobody considers them their responsibility.
Restrict who can share externally
External sharing is one of the most powerful features in SharePoint and one of the most frequently abused. In the default configuration, any Member of a site can share content with external users. For most organisations, this is too permissive. Consider restricting external sharing to site Owners only, or to a specific security group of users who have been trained in your sharing policies. This does not prevent collaboration with external partners. It simply ensures that external access is granted deliberately, by someone who understands the implications, rather than casually by anyone who happens to click the Share button.
Use sensitivity labels and DLP policies
If your Microsoft 365 licence includes Microsoft Purview (formerly Microsoft Information Protection), sensitivity labels allow you to classify and protect content based on its sensitivity. A document labelled “Confidential” can be automatically encrypted and restricted to specific groups, regardless of where it is stored or how it is shared. Data Loss Prevention policies can detect and block the sharing of sensitive content, such as financial data, personal information, or intellectual property, before it leaves your control. These tools work alongside SharePoint permissions to create a layered security model. Permissions control who can access a location. Labels and DLP control what can be done with the content itself.
Automate site provisioning with templates
One of the reasons permissions become tangled is that sites are created ad hoc, with inconsistent structures and permission models. Site templates and provisioning workflows address this by ensuring that every new site starts with a consistent, governed configuration. Define templates for common use cases: team collaboration, project delivery, departmental resources, external partner workspaces. Each template includes predefined permission groups, sharing policies, and retention settings. When a user requests a new site, they select the appropriate template and the site is provisioned automatically with the correct governance controls in place from day one.
The cost of getting it wrong
Oversharing in SharePoint is not a theoretical risk. It is one of the most common findings in Microsoft 365 security audits, and the consequences range from regulatory penalties to reputational damage. These numbers illustrate why permission governance deserves serious attention.
of organisations report oversharing as their top data security concern in Microsoft 365
average time to identify and contain a data breach caused by excessive internal access
of SharePoint environments we audit have at least one site with broken inheritance issues
Need help with SharePoint permissions?
We help UK businesses audit, clean up, and govern their SharePoint environments. Whether you need a one-off permissions review or an ongoing governance framework, we can help you move from a tangled mess of ad-hoc permissions to a clean, auditable structure that scales with your organisation.
If you’re not sure where you stand, a SharePoint permissions audit typically takes a day and will give you a clear picture of your current exposure, along with a prioritised remediation plan.