Right-sizing governance for Microsoft 365

The governance paradigm has shifted in Microsoft 365.

Microsoft 365 provides mechanisms to decentralize control and automate governance in tools such as Teams, SharePoint Online and Azure Admin Centers. This means an open-by-default philosophy instead of restrictions that limit use and access. We call this an “open-by-default and closed-by-exception” model.

This can be a jarring change for IT teams used to a traditional centralized governance model. The benefit of shifting to a decentralized model is it requires less overhead and maintenance over time. It’s a win-win for users as well, who have more control and less incentive to store content outside the system.

This article goes deeper into shifting to this new model of governance.

How to right size governance in Microsoft 365

Typically IT Admins have many questions about governance in Microsoft 365, but they boil down to two fundamental areas:

1. Should we enable self-service creation?

2. How do we manage the content over time, at scale?

Let’s look at these two areas:

1. Enable self-service options

IT groups are often rightly concerned about Group, Team and Site sprawl, which why they want to approve any requests for new items.

The problem with IT driving an approval process for Groups, Sites or Teams is that the burden of work falls on the team through tickets and requests. It’s also not a great experience for end-users who must wait for access to collaboration and may choose to work around IT to get access to functionality they need.

So, what do you do? Turn off self-service creation to minimize content sprawl? Turn it on and manage inappropriate content later?

We recommend allowing end-users to create Groups, Teams and Sites with a few ‘guardrails.’

Guardrails can be as simple as:

1. requiring purpose, description or additional detail before creating items and

2. setting smart defaults.

 Here’s an example of the information required before creating Project Teams and Sites in our environment:

View fullsize

Example of a form to specify site purpose and description

The guardrails here are: having an active client, project manager and project name before creating a project. Anyone can technically do this and have a project site, but they can’t get past this form without filling in required information first. This is a form created by extending SharePoint with Power Apps, but you can also use the standard site creation process to require description and purpose before continuing.

For smart defaults, we recommend naming conventions, templates, and sensitivity labels. Naming conventions and templates are relatively straight-forward, but sensitivity labels are typically not well-understood.

Here’s an example of how to use sensitivity labels in the context of creating a new Team in Teams. On the new Team panel, the sensitivity option is shown and for content that has a Confidential label, the privacy is set to Private by default:

Sensitivity setting on a Team

This allows the organization to restrict sharing of confidential information to public or guest users based on self-selected criteria, or to use sensitivity labels for groups with higher-risk information (e.g. Finance). Learn more about setting sensitivity labels in Microsoft 365.

Exceptions

There will always be exceptions to allowing users to have full self-service creation of Groups, Teams and Sites. You may want to centralize governance and approval for higher risk content or external sharing. In this case, if central approvals are required, we recommend SLA’s of 24 hours or less. Here’s an example of an approval step built with a Power Automate flow that goes to email:

View fullsize

Example of an approval step from Microsoft Power Automate

2. Managing Microsoft 365 content over time, at scale

Automate governance when possible

As described above, we recommend following a self-service model where anyone can create a Group, Site or Team with guardrails.

The next step is to automate the management and lifecycle of the group to manage the growth of content over time at scale.

You do this through policies in Azure and throughout Microsoft 365. For example, you can:

• Set timelines for expiry of inactive groups

• Send emails to remind members when there is no owner for a group

• Require groups to be renewed on a regular basis.

These policies behind the scenes will help you, as the IT Administrator, automate the management of the group.

Here’s an example of automating expiry though Azure:

View fullsize

Setting group expiry through Azure

Finding Groups or Teams without owners is harder without PowerShell or paying for a third-party tool. Microsoft promises to be working on this by adding a new filter to the groups section of the Microsoft 365 Admin Center. You’ll be able to view a list of ownerless groups, and then send them emails as shown:

View fullsize

Ownerless groups filter from Microsoft 365 Admin Center - Courtesy of Microsoft (skip to 18:45 min mark)

You can follow this feature as it reaches preview in the roadmap.

General principles

In summary to right-size governance for Microsoft 365 we recommend these principles:

• Decentralize management for most cases

• Automate governance when possible

• Make governing as frictionless as possible with self-serve options

• Ensure timely response to requests that require governance

• Ensure you have resources dedicated to the ongoing improvement and updates of the platform

---

Sometimes it helps to have a third-party advise on a Microsoft 365 governance plan for your organization. We’ve done this for many highly-regulated organizations, and we can help you with your governance planning. Reach out to us today.