Detection Engineering as a Practice

Most DLP policies are configured once during deployment and never revisited. They then decay quietly — the business changes, the exclusions accumulate, the assumptions expire — and nobody notices because the alerts keep arriving.

Detection engineering is the practice of treating each detection as something owned, documented, tested and retired.

Each detection needs

A stated purpose. What behaviour is this trying to catch, and why does it matter. Six months later nobody remembers, and unexplained rules never get removed.

A data category from the inventory. If it does not map to something you defined as sensitive, ask why it exists.

Documented exclusions with reasons and review dates. An exclusion without an expiry becomes a permanent hole nobody can justify.

A known false positive rate, measured rather than assumed.

An owner. A person, not a team.

A test. How you verify it still fires.

That is a paragraph per detection. A programme with forty undocumented rules and one with twelve documented ones — the second is stronger.

Version control

Policies should live in a repository, not only in the product console.

Change history. Who changed what, when, why. Products log this inconsistently and rarely in a form you can review.

Review before deployment. A second person looks at a rule change. This catches the exclusion that was written too broadly, which is the most common damaging error.

Rollback. When a change causes a flood or a business interruption, reverting should take minutes.

Reproducibility. If the product is rebuilt or replaced, the logic exists outside it.

Exporting policies to a repository on a schedule is a half-day of work and it is the difference between a configuration and an engineering artefact.

The lifecycle

Propose. What behaviour, why, expected volume, what data category.

Build and test in monitor mode, on real traffic, before it affects anyone.

Measure. Actual volume and precision over a fortnight. Most rules look different in production from how they looked in design.

Tune or retire. A rule that has produced no true positive in a year is either perfectly preventive or useless, and you generally cannot tell which. Retire it and see.

Review on a schedule. Annually at minimum, and whenever the business process it covers changes.

Retiring detections

The step nobody takes. Rules accumulate because removing one feels like reducing security.

A rule that has never produced an actionable finding is costing you. It consumes review attention, it adds to the volume that hides real events, and it creates the impression of coverage where there is none.

Keep a retirement log with the reasoning. It makes the decision defensible and reversible.

What to measure per detection

Volume, precision on acted-upon rules, time to review, and true positives over a rolling period.

Per rule, not in aggregate. Aggregate metrics hide the single badly designed policy generating most of the noise, which is almost always what is happening.

The organisational point

This is a maintenance discipline, and maintenance is chronically unfunded because it produces nothing visible.

The argument that works with a budget holder: a programme that is not maintained degrades to a log within about two years, and the licence continues either way. The maintenance is not an addition to the cost of the tool; it is the thing that makes the tool worth anything.