# Decide what counts as sensitive

- URL: https://m365playbooks.com/playbooks/decide-what-counts-as-sensitive/
- Topic: Data loss prevention: Organization (trk-dlp)
- Pillar: Security Management
- Stage: Govern
- For: Decision-maker, Security analyst
- Last reviewed: October 14, 2026
- Version: 1
- Written by: Sev Derghazarian

## Situation

We need data loss prevention, but nobody has agreed which data actually matters or how much friction people will accept.

## At a glance

**Outcome:** A short, owned list of sensitive data categories, the friction each one justifies, and a working exception process.

**Benefits:**

- Protection effort goes to the data that carries real risk. (How to measure: Share of DLP matches that fall in an agreed category.)
- Fewer arguments during rollout, because the trade-offs were settled first. (How to measure: Number of policy changes requested in the first 90 days.)

**Resources required:**

- Who is involved: Privacy or legal lead, security lead, records manager, one operations representative.
- Skills: Knowledge of the organization's regulatory obligations and main data flows.
- Effort: Two or three working sessions.
- Duration: Two to four weeks.

**Risk of not doing it:** Policies get written around what the tools detect by default rather than what the organization must protect, producing noise and gaps at the same time.

## Make the decision

### The decision to make

Which categories of information are sensitive enough to warrant automated controls, and how much interruption each category justifies for the people who handle it.

### Options and trade-offs

1. **Start from regulation only.** Fast and defensible, but misses intellectual property and operational data that no law names.

2. **Start from a full data inventory.** Thorough, but slow; DLP waits months for a document nobody finishes.

3. **Start from a short list of high-impact categories and grow it.** Gets protection running in weeks. Needs a review cadence so the list does not stay short forever.

### Recommended default

Start with three to five high-impact categories, each with a named owner and a friction level: **audit only**, **warn with override**, or **block**.

### Owners

- Decides: Privacy or legal lead, with the security lead
- Operates: Security operations
- Consulted: Records management, operations leads, labour relations where applicable

### Policy statement

> The organization protects the information categories listed in its sensitive data register. Each category has an owner and an approved level of control. Exceptions are requested through the service desk, approved by the category owner, and expire after twelve months.
>

### What this constrains downstream

The categories and friction levels set here become the policy design in [Roll out DLP without breaking work](https://m365playbooks.com/playbooks/roll-out-dlp-without-breaking-work/).

## Making it scale

Sensitive info types and DLP policies are managed centrally and applied to every location by default, rather than through per-site exceptions. Narrow a policy with groups or administrative units; adaptive scopes for DLP cover SharePoint only and are in preview.

_Enforced by a mechanism._

## Avoiding common pitfalls

1. **Turning on every built-in sensitive info type.** Pick the types that map to your agreed categories. Each extra type adds matches someone must review.

2. **No owner per category.** Name one person who can approve exceptions and changes for each category.

3. **Exceptions that never expire.** Give every exception an end date and review them on the Maintenance cadence.

## Checkpoints

- Every sensitive category has an owner and a friction level.
- The policy statement is approved and published.
- The exception process is live in the service desk.

## Sources

- [Lightweight guide to mitigate data leakage](https://learn.microsoft.com/en-us/purview/deploymentmodels/depmod-lightweight-dlp-intro) (Microsoft Learn)
- [Reduce false positives by using SITs and advanced classifiers](https://learn.microsoft.com/en-us/purview/deploymentmodels/depmod-reduce-false-positives) (Microsoft Learn)
- [Data Loss Prevention policy reference](https://learn.microsoft.com/en-us/purview/dlp-policy-reference) (Microsoft Learn)
- [Reduce false positives with sensitive information types and advanced classifiers](https://learn.microsoft.com/en-us/purview/deploymentmodels/depmod-reduce-false-positives) (Microsoft Learn)

**Reviewed against:**

- [Lightweight guide to mitigate data leakage](https://learn.microsoft.com/en-us/purview/deploymentmodels/depmod-lightweight-dlp-intro), checked 2026-10-14
- [Reduce false positives by using SITs and advanced classifiers](https://learn.microsoft.com/en-us/purview/deploymentmodels/depmod-reduce-false-positives), checked 2026-10-14
- [Data Loss Prevention policy reference](https://learn.microsoft.com/en-us/purview/dlp-policy-reference), checked 2026-10-14

## Changelog

- Version 1, 2026-10-14, Sev Derghazarian: First published. Placeholder text for the pilot build; replace before launch.