Governance Archives - blog.crim.dk

What you need to include in your Microsoft 365 governance

The goal of creating a governance is to define roles, responsibilities, polices and processes for how the organization should work in order to achieve it’s goals.

For many organizations the task of defining a governance is often overlooked, and the word “governance” is first mentioned after implementation of the Microsoft 365 platform. By then the business has already started working with all the great new features.

So, is it too late to define you governance then? Absolutely not, it is never too late, but you may need to do more work in order to enforce implementation of the governance if you start out late in the implementation process. Nevertheless you will do yourself a great favor by giving the governance implementation a high priority.

How to get started with Microsoft 365 governance

Before you start defining your Microsoft 365 governance you need to ask yourself a few questions which should help you determine what should be included in the final product.

Here are some examples:

Who are your users?
- Administrators
- Internal users
- External users / partners
- Etc.
How are these users working together or as an individual?
- Do you have an overview of current and future work processes or do you need to do pre-analysis first?
Which Microsoft 365 services do you plan to implement?
- Personal (e.g. Outlook/Exchange, OneDrive)?
- Collaboration (e.g. MS Teams, SharePoint, Yammer)?
What is your top 3 priorities for the use of Microsoft 365?
- Examples:
  - Security and compliance
  - Process improvement
  - Collaboration

The reason why it is important to go through the above exercise is that it gives you an indication of what needs to be described and how. For example, when you have identified your involved users and their current work processes (you can create uses cases to describe this), you instantly have a baseline for describing, and even improving, how the users should work in the future Microsoft 365 setup.

Remember, the governance definition is also a description of how the users must use the available Microsoft 365 services in certain business scenarios (What tool to use when?). When having that description and implementation in place, you ensure a higher level of compliance and streamlined processes.

While the Microsoft 365 platform involves a lot of available services (suggestion: take a look at the M365 periodic table made by jumpto365.com), you may want to create an overall governance that covers all your selected services. And then split your governance description into sub-areas covering each individual service (e.g. OneDrive, MS Teams, SharePoint) as these may have different settings and policies.

In general it is a matter of describing: Who? When? What? and How?

What to include

There are some common areas that your would normally include in your governance structure. How detailed you would like to describe these areas is up to you, but start out with some simple descriptions – you can always expand at a later time.

A normal governance document would at least include these areas:

Roles and responsibilities – describing who are the actors involved in the implementation of Microsoft 365 and what can they do within each area.
Common use case scenarios – describing the overall business requirements which needs to be solved.
Solution description – a description on how the business requirements must be solved – which Microsoft 365 tool/service when? E.g. for sharing documents with externals you may prefer using SharePoint Online or MS Teams as the primary service. It is always a good exercise to demonstrate how already defined user requirements can be carried out by using a specific Microsoft 365 service.
Security – How is security handled and enforced. E.g. how is identity management and access to data handled.
Information management – How is data handled and maintained (tip: look at my article about retention policies and Microsoft’s Information governance).
Life-cycle management – Describe the process of how your Microsoft 365 applications will be provisioned, maintained and archived/deleted.

Why you need a Microsoft 365 retention policy

In modern workplaces we often see that data start to grow in very large scales. For some companies managing large number of data it often becomes a huge challenge to come in control of what data should be retained and what should be deleted.

There could be several reasons for creating a retention policy: e.g. due to legal regulations or internal company polices. But we all have run into situations loosing overview of if our documents were actually deleted as required.

A retention policy defines the rules of:

What data should be retained
How long should data be retained

The retention policy definition in general is quite simple: What should be retained and for how long? But the work to get it defined can be more complex. Therefore you should look into the below sections.

Data classification

To get a well defined retention policy in place you first need to classify your data. You can look at classifications as a way to “Categorize” your data. But classification is more a policy thing than just categorizing content.

Data classification is a standard governance operation which can help you in other situations as well.

By putting your data into classifications, you first of all help yourself creating an overview of what data you actually manage. But secondly you also prepare your solutions for applying sensitivity labels and automated retention which is supported in Microsoft 365.

It is recommended to keep your overall classifications limited to 2 to 3 classification subjects. You could have a requirement to expand this limit. If so, you should consider using retention policies combined with retention labels.

Examples of classifications:

Sensitive – “Sensitive” data often contains personal or business critical content. As a company you often want to protect this data with extra security and retention.

Private – data that is classified as “private” can be used to determine if the content should be protected by certain security policy, but at the same time a retention policy may also apply to this type of data.
Public – data that is classified as “public” usually doesn’t contain sensitive data but a retention policy is often very important because public data often seem to grow fast.

As you can see from the above, you can use classifications for different purposes. Retention policy is just one.

Use the Microsoft 365 built-in retention policies

As a part of your Microsoft 365 governance you should always consider how content should be managed. If you look into the Microsoft 365 product you actually have great options for automating this management through retention policies.

One important thing to remember is that retention policies work different for Microsoft 365 services. Thus, retention for e.g. Outlook/Exchange is different from OneDrive/SharePoint.

You can apply a retention policy for a single service or one policy for all services depending on your requirements.

The following Microsoft 365 services supports retention policies:

Exchange
SharePoint
OneDrive
Microsoft 365 Groups
Skype for Business
Exchange public folders
Teams channel messages
Teams chats
Yammer community messages
Yammer private messages

Combining retention policies with retention labeling

An effective way of automating your retention policies is to apply retention labeling. With labeling you can apply a label to a single document, e-mail or conversation and then ensure the retention policy is met.

Adding retention to your labeling is effective if your want your users (mostly editors) to apply retention themselves. The users often have the knowledge about the data, so they often also know how data should be treated. For example your HR department is more aware of how employee data should be handled rather than your IT support department.

Remember, while retention policies alone can be used to apply automatic retention on a higher level e.g. on SharePoint site collection or mailbox level, labels with retention policies can be applied to single items (documents, mails etc.). When an item is labeled to an item the retention policy applied follows the item if it is moved to another location within your Microsoft 365 tenant. This is not the case for retention policies in general. For more details, see this link.

Configuring your retention policies in Microsoft 365

As mentioned earlier above you can configure your retention policies to target any supported Microsoft 365 service individually or as a global policy.

To start configuring you retention policies in Microsoft 365, look at this article: Link.

Below is a list of links to each service that can be configured:

FAQ about retention policies in Microsoft 365

Is retention policies restricted by Microsoft 365 user license?

Retention policies added tenant wise by a global administrator applies to all users in the tenant regardless of user license.
Users with F1, F3, E1 licenses assigned does not have access to manage retention policies in the Microsoft 365 Compliance Center.

Where can I find information about how to create retention policies?

The official documentation from Microsoft can be found here: Link

Can you apply retention labels automatically?

Yes you can – see this article in order to setup automatic retention labels: Link

Is retention labels and retention policies a substitute for Records Management?

No, not really. In fact Records Management is an addition to retention labels where you can add even more features: Link

Can you apply retention based on events?

Yes, you can. Using retention labels, you can trigger retentions based on an event. E.g. if a user leaves the company, the user’s content should be retained for X period of time: Link

Find more information on Microsoft’s official governance documentation dashboard: Link