The default permission model
Every SharePoint site, by default, has three groups: Owners, Members, and Visitors. Each is assigned a default permission level. This is the model Microsoft ships with, and the right starting point for almost every site.
| Group | Default permission level | What it lets you do |
|---|---|---|
| Owners | Full Control | Manage the site, change settings, manage permissions, manage everything. |
| Members | Edit (Microsoft default) | Add and edit content. Also: create, edit, and delete libraries, lists, and views. Modify site structure. |
| Visitors | Read | View pages and items. Open documents. Cannot edit. |
Use the default groups. They cover most needs, are well-understood, and are the model Microsoft optimizes around. Custom groups should be the exception, not the rule.
Decision: Members = Edit or Contribute?
Microsoft ships the Members group with Edit permission. Edit includes the Manage Lists permission, which lets users create, edit, and delete libraries and lists, change library settings, and modify metadata schemas. Contribute strips that out — Contribute users can add, edit, and delete content inside existing libraries, but they cannot change the structure of the site.
| Members = Edit (Microsoft default) | Members = Contribute | |
|---|---|---|
| What users can do | Add/edit content; create and delete libraries and lists; modify library settings; change metadata schema; modify navigation. | Add/edit content. Cannot create or delete libraries; cannot modify library settings; cannot change metadata schema. |
| Pros | Empowers business users to evolve their site. Less central work. Aligns with Microsoft's defaults. | Prevents accidental structure changes. Keeps governance tight. Easier to recover from user errors. Information model stays under IM control. |
| Cons | Users can break site structure unintentionally. Inconsistent libraries appear. Metadata schemas drift. Site Owner can't easily see what's been changed. | Site Owners must be elevated to Owners (or Designers) to make structural changes. More requests come back to the Broker or IM. |
| Best for | Highly engaged users with information-management training. Pilot or sandbox sites. | Production sites in governed environments. Most organizations most of the time. |
Most governed deployments downgrade Members to Contribute. The reduction in accidental damage outweighs the small loss of flexibility. Library and list creation flow through the Site Owner (who has Full Control) or via a Library Catalog request — which keeps standards consistent.
If users genuinely need the ability to create their own lists and libraries, give them Site Owner permission (Full Control) explicitly. Don't expand the entire Members group's permissions to give a few users that capability.
This is a tenant-wide default decision. Apply consistently to all new sites; modify selectively where the use case justifies it.
Impact's workspace templates apply Members=Contribute as the default during provisioning. Library and list additions flow through the Library Catalog request, which goes to the Broker for approval and then to the Workflow Engine for provisioning — preserving consistency without requiring users to wait for a manual configuration cycle.
Decision: Visitor philosophy — open or closed by default?
Whether the Visitors group is broad (everyone in the organization) or narrow (only invited users) is a platform philosophy decision. It defines whether your default posture is discoverable-and-locked-down-where-needed, or hidden-and-opened-up-where-needed.
| Open by default (broad Visitors) | Closed by default (narrow Visitors) | |
|---|---|---|
| Visitor membership | All employees (or a tenant-wide group). Most sites are visible to everyone read-only. | Only invited users. Most sites are not discoverable to non-members. |
| Pros | Promotes discovery, knowledge sharing, transparency. Reduces 'where is this stored?' help-desk traffic. Search and Copilot work as intended. | Strong default protection. Less risk of inadvertent exposure. Aligns with regulated/sensitive environments. |
| Cons | Sensitive content must be actively locked down (broken inheritance on libraries/folders). One mistake exposes content to the org. Higher Copilot exposure risk. | Discovery degrades. Users can't find things they should be able to find. Search underperforms. Higher manual access-request load. |
| Best for | Mature, trust-based organizations. Knowledge-driven environments. Organizations that have invested in sensitivity labels and DLP. | Highly regulated environments. Healthcare, financial services, government, legal. Organizations with weak data classification. |
Most organizations should start closed-by-default during initial rollout, then open up selectively as data classification matures. Department hub sites and intranet content can be made broadly visible early; operational and project sites stay restricted to their members until the platform's sensitivity-label coverage is robust enough to support broader discovery.
Targeted permissions audit pattern
After the default groups are configured, the productive next step is not to pre-architect permissions for every library and list. It is to walk the site contents and identify the exceptions — the few libraries or lists that genuinely need different permissions from the rest of the site.
The pattern:
-
Set defaults. Apply the standard groups (Owners/Members/Visitors) and the chosen permission levels at the site level. Inheritance flows from there.
-
Walk site contents. Review every library and list on the site. Ask: does this need different permissions from the site default?
-
Identify the exceptions. Most libraries inherit the default. A few may need to be restricted (e.g., a 'Confidential' library with limited Members) or opened up (e.g., a 'Templates' library visible to all employees).
-
Apply unique permissions only where justified. Break inheritance at the library or folder level. Document the exception.
-
Avoid file-level breaks. Item-level permissions are unmaintainable at scale. Move sensitive files to a folder with broken inheritance, not the other way around.
Permissions debt accumulates from well-intentioned ad-hoc breaks. A folder gets unique permissions in 2024 because a contractor needed limited access; the contractor leaves; the permissions are never cleaned up. Within two years, the site has dozens of broken-inheritance scopes that nobody understands. Document every exception, audit them quarterly, and clean up aggressively.
Breaking inheritance — where and how
By default, libraries, folders, and items inherit permissions from the site. This is the preferred model — it's simple, scalable, and easy to manage. Break inheritance only where required, and at the lowest level that solves the problem.
| Scope | Use it for | Avoid it for |
|---|---|---|
| Site-level | The default. All libraries inherit from the site. | — |
| Library-level break | An entire library that's sensitive (e.g., 'Confidential', 'Management', 'HR Sensitive'). | — |
| Folder-level break | A subset of content within an otherwise-shared library. | Routine collaboration cases. Only when content is genuinely partitioned. |
| Item-level break | Truly exceptional. Almost never the right answer. | Anything other than emergencies. Use a folder instead. |
SharePoint permissions only apply while content remains in SharePoint. Users with Read access can still download files, share via email, and store content locally. Sensitivity labels with encryption (Doc 2.6) and DLP policies are how you protect content beyond the SharePoint boundary.
Entra ID groups for membership management
SharePoint groups are site-specific. Entra ID groups (formerly Azure AD groups) are managed centrally and can be used across the entire Microsoft 365 platform. The recommended pattern is to use Entra ID groups for membership and add them to SharePoint groups for permission.
Why this matters:
-
Centralized membership management. Add a user to one Entra ID group and they get access to every site/library that group is associated with.
-
Dynamic membership. Entra ID groups can be dynamic (membership calculated from user attributes), keeping membership accurate as roles change.
-
Role-based access. An Entra group like 'HR Staff' or 'Project Foo Team' can be reused across many sites and libraries — single source of truth for membership.
-
Better lifecycle. When a user leaves, removing them from Entra ID groups automatically removes their access everywhere.
The pattern:
-
Create an Entra ID group for the team or role (e.g., 'Digital Health — Infrastructure Team').
-
Add that Entra group to the SharePoint Members group on the relevant site.
-
Manage membership in Entra ID — add and remove users there, not in SharePoint.
Adding individual users directly to SharePoint groups. It works, but it scales badly — you end up with the same user added to dozens of SharePoint groups across many sites, with no central view of access. Use Entra ID groups for membership; use SharePoint groups for permission assignment.
Impact's workspace provisioning creates Entra ID groups for site Owners and Members based on the requested role configuration, adds them to the appropriate SharePoint groups, and registers them in the property bag for downstream lifecycle and reporting. Membership management then happens in Entra ID — Site Owners use the standard tools, and the Insights module reports on group sprawl and orphan groups across the tenant.
Naming conventions for Entra groups
Without a naming convention, Entra groups become impossible to manage. A working pattern:
-
<Department> — <Function/Team> (e.g., 'HR — Compensation Team')
-
<Department> — <Project> — <Role> (e.g., 'IT — CRM Migration — Members')
-
Use a consistent prefix for groups created by Kybera Impact or other automation, so they sort together and are easy to identify in admin tools.
-
Don't put security details (e.g., 'Confidential') in group names that show up in user-facing places.
Discussion Questions
• Are we comfortable downgrading Members to Contribute as the tenant-wide default?
• Where, if anywhere, do we want Members=Edit (sandbox sites, pilot environments)?
• Is our default posture open by default + lock down sensitive, or closed by default + open up where needed? What does our regulatory environment require?
• Are we using the default SharePoint groups (Owners/Members/Visitors) or have we built a custom group model? Should we rationalize?
• What's our policy on breaking permission inheritance — at what level is it acceptable, and what's the documentation requirement?
• Are we using Entra ID groups for site membership today, or are users added directly to SharePoint groups?
• What naming convention applies to Entra groups created for SharePoint access?
• How often do we audit broken-inheritance scopes and clean up unnecessary exceptions?