Phase 1 – Where DLP Programs Quietly Break Down

The DLP SOC Operating Model.

Overview

DLP incidents don’t fail at the detection layer. They fail at the ownership layer.

Quick recap

In the previous post, we introduced the DLP Incident Formation Model, a working model for how alerts become incidents:

Alert → Context → Decision → Incident

The model separates signal from validated risk. But once you have a validated incident, a different problem surfaces. That is, who actually owns it, and what does “owning” it mean?

Why DLP ownership is structurally ambiguous

Most security domains have relatively clear ownership. Endpoint incidents go to the SOC or endpoint team. Identity incidents go to IAM. Network incidents go to network security.

DLP doesn’t have a natural home.

A single DLP incident can simultaneously involve the SOC (investigation and response), compliance (policy intent and regulatory obligations), security engineering (whether the policy behaved correctly), HR and legal (if the incident involves employee misconduct or reportable exposure), and the relevant business unit (data ownership and authorization context).

That’s not an edge case, it’s the standard shape of a non-trivial DLP incident. And in most organizations, that cross-functional reality isn’t addressed until after the first few incidents have already been mishandled. The result is a set of informal workarounds that work inconsistently and don’t scale.

What the default looks like

The pattern is familiar to anyone who’s worked in a Purview environment that wasn’t operationalized properly.

SOC triages the incident but can’t act without business context they don’t have. Compliance owns the policy intent but wasn’t set up to run incident response. Security engineering gets pulled in to explain why the policy fired, which isn’t the same as investigating whether the behavior was risky. Legal and HR find out about incidents after the response window has passed.

Everyone is involved, but nobody is accountable for the outcome.

Why forcing ownership into one team doesn’t work

The instinct is usually to assign DLP incidents to one team – typically the SOC or the compliance function – and build from there. That works for low-complexity incidents, but it breaks down quickly for more complex ones.

SOC teams are optimized for technical investigation and response. They’re not well-positioned to make regulatory impact assessments or understand data classification intent without significant context from other teams. Compliance teams understand policy intent and regulatory obligations but typically don’t have the tooling access or investigation workflow experience for incident response at volume.

The more durable model is one where different teams own different layers of the incident lifecycle, with structured hand-offs between them, rather than one team trying to cover the full range of responsibilities.

A more realistic model

Each layer has a distinct scope, distinct access requirements, and a distinct definition of “done.”

Breaking it down

Tier 1 – Triage

Tier 1 is responsible for reviewing alerts, filtering false positives, and making the initial call on whether an incident warrants deeper investigation. Their scope is deliberately constrained, they work with metadata and activity context, not sensitive content.

Purview’s DLP alert management gives Tier 1 enough signal to make triage decisions (e.g. user, workload, policy matched, severity) without requiring access to the actual content involved. If your Tier 1 analysts are routinely reviewing full document content to make triage decisions, the access model is misconfiguration and the workload is too high for that layer to handle at scale.

Tier 2 – Investigation

Tier 2 handles deeper analysis. This includes context enrichment, intent assessment, correlation across related alerts or prior behavior. They need broader visibility, including access to metadata, controlled and audited access to content through Content Explorer or Activity Explorer, and the ability to correlate activity across time and systems.

This is where most incidents are actually decided. An incident that reaches Tier 2 either escalates with documented justification or closes with a documented rationale for dismissal. The output should never be “we looked at it and it seems fine” , it should be a recorded decision.

Tier 3 – Containment and Remediation

Tier 3 takes action. This includes revoking sharing permissions, restricting user access, triggering policy changes, or formally initiating HR and legal workflows. This is the execution layer.

The key constraint here is that action should follow investigation, not precede it. Containment decisions made without Tier 2 context tend to be either too aggressive (causing legitimate business disruption) or too conservative (leaving real exposure unaddressed).

Governance Layer – Compliance, Legal, HR

This layer interprets impact, manages regulatory obligations, and handles cases that involve reportable data exposure or employee misconduct. They don’t run investigations. They don’t triage alerts. But when an incident crosses a threshold that involves regulatory notification requirements or formal HR process, they need to be formally engaged, not updated retrospectively.

The timing of that engagement matters. Getting Legal and HR into the loop after containment has already been applied, rather than before, is a common operational failure with real consequences.

The pattern

Triage → Investigation → Containment → Governance

This is the structure that mature DLP operations converge on, usually after a few painful incidents that exposed where the informal model broke down. It maps closely to the tiered SOC model most security teams already understand, applied to the specific characteristics of DLP incident handling.

I tend to refer to this as the DLP Response Pyramid, a shorthand for the layered ownership model that most DLP programs are missing when incidents consistently fail to reach a documented outcome.

Where RBAC becomes unavoidable

This layered model immediately raises an access design question that most deployments haven’t properly addressed.

Tier 1 shouldn’t have access to sensitive content, they need activity metadata, not document contents. Tier 2 needs controlled, audited access to content for investigation purposes. Tier 3 needs action rights. Governance needs context and case history, not raw data.

Purview’s RBAC model supports this separation, but it requires deliberate configuration. The defaults don’t give you least-privilege DLP operations out of the box, they give you a working starting point that most organizations don’t refine until something goes wrong.

Getting the RBAC model right is the subject of the next post, and it’s worth treating as a first-class design decision rather than an afterthought to the operating model.

What a well-defined operating model fixes

When roles and responsibilities are explicit and access is properly scoped, alert triage moves faster because Tier 1 knows exactly where their decision boundary is. Investigations become consistent because Tier 2 has a repeatable process and the right access to do the work. Escalation becomes structured rather than reactive.

More importantly, incidents start reaching documented outcomes, which is the only basis on which you can improve the operating model over time.

What a poorly defined one produces

Without clear layer ownership, Tier 1 escalates defensively because the cost of a missed incident feels higher than the cost of unnecessary escalation. Tier 2 becomes a second triage function. Engineers get pulled into investigations because nobody else can interpret the telemetry. Compliance and Legal find out about incidents well after the operational response has already been applied.

The end state is a DLP program that generates a lot of activity and very few documented outcomes.

What’s coming next

The operating model defines who owns each layer of the incident lifecycle. But those layers need access controls that match their responsibilities, and that’s where most Purview deployments have significant gaps.

The next post covers RBAC design for DLP incident management, what least-privilege operations looks like in Purview, and where the non-optimized configuration leaves teams either over-exposed or unable to do their jobs.