Put ‘Power Platform DLP’ or ‘Power Platform Data Loss Prevention’ into Google. You won’t find a huge amount of content ranking highly that isn’t published by Microsoft themselves. Why is it so lacking in what is a KEY area to enable a workforce with the Power Platform? There’s loads of content on the ‘fun’ stuff; building apps, setting up ALM, doing magical automations. Whether you’re a consultant, developer or business decision maker, Data Loss Prevention HAS to come before all of that. At least from a technical perspective, anyway.
Power Platform DLP is one of my favourite subjects over the past few years. I’ve done many DLP review & rollouts and seen a lot that I’m excited to share through my blog. In this first of a multi-part series, I’ll dive into what Power Platform DLP is, why it’s so important and the risks you face without having it.
DLP stands for ‘Data Loss Prevention’. As per this Microsoft Security article, it’s “a solution to identify and help prevent unsafe or inappropriate sharing, transfer or use of sensitive data“. Most on-premise and cloud tools these days will have DLP features that can be enabled by administrators. It keeps organisations free from data-related risk, it’s also fundamental for maintaining compliance against national and/or international regulations.
Data leaks from within an organisation can be caused by compromised users, intrusion by attackers (ie phishing), or unintentional or deliberate data exposure by employees. The latter is especially true with the Power Platform, as it’s so easy to do without any DLP in place.
What is Power Platform DLP?
Power Platform DLP helps to prevent your employees from exposing organisational data via the Power Platform toolset. With access to over 1,100 API endpoints (aka connectors) and the ability to build your own, it’s easier than ever to send company beyond the digital walls.Â
To help, bespoke Data Loss Prevention policies for Power Platform use can be created and deployed. These provide guardrails as to what connectors your employees can and can’t interact with. These policies are created in the Power Platform Admin Centre by someone with sufficient access.
But we already have DLP
I would hope so, certainly for the wider Microsoft 365 services anyway. There’s WAY more knowledge around this and you’ll find most M365 admins have successfully protected their organisations data with DLP.Â
These days, Microsoft Purview is the place to configure DLP for a range of Microsoft-related services. There’s a lot of fantastic information here, but what do you notice about the below extract from that URL?
That’s right – there is no mention of the Power Platform. Power BI is part of that platform and that’s called out individually there, but nothing for Power Apps, Power Automate etc. I guess it’s easy to assume they’d be covered automatically.
In my experience of working across a range of clients, this assumption is very common. One of the first things we say to clients on engagements – it’s not. Power Platform DLP is its own living organism that you have to plan for and configure; it’s off by default. What follows is usually some widening of pupils & fidgeting on seats, as the realisation sinks in that there’s a weak point for exposing company data.
That's ok, no-one is using the Power Platform
The go-to response when we question if Power Platform DLP is in place, and they say no. Most organisations haven’t truly planned for, or even discussed wider Power Platform usage. It’s not been in any of their roadmaps, therefore no-one’s using it because it hasn’t been rolled out. It’s another common assumption we see as consultants.
Unfortunately, there’s this tiny little thing called the Power Platform default environment in every Microsoft 365 tenant. It’s created automatically, can’t be deleted and EVERY employee in your Active Directory has access to it. In this environment, they can freely build apps, flows and chatbots. These can use any of the available connectors to potentially leak personal or company data.
This is usually where the CoE Starter Kit comes in. Installing this and viewing the Power BI reports will quickly show activity in the default environment. It will highlight what connectors are being used and so can plan for Data Loss Prevention. I’ll cover this in more detail later in the series.
Naughty naughty
Here’s an example I’ve encountered of “no-one is using Power Platform in our company”. I previously worked with a large organisation who had 3000+ SharePoint sites, each with their own levels of security. The Power Platform default environment had 5+ yrs worth of activity but wasn’t given the resource or attention. As such, there wasn’t a hardened focus on the tools or how data could potentially be exposed. After many internal battles we were allowed to install the CoE Starter Kit. Our first step was to have a look at connectors being used, high on the list was Google Drive. The company was a Microsoft house so this rung some alarm bells. Why would anyone need to use Google Drive in Power Apps or Flow?
Well, here’s one such example:
On the face of it, that’s sharing company data inside of SharePoint with an external service.
It got worse.
The document library in question was used by therapists to store notes for their daily therapy sessions with clients. VERY sensitive information. Each time any therapist added a new set of notes, the flow ran and made a copy in the personal Google Drive of the flow creator. No DLP or Data Protection Impact Assessment in place, no Data Sharing Agreement in place either.
This may have been completely harmless of course. At this company there was lots of hatred towards Microsoft 365. People wanted to use Google instead so they created flows to move or ‘sync’ libraries and calendars. There wasn’t awareness on the risks to themselves or the organisation, but so free and easy to set up. Unmonitored, ungoverned, in the default Power Platform environment.Â
You might think that example is a bit extreme. It’s on that end of the scale, sure, but I’ve seen that or similar so many times – and not just in a default environment either! I could cite many examples involving 3rd party file or email services that will, unknowingly or otherwise, present risk. There’s so many connectors available now, it’s hard to keep on top of what ones are the right ones to use. It’s easy to see why Power Platform DLP is so important, but worrying that it’s not as sharply in focus as it should be.
It's like a Sat Nav
Along with a solid environment strategy, Power Platform DLP is one of the key guardrails for the Power Platform. But I urge you not to think of it solely as a governance tool. All to often we engage with clients who want to “restrict”, “control”, “govern”; Power Platform DLP is your first step to guiding and nurturing a maker culture within your organisation. You can’t shut down the default environment but you guide employees to use it sensibly, without risking themselves or the company.Â
When we travel somewhere we’ve never previously been, chances are we’ll use satellite navigation. These days they’re either built into cars or available on our smartphones. They’ll automatically detect our current location, then after putting in our destination, will present us with multiple routes to choose from. We can select the one we want based on time, or avoiding toll bridges or major roadworks. We trust the sat nav to get us to where we need to, in the most safe & efficient way.
Power Platform DLP is no different. You can’t stop people from making apps and flows in the default environment, but you can guide them. Give them multiple paths (aka connectors) they can use to get to their destination (aka building kick-ass solutions to rubbish processes), in the safest way possible.
How does it work?
In a Power Platform DLP policy, connectors can be placed in 1 of 3 categories; Business, Non-Business or Blocked. An app or flow must use connectors only in the Business category, or only in the Non-Business category, you can’t mix and match. Let’s use the earlier SharePoint to Google Drive example to visualise.Â
If both connectors are assigned to the Business category in a DLP policy, the flow will work. Any user wishing to make a new flow with this relationship will be able to:
If both connectors are assigned to the Non-Business category in a DLP policy, again the flow will work. Non-Business is the default state for all connectors. Any user will be able to do this right away without an active policy in place:
If one connector is in the Business category and the other in Non-Business, the flow won’t work. It doesn’t matter which connector is in which category. Anyone trying to create a new flow with these connectors will be blocked from doing so:
In the same way, if either connector is aligned to the Blocked category, the flow won’t work.
Therefore, to protect your company data within the Power Platform, it’s imperative to create Data Loss Prevention policies. It’s your responsibility to ensure only business-approved connectors are to be used for Power Platform transactions. You can have different policies for different use cases, but you’ll need a baseline stance to at least cover the default environment. You may have some extra work on your hands if your employees have already had unrestricted freedom until now.
Hopefully this has provided a good introductory insight into Power Platform DLP. As we move through this series, I’ll articulate how to build a baseline policy and provide very granular insight on connectors to watch out for. I’ll also go over steps to run an impact assessment to see assets that could be affected by a DLP policy.
The next article in the series will focus on getting a deeper understanding of some of the connectors, and where we’d align them in a DLP policy.
If you liked this article and want more epic Power Platform stuff to land in your inbox every week, don’t forget to subscribe 😊
Thank you for this good article
You’re welcome!
As always brilliant, article, super clear and concise.