Policy Design: Start in Monitor Mode and Stay There Longer Than Feels Comfortable

Every DLP product ships with a policy library and the ability to block. The temptation to switch both on is strong, and it is the most reliable way to end up with the programme disabled a year later.

Why blocking early fails

You do not know your own workflows. Every organisation has legitimate processes that look exactly like violations: finance emailing spreadsheets to an external auditor, HR sending records to a benefits provider, engineering pushing to a partner repository.

Block those on day one and you have interrupted the business. The interruption is remembered far longer than any incident you prevent, and it determines whether anyone cooperates with you afterwards.

Default policies target generic patterns, not your data. They fire on anything shaped like an identifier, including test data, sample files and documentation.

Users route around blocks. A blocked email becomes a personal webmail. A blocked USB becomes a photograph of a screen. Blocking without understanding the underlying need moves the activity somewhere you cannot see.

The progression

Stage one: silent monitoring. No user-visible effect at all. You are building a picture of normal.

Expect the first weeks to be unusable. Thousands of events, nearly all legitimate. This is the point.

Stage two: tuning. Identify and exclude the approved workflows. Narrow the policies from generic patterns to your actual data categories. Reduce volume to something a person can review daily.

This takes longer than anyone plans for. Budget a quarter, not a fortnight.

Stage three: user notification on narrow, high-confidence policies. A prompt at the moment of action: "this file appears to contain customer records — are you sure you want to send it externally?"

This is the highest-value intervention in most programmes and it is not blocking. It catches mistakes, which are the majority of incidents, without stopping anyone from doing legitimate work. Someone who genuinely needs to send it, sends it, and you have a record with their justification.

Stage four: blocking, selectively. Only for the small set where you are confident, the consequence is severe, and there is an approved alternative path.

Some programmes never reach stage four, and that is a legitimate outcome rather than a failure.

Designing a policy that works

One data category per policy. Combined policies produce alerts you cannot interpret.

Narrow the channel. "Customer records to external email" is actionable. "Customer records anywhere" is noise.

Include the exceptions in the policy, not in a mental note. The finance-to-auditor flow needs an explicit exclusion, documented, with a review date.

Set severity honestly. If everything is high severity, nothing is. Most policies should be informational.

Write down what the policy is for. Six months later, nobody remembers why a rule exists, and unexplained rules never get removed.

The conversation to have with the business

Before enforcing anything, ask the teams whose work touches sensitive data how they actually work. Not how the process document says.

You will learn about the workflows that will break, and you will learn them in a meeting rather than in an incident. You will also acquire allies, which matters more than the information.

The honest expectation

A well-tuned programme in an organisation of a few thousand people generates a handful of events a day worth human attention. Not hundreds.

If your volume is higher than a person can genuinely review, you do not have a detection programme. You have a log.