Data Loss Prevention

An engineer who just gave two weeks notice uploads the full customer list to their personal Google Drive. Data loss prevention is the control that is supposed to catch that upload. Sometimes it does. Often it does not, because they zipped the file first, or renamed it to vacation-photos.zip, or pasted the rows into a web chat the DLP policy never covered. Knowing exactly when DLP catches an exfil and when it shrugs is the difference between trusting it and being surprised by it.

DLP inspects data in three places. In motion, watching email, web uploads, and network egress for sensitive content leaving. At rest, scanning file shares and endpoints for sensitive data sitting somewhere it should not be. In use, an endpoint agent watching a user copy files to a USB stick, print them, or hit the clipboard. Microsoft Purview, Forcepoint, and the DLP built into most secure web gateways all cover some mix of these.

How it decides what is sensitive matters more than where it looks. Regex and pattern matching catch structured data like card numbers and SSNs, and they are noisy because a lot of 16-digit strings are not cards. Exact data matching, sometimes called fingerprinting, is stronger: you feed DLP a hash of your actual customer database, and it fires only when those specific records move, which kills the false positives. Document fingerprinting does the same for whole files. If you only turn on regex, expect the SOC to drown in alerts about phone numbers.

Where it works, and where it quietly fails

DLP is very good at accidents. The honest employee who emails a spreadsheet to jsmith@gmail.com instead of jsmith@yourcorp.com, the finance person who attaches the wrong workbook, the developer who pastes a config with real credentials into a public Stack Overflow question. Those are most real data-loss events, and DLP catches the overwhelming majority of them. That alone justifies deploying it.

Against a determined insider, it leaks like a sieve. Content inspection cannot read what it cannot parse, so a password-protected zip is opaque to it. The policy can block all encrypted archives, but that also blocks the legitimate ones your business sends daily, and now you are in the tuning fight every DLP admin knows. Photographing the screen with a phone defeats it entirely. So does copy-pasting into a channel the policy does not monitor, or using a personal cloud client on an unmanaged device the agent was never installed on.

That last line is the defender's real edge. A canary record, a fake customer whose email or account fires an alert the moment it is queried or appears anywhere outside the database, catches the exfil that content inspection missed. It works precisely because it does not rely on parsing the payload.

Run DLP in block mode too aggressively and you halt the business, so most shops run it in monitor-and-alert mode. That makes it a detection tool feeding your SOC, not a wall. The honest way to think about DLP is friction plus detection: it turns an insider's exfil from trivial into slightly annoying, and it catches almost every accident. It does not stop someone who has decided to steal and has ten minutes to think. The P in the name oversells it.