This is the final part of a 3-part series on OneDrive For Business Sharing Policies, and their impacts to Mergers, Acquisitions & Divestitures (MAD).

Review

In Part 1, we covered How To View OneDrive For Business Sharing Polices In PowerShell & The Admin Center.  This post can be found here:  https://madmike.net/how-to-view-one-drive-for-business-sharing-polices-in-powershell-the-admin-center/

In Part 2, we showed how to change OneDrive For Business Sharing Policies in PowerShell at the user level.  This post can be found here:  https://madmike.net/how-to-change-onedrive-for-business-sharing-policies-in-powershell-at-the-user-level/

In this part we will review why OneDrive For Business Sharing Policy analysis is important in Mergers, Acquisitions & Divestures, and provide some practical advice.

Conflicts In Policy

In Part 1 we covered the Sharing Policy and how to look at User Policies.  As part of the planning stage for migrating OneDrive for a Tenant-To-Tenant project, this simply must be done to ensure there are not unintended impacts.  These policy decisions need to be done in advance, and not just something that pops up after the users migrate.

Looking at the overall organization policy simply isn’t enough, as users can have a more restrictive policy, sometimes for good reason.  See the bottom of this post for advice on this issue.

Let’s dive into common scenarios on why these policies may conflict and what this means for the migration.

Reduce Data Risk

Quite simply put, anytime we can turn off features that do not need to be used, we can focus on other things.  If our organization’s behavior results in limited needs for external collaboration, then it isn’t a bad idea to turn it off.  We must be careful though, because as times change, so does our business.  (For example, buying a company that needs external collaboration!)  If we keep things too restrictive, and legitimate business needs exist, we will find shadow IT popping up.  (I will repeat this mantra several times in this article.)  It is always better to control and audit systems, rather than business units signing contracts or finding ways around policies.  Some would argue this issue alone is a reason to keep external sharing open regardless of today’s needs.

Regulatory / Contract Compliance

Some business units may have very tight language and require closing certain features, or the language infers this should be done.  Employees with access to very sensitive data may need to be “locked down”.  These policies may not be consistent through-out the organization.  For example, perhaps a government contract requires stricter controls, but the marketing teams are not under these restrictions. 

Best Practice?

Logically a lot of us can understand the best practice of turning off anonymous links or disabling low security options.  In the past, allowing anonymous links was popular as it supported users that are not on Office 365.  Many users “defaulted” to using this option because it was easy and seemed to always work, but the users never fully understood how it worked.  For collaboration, where any barrier is a barrier to business, these habits can easily be understood, and hard to break.  However, as time has gone on, most companies are using the service, or can use stronger authentication options.  This also means security can be seamless for most users now.

Bad Practice?

Then we have the final “just because” reason for tighter security.  This includes the “it’s just the way we did it” justification, or organizations that really tightened controls as part of their cloud adoption strategy.  Sometimes these practices are right, but for the wrong reason.  When I find organizations that have used strict policies, but do not have a strong business case for it, it reminds me of an old, and out of date, IT mantra where IT puts down policies “just because”.  Again, this just breeds shadow IT, which increases data risk.

That all said, organizations moving away from anonymous links is generally accepted as a good idea.  If you require a user to be in the directory for users, but there is no vetting in the approval process to get a user added, and you have difference in policy, it may be time to review this setting to make sure it still suits your business purpose without creating unneeded risk

Differences in Date Policies

Another common policy difference is the sharing link expiration setting.  If you have anonymous links turned on, and do not expire them, you really need to consider this change.

Organizations drastically differ on this setting and the setting can have significant impacts on your collaboration. The default of -1 means there is no expiration.  On the flip side, if you only allow 90 days, but most of your external collaboration is on-going, this setting may not be right for you.  Again, reconciling this setting is part of the MAD planning process.  Looking at power users to understand their requirements for sharing limits will guide you to the right decision.

Reconciliation Process

If the new organization is more restrictive:

This scenario really falls into the traditional MAD scenario.  It will invoke emotions of the “big bad buyer” coming in and forcing things down.  (something we covered in our Method To The MADness series which can be found here https://madmike.net/method-to-the-madness/)  This is particularly true if the new organization has a consistent standard across all users that is stricter than what you have today.

When this happens, you should follow these steps:

1. Why is the source company’s policy looser?  Was it just preference, or is there a real reason why?
2. How often is this looser policy being used?
3. Will this setting change cause a barrier to business?
4. What is the data being shared in the target today and what is the risk of changing the setting?
5. Will my external customers from the source tenant be able to easily comply?

Once you have answered these questions you will find yourself with some paths forward:

1. Accept and communicate the change.  Good communication with a security centric announcement can make the change easier to accept.
2. Lower the policy in the target tenant, raise the strength of the policy on the existing target users to the current org setting.  Next, Lower the setting for the users moving over.  This is a complex decision and requires maintenance, but if there is a real business need, it may be the right path forward.
3. Lower the target policy for everyone.  This is common if the stricter setting isn’t necessary or is no longer the right choice.  You may require additional training on how to protect data for all users, or only for users that need this new lower setting.
4. Use a different service for a subset of sharing needs.  Perhaps the sales system can be used to share quotes?  Perhaps we create a SharePoint or Teams site with external access that may be easier to use?  In rare situations you may use a third-party system for this need, but ensure it is controlled!

Ignoring this issue is not an option.  If you do restrict things more, you also need to monitor for users . . . you guessed it . . . leveraging shadow IT.

If the new organization is less restrictive:

In this situation you may be thinking it is a “slam dunk” but it isn’t always this way.  You may find new challenges, and again need to find out why this setting was selected in the source.  You should follow these steps:

1. Why is the source company’s policy stricter?  Was it just preference, or is there a real reason why? Are there contracts that mandated it?
2. Will this setting change increase data risk? 
3. Is the data in the source environment of higher sensitivity than the target company is used to?
4. If some users are stricter than others, you need to scope why they are this way and make a determination of the right path forward.

Once you have answered these questions you will find yourself with some options:

1. Accept and communicate the change.  Enhanced functions are typically easier to communicate, but you may want to communicate proper use of the change.
2. Increase the target policy and bring everyone to a tighter policy.  This is a good idea if the company is moving into a more regulated environment or will have to meet certain contracts together..  The most common change is turning off anonymous links, something most organizations are moving to.
3. As users move over, keep the source users on a stricter policy, but at the user level.  Leave the existing target users at the looser policy.  This is a great solution if the new organization is going to be operating in a segmented manner and may allow you to meet contractual requirements needs if they exist.

End of series…

That’s it for this series!  Thank you for following.  OneDrive sharing policies are getting a lot more attention these days.  As we covered, in Merger, Acquisition & Divestiture scenarios, we have to address them head on to avoid business disruptions.

If you would like to discuss this topic more, feel free to contact me!