Skip to content

DLP Policy Decision Guide

One DLP policy for all environments is not a governance model. It is a policy that will either block everything or protect nothing.

TL;DR

DLP policies must be tiered to match environment risk: Tier 1 (Default, maker sandboxes) — most restrictive, business data connectors blocked; Tier 2 (development, test) — standard internal connectors allowed, external restricted; Tier 3 (production) — approved connectors only, strictly governed. Apply a Tenant-level policy as a baseline. Apply environment-level policies for additional restrictions. Never rely on a single tenant-wide policy to cover all scenarios.

Applies To

Audience: Platform Admin · Security Architect · CoE Lead Frameworks: SHIELD (Harden) · SCALE-OPS (Containment)

The Decision Framework

Step 1 — Classify Your Connectors

Before writing a policy, classify every connector in use (or likely to be used):

Classification Examples DLP Treatment
Business — Core SharePoint, Teams, Dataverse, Office 365 Allow in all business environments
Business — Approved Approved 3rd-party SaaS (Salesforce, ServiceNow) Allow in production after security review
Business — Restricted HR systems, financial data, regulated databases Allow only with explicit approval; log access
Non-Business Social media, consumer apps, entertainment Block in all business environments
Blocked High-risk, data exfiltration risk Block at tenant level

Step 2 — Design the Policy Tiers

Design one policy per environment tier — not one policy for the tenant.

Tier 1: Default and Maker Sandbox Environments

Most restrictive. The default environment is where ungoverned solutions proliferate — it needs the tightest DLP to limit blast radius.

  • Business group: Microsoft 365 core services only (SharePoint, Teams, OneDrive, Outlook)
  • Non-business: everything else
  • No custom connectors
  • No HTTP connectors

Tier 2: Development and Test Environments

Moderate restriction. Makers need to test against realistic connectors — but external and non-business connectors remain blocked.

  • Business group: Core + Approved 3rd-party connectors
  • Non-business: consumer, social, entertainment
  • Custom connectors: allowed if pre-approved
  • HTTP connectors: allowed (required for integration testing)

Tier 3: Production Environments

Strictest set of approved connectors — but scoped to only what the solution actually uses. Smaller approved set than Dev/Test (no experimental connectors).

  • Business group: only connectors used by live solutions
  • Non-business: everything else
  • Custom connectors: approved and documented only
  • Regular review cycle (quarterly minimum)

Step 3 — Apply the Tenant-Level Baseline

The tenant-level DLP policy applies to all environments. Use it as a floor — not a ceiling.

Tenant baseline should: - Block all genuinely dangerous connectors (HTTP with AAD, custom connectors without review) - Block social media and consumer connectors - Not overlap with environment-specific policies unnecessarily

Tenant baseline should not: - Block connectors that legitimate development needs - Be the only DLP policy - Attempt to cover production security requirements

Step 4 — Govern the Exception Process

Every connector not on the approved list requires an exception process. Define it before makers ask.

Request Type Process Decision Maker SLA
Add connector to Tier 2 approved list Submit request → CoE Lead review CoE Lead 3 business days
Add connector to Tier 3 production Security review + CISO sign-off Security Architect + CISO 5 business days
Temporary exception for testing Time-limited, documented Platform Admin 1 business day
New custom connector Security review + connector registration Security Architect 5 business days

Common Mistakes

Mistake Consequence Fix
Single tenant-wide policy Either too restrictive for dev or too permissive for prod Tier policies to match environment risk
Adding connectors to approved list without review Security review debt builds up Define and enforce the exception process
No policy on the Default environment Shadow solutions with unreviewed connections Apply strictest policy to Default
DLP policy review only when there's an incident Policy drifts from actual risk Quarterly policy review cadence
Blocking HTTP connector in all environments Breaks legitimate integration testing Allow HTTP in Dev/Test, block in Prod

Next Steps