DLP · Insider risk · Detection engineering

Most data loss is not an attack

It is someone emailing a spreadsheet to their personal account before a holiday, or a departing employee taking what they consider their own work. This is a practical reference for building programmes that catch that without turning the organisation into a surveillance operation.

  • 42 entries
  • 5 kinds
  • 18 domains
  • 5 stages

Where to start

If you have been told to deploy DLP and have not started, read what DLP actually does first, then data classification and building the data inventory. The tool cannot supply either, and deployments that skip them stall.

If a deployment is already generating unreviewable noise, go to the false positive problem and alert enrichment. The answer is almost never raising thresholds.

If you have no budget and no security team, read insider risk in small organisations and what you can do without a DLP product. A substantial share of real exposure is addressable with capabilities you already own.

If you are writing a business case, start with building the business case and what the regulations actually require. The compliance mandate you have been told about probably does not exist, and there are better arguments.

If someone has just done something and you are deciding what to do, read containment and triage before acting. Several of the obvious first moves destroy the case.

What this site takes as given

A few positions run through everything published here. They are stated plainly so you can disagree with them deliberately.

Most data loss is error, not malice. Someone emailing a spreadsheet home before a holiday, or sending the wrong attachment. Programmes designed around a sophisticated adversary drown in this and catch neither.

DLP is instrumentation, not a wall. It cannot stop a determined person with legitimate access, and any programme sold to executives as prevention will fail publicly at the first incident.

Access reduction outperforms detection. Reducing how many people could cause an incident is the only measure that changes the denominator. It is cheaper than monitoring, more effective, and consistently underfunded because it does not demo well.

The departure process is the highest-yield single intervention. Most real incidents involve someone leaving. It is the one scenario that comes with advance notice.

Monitoring employees is regulated. Transparency, proportionality, impact assessment and consultation are obligations in much of the world, not optional refinements. A programme that ignores them produces evidence a tribunal will not admit.

A programme that catches nothing may be blind rather than effective, and no metric distinguishes them. The honest response is to say so rather than substitute a number that implies otherwise.

What is not here

This site is written from the defender's side. It covers detection, programme design, investigation and compliance.

It does not publish material on evading data controls or moving information undetected, and it will not. That material helps one side of this problem, and it is not the side our readers are on.

Kind
Domain

Fundamentals07

What the terms mean, where data actually goes, and what has to exist before any tool helps.

Programme design09

Governance, legal constraints, staffing and the questions to settle before deployment.

Detection and tuning11

Policy design, false positives, behavioural analytics and the major egress channels.

Investigation and response06

Triage, evidence, escalation and the departing employee.

Context09

Why deployments fail, what to ask vendors, and what the regulations actually require.