It’s easy to create and implement a Power Platform DLP policy. Sometimes, your business might need an immediate ‘quick fix’ to plug a few leaks. However, you can make a strong case for fully understanding all business requirements first. There’s likely to be different scenarios that will need different policies, so defining your Power Platform DLP strategy is critical for its success.
As a quick note, Power Platform DLP strategy usually goes hand-in-hand with environment strategy. One will, more often than not, have an impact on the other. The DLP strategies outlined below are largely derived from previous DLP implementations I’ve done and common environment ‘patterns’. Endeavour to establish a robust environment strategy for your business, ensuring your Power Platform DLP policies compliment nicely.
In terms of policy construction, a reminder that a connector is aligned to one of three categories; Business, Non-Business or Blocked. This article focuses heavily on connector patterns we’d typically align to the Business category of Power Platform DLP policies.
In the previous article of this series, I walked through how to run an impact assessment for a proposed policy. You can repeat this exercise many times against any number of environments. In that example I used what I refer to as a baseline policy, your MVP – Minimal Viable Policy 😉.
This will likely form your tenant-wide Power Platform DLP policy; your ‘catch all’ for ANY new environments created, granting access only to the core essential connectors. Typically, these will be any that are unblockable and relate solely to the Microsoft 365 stack plus a couple of others. This will also be the policy that guides users in your Power Platform Default environment, which is absolutely ESSENTIAL.
In the example below, our baseline is connectors that can’t be blocked, plus the following: Microsoft Forms, Power Apps for Makers, Power Automate Management.
A typical baseline DLP policy would have the following in the Business category, with anything else moved to Blocked:
If there are connectors within this batch you don’t want users in the default environment to use, align them to the Non-Business category of your baseline. Keep everything else in the Business category. An example of a Non-Business category here might be Skype for Business Online, especially if your organisation has embraced Microsoft Teams. I would also recommend moving Dynamic 365 Customer Voice to Non-Business for your baseline. If this policy is to cover your default environment, it’s unlikely you’ll want production ready D365 functionality running from there.
If you’ve not yet committed to Dataverse, this could be another candidate for moving to Non-Business for your baseline.
Dataverse for Teams
Are you adding Dataverse to Non-business for your baseline policy? Consider the impact on Dataverse for Teams. This is a scaled-down offering introduced during Covid, that allows anyone to make apps and flows behind a Microsoft Team. If you want to use it to create solutions that interact with other core platforms (ie SharePoint, Office 365 Outlook), Dataverse must be assigned to the same category in a DLP policy.
These environment types are easy to identify in the Power Platform Admin Centre. They’re also easy to identify when you add or remove environments in the DLP Creator:
Typically, I’ve seen these environment types covered by the same policy as the default environment. Depending on your organisational requirements and/or environment strategy, you may or may not want to do the same. If you want Dataverse for Teams environments to have their own policy, you must set up a process to exclude them from the base policy and add them to a specific D4T policy.
Your organisation may have one or more Dynamics 365 tools in use. These may be part of the same Power Platform/Business Applications team, or they may be completely separate. I’ve experienced both equally, and DLP alignment can be difficult depending on the circumstances.
As you can see from the baseline above, there are no Dynamics 365 connectors. A good strategy is to have a dedicated DLP policy just for your D365 environments. Remember, these are still running off a Dataverse backend, so make sure that’s in the same category as your D365 connectors.
If your DLP baseline policy automatically captures new D365 environments, you may need an internal process to manage the policy after it’s created. For a typical Power Platform DLP policy dedicated to D365 environments, you’ll likely want all these in the Business category:
Add or remove any related D365 elements according to the needs of your business.
CoE Starter Kit
Microsoft recommends setting up 2 environments for the Power Platform Centre of Excellence (CoE) Starter Kit. One for testing monthly releases and another for your business facing (aka Production) instance. You’ll need a dedicated DLP policy that includes these 2 environments to allow the connectors listed in the CoE setup documentation.
You can create a policy that only allows those connectors in the Business category. However, I’d recommend including all the other ‘baseline’ connectors if you want to create your own CoE-related customisations/extensions:
It’s common that community / developer environments can be created by anyone in your tenant. An administrator can turn this off so that they can only be created on request. Developer environments provide a user with free access to premium features, which means they have their own personal sandbox to create proofs of concepts. They can also use the ability to experiment with other connectors, unless this is properly regulated.
For those who freely allow their users to create them, it’s important that your tenant-wide policy captures them immediately. You may want to set up a different DLP policy for these environments to allow connectors that aren’t available in the default environment. In this case, too, you need a process to switch a created developer environment from the tenant-wide DLP policy to a standalone or developer environment-centric policy.
I’ve seen ‘Power Users’ being given their own Power Platform DLP policy in previous engagements. This is another good example of being able to provide additional connectors to individuals under an agreed context. For example, perhaps they want to build some automations with some of the Azure connectors. This would be something a user can’t do in the default environment with the tenant-wide DLP policy, but could do elsewhere.
Organisations have many different ways to identify their power users. They may have developed and published a set of solutions, or they may be helping to train others to use the Power Platform tools. They’re likely part of your ‘champions’ network. So giving them the opportunity to test and review other connectors can help them identify new ways to innovate in your organisation.
Many companies have many different ‘approved’ and licensed data sources, such as SQL Server, Saleforce, DocuSign or Azure DevOps. As part of your strategies, determine where additional connectors need to be located for the business units. Who is making things, where are they making them, where should they make them? There are many ways to split your Power Platform DLP strategy. Make it work for you and your business.
And one more thing to consider. As an administrator, you can apply multiple Power Platform DLP policies to a single environment. In my experience, that’s like steering a car with your knees: you can do it, but that doesn’t mean it’s a good idea. You only have to scroll down to the bottom of this MS Docs article to see the line “we highly recommend you apply a minimum number of policies to any given environment“.
Personally, I’d recommend that each environment be subject to only one DLP policy at any given time. Don’t give yourself any unnecessary headaches, life is stressful enough.
Be prepared to pivot
For all the best intentions and strategy, you can’t plan for every eventuality. There are likely to be exceptions to the rule that you’ll need to handle on a case-by-case basis.
In a previous DLP deployment I worked on, a particular maker requested their Developer environment have its own DLP policy. They would routinely log a ticket to add or remove connectors from the Business category. This enabled them and their department to evaluate integrations and identify possible cost/time savings. As it was a dedicated policy for a single environment, these connectors weren’t available to everyone else. This was still kept sensible as well, only using connectors that were considered acceptable to internal security & governance teams.
My point is to remain open-minded. The design of DLP is to provide safe routes for makers to make safely. There’s highly unlikely to be a one-size-fits-all approach, as some of the above examples have shown. It’s about finding a great balance between guardrails and innovation.
The most important part of the whole process! Deploying a Power Platform DLP strategy isn’t always easy, especially when there’s already been activity in your tenant. If there’s a high change of apps and/or flows being impacted, work with makers to help alleviate fears and maintain business continuity.
For example, those who’ve used the Mail connector in their flows. Amazing, praise them! They’ve been innovating, they’ve made an automated process that saves them & colleagues some time. They weren’t aware this isn’t the best connector to use. They’ll perhaps need a softer approach to help transition them to the Office 365 Outlook connector instead, so their flows carry on performing as planned.
Makers creating copies of SharePoint documents to their personal Google Drive, well maybe they need some slightly stronger comms!
Hopefully these example policies give some idea as to the thought process for Power Platform DLP. If you’re able to have 1 policy to govern everything – great! The reality is you’ll likely need a few. Use your connector review and impact assessments outputs to best inform strategy and communication plans.
If you liked this article and want more epic Power Platform stuff to land in your inbox every week, don’t forget to subscribe 😊