Why your DLP gets switched off in month three
Data loss prevention fails for a predictable reason, and it is almost never the detection engine. It is what happens the first time it blocks something legitimate.
DLP policy in monitor mode
Real product screenshot of a policy in monitor-only mode with match counts. Redact all customer names, paths and addresses. Light theme.
2400×1350 · PNG · @2x
The pattern is consistent enough to set a calendar reminder by. Month one, the policy goes live in blocking mode because the project needed a visible win. Month two, the finance team cannot send the file they send every month. Month three, somebody with authority says "just turn it off for now", and it is never turned back on.
Over-blocking is the failure mode, not under-blocking
A DLP that misses one exfiltration path is a gap. A DLP that stops a sales director sending a legitimate contract is an outage, and outages get escalated. The second failure gets the product removed; the first one usually goes unnoticed for years. Any deployment plan that does not take this asymmetry seriously will lose.
Nobody escalates a missed detection. Everybody escalates a blocked invoice.
Monitor first, and mean it
Run in monitor-only mode across a representative group — not the IT department, who send nothing normal — for long enough to see a full business cycle. Month-end is different from mid-month. Quarter-end is different again. If you have never seen what your organisation does in the last three days of a quarter, you are not ready to block anything.
Then tune until false positives are rare, not until they are explained. "That is expected behaviour, the analyst knows to ignore it" is how a queue becomes wallpaper.
Three tiers, not one switch
- Block the genuinely unambiguous: a spreadsheet of card numbers to a personal webmail address.
- Warn and allow the ambiguous, with a one-line justification the user types. This is where most of your real traffic lives, and the justifications become your tuning data.
- Log silently everything else, so you keep visibility without friction.
Build the exception process before you need it
The reason the finance team escalated in month two is not that they were blocked. It is that being blocked left them with no route forward except a phone call to someone senior. A time-boxed, approved, audited exception — requested in the moment, granted in minutes, expiring automatically — converts an outage into a small piece of friction, and gives you a record of exactly which controls are getting in the way of real work.
Every deployment we run ships the exception workflow before the first policy moves into blocking. It is not a nice-to-have. It is the thing that determines whether the platform is still running next year.