Skip to main content
io4 Technologies

Data & Governance

DLP for non-Microsoft apps: Purview takes over from Defender on January 6, 2027

Microsoft is retiring Defender for Cloud Apps file policies on January 6, 2027, and has just extended Purview DLP to Google Workspace, Box, Salesforce and ServiceNow. What you need to decide before the deadline.

By Jordane Dours 6 min read

Microsoft is retiring Defender for Cloud Apps file policies on January 6, 2027, and has just extended Purview DLP to Google Workspace, Box, Salesforce and ServiceNow. What you need to decide before the deadline.

Two announcements that only make sense together

On July 7, 2026, Microsoft published a retirement notice: file policies in Defender for Cloud Apps stop being supported and enforced on January 6, 2027 (MC1417993). Anything not migrated by then protects nothing at all. A month later, on August 7, 2026, a second announcement landed: Microsoft Purview DLP and auto-labeling are extending to non-Microsoft applications (MC1449180).

Taken separately, both read like plumbing. Together, they describe a clear shift: file protection is moving out of Defender for Cloud Apps and into Purview, including for data that does not live in Microsoft 365. And the timeline is tight, because the replacement capability is only just arriving.

What DLP for non-Microsoft apps actually covers

The scope rides on the Defender for Cloud Apps connectors. Purview DLP policies can target Google Workspace, Box, Dropbox, Salesforce, ServiceNow, Amazon Web Services and Cisco Webex. Auto-labeling, on the other hand, only covers Google Workspace and Box.

That asymmetry matters. If your plan was to apply sensitivity labels to Salesforce or ServiceNow content, it is not on the menu: you can detect and block, not classify automatically.

The announced timeline: public preview from mid-August to early September 2026, general availability from early September to late October 2026. So the feature leaves preview only a few weeks before the January deadline. That is not much time to validate in simulation.

The two mechanisms cannot coexist

Microsoft is explicit about this, and it is the most expensive trap. Before creating a Purview policy on a non-Microsoft location, you have to turn off or delete the Defender file policy targeting that same location. Running both in parallel creates enforcement conflicts.

The safe sequence is therefore counter-intuitive: create the Purview policy in simulation mode, validate what it catches, turn it on, and only then disable the Defender policy. Without deleting it right away: keep the configuration export long enough to compare results.

What you lose in translation

Defender file policies relied on more than twenty metadata filters and a built-in regular expression engine. Purview does not carry all of that over, and Microsoft's migration documentation lists the gaps:

  • Scoping is expressed at the site level, no longer at the parent folder level.
  • The file ID condition has no equivalent.
  • Regular expressions have to be rebuilt as custom sensitive information types.
  • Several metadata filters have no counterpart.
  • Quarantine goes to an admin-managed site rather than a user folder.
  • Removing a specific collaborator is replaced by a block, which prevents future access without undoing the sharing already in place.

The billing logic changes

None of these points is a blocker on its own. Together, they mean a successful migration is not a copy-paste of rules, it is a review of your rules. A second possible surprise: usage is not covered by the licence alone. You need enterprise-tier Purview licensing, and processing files from non-Microsoft applications is billed through the pay-as-you-go Purview At Rest Protection meter, where one thousand files count as one data asset.

So the question to ask before configuring anything is simple: which non-Microsoft locations actually hold personal information or regulated data? Extending DLP everywhere because you can is the surest way to pay for scanning marketing folders.

What to do between now and January

For an organization subject to Quebec's Law 25 or to the GDPR, there is an indirect benefit to doing this now. The question of where your personal information sits and who can move it out does not stop at the Microsoft 365 boundary, and the inventory this migration forces you to produce looks a lot like the one a processing register calls for.

  • Inventory the active file policies in the Defender portal (filter on Type: file policy) and document the target apps, the conditions and the actions.
  • Sort them: detection work moves to Purview DLP, label application moves to auto-labeling.
  • Decide the non-Microsoft scope from real risk, not from the catalogue of available connectors.
  • Rebuild in simulation mode, compare detections for two to three weeks, then switch over.
  • Check the roles: compliance administration or compliance data administration on the Purview side, Cloud App Security administration on the Defender side.
Keywords:DLP for non-Microsoft appsPurview Google WorkspaceDefender for Cloud Apps file policies retirementPurview DLP Box SalesforcePurview auto-labelingSaaS data protection Law 25

Want to talk it through?

Let's spend 30 minutes on your situation.

A free assessment with an io4 architect. No commitment, no pressure.

Book my assessment
Let's talk about your project

30 minutes to frame what matters.

A direct conversation with one of our experts. No commitment, no pressure. You leave with a clear, reasoned perspective on your situation.

Or call us directly:1 888 285 9583
Free assessment