Your DLP Is Not Stopping Data Exfiltration

Data loss prevention, DLP, has been a security control category for 20 years. DLP, in most deployments, catches accidental data exposure, the wrong attachment on the email, the wrong file uploaded to the cloud, the wrong person with access to the wrong data. DLP does not, in most deployments, stop intentional data exfiltration. The malicious insider with admin access to a sensitive database. The attacker with a stolen credential and a curl command. The third party with a one time data export that was supposed to be temporary. DLP is built for the accidental case. The intentional case runs as the breach case. The gap serves as the reason DLP has been a $2 billion market that has not, by any measurable metric, reduced the rate of data exfiltration breaches.

DLP, in 2026, is a mature control. The vendors are good. The products are well tested. The integrations with email, cloud, endpoints, are solid. The compliance regime is built around the control. The audit checklist includes DLP. The compliance team signs off on DLP. The board is told DLP is in place. The DLP, in place, catches the wrong attachment. The DLP, in place, does not catch the breach.

The breach runs as the intentional case. The breach stands as the case that DLP, in most deployments, was not designed for. The breach counts as the case that the DLP marketing did not mention. The breach sits as the case that the audit checklist did not include. The breach sits as the case that the compliance sign off did not cover. The breach is, in other words, the case that the DLP deployment was not actually defending against, and the breach runs as the case that the security team was not actually prepared for.

What DLP is supposed to do

DLP, in the original design, was a control to prevent the accidental exposure of sensitive data. The original use cases were the wrong attachment on the email, the wrong file uploaded to the cloud share, the wrong print job sent to the wrong printer. The original use cases were the accidental cases, the human error cases, the cases where the user did not intend to expose the data, but the data was exposed anyway because the user clicked the wrong button, or pasted the wrong recipient, or selected the wrong file.

DLP, in the original design, used content inspection to detect sensitive data. DLP, in the original design, used policy enforcement to prevent the exposure. DLP, in the original design, produced alerts when the policy was violated, and blocked the action when the policy was configured to block. DLP, in the original design, was effective against the accidental case. DLP, in the original design, was the right control for the right problem.

What DLP actually does

What DLP actually does, in 2026, is mostly the accidental case. DLP catches the wrong attachment. DLP catches the wrong file upload. DLP catches the wrong print job. DLP produces, in most enterprises, between 100 and 1,000 alerts per day. The alerts are, in most cases, low confidence. The alerts are, in most cases, false positives. The alerts are, in most cases, triaged by the SOC, marked as benign, and ignored.

The DLP, in the SOC’s experience, is a noise generator. The DLP, in the SOC’s experience, is not the control that is going to stop the breach. The DLP, in the SOC’s experience, amounts to the control that the compliance team points to, and the SOC has to deal with. The SOC has, in most enterprises, learned to ignore the DLP alerts. The DLP, in the SOC’s behaviour, is dead. The DLP, in the audit’s checklist, is alive.

The accidental case

The accidental case becomes the case DLP was designed for. The accidental case becomes the case DLP, in most deployments, handles well. The accidental case amounts to the case the audit checklist includes. The accidental case counts as the case the compliance sign off covers. The accidental case is, in other words, the case the DLP deployment is good at.

The accidental case is also, by every measurement, the case that does not lead to the major breaches. The major breaches, the ones that make the news, the ones that drive the regulatory action, the ones that cause the customer churn, are the intentional cases. The intentional cases are the data theft by the malicious insider. The intentional cases are the data exfiltration by the attacker with the stolen credential. The intentional cases are the data export by the third party with the legitimate access. The accidental cases are, in the breach statistics, the minority. The accidental cases are the case DLP catches. The intentional cases are the case DLP misses.

The intentional case

The intentional case runs as the case DLP, in most deployments, was not designed for. The intentional case serves as the case where the user becomes the attacker, or the user has been compromised, or the user has been given access that is broader than the user should have. The intentional case serves as the case where the user knows the data is sensitive. The intentional case sits as the case where the user is taking the data with intent.

The intentional case is, in the DLP architecture, the case that defeats the controls. The malicious insider uses a personal device, on a personal network, with a personal VPN, with the data transferred out of band, in a way that the DLP cannot see. The attacker with the stolen credential uses the same access the legitimate user uses, with the same tools, with the same protocols, with the data exfiltrated in small chunks over time, in a way that the DLP does not flag. The third party with the legitimate access uses the access, takes the data, deletes the access log, in a way that the DLP does not detect.

The gap

The gap counts as the difference between what DLP catches and what DLP misses. The gap sits as the difference between the accidental case and the intentional case. The gap becomes the difference between the deployment the audit signs off on and the deployment the attacker defeats. The gap is, in other words, the difference between the DLP the security team thinks it has and the DLP the security team actually has.

The gap is, in most enterprises, large. The DLP catches the wrong attachment. The DLP does not catch the data theft. The DLP catches the accidental case. The DLP does not catch the intentional case. The DLP, in the audit, amounts to the answer. The DLP, in the breach, becomes the question.

What real data exfiltration defence looks like

Real data exfiltration defence, in 2026, is not a single product. Real data exfiltration defence is a set of controls, working together, addressing the intentional case. The controls include identity and access management, with the principle of least privilege, with just in time access, with access reviews. The controls include data classification, with the sensitive data identified, with the sensitive data tagged, with the sensitive data handled differently from the non sensitive data. The controls include user behaviour analytics, with the baseline behaviour established, with the anomalies detected, with the anomalies investigated. The controls include data loss prevention, but the DLP amounts to the secondary control, not the primary control. The controls include the SOC, with the analysts trained on the intentional case, with the playbooks for the exfiltration scenarios, with the relationships with the legal team and the regulator.

Real data exfiltration defence is, in other words, a program. The program is more than the DLP. The program is more than the audit checklist. The program becomes the work the security team has to do, in addition to the DLP deployment, in addition to the compliance sign off, in addition to the audit.

The realistic setup

1. Treat DLP as the secondary control, not the primary. The DLP catches the accidental case. The primary controls for the intentional case are identity, classification, behaviour analytics, the SOC.
2. Classify the data. The data the security team is trying to protect has to be identified. The classification has to be the basis for the access controls, the DLP policies, the behaviour analytics. The classification counts as the work that the DLP cannot do for you.
3. Apply the principle of least privilege. The users have access to the data they need, not the data they have. The access is reviewed, regularly. The access is revoked, when it is no longer needed. The principle amounts to the work that the DLP cannot do for you.
4. Deploy user behaviour analytics. The analytics establish the baseline. The analytics detect the anomalies. The analytics are the signal in the noise. The analytics are the work that the DLP cannot do for you.
5. Train the SOC on the intentional case. The SOC has the playbooks for the accidental case. The SOC needs the playbooks for the intentional case. The training runs as the work that the DLP cannot do for you.
6. Stop telling the board that the DLP runs as the answer. The board needs to know that the DLP is one control of many. The board needs to know that the data exfiltration defence becomes the program, not the product. The board needs to know that the work serves as the program, not the deployment.

The honest assessment

DLP is a useful control. DLP catches the accidental case. DLP does not catch the intentional case. DLP is, in the audit, the answer. DLP is, in the breach, the question. The security team that relies on DLP for data exfiltration defence becomes the security team that will be reading about itself in the post incident report.

The security team that takes data exfiltration defence seriously, that treats DLP as the secondary control, that builds the program of identity, classification, behaviour analytics, and SOC training, serves as the security team that will not be reading about itself. The program is more work than the DLP deployment. The program is, however, the only thing that works.

The bottom line

Your DLP is not stopping data exfiltration. Your DLP is catching the wrong attachment. The intentional case, the breach case, the case the attacker uses, stands as the case your DLP does not cover. The fix is not a better DLP. The fix is a program of identity, classification, behaviour analytics, and SOC training. The fix becomes the work. The work is yours.