Phase 2 – Building the DLP Operating Model

Communication and Escalation Patterns.

Overview

A well-defined operating model with correct RBAC gets you the right people with the right access. What it doesn’t give you automatically is a clear set of rules for how those people hand work off to each other. That’s where most DLP incidents break down, not because the wrong person is handling them, but because the handoff between the right people is undefined.

Quick recap

In the previous post, we covered RBAC design for the DLP Response Pyramid, mapping access permissions to the four operational layers:

Triage → Investigation → Containment → Governance

Each layer has scoped access that matches its responsibilities. Now we look at how those layers communicate, escalate, and hand off work, because the layer boundaries are only useful if the transitions between them are explicit.

Get ready for a colorful post!

Why handoffs are where incidents fail

An incident that enters Tier 1 with a clear triage decision and a documented escalation rationale has a reasonable chance of reaching a defined outcome. An incident that moves between layers as an informal “hey, can you look at this?” has no consistent structure. Inconsistent structure produces inconsistent outcomes.

The handoff problem in DLP is compounded by the cross-functional nature of the domain. A single incident might move from SOC Tier 1 to Tier 2, then get partially handed to a security engineer for policy interpretation, then escalated to a compliance officer, then looped back to security for containment, then handed to HR for employee process. Each of those transitions is an opportunity for context loss, duplicated effort, or a decision made without full information.

In most organizations, that transition chain isn’t designed, it just emerges. And what emerges is inconsistent enough that two analysts handling the same type of incident will reach different outcomes based largely on who they happened to involve.

What a structured escalation model looks like

Each transition in this model has two things: a trigger condition and a documentation requirement. That’s the difference between a handoff and a notification.

Escalation triggers

Defining what causes an alert to move between layers is more important than defining who owns each layer. Without explicit triggers, escalation becomes a judgment call. And judgment calls under pressure default to escalating everything.

Tier 1 → Tier 2

Escalate when:

• The alert cannot be dismissed as a clear false positive based on available metadata alone
• The user’s activity pattern is inconsistent with their role or normal behavior
• The same user has had two or more alerts in a defined rolling window (e.g. 30 days)
• The data involved is classified at a high sensitivity tier (e.g. Highly Confidential label)
• The workload or destination represents elevated risk (external domain, unmanaged device, cloud upload, etc.)

Dismiss (with documented rationale) when:

• The alert matches a known low-risk pattern (e.g. finance team scheduled export triggering a credit card SIT match)
• The user and data context are consistent and the policy match is a known false positive pattern
• The policy has a documented false positive history for this scenario

The dismiss criteria matter as much as the escalation criteria. If Tier 1 has no documented basis for dismissal, everything escalates by default, and Tier 2 becomes a second Tier 1.

Tier 2 → Tier 3

Escalate when:

• Investigation confirms real risk. That could be that the behavior is inconsistent, the intent is ambiguous or clearly malicious, and the data exposure is material
• Immediate containment is required to prevent further exposure
• The investigation has produced enough evidence to justify a containment action

Close (with documented rationale) when:

• Context establishes that the behavior was authorized, accidental with no material impact, or consistent with a known business process
• The alert does not meet the organization’s threshold for formal incident treatment

Tier 2 / Tier 3 → Governance

Engage Governance when:

• The incident involves data subject to regulatory notification requirements (e.g. personal data, health information, financial records)
• The incident involves suspected insider misconduct. HR needs to be in the loop before containment actions are taken against an individual
• Legal hold or evidence preservation may be required
• The incident has or is likely to have external visibility (e.g. customer data, partner data, regulatory reporting)

Governance engagement is not an escalation in the traditional sense. It’s a parallel notification with a specific information handoff, not a transfer of ownership. Security retains operational ownership of the incident. Governance handles the regulatory and HR dimensions.

What the documentation at each handoff should contain

Undocumented escalations create two problems, the receiving tier doesn’t have the context they need, and there’s no audit trail for the decision that triggered the escalation.

A minimum escalation record at Tier 1 → Tier 2 should contain:

• Alert ID and link to the source alert in Purview or Defender XDR
• User identity and department
• Workload and action type
• Policy matched and sensitivity label state (if applicable)
• Summary of why the alert wasn’t dismissed (the specific trigger criterion met)
• Analyst ID and timestamp

A Tier 2 → Tier 3 escalation record should contain all of the above plus:

• Summary of investigation findings
• Assessment of intent (e.g. accidental / ambiguous / likely malicious)
• Specific containment action recommended and justification
• Whether Governance engagement is required and why

This doesn’t need to be a form, it can be a structured comment in your ITSM tool, a case note in Defender XDR, or a documented entry in your incident tracking workflow. The format matters less than the discipline of doing it consistently.

Cross-functional communication with Legal and HR

The Governance layer operates under different constraints than the security tiers. Legal and HR teams have confidentiality obligations, employee relations sensitivities, and regulatory timelines that don’t map neatly to security incident workflows.

A few things that reduce friction here:

• Agree on a notification threshold in advance: Don’t wait for a real incident to decide when Legal gets called. Define the criteria (e.g. data type, exposure scale, user involvement) and get Legal and HR sign-off on those criteria before you need to apply them. The conversation is much easier before an incident than during one.
• Separate the information you share: Legal and HR don’t need raw technical investigation data. They need what happened, who was involved, what data was at risk, what actions have been or will be taken, and what their role is from here. A one-page incident brief is more useful than a full Defender XDR case dump.
• Establish a single point of contact on each side: Security incidents involving HR can degrade quickly if multiple people from both sides are communicating informally. A named security contact and a named HR/Legal contact per incident reduces the chance of contradictory communications reaching the employee or management.

Communication patterns during active investigation

While an incident is in active investigation at Tier 2, there are a few communication anti-patterns worth naming explicitly.

• Don’t loop in the subject’s manager informally: This is one of the most common ways DLP incidents involving employee behavior go wrong. A manager who is informally told “we’re looking at some activity from one of your team” will often act on that information. Sometimes in ways that interfere with the investigation or tip off the subject. Any manager communication should go through HR and should be formally coordinated.
• Don’t share investigation status broadly: DLP incidents involving specific individuals are sensitive by nature. Investigation status should be on a need-to-know basis until the incident is closed and a formal outcome is documented.
• Do keep Tier 1 and Tier 3 informed of material developments: If Tier 2 determines mid-investigation that the severity has changed significantly, Tier 1 (for queue management) and Tier 3 (for containment readiness) should be updated. This doesn’t need to be a formal escalation, just a status update in the case record is sufficient.

Tooling for communication and escalation

The right tooling here depends heavily on your operating model. A few patterns that work:

• Defender XDR as the incident hub: Microsoft Defender XDR supports incident management natively, including case notes, assignment, status tracking, and activity history. For organizations that are M365-centric, this is the most natural place to manage the operational side of DLP incidents, with escalation documented as case updates and assignments.
• ITSM integration for cross-functional handoffs: When incidents need to cross into Legal, HR, or business unit ownership, a ticketing system (ServiceNow, Jira Service Management) provides a more accessible interface for non-security teams and a cleaner separation between the technical investigation record and the cross-functional coordination record. We’ll cover ITSM integration patterns in depth in Phase 4 of this series.
• Structured email or Teams channel for Governance notifications: For smaller environments, a structured notification template sent to a dedicated Legal/HR channel — with a defined information set and a named owner — is sufficient. The key is that it’s consistent, not improvised per incident.

The escalation pattern (The VisionStack version )

You can think of a well-functioning DLP escalation model as having three properties:

• Triggered –> escalation happens because a defined criterion was met, not because someone was unsure what to do
• Documented –> every transition between layers has a record that the receiving layer can act on
• Bounded –> each layer has a clear definition of what “done” means before handing off

Without all three, escalation becomes a mechanism for distributing uncertainty rather than resolving it.

I tend to think of this as the DLP Escalation Discipline, the operational complement to the DLP Response Pyramid. The Pyramid defines the layers. The Escalation Discipline defines how work moves between them.

What’s coming next

Phase 2 has covered the operating model, the access model, and the communication patterns that hold it together. Phase 3 moves into the investigation layer itself. Starting with how DLP analysts actually triage an alert and make a structured decision about what it means.

The next post covers the DLP triage framework: the specific inputs, assessments, and decision criteria that separate a functional Tier 1 process from a reactive one.