Microsoft Purview DLP: Instances Policy Location Retiring in January 2027

Microsoft has announced the retirement of the Instances policy location in Microsoft Purview Data Loss Prevention (DLP), with the change taking effect on January 6, 2027.

Today, organizations using the Instances location rely on the Microsoft Defender for Cloud Apps file policy infrastructure to enforce DLP and auto-labeling policies across supported third-party applications. To simplify policy management and provide a more consistent compliance experience, Microsoft is moving away from this approach and introducing dedicated application-specific policy locations directly within Microsoft Purview.

Supported applications include:

  • Google Workspace
  • Box
  • Dropbox
  • Salesforce
  • ServiceNow
  • AWS
  • Cisco Webex
What’s Changing?

Instead of creating policies under a generic Instances location, administrators will use dedicated locations for each supported application.

For example:

Current LocationNew Location
Instances (Google Workspace)Google Workspace
Instances (Box)Box
Instances (Dropbox)Dropbox
Instances (Salesforce)Salesforce
Instances (ServiceNow)ServiceNow
Instances (AWS)AWS
Instances (Cisco Webex)Cisco Webex

This change aligns non-Microsoft application protection more closely with the broader Microsoft Purview compliance framework.

Microsoft is introducing these new application locations ahead of the retirement date to allow organizations time to migrate.

Key dates:

  • Dedicated application locations will be rolled out before retirement.
  • January 6, 2027: Instances policy location officially retires.
  • Retirement rollout begins in early January 2027 and is expected to complete by mid-January 2027.
What Happens After January 6, 2027?

Once the retirement takes place:

  • New policies can no longer be created using the Instances location.
  • Existing policies configured with the Instances location will no longer be supported.
  • Organizations should use the new dedicated application locations for all future DLP and auto-labeling policies.
  • Policies that continue to rely on the retired Instances location may no longer be enforced as expected.

If your organization currently uses the Instances location, Microsoft strongly recommends recreating those policies in the new application-specific locations before the retirement deadline.

Recommended Next Steps

To avoid any disruption to DLP enforcement, organizations should begin preparing well before the 2027 deadline.

1. Review Existing Policies

Identify any DLP or auto-labeling policies currently configured through the Instances location.

2. Identify Affected Applications

Determine which non-Microsoft platforms are involved and map them to their new dedicated policy locations.

3. Recreate Policies

Build equivalent policies using the new application-specific locations within Microsoft Purview.

4. Test and Validate

Before retiring legacy policies, verify that policy enforcement, labeling, and user experiences behave as expected.

5. Update Documentation

Review operational procedures, internal documentation, and administrator guidance to reflect the new management model.

6. Notify Stakeholders

Make sure compliance, security, and support teams are aware of the upcoming change and migration timeline.

While the retirement is still several months away, organizations using third-party cloud platforms for collaboration and data storage should start planning their migration strategy now. Moving to dedicated application locations will ensure continued DLP and auto-labeling protection while providing a more streamlined and unified compliance experience within Microsoft Purview.

The bottom line: If you’re using the Instances location today, plan your migration before January 6, 2027. If you’re not, you can safely continue using Microsoft Purview as normal and take advantage of the new dedicated application locations as they become available.

Microsoft Purview Tightens Rules for Custom Sensitive Information Types

Organizations using Microsoft Purview custom Sensitive Information Types (SITs) should be aware of an upcoming change that may require updates to existing regex patterns.

Microsoft is moving forward with enforcing a long-documented rule that allows only one capturing group per regular expression in custom SIT definitions. The goal is to improve the consistency, reliability, and predictability of how sensitive data is identified and classified across Microsoft Purview and Data Loss Prevention (DLP) workloads.

When is this happening?

The rollout is expected to be completed by early July 2026 across all Microsoft cloud environments, including:

  • Worldwide
  • GCC
  • GCC High
  • DoD
Who is affected?

This change primarily impacts:

  • Microsoft Purview administrators
  • Compliance teams managing custom Sensitive Information Types
  • Organizations using custom SITs in DLP, data classification, and compliance solutions

The enforcement applies whether SITs are managed through:

  • The Microsoft Purview portal
  • PowerShell, including:
    • New-DlpSensitiveInformationTypeRulePackage
    • Set-DlpSensitiveInformationTypeRulePackage
What changes?

Once enforcement is in place:

✅ New custom SITs must contain only one capturing group in each regular expression.

❌ Creating a new SIT with multiple capturing groups will be blocked.

❌ Updating an existing SIT that contains multiple capturing groups will fail validation.

❌ Administrators will not be able to save changes to existing SITs until non-compliant regex patterns are updated.

What about existing SITs?

Existing custom SITs that contain multiple capturing groups will continue to work in their current state. However, they become a potential issue the moment you need to modify, update, or re-save them.

In other words, if an existing SIT contains a regex pattern with multiple capturing groups, you’ll need to redesign that pattern to comply with the one-capturing-group rule before any future changes can be saved.

Many organizations rely on custom SITs to identify sensitive business information and power key compliance capabilities such as:

Why does this matter?
  • Data Loss Prevention (DLP)
  • Data classification
  • Compliance monitoring
  • Information protection policies

If a custom SIT cannot be updated because it fails validation, it could delay policy changes, compliance updates, or new data protection initiatives.

What should you do now?

To avoid surprises, Microsoft Purview administrators should proactively:

  1. Audit existing custom SITs
  2. Identify regex patterns that use multiple capturing groups
  3. Redesign patterns to use a single capturing group
  4. Test and validate updated SITs before future modifications are required