Yes, yes, that ‘C’ word again. You can’t get away from it and neither should you. Copilot is here to stay and it’s already super powerful. From a governance standpoint though, we need to ensure Power Platform DLP and Copilot co-exist, with equal importance & priority.
This article looks at how easy it is to create apps & flows with Copilot, and how essential Power Platform DLP is as a result. I’ll also close this series off with a few more thoughts around this critical subject.
Copilot will make building apps and flows easier than ever. It brings the barrier of entry down massively to help new and existing makers to get started quickly. This is hugely positive and something I’m really excited about. Yet, from an administrative perspective, it’s so important to have Power Platform DLP in place before makers are building Copilot-charged apps and flows. Example? Ok then.
Here’s a very simple prompt:
Within 3 seconds it suggests this as a possible option. Brilliant!
Add some connection references and I’m set, data breaches with the help of Copilot! You can do similar with Power Apps, too.
My point here is make sure you have a tenant-wide Power Platform DLP policy implemented ASAP. It’s all about providing the right guardrails so your makers can navigate safely to build applications and workflows. Copilot is a fun tool, makers will want to experiment and test boundaries. Make sure the boundaries are set, so when trying to save or test a Copilot-built flow with a blocked connector, they’ll still see something like this:
Resource the admins!
As I draw this series to a close, it confirms something I’ve thought for quite a while.
1- There isn’t enough priority placed on Power Platform administration.
2- Most admin resource for Power Platform isn’t dedicated. It’s a hybrid of developer, product owner, evangelist, architect and admin.
DLP for Power Platform is a big job in itself, requiring constant review and strategic planning to ensure makers are always going in the right direction. It’s well coupled with the creation and management of environments and the security required. DLP is strongly supported by the Centre of Excellence Starter Kit, either in the standard version or with custom extensions. When you have to roll out CoE updates twice each month (one for test, one for production), you’ll know it’s not a 5 minute job.
I’ve seen organisations that have multiple SQL DBAs, multiple Active Directory admins, multiple Exchange admins, and multiple SharePoint admins. These are roles that we’ve had in IT for many years. We’ve moved all of those services from servers to the cloud, but the roles and responsibilities have remained. In fact, data breaches are much more common now that we’re in the cloud, so it’s easy to argue that AD and Exchange admins have much more to do now.
Power Platform administrators are no different! Such resource needs parity with other current Microsoft-related admin roles. It’s ESSENTIAL in this new & exciting AI era, especially when Copilot creation of apps and flows could easily lead to an increase in technical debt.
Knowledge gaps
What’s also becoming clearer is the lack of knowledge about Power Platform guardrails. We’re now at a stage where experienced makers are stepping into the role of consultants or developers. The likelihood is that while they’ve developed many app and flows, they’ve not had exposure to the broader ecosystem: data modelling, security, strategies, guardrails, governance, evangelization. Power Platform DLP is an important part of that. What does it do? How does it work? What are the risks of not having it? Do I need multiple strategies?
We have entered the Copilot-driven age where we need to brush up on our consultancy skills. It’s not just about building pretty canvas apps anymore, AI will get us part of the way there already. Therefore, EVERYONE is responsible for understanding DLP and other ecosystem topics. EVERYONE is responsible for ensuring business data is secure and accessible to only those who need it. Consult with your organisation or clients to at least raise awareness about tenant isolation and the use of a tenant-wide baseline DLP policy.
To be fair, the lack of awareness probably isn’t helped by things like:
1- Microsoft Learn has a few short tutorials, but they’re high level. They’re also outdated, as some of the examples and screenshots shown have been out of date for a while.
2- Everyone loves the shiny new things. I get it, I like shiny things too. Articles about DLP won’t get the same attention because it’s not about [insert shiny new feature here]. The perception of governance features tends to be “that’s someone else’s job” or ignore it altogether.
3- Not enough real world experiences shared so others can learn from them. You only learn so much from applying DLP policies for Contoso Ltd.
Series recap
My goal for this series was to try and fill that knowledge gap a bit. I wanted to provide some granular content that others can stumble upon so they can get the help they need. It’s already proved worthwhile with those who’ve commented on the posts in the series, engaged on LinkedIn, or sent DMs about this topic (thank you!). I’m glad to have helped others gain better understanding of Power Platform DLP. I hope the series will help others too and I’ll endeavour to keep it updated.
Throughout this series, I’ve stressed the importance of keeping your enterprise data secure. For Power Platform, that means applying data loss prevention policies across all of your environments. These policies aren’t enabled by default, nor are they included in Microsoft 365 DLP. Admins may have to work through years of activity to enable these important digital guardrails.
Below you’ll find a logical sequence to ensure your business or clients are using Power Platform tools safely, with or without Copilot.
Power Platform Data Loss Prevention (DLP) isn’t the sexiest subject in the world, but its essential to have a good understanding of it. It’s important to know why it’s needed and what can happen without it.
This prevents any applications or workflows from moving data from one tenant to another. You can specifically allow certain tenants and exclude others. Make sure this is switched on for your tenant.
Using the Power Platform Centre of Excellence (CoE) Starter Kit, monitor existing and future connector usage in apps and flows. Interrogate connectors you aren’t comfortable with, articulate the risks of continued use.
In a perfect world you’ll only need 1 Power Platform DLP policy; the reality is you’ll need several. Use your connector review outputs to define what DLP policies you need for what environments. Define how you’ll manage future requests for new environments and policies.
Before implementing any Power Platform DLP policies, use the DLP impact assessment tools in the CoE Starter Kit. You’ll be able to assess any potential issues and help build a communications plan ahead of policy implementation.
Creating a Power Platform DLP policy involves aligning connectors to one of three categories – business, non-business or blocked. There are many additional features you can leverage to provide granular protection to your data.
DLP for Dataflows
Thanks to those who’ve read any or all the posts in this Power Platform DLP series!
If you liked this article/series and want to receive more helpful tips about the Power Platform every week, don’t forget to subscribe 😊
