Teams Governance: The Basics

Posted by: Joy T. Apple on May 18, 2021

Governance. We cringe when we hear that word, much less when we need to create a plan for it! Many of us are in the position of having rolled out Microsoft Teams quickly to meet the rapid movement to work from home in early 2020. It can feel overwhelming to try to wrap governance around a tool as popular as Teams in a way that won’t disrupt current work-streams.


Regardless of where you are in your journey with Microsoft Teams, its not too late to step through basic decisions that should be evaluated for Teams and create common sense governance for the organization.  

  1. Who should be able to create teams?

    It is common to restrict the ability to create teams to a small, trained group in the early phases of deploying Microsoft Teams. This is accomplished by using a policy to restrict the creation of Microsoft 365 Groups from anyone in a particular AAD group.  

    This will require a premium AAD license for those in that group.  

    Manage who can create Microsoft 365 Groups | Microsoft Docs 

    If creation will continue to be restricted after your rollout of Teams, I recommend you create a request process for the creation and quick turnaround of new teams. (Hello, Forms Check out the webinar we did on Microsoft forms!) 

    You should also consider not restricting this group to only IT personnel. Having trained folks across departments to fulfill the requests ensures that the request is going to someone with familiarity with how that department or functional area works and who’s who. It also keeps IT from becoming a bottleneck and slowing down the progress of collaboration.  

  2. Should there be naming conventions?

    Naming conventions for Teams can be as simple as recommended guidelines communicated to the organization and taught in training sessions, lunch and learns, or tutorials. They can also be enforced through M365 group policy.  

    Typically, naming conventions consist of a prefix or suffix added to the name of a team to designate a project code, type of team, department, location, or division.  

    Naming conventions can complicate the creation process and may add confusion if the need and meanings are not clear to business users.  

    Examples of M365 Group naming policies from Microsoft are: 

    • Prefix-suffix naming policy 
    • You can use prefixes or suffixes to define the naming convention of groups (for example: "US_My Group_Engineering"). The prefixes/suffixes can either be fixed strings or user attributes like [Department] that will get substituted based on the user who is creating the group. 
    • Custom blocked words 
    • You can upload a set of blocked words specific to your organization that would be blocked for groups created by users. (For example: "CEO, Payroll, HR"). 

    Blocked words would keep well-meaning business from creating Teams (and sites and M365 groups) with names that mimic the more official workspaces in the organization.  

    Microsoft 365 groups naming policy | Microsoft Docs 

  3. Will we allow guest access?

    Seinfeld Newman GuestDo certain teams in your organization need to be allowed to invite gusts from other organizations into Teams? It is important to note that guests are granted permissions very similar to members. They can add, delete, and edit content to channel Files tabs and participate in Team chat.  

    By leveraging tenant controls, you can limit which teams can have guests.  Once a team has guests, team owners can decide what those guests are allowed to do within the team such as channel creation and editing.  

  4. Approved applications

    apps1Microsoft has positioned Teams to be a service application delivery platform. Not only does it provide streamlined communication and collaboration but further reduces context switching by providing easy access to the applications we use throughout the organization day in and day out.  

    IT teams should evaluate the applications that are available to leverage from within Microsoft Teams for not only security compliance but logical business usage. 

    You may decide to only allow the Microsoft apps at first and have discover conversations with your business departments to discover what 3rd party apps are in use.  

  5. Content management and structure

    Microsoft Teams makes it possible to bring department, project, and functional area collaboration and communication into one application. It also approaches file management and even security differently than how users may be accustomed to.  

    Teams (and SharePoint) content management and structures are best utilized in flat structures. The files tab in teams is truly a folder in the connected SharePoint team site’s Documents library. This should be the extent of depth in document structures. Additional channels should be created for content organization, rather than going deeper with nested folders in Files.  

    Roles are democratized in Teams. If you’re in the team, you’re on the team. Team members and guests are active participants and contributors to the conversations and content stored within the standard channels of a team.  

    Read only access to documents can be granted using the SharePoint team site permissions features.  

    IT departments should work with departments to discover how content is accessed and used within traditional security scenarios. Teams should be built according to permissions. This may mean that what was once one site with many granularly secured folders, libraries, and sub-sites now breaks into multiple teams and team sites.  

  6. Data securityCanva - Smartphone Showing Activated Security System

    When approaching your Teams implementation time should be taken to consider the sensitivity of data that will be accessed in Teams. Security labels can be used to classify teams that contain sensitive data. It is recommended to have a basic retention policy in place for Teams. This can be built upon as your organization matures in its use of Microsoft Teams.  

Yes, there are big decisions to make that can have big impact on our business users and data security. Start with the basics and start simple. Build on the complexity as needed. Engage with departments and functional groups to see what’s working, what’s not, how they work with their content and co-collaborators. Use this information to create governance that works with them.  

If you get stuck, I know some folks who can come alongside and help you have these discovery conversations and create a plan for moving forward. You can reach out and get that help whenever you are ready. 

Until then, here's a previously recorded webinar on Governance in Microsoft Teams from our PAIT Group YouTube Channel. 


Topics: Governance, Microsoft Teams, Microsoft Teams Governance, guest access

Subscribe Today!

Recent Posts