Why tuning is the whole game
Authoring a DLP rule takes an afternoon; making it survive contact with users takes a program. An untuned rule matching a generic pattern fires on invoices and reference numbers, and the human response is predictable: reflexive override, or a switch to personal email / screenshots. Both defeat the control. Tuning is how you keep the signal high enough that people respect the block.
The five levers
- Confidence level — require high confidence where the SIT supports it, so corroborating evidence (keywords, checksums, proximity) must be present, not just the bare pattern.
- Instance count — "10+ matches" separates a document about sensitive data from one that merely mentions it once. A count floor kills a large slice of noise.
- EDM — match your actual records rather than any value of that shape; the precision instrument for known data (see the classification-engine concept).
- Context conditions — fire only when it matters: shared externally, sent to a personal domain, downloaded to an unmanaged device. Context turns a broad rule into a risk-shaped one.
- Exceptions — exclude known-legitimate flows (a finance mailbox that should handle card data) rather than lowering the whole rule.
The override ladder
Match the action to the risk, don't hard-block everything:
| Sensitivity | Action | Why |
|---|---|---|
| Medium / ambiguous | Block with override + justification | Keeps the business moving, captures intent, produces a reviewable record |
| Genuinely sensitive, external | Hard block | Reserved for the cases where flow must stop |
| Everything under test | Audit only | See what would fire before you enforce anything |
Overrides are not a weakness — a well-placed override with mandatory justification gives you telemetry (who, what, why) that a silent block never does. The trap is over-using hard block: every unjustified block is a nudge toward the route-around.
Run it as a program
Start in simulation/test mode everywhere, read the would-have-blocked report for weeks, and only then enforce. Then review monthly: override rate, false- positive rate, and top-firing rules. A rule that is 95% false positive is worse than no rule — it manufactures alert fatigue. Flat, low false-positive rates mean tuned; rising overrides mean the policy is training users to ignore it.
What to watch (proofs)
- Simulation output: new/changed policies in test mode and their would-have- blocked counts before enforcement — impact sized before it lands on users.
- Rule composition:
Get-DlpComplianceRuleconfirming each rule specifies confidence, instance count and context conditions — not "any match, anywhere." - Match economics: alert volume by rule and its true/false-positive split (Purview alerts / Activity Explorer) — the tuning backlog, ranked.
- Override behaviour: override-with-justification rates and trend
(
Search-UnifiedAuditLogfor DLP override events) — flat is healthy, climbing is the reflexive-override warning.