Most of this applies best to classic SharePoint sites that are not using M365 Groups. That said, you can and should continue to create additional SharePoint permission groups if you have the need to segregate content on your modern UI sites.
Practice the principle of least privilege.
This is specifically because you should not give elevated access to anyone anywhere there is not a business justification to support it. Far too often entire teams will get full control so the person who should be managing the site’s overhead and maintenance isn’t bothered with managing the content or its permissions, and this will always lead to bigger problems. Those who do not have the job duty of site management, not content management, should not have full control. It is highly unusual for a branch chief or division chief to have full control because they have more important duties to carry out with their time. If they insist on having full control because they are the boss, be certain to inform them that you will be giving the commissioner full control as well because she is the boss of everyone. You also do not want to give random people in Idaho access to files for people in Maine. Think of this as the principle of need to know, but also ask if there is a business reason why others might need some level of access. You will usually add everyone to your visitors group, so you will remove the group’s access from any of those lists and libraries where random people from across the SSA should not be looking at particular pieces of content.
Use role-based access control (RBAC).
Use role-based access contrGenerally, most people initially work with SharePoint permission groups organizationally. The site focuses on the content belonging to a team, a branch, a division, or a component, so it is obvious to arrange general permissions based on these larger groups. As you apply work processes, however, to the apps on the site, it makes sense to create groups based on the roles for the work. You might have a few people who do testing, only a few people who can approve vacation requests, and different tiers of support for your customers. These people should go into their own groups whenever a business need indicates that they might need a level of access to the content that others should not. Because of the POLP, you don’t want to give everyone edit rights to the list where they put in their trouble tickets because they can continue to change things or edit someone else’s items. By dropping the level of access the larger groups have and granting permissions to these smaller role based groups, you will meet the needs of the business while keeping your content more secure.
Rename your permission groups to best reflect the roles needed.
Owners, members, and visitors is good enough most of the time, but if you are having a hard time trying to convince the boss who doesn’t know the difference between a folder and a library that he should not have full control, it might be useful to change the name of the owners group to Site Admins and create a new group for the boss called Leadership. It gives a better feeling for those in it than Management would. You can ensure the Leadership group is able to read all of the content without letting the group break things. Remember that there is a big difference in what Microsoft was thinking between site owners and content owners; but, for those less versed in how Microsoft is using these names, changing the names to better reflect what your office calls the different roles in your office can be very useful.
Be careful to not be redundant in permission levels.
There is no reason to grant the members group Edit, Contribute, Read, and View permissions. Sometimes groups look like this on a site, and you should take the time to fix it. More than likely, someone broke permissions and used this technique to get the group to finally access the content, so take the time to find the underlying problem.
Never allow the owner of a group to be another person.
You create a single point of failure when you limit ownership of groups to a person. If updates need made or a workflow is broken and that person is on vacation, you will need support from someone else possibly. Worse, if that owner leaves the organization, you could end up with a lot of orphaned content. A site collection administrator will need to assist just to find that content and free it for visibility for others.
Never assign permissions directly to a person.
This just causes a management nightmare. Assume you have 100 lists and libraries and you have broken inheritance where you have granted the leadership of the whole organization contribute rights to half of them. Now imagine that one member of that leadership team leaves and a new person joins. Do you want to update 50 different list permissions, or do you want to go into a permission group (role) you named Leadership to remove one person and add another? It is far simpler to manage five groups over 150 individuals. If there are unique business reasons why one person needs to have access to a file or a folder, try to have PowerAutomate break the inheritance on the item and add the additional permissions. Let the system automatically set the permissions rather than relying on a human to make a break and adding read access to a folder to the person who is the subject of that folder.
Turn off access requests.
If you have planned out your permission architecture correctly, you should never get a request because everyone who should have any level of access through their role already has the right level of access. The only time you will update your permissions will be either when you create a new application on the site or have personnel turnover. If you just created the site, keep it on for a few weeks just to catch people you might have forgotten, but be careful to not fall into the trap of assigning someone permissions directly rather than placing them in a group if you get a request.
Make your permission group membership viewable by everyone.
Unless you are managing SharePoint sites for the Freemasons or some other secretive society, you don’t likely have a business case for limiting visibility to end users. By default, groups are set to only have membership viewable by members because a long time ago (by tech standards) SharePoint sites could be set to have anonymous access from the internet and have internet facing sites. It led to a lot of phishing when anonymous users could see the names of everyone in the owners groups. If you use PowerAutomate or SharePoint Designer workflows to send out alerts or perform any other function, they run under the permissions of the one executing the workflow. If the user cannot see the membership of the group, the workflow cannot email the alert to the group.