Phase 2 – Building the DLP Operating Model

RBAC for Purview DLP Incident Management.

Overview

The DLP Response Pyramid defines who owns each layer of the incident lifecycle. But a layered model without a matching access model is just an org chart. This post covers how to configure Role Based Access Control (RBAC) across Microsoft Defender XDR and Microsoft Purview to make that model operational, and why the dual-portal nature of DLP permissions is exactly where most deployments fall short.

Quick recap

In the previous post, I introduced the DLP Response Pyramid, a layered operating model for DLP incident handling:

Triage → Investigation → Containment → Governance

Each layer has a distinct scope and a distinct definition of “done.” The model only works if the access configuration matches the responsibilities of each layer. Tier 1 analysts who can view full sensitive content make decisions they shouldn’t be making. Tier 2 investigators who can’t access content can’t do their job. Tier 3 responders who lack action rights become a bottleneck before every containment decision.

Getting RBAC right isn’t just a configuration detail, it’s what makes the operating model functional.

A note on the tier model

The three-tier structure used here – Triage, Investigation, Containment – is my suggested pattern, not a prescription. Organizations with smaller security teams or flatter structures may combine tiers based on capacity. Level 1 and Level 2 are frequently merged into a single analyst role. In some environments, Level 2 and Level 3 are the same person. That’s a perfectly valid operating model as the underlying permission logic still applies, it just maps to fewer distinct identities.

The goal of the tier model is to define what access each function needs, not to dictate headcount or org structure. Use it as a reference and adapt it to what your organization can actually sustain.

Why DLP RBAC spans two portals

This is the part that catches most deployments off-guard. DLP incident management permissions in the Microsoft ecosystem don’t live in a single admin portal. Incident and alert handling happens in Microsoft Defender XDR, which uses its own Unified RBAC (URBAC) model. Content visibility, data classification access, and compliance-oriented roles are managed in Microsoft Purview.

To configure a functional, least-privilege DLP operations model, you need to work in both portals, and the permissions granted in each need to be deliberately aligned. An analyst configured correctly in Purview but not in Defender XDR can’t access the incident queue. An analyst configured in Defender XDR but not in Purview can see incidents but can’t view the evidence content.

Neither is useful on its own.

The two failure modes

Before getting into the specifics, it’s worth naming how this typically goes wrong.

The first is over-permissioning. Everyone who touches DLP incidents gets broad access because it’s simpler to configure and nobody pushed back during rollout. Tier 1 analysts can view full sensitive content. Multiple people have response and action rights across both portals with no separation. The result is a least-privilege violation that, in regulated environments, creates real compliance exposure.

The second is under-permissioning. Access is locked down, but without a clear map of what each function actually needs across both portals. Tier 2 investigators can see incidents in Defender XDR but can’t view evidence content because the Purview content viewer role was never assigned. Tier 3 responders can investigate but can’t take containment actions because the Response permission wasn’t included in the URBAC custom role. Both groups escalate to a security administrator who has full access, and that person becomes the permanent bottleneck for every non-trivial incident.

Both failure modes produce the same operational outcome. That is incidents don’t close on time and the operating model stops working.

Role configuration by tier

The model below maps each operational tier to specific Defender XDR Unified RBAC permissions and Purview role groups. The Defender URBAC permissions are configured as custom roles in the Defender XDR permissions section. Purview role groups are managed in the Microsoft Purview compliance portal.

Tier 1 – DLP Analyst (Triage)

Purpose: Review alerts, filter false positives, make initial escalation decisions. Limited to metadata and activity context, no access to sensitive content.

Defender XDR – Custom Unified RBAC role:

Purview – Role Group:

What this gives them in practice:

• Can access and manage XDR DLP incidents and alerts
• Can view evidence metadata only
• Can view SIT match counts, but not sensitive info details
• Cannot view or download evidence content (email body, file contents)
• Cannot action email evidence (remove from mailbox, release from quarantine)
• Can action SharePoint and OneDrive file evidence (un-share, apply a label, delete)
• Cannot initiate automated investigations

Tier 2 – DLP Investigator (Investigation)

Purpose: Deep-dive analysis, context enrichment, intent assessment, investigation decisions. Needs controlled access to evidence content, but download rights are restricted.

Defender XDR – Custom Unified RBAC role:

Purview – Role Groups:

What this gives them in practice:

• Can access and manage XDR DLP incidents and alerts
• Can view evidence metadata and content
• Can view SIT match counts, sensitive info details, and contextual summary
• Can view email and file evidence source, but cannot download
• Cannot remove email evidence from mailboxes, but can release from quarantine
• Can action SharePoint and OneDrive file evidence (un-share, apply a label, delete)
• Can initiate automated investigations

The RMS Decrypt role is worth calling out specifically. In Microsoft Purview’s Content Explorer, this role allows the portal to strip encryption for inline viewing. Without it, investigators cannot view protected content there at all.

In the Defender XDR and Purview portals, the behavior is different. MIP-encrypted emails and files appear as “Protected” and cannot be viewed inline, the “source” view is not available for encrypted items regardless of roles assigned. Encrypted evidences must be downloaded and opened in the relevant Office app in order to be inspected.

In most enterprise environments, the files most likely to be involved in real DLP incidents are exactly the ones with protection applied. Worth factoring into your investigation workflow design.

Tier 3 – DLP Incident Responder (Containment)

Purpose: Take confirmed containment and remediation actions on validated incidents. Full evidence access including download rights, and full email and file action rights.

Defender XDR – Custom Unified RBAC role:

Purview – Role Groups:

What this gives them in practice:

• Can access and manage XDR DLP incidents and alerts
• Can view evidence metadata and content
• Can view SIT match counts, sensitive info details, and contextual summary
• Can view and download email and file evidence
• Can action email evidence: remove from mailbox, release from quarantine, and other advanced actions
• Can action SharePoint and OneDrive file evidence (un-share, apply a label, delete)
• Can initiate automated investigations and propose remediation

The difference between Tier 2 and Tier 3 from a Defender URBAC perspective is the addition of Email & collaboration advanced actions (manage). That single permission is what separates an investigator who can look at email evidence from a responder who can act on it.

Governance Layer – Compliance, Legal, HR

This layer requires incident context and case status visibility. They don’t need content access or action rights unless a specific regulatory or legal scenario requires it. And if it does, that access should be time-bound and audited.

For most organizations, read access to case status in Defender XDR (via Security Reader) and relevant Purview audit log access (View-Only Audit Logs) is sufficient. Avoid assigning Compliance Administrator or Security Administrator to governance personas, those roles carry significant action rights that the governance layer has no business need for.

A word on content access and audit discipline

The content viewer roles in Purview – particularly Data Classification Content Viewer – are the highest-sensitivity permissions in this model. They allow analysts to see actual file and email content involved in DLP incidents, which means they can see the sensitive data itself.

All access through Content Explorer is logged in the Microsoft 365 unified audit log. That audit trail should be actively reviewed, not just retained. In environments with regulatory data handling obligations – GDPR, HIPAA, financial sector requirements – having a documented review process for content access is part of demonstrating compliance, not just a good practice.

For environments using Azure AD Privileged Identity Management (PIM), the content viewer roles and the Tier 3 response permissions are strong candidates for just-in-time (JIT) elevation rather than permanent assignment. The friction is low. The audit trail and time-bound access are meaningful controls.

Connecting the permission model to the operating model

The RBAC configuration above gives each tier the access they need and nothing more. But the permission model only works if the incident workflow enforces the tier boundaries in practice.

Tier 1 should complete triage and log a decision before escalation, not forward raw, unreviewed alerts to Tier 2. Tier 2 investigation records should document the rationale for escalation or closure, not just a status change. Tier 3 containment actions should reference a specific investigation record. None of this is enforced by RBAC alone, it requires workflow discipline on top of access control.

That’s the subject of the next post.

What’s coming next

Access controls define what each tier can see and do. Communication and escalation patterns define how those tiers hand work off to each other, and that’s where most DLP incidents quietly stall even when the RBAC model is correctly configured.

The next post covers escalation triggers, documentation requirements at each hand-off, and how to handle the cross-functional communication with Legal and HR that most security teams underestimate.