Permissions and Your Governance Strategy

In my second webinar in the ‘Governance Rules!’ series for the European SharePoint community entitled ” Why Permissions Drive Your Governance Strategy,” I focused on one of the most important aspects of the governance puzzle: clarifying plans for permissions management. If governance is about helping you to organize, optimize, and manage your systems and resources, then permissions is the vehicle through which governance is enabled. Generally speaking, when a user reports a problem with SharePoint, the first place an administrator will look is to their permissions — does the user have access to the location, and the right level of access? Similar to the popular Microsoft Windows refrain “Have you tried turning it off and on again?” is the common SharePoint question “Do you have the right permissions?”

In any governance implementation, you often start your planning with an understanding of the roles and responsibilities within your SharePoint environment: how and where end users will access the system, what content is secure and who owns each type of content (as opposed to content types), who manages all the different parts of your farm, how access is granted, and the policies and procedures that secure and protect the growing needs of your organization. Unfortunately, SharePoint does not easily provide the data you need to compile a comprehensive view of permissions across your environment. The ‘Check Permissions’ admin feature at the site level gives some visibility, otherwise you’ll need to utilize PowerShell or a 3rd party tool to capture this information for planning purposes.

Permissions reporting is critical to your governance planning, and is essential to auditing, compliance, and overall system transparency so that you can troubleshoot functionality problems that, commonly, stem from end users attempting to perform a task without having the right level of permissions.

Making Permissions Part of your Plan

Key to building a successful governance strategy is understanding your structure and your content. Understanding how people will use the platform, their expectations, and the business requirements will help you to better identify roles and responsibilities, and then customize permission levels for each. Roles may include Farm Admins, Site Collection Admins, Site Admins, Team Leads, Power Users, End Users, and various Groups — each with clearly defined scope and limitations, allowing you to quickly audit your system and identify risks based on these standardized permissions levels.

Part of the goal of any governance strategy is to identify — and have a process for — any exceptions to these standards. “If you use fine-grained permissions extensively, you will spend more time managing the permissions, and users will experience slower performance when they try to access site content.” (Planning site permissions, Technet  Exception-based permissions management (additions, deletions, edits) is done one securable object at a time, so take this into consideration when defining your policies for allowing exceptions. SharePoint is designed to allow various user types, from Farm Administrators will full-control of every aspect of the environment down to read-only casual users, but just because you can allow exceptions doesn’t mean you should allow them.

Best Practices

My general advice to any team or organization preparing to build out their governance strategy for SharePoint is to utilize their established project management methodology — every IT organization has a process in place to capture requirements and stakeholder input, to get sign off from end users and management on designs, and to move projects from inception through to delivery. Use it. Share the results of your planning at each steps, allowing all stakeholders to review your analysis of the site and content structure, information architecture, and proposed roles and responsibilities.

Of course, this is advice that spans any IT project — not just building your governance strategy and permissions plan. More specific to SharePoint, here are some best practices that will help you to better manage your permissions:

  • Use SharePoint Groups to manage memberships, building them from your Active Directory (AD) groups. SharePoint groups are more flexible than using AD groups alone, which may be out of your control and become a bottleneck.
  • Use role-based permissions rather than manage by exception. ALWAYS document exceptions, as these rogue users are often the cause of many future headaches. The exception approval process should be part of your defined governance strategy.
  • Use SharePoint inheritance, whenever possible (it should be the standard, not the exception), scrutinizing requests for custom permissions. Avoid item-level permissions unless it is a clear use case and business need (such as tracking financials, or possibly a product roadmap).
  • Do your best to get more visibility into user access. Permissions reporting is critical to your business for a number of reasons – from regular auditing, to maintaining accurate user access, to troubleshooting functionality problems that, commonly, stem from end users trying to perform a task without having the correct permissions. Whether through PowerShell or 3rd party tools, successfully enforcing governance policies around permissions requires more than what is offered out of the box in SharePoint.

Your governance plan should specify policies for how to manage access to sites and content, how to define groups, roles, and user permissions. As much as possible, try to keep your policies simple – so people can understand them, which will make it more likely that they will follow them. The more complex you make your permissions, the more difficult it becomes to determine who has access to what – increasing the risk of information security breaches and the exposure of confidential information.

This article was first published on BuckleyPlanet. Check out our resource centre for more SharePoint content from Christian and other SharePoint specialists!

Share this on...

Rate this Post: