DLP: Data Loss Prevention Explained for Practitioners

Most data does not leave an organisation through an intrusion. It leaves through a person: a spreadsheet emailed to a personal address to work on at home, a customer list copied to a USB stick before a resignation, a file uploaded to a personal cloud account because the corporate one was awkward, a document sent to the wrong recipient because autocomplete filled the name.

Data loss prevention is the control layer aimed at that traffic. It inspects content, compares it against policy, and blocks, quarantines, encrypts or records the movement.

This guide covers what it inspects, how detection actually works, where enforcement sits, and the limits, which are substantial and worth stating plainly before anyone buys a platform on the strength of the name.

Scope: Insider Threats Guide owns the human risk and the program around it, Encryption Explained owns protecting data at rest, and What to Do After a Data Breach owns the aftermath. This page owns the control.

Three states, three enforcement points

State	Where it is	Enforcement	What it catches
In use	Open on an endpoint	Agent on the device	USB copies, printing, clipboard, screenshots, uploads through any browser
In motion	Crossing a network	Gateway, mail flow, proxy, CASB	Email to external recipients, web uploads, file transfers
At rest	Stored	Scanner crawling file shares, endpoints, object storage, SaaS	Sensitive data in places it should not be

Each answers a different question. The at-rest scan answers "where is our sensitive data", which most organisations cannot answer and which is the prerequisite for the other two being sensible. The in-motion controls cover the paths everyone thinks of first. The in-use agent covers the paths that never touch a corporate network at all, which on a laptop at home is most of them.

Classification comes first

A DLP policy has to know what it is protecting. There are three ways it finds out, and mature programs use all three.

By content. The system inspects the data and decides. This is the detection machinery below.

By context. Where the file came from, who created it, which application produced it, which repository it lives in. A file downloaded from the finance system is finance data regardless of what is inside it.

By label. A person or a system attaches a sensitivity label that travels with the file, and policy acts on the label. Labels are the most reliable input available, because they carry intent, and they depend on people applying them correctly, which needs the label set to be small. Four or five levels work. Twelve do not.

An organisation with no classification scheme cannot write a meaningful DLP policy, which is why the first phase of these programs is always about deciding what actually matters: customer records, payment data, health information, source code, unreleased financials, engineering designs.

How detection works

Ordered from cheapest and noisiest to most precise.

Pattern matching. Regular expressions for structured identifiers: card numbers, national insurance or social security numbers, IBANs, passport numbers. Cheap, and false-positive prone unless validated. A sixteen-digit pattern without a Luhn checksum matches order numbers, part numbers, concatenated timestamps and internal reference codes, permanently.

Keywords and dictionaries. Terms that indicate a category, such as diagnosis codes in a health context or project code names. Weak alone, useful as a supporting condition.

Proximity and combination rules. A number matching a card pattern is weak evidence. The same number within fifty characters of an expiry date and a cardholder name is strong evidence. Most usable policies are combinations with a confidence threshold and a minimum count.

File properties. Type, size, whether it is encrypted, whether it has a label, where it came from.

Exact data matching. The system indexes your real records, storing hashes of the field values rather than the values, and a policy triggers only when content contains actual entries from that table. This is the difference between "something shaped like a customer record" and "row 84,221 of the customer database". It removes most false positives and adds an indexing pipeline that has to be kept current.

Document fingerprinting. Similar idea for unstructured documents: index a template or a specific document, then detect derivatives and partial copies of it.

Trained classifiers. Machine learning models for categories that resist rules, such as source code, legal contracts or resumes. Useful, probabilistic, and always tuned rather than trusted.

Optical character recognition. Text inside images and scans. Expensive to run and closes an otherwise trivial bypass.

Enforcement, in ascending order of disruption

• Audit. Record and do nothing. Where every deployment starts, and where a surprising number should stay for the first month or two.
• Notify. Record and tell the security team or the user's manager.
• Coach. Warn the user, explain which policy matched, and let them proceed with a justification. This is the highest-value mode in most environments: it stops mistakes, it educates, and the justifications become the data you tune the policy with.
• Encrypt or redact. Apply protection automatically rather than blocking, so the business action still happens.
• Quarantine. Hold the message or file for review.
• Block. Refuse the action.

The order matters because a DLP program's failure mode is loss of trust. Block first and you generate a queue of exceptions, a stream of complaints, and pressure to disable policies wholesale. Start in audit, learn what normal movement looks like, then block the narrowest high-confidence case.

Where it breaks

Being specific here separates a useful control from an expensive one.

Encrypted traffic. Network inspection of HTTPS requires interception, which requires a trusted certificate on every endpoint and fails against certificate-pinned applications. Those applications are then blocked or exempted, and exempted paths are uninspected paths.

Unmanaged devices. No agent, no endpoint enforcement. A personal laptop with access to a SaaS application is a path the endpoint layer cannot see, which is why cloud-side API controls matter.

The analogue hole. A photograph of a screen carries the data out of every digital control. Nothing inspects it.

User-side encryption. A password-protected archive created before the file reaches an inspection point is opaque. Policy can block encrypted archives it cannot inspect, which is a blunt instrument with real business cost.

Chunking and encoding. Data split across many small transfers, or encoded to look like something else, evades threshold-based policies. Steganography, covered in Steganography Explained, is the extreme version.

False positives at scale. The dominant operational problem. A noisy policy trains people to click through warnings and trains analysts to close alerts unread, which is the same failure described in What Is a SIEM.

Performance and stability. Endpoint agents that inspect every file operation have a cost, and inspection at scale on shared storage has another. Both surface as pressure to narrow the scope.

Cloud and SaaS

Most sensitive data now moves between cloud services without touching a corporate network, so a gateway-only deployment is inspecting a shrinking share of the traffic.

The controls that apply:

• API-based scanning of SaaS platforms, which reads content already stored there and finds files shared publicly or with external parties. This is usually the fastest source of real findings in a new program.
• Inline controls for uploads and downloads, delivered through a proxy or the platform's own policy engine.
• Sharing controls, which are frequently the higher-value half. A DLP policy that inspects file content matters less than a setting that prevents "anyone with the link" sharing outside the tenant.
• Tenant restrictions, so a managed device can reach the corporate instance of a service and not a personal one, which closes the "upload it to my own account" path.

Running a program that works

1. Decide what matters. Three or four data categories, defined precisely enough that a policy can be written for them.
2. Find where it is. An at-rest scan of file shares, endpoints and SaaS. Expect surprises, and expect that some of the findings are best fixed by deleting data nobody needs.
3. Write narrow policies for the highest-value category on the most common path. One data type, one channel.
4. Run in audit for several weeks. Measure the match rate and read a sample by hand.
5. Tune before enforcing. Raise thresholds, add proximity conditions, move from regex to exact data matching where the volume justifies it.
6. Enable coaching, then blocking on the narrowest case.
7. Build the exception process before you need it, with an owner and an expiry on every exception.
8. Report on trends rather than on alert counts: which categories move, on which channels, and whether that is changing.

The metric that matters most is the ratio of true findings to alerts. A program with thousands of alerts a week and a handful of real ones is producing noise, and no amount of additional coverage improves it.

The verdict

DLP is a good control against ordinary human error and casual policy breaking, which is most of what actually happens. It is a poor control against a determined person, and any deployment sold on the promise of stopping insider theft outright will disappoint.

Two things determine whether it works. Classification, because a system that cannot tell what is sensitive cannot make a sensible decision. And tuning, because a noisy policy trains everyone involved to ignore it.

And the cheapest win in the whole subject sits outside the product: hold less data. Records that were deleted when they stopped being needed cannot be exfiltrated, cannot be mailed to the wrong recipient, and need no policy at all.

Related guides

• Insider Threats Guide
• Encryption Explained
• What to Do After a Data Breach
• Least Privilege Explained
• Cloud Security Fundamentals