Good work, you’ve managed to deploy Microsoft Teams!
You’ve been planning to deploy it for months, and you scheduled the rollout over a 3-month period, but instead, you deployed it in 2 days thanks to a global pandemic.
Kudos to you.
So, what’s next?
Well, let’s take a step back and review a few things.
When Teams is rolled out in a more staged approach, generally one of the most important things to consider is how your organization will manage and govern the platform. Rolling out in such an urgent matter like what we have seen in the past few weeks tends to cause organisations to ‘park’ these points.
In this article, we’ll look at some of the items you would normally consider in a more controlled rollout to help you understand what you may have missed.
When you deployed Teams, did you consider the following?
- Data Sovereignty
What we’ve noticed in deployments is that once the platform is in place, users generally begin using it right away. Users begin uploading files, sharing important pieces of information about clients and employees and use Teams as a file repository system.
What’s important to note here is that all that data will now reside in your Office 365 tenant. Taking into consideration data sovereignty compliance requirements, we need to ensure that the data meets compliance requirements imposed on your organisation.
So where is your data being stored?
Thanks to compliance requirements around the world such as GPDR, Microsoft have made it extremely easy for organisations to check where their tenant data resides.
Administrators can do this by logging into the Office 365 Admin Portal, and locating their “Organization Profile” settings where they will be presented with a list of all services in Office 365 and where your tenant’s data is physically stored.
- What retention policies are in place for your data?
Some organisations like to have control over how long data is kept once it is uploaded into teams channels. This may be a compliance requirement imposed on the organisation.
Your strategy may stipulate that certain teams or departments have certain expiration dates on their teams channels or potentially archive inactive teams to preserve the content.
This all may depend on the type of data you think users will likely upload via Microsoft Teams. To help build your strategy and retention policies, consider the following
- Does your organisation have compliance requirements that may govern your retention policies?
- What would you like to happen to teams channels that become inactive? An example of this might be when a project is complete.
- In the event of a legal case, does your current licensing model have the ability to search for content created in Teams?
- Did you deploy naming policies?
Out of the box, users are able to create teams channels with pretty much any name they choose. This may be fine in a smaller organisation where not many channels may be created but in a school environment or a larger organisation, you may want to consider how you control this.
Teams channels have a tendency of creating an element of confusion in organisations when it comes to groups and naming. A good example of this is outlined below.
The Contoso organisation already has a mailbox for all HR enquiries. The mailbox address is hrqueries@contoso.com. The organisation also has another project running that is looking to consolidate all HR systems into one. They’re running their project out of a teams channel and they’ve decided to name that teams channel HR. This would result in an Office 365 group with the address HR@contoso.com.
In the example above, the newly created channel would create organisation-wide confusion as this new email address appears in the Global Address List.
To prevent this sort of confusion, Azure AD allows administrators to configure Naming Policies. These naming policies can enforce naming standards which will help isolate Office 365 Groups created via Teams.
Naming policies allow administrators to enforce prefixes, suffixes, the use of attributes as tags and word blocking.
- Are Teams users required to sign-in using multifactor authentication?
Not only does Microsoft Teams allow an organisation’s staff to collaborate on a single platform, but it also allows users to login from pretty much anywhere that has an Internet connection.
While all this sounds great, it is absolutely essential that organisations consider that this means users will be logging in from networks that may not be as secure as a corporate network.
With the smart social engineering attacks we see these days, all organisations should already be implementing or utilizing multifactor authentication for all authentication.
Teams is no exception. We suggest that administrators deploy multifactor authentication via Azure AD Conditional Access policies which allow administrators granular control over authentication. The policy doesn’t have to be specific to Teams but Teams should definitely be a part of any existing multifactor authentication policies that are in place today within your organisation.
- Does your organisation need to limit any features within Teams?
There are many features in Teams that organisations may like to restrict or allow based on their own policies and strategies.
Administrators can apply restrictions on the whole Microsoft Teams tenant or specific users. This may be useful in some organisations such as schools where administrator may want to limit the use of certain capabilities.
Some things to consider when limiting features
- Have you considered who can create teams channels?
It may be useful to limit who can create new teams to your IT teams but this may create unnecessary overheads
- Have you considered who can share screens in a meeting?
Some organisations such as schools may not want all attendees in a meeting to be able to share their screens.
- Do you want users who join by phone to automatically be admitted into meetings?
Organisations may consider this a security risk and therefore enforce that users are approved prior to entering meetings over the phone.
- Do you want to give users the ability to record meetings?
By default, users of Teams are able to record meetings for later playback. You may want to consider reviewing these settings and confirming whether they are truly required or not.
- Are you allowing external guests?
External Guest access allows Teams users to collaborate with other Teams users outside of their organisation’s tenant. This is a great feature that allows customers to cross-collaborate with their partners, their clients, etc.
It can also be viewed as a potential risk of data exfiltration within the environment. What we see these days is that once a malicious actor has access within a tenant, these are the features that allow them to retain access once their access is removed via the compromised account. For example, we see that once a user has their account compromised, one of the first things that occurs is the sharing of OneDrive or Teams data to an external guest account which is then used to capture organisational data.
This doesn’t mean it’s all bad and you should turn the feature off. You should keep an open mind to this feature as it has the benefit of allowing your staff to collaborate externally and to keep data in one place. Disabling features like this is usually a catalyst for staff to begin provision shadow IT setups to share data, etc.
When considering external guest access, take into consideration the following points
- Ensure that MFA for external guest users is enabled.
MFA is not negotiable. Do not rely on the partner organisation’s MFA for security. Enforce it from within your own tenant.
- Consider limiting who can invite guest users.
This may create administration overhead but in an organisation which errs on the side of caution, it may be a good middle ground between you and your security department
- Review all options for external sharing.
Microsoft provides many options for external sharing configuration. Review these settings carefully and find the one that meets your security requirements.
- Ensure that your external sharing policy is a universal strategy.
Although it brings many platforms together, Teams is only a part of the Office 365 ecosystem. Once you’ve determined your external sharing policy, ensure that your external sharing policies are applied universally across all applications in the suite.
- What defines a successful deployment?
Last but not least is, what you define as a successful deployment.
As consultants, this is something that we usually tackle first by developing UAT strategies and success criteria but let’s face it, this deployment was rushed.
So how will we define its success?
Consider the following:
- Are users actively using Microsoft Teams?
- Are you staff beginning to use Teams to share data and collaborate with other members?
- Send staff satisfaction surveys – you could even use Microsoft Forms and push the questionnaire out via Teams.
- Are there any features that your staff have questions about?
IIn summary, it’s important that you have your Teams strategy in place and if you don’t have one yet, it’s not too late to deploy a strategy!
