M365 PlaybooksOrganization· Security Management
Decide what counts as sensitive
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
Start from regulation only
Fast and defensible, but misses intellectual property and operational data that no law names.
Start from a full data inventory
Thorough, but slow; DLP waits months for a document nobody finishes.
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
Copy and adapt this statement for your policy.
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.
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
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.
No owner per category
Name one person who can approve exceptions and changes for each category.
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 (Microsoft Learn)
- Reduce false positives by using SITs and advanced classifiers (Microsoft Learn)
- Data Loss Prevention policy reference (Microsoft Learn)
- Reduce false positives with sensitive information types and advanced classifiers (Microsoft Learn)
Reviewed against
Changelog
Changelog (1 version)
| Version | Date | Author | Change |
|---|---|---|---|
| 1 | Sev Derghazarian | First published. Placeholder text for the pilot build; replace before launch. |