Teams, SharePoint and OneDrive best practices? Part 3: Data governance

In part 1 of this series, we discussed external sharing and chat. In part 2, we dealt with access controls and notifications. Now, we turn our focus to Data governance, a very important conversation indeed when it comes to compliance.

And when it comes to compliance, every organization is going to answer these questions differently. So I repeat yet again, there is no “best practice” here, other than you need to be talking to your stakeholders about these items. Most of the time the people who “need to know” this stuff, simply don’t. They never learned what was possible–and how would they? If you are leading or involved with the IT engagement on an Office 365 adoption project, then it is your job to educate the stakeholders, so that they can be empowered to make the best decisions for the business, and give you direction to execute appropriately.

Microsoft Teams and the invisible compliance boundary…

Before we delve into the various dials and levers that we have around data governance, it is important for us to understand just where our compliance boundary lies. What am I talking about?

Specifically, I am referring to the Teams application. Because Teams is not exactly like a traditional SaaS app, where all of the data lives in just one place. Teams is a window into data sets from, well, just about anywhere. Not only is a Team going to have data living in SharePoint, where files are stored, and Exchange Online, where conversations are written into invisible folders within your personal mailbox and group mailboxes. But, it is also possible for end-users to connect other applications into Teams, and collaborate in their groups using outside services.

None of these other third-party services are going to be covered under the compliance boundary. So when you apply a retention policy, for example, to Teams chats and channels, you can certainly capture conversations that are taking place, but you aren’t capturing anything from outside applications that are attached to various channels as a tab. Even “inside” applications like Planner, Forms or Flow–there are just aren’t any “hooks” into those apps at this time, and so these controls that we’re about to discuss–they do not apply.

Per the graphic below, which comes from this source, unless the Teams data is ingested into either Exchange Online or SharePoint Online/OneDrive for Business, it is not protected by any of the tools we’re talking about.

Therefore, I could share a file from my OneDrive for Business folder into a chat or channel, and it would covered. I could share files from other SharePoint locations, and they would be covered. But if I shared a DropBox location, or any other outside location, it would not be covered.

Make sense? Be sure your stakeholders are aware of this when you discuss compliance and data governance. Okay, now that we got that out of the way, let’s proceed.

Data retention

Find the settings that control data retention in the Security & Compliance center > Data governance > Retention.

Create a retention policy to ensure that data is preserved, even if it is deleted, for whatever time frame is appropriate to your organization. By default, SharePoint Online will only keep your deleted items available for 93 days after deletion. Then it’s gone forever. The OneDrive default is 30 days.

Speaking of which, check out the OneDrive admin center > Storage. Did you know that you can set the default storage limit per user up to 5 TB (if you have 5 or more licensed users)? And although the default retention for deleted accounts is set to 30 days, this value is actually configurable up to 10 years (3,650 days).

Now if you need custom retention periods on content in other locations (even for deleted items and messages) then you need to create some retention policies. When you do set these up, you can choose to preserve data or auto-delete data (or do both: preserve and then delete). For example some organizations may choose to specifically delete older data-sets whether to limit liability, or to manage storage/sprawl, or both. Other orgs may want to preserve data and keep it searchable, but they don’t necessarily want to delete that data after the preservation period ends.

There are no right answers, although certain regulated industries might say, for instance, you have to keep tax records for at least 7 years, or 10 years or something like that. It is important for your stakeholders to know what laws and regulations they are subject to, and they may even consider checking with their legal counsel on these matters.

Data classification (Sensitivity labels)

In every tenant that includes Azure Information Protection P1, such as via Microsoft 365 Business or one of the Enterprise plans, I would recommend discussing this item with your stakeholders. Adoption for this feature is somewhat low right now, and as of today there is a separate client-side (plug-in) installation required. But this feature is highly valuable and more people should be adopting it in the near future, especially as these sensitivity labels are made more widely available in the Office clients.

I have written about this topic extensively on this blog before. In a nutshell: using Sensitivity labels, it is possible to label (encrypt) documents and messages. That means, rather than relying on the permissions which are set on a “container” such as OneDrive or a SharePoint library, this protection applies permissions to the document itself. This is way more powerful, since it means that any labeled document will remain protected no matter what container it travels to out of its original home in Office 365.

• External USB media? Still protected.
• Downloaded to a local hard drive and then re-shared to consumer DropBox? Still protected.
• Emailed outside the organization? Still protected.
• Accidentally shared into the wrong email thread, Teams channel or chat conversation? Still protected.

You get the idea. When the document is opened, before a user can gain access to the content, Office 365 must check in with the label’s permission list as published via Azure Information Protection. Does this person have access or not? If yes, what level of access do they have?

To consult with stakeholders regarding these labels, there is a fair amount of planning required. You will want to gather from them:

• What labels do we want to publish? Public? Confidential / All employees? Other custom labels?
• What will the labels do? Header/footer/watermark? Encrypt content? Restrict access to specific groups? Which groups?
• How much restriction will be placed on each label and for each group that has access to the label?
• Do you want to allow offline access to labels (for example so that your authentication is good for say 7 days before re-authenticating)?
• Who should be allowed to see/apply which labels?
• Should users be able to remove labels (providing justification)?
• Should certain data-sets be auto-labeled (requires Azure Information Protection P2)

If you need to review the pre-defined permissions roles that are available then check out this table, below:

Custom permissions are also possible. And, you can assign multiple groups to each label, each with a different permission role. So for instance you might have a Finance label that grants Co-Owner to the Finance users, Co-Author to Upper Management, and Reviewer or Viewer for Board members.

For further reference I cannot recommend this Microsoft article highly enough. It contains great detail, links to other good references/resources, and explains the differences between the classic labels, and the newer “unified” labels very nicely.

Data Loss Prevention (DLP)

Last but not least, I’ll include a tip of the hat to DLP. You can do a lot with this tool, but its primary purpose is to limit or prevent the over-sharing of sensitive data types. Find this under the Security & compliance center > Data loss prevention > Policy.

Again, options here vary widely based on industry, compliance requirements, and so forth. I have written some articles detailing examples of these policies in action, you may refer to them below:

• Auto-encrypt sensitive info types such as GLBA (Email only)
• Automatically file an incident report for HIPAA 

Wrap-up

Again, this overview is not meant to be exhaustive–we didn’t really cover other compliance related topics like Content search and eDiscovery. Certainly part of your engagement and customization would be learning who in the organization should have eDiscovery rights. We could go on and on here. But, at the end of all of this, I hope that through this series I have illustrated my key point: when it comes to SharePoint, Teams and OneDrive, one thing is certain–we’re going to continue to see the adoption of these services balloon in the next few years. And the only best practice “take-away” that I have for you is this:

Be sure to cover off on security & compliance related considerations with your stakeholders in the project. There is no right answer, and no wrong answer, except of course skipping the question.

Successful implementation (and adoption) depends on tackling these types of questions. Plus, being able to advise on good security & compliance hygiene will open up many other opportunities for you as the trusted technology adviser (whether you are internal IT, or a consultant like me). From there, you will likely run into host of other considerations you need to work through with your stakeholders. One opportunity leads to another, leads to another, leads to another.