Purview DLP and auto-labeling in Google Workspace, Box and Salesforce: cross-cloud data protection reaches preview

Organisational data long stopped living inside Microsoft 365 alone. Sales works in Salesforce, marketing shares via Box or Dropbox, the service desk logs tickets in ServiceNow, and engineering runs pipelines on AWS. For security and compliance teams that has meant fragmentation: the DLP policy you build in Purview stops at SharePoint, OneDrive, Exchange and Teams. Everything beyond that was a separate exercise in a separate console.

Since mid-August 2026 that changes. Microsoft has confirmed via the Message Center that Purview Data Loss Prevention and Information Protection auto-labeling are being extended to non-Microsoft applications in stages. The preview has started, general availability follows in early September 2026, and the worldwide rollout is scheduled to complete by the end of October 2026. For organisations with a hybrid SaaS landscape, which is now the norm, this is one of the most important steps toward a single consistent data protection policy.

What exactly is Microsoft rolling out?

The expansion has two tracks. The first is DLP policy: you define a policy in the Purview portal that applies to Google Drive or Box, using the same building blocks as today: content inspection based on sensitive information types, sensitivity labels or trainable classifiers as conditions, and actions such as block, warn, quarantine or restrict access.

The second track is Information Protection auto-labeling. Files in Google Workspace and Box can automatically receive a sensitivity label based on the same rules you use today for Office files, including matching protection, encryption and usage rules. The common thread: your existing Purview configuration for labels and information types is reused, you extend your current policy to more destinations without building a second taxonomy.

Which applications are supported?

The initial list is broad and covers most SaaS tools you encounter in a typical business. For DLP policy that includes Google Workspace, Box, Dropbox, Salesforce, ServiceNow, Workday, AWS, Cisco Webex, Slack and GitHub Enterprise Cloud. For auto-labeling the initial focus lies on Google Workspace and Box, where files can receive a sensitivity label including matching encryption.

Microsoft explicitly notes that available conditions and actions vary per application. That is unavoidable: every SaaS has its own API and its own model for shared and external access. In Salesforce you respond differently to an export than in Google Drive to an outbound share link. When building policy, review the available actions per application rather than assume everything works everywhere.

How does it work under the hood?

The connection runs through Microsoft Defender for Cloud Apps. For every SaaS you want to protect, you connect the matching MDCA app connector. That connector gets OAuth permissions to read metadata and, where the application allows it, request content and perform actions, for example revoking access to a shared link or moving a file to quarantine.

In the Purview portal you then configure your DLP or auto-labeling policy and select the non-Microsoft application as a location. Purview sends the policy through MDCA to the connected application. Detections, incidents and policy tips flow back into the familiar Purview and Defender dashboards, where your security team processes them in the same workflow as your existing Microsoft 365 signals.

You need a Microsoft Defender for Cloud Apps licence, typically part of Microsoft 365 E5 or available standalone, plus the appropriate Purview licence for DLP and auto-labeling. On the source SaaS an administrator must approve the MDCA connector: this requires alignment with the owner of, for example, the Salesforce or Google Workspace tenant.

What is included and what is not yet?

In the preview, not every scenario you know from Purview for Microsoft 365 is available one-to-one. Endpoint DLP actions such as blocking copy to a USB stick remain a Windows and macOS endpoint story, independent of what happens in Google Drive or Box. Advanced scenarios around insider risk signals are also not yet fully extended.

What does work from the first phase: detection on sensitive information types and existing sensitivity labels, alerting and policy tips for users, blocking or quarantining on disallowed sharing actions, and applying labels to new and modified files in Google Workspace and Box. For most concrete DLP use cases, such as preventing a customer list from being shared externally, this is sufficient.

Also account for the staged rollout: if your tenant sits later in the worldwide wave, several weeks may pass between preview and the policy actually enforcing on your connectors.

What does this mean for your current DLP strategy?

For many organisations the first reflex is understandable: finally a consistent layer, so roll out all existing policies to Google Workspace, Box and Salesforce as fast as possible. That is unwise. A DLP policy that works well on SharePoint can, in a SaaS with a different sharing model, immediately produce hundreds of false positives, obstruct users and erode support for the whole programme.

The sensible approach: first inventory which non-Microsoft applications hold your most sensitive data. Often that is two or three, not ten. Then run a targeted pilot per application with a single policy, for example BSN numbers or credit card data, in monitor mode. Only after demonstrably low false-positive rates do you move the policy into enforce mode.

The same applies to auto-labeling. Start with a label you already trust in the Microsoft 365 environment, such as Internal or Confidential, and measure how often the auto-label logic applies it correctly on Google Drive or Box before you activate encryption and usage restrictions.

Four preparation steps for the coming weeks

First, map your SaaS portfolio. Which non-Microsoft applications does your organisation really use, who owns each tenant and who is the business owner? Without this inventory you cannot prioritise the rollout.

Second, check your MDCA licence status. If you are not yet using Microsoft Defender for Cloud Apps, now is the time to determine whether you already have the licence through an existing E5 or Security suite or whether you need to expand. The MDCA connector is the key: no connector, no Purview extension.

Third, review your existing sensitivity label taxonomy. If you use three labels today, that is fine to extend. If you have a heavily broken-out taxonomy with dozens of sub-labels, evaluate whether that complexity translates to the other SaaS. Often this is a good moment for consolidation.

Fourth, plan communication toward business owners. Users who could work freely in Google Drive or Box until now will start seeing policy tips, warnings or blocks. If that arrives without notice, friction grows. A short notice with explanation demonstrably works better for changes like this than a silent rollout.

Extending Purview to non-Microsoft applications is not radical new technology, but it is a fundamental step in simplicity. Where you needed multiple consoles until now to make data protection consistent across your SaaS landscape, that can be done from one central place. For IT teams with limited staffing, that translates into less time, fewer errors and an auditable policy.

Want help inventorying your SaaS portfolio, setting up Purview DLP for non-Microsoft applications or integrating MDCA into your current environment? Zarioh helps with the complete configuration of Purview, MDCA and Defender XDR for organisations managing data across multiple clouds. Contact us for a no-obligation conversation.