The content pages “Permission levels”, “Item-level permissions” and “Data containers” are related to this subject.

Below, I describe my default to-go security setup.

  1. I prefer a least privilege access when creating business solutions. This often results in the use of custom permission levels (see content page Permission levels). Example: If a role only needs to be able to update a record, then I only assign the custom permission level “Update”.
  2. I prefer “Team site” SharePoint sites without a Microsoft 365 group attached because this is enough for storing data,
  3. Rights in a business solution is based on roles.
  4. Every role has a related SharePoint group.
  5. Rights are set with SharePoint groups.
  6. Users who only need indirect access to data in SharePoint will only get rights on a list/document library.
  7. Users who will work directly in SharePoint, will get rights on site and list/document library level.
    • In general, I prefer that users do not work directly in SharePoint. There are administrator activities where I do support the direct interaction with data in SharePoint. For example, maintenance of master data in a SharePoint list by a functional application manager.
  8. All lists and document libraries have dedicated rights (broken inheritance).
  9. On site level, users – with the exception of technical application management – are only assigned the permission level “Read”.

Accounts and Entra ID security groups can be member of a SharePoint group. It depends on the situation what to use and what can be used. This also includes a combination of accounts and Entra ID groups. SharePoint groups cannot be nested.

Application management

Two often required roles are:

  • Functional application management
  • Technical application management

The exact differentiation between the rights of these roles depends on the situation but in general, it can be said that:

  • a functional application manager focuses on user and master data management.
  • a technical application manager focuses on everything a normal user or functional application manager is not able to do because of lacking rights and lacking knowledge.

Both roles are involved in questions, feedback, incidents and changes.

This results in:

  • functional application managers having the rights to create/read/update/delete (or a selection of it) data in lists and document libraries what other users cannot do. Example: Maintain the data in the list containing all drop down choices.
  • technical application managers having full control on all containers and data.

As a best practice, application managers do not have their extra rights enabled by default. Technical application managers often have a separate account for there activities but functional application managers do not. Luckily, SharePoint allows for a configuration to deal with this: SharePoint group ownership

SharePoint group ownership

Group ownership can be used to improve security by allowing users to only get additional rights when needed.

An owner of a SharePoint group can add members to that group. The trick to know is that another SharePoint group can be set as group owner resulting in members of that other group to add themselves to the group resulting in additional rights.


There are two custom SharePoint groups:

  1. Functional application management
  2. Functional application management – Members

The second group is owner of the first group and contains all the users belonging to the related role. The first group is used to set rights. Example: This SharePoint group is assigned the “Contribute” permission level on a list so all members can create/read/update/delete data in that list.

Some in the members group can now add herself/himself to the related group resulting in additional rights.

Other info

  • The SharePoint group ownership setup can be extended with a scheduled cloud flow (Power Automate) which removes all members of the group used to set the rights.
  • If more control is needed for a user to get additional rights, a setup with a list for requests and a cloud flow (Power Automate) for the approval and configuration can also be used.


This video demonstrates two security measures:

  1. All lists and document libraries have dedicated rights (broken inheritance).
  2. SharePoint group ownership.


Please enable JavaScript in your browser to complete this form.

You can use the form below to submit feedback if you think that content on this page:

  • is wrong. Please then also provide what is wrong and why.
  • could be more comprehensive. Please then also provide which content should be added/updated.

Thank you!