Why your DLP doesn't work on your CRM (and what to do about it)

I spent eight years as Head of DLP at a global law firm. We ran every major enterprise DLP product at various points, Symantec, Forcepoint, Microsoft Purview, Digital Guardian, a handful of smaller ones. None of them worked reliably on our CRM. Not once. And the gap was where our client data actually leaked.

This is why.

Legacy DLP was built for a world we don't live in anymore

Every major DLP platform's architectural assumptions were fixed between 2005 and 2015. They assumed:

• Your data lived on-premise in files, on shares, in databases, in Exchange mailboxes
• Sensitive data moved via email attachments, USB drives, and printed pages
• The network perimeter was the control point, and traffic flowed through it
• Your users sat at corporate desktops with managed applications

Almost none of this describes a modern business. Your CRM is SaaS, accessed in a browser, by users on a mix of devices. Your sales team copies client records into personal spreadsheets, emails, and, increasingly, into AI tools. The 'data' never touches your network perimeter because it was never inside it to begin with.

The specific reason it fails on your CRM

When a user in Salesforce opens a contact record and copies the email address, home address, or notes field, the DLP product has no visibility into that action. The DLP product lives on the endpoint (an agent), on the network (a proxy), or in the email gateway. None of those sees the browser clipboard for a SaaS application.

Some products tried to solve this with browser extensions, but only as a monitoring layer, not a preventive one. They could tell you after the fact that data was copied. They could not stop the copy from reaching its destination.

Telling compliance after the fact that client data was already in someone's personal Gmail drafts is not the conversation anyone wants to have.

What browser-native DLP actually needs to do

To work, browser-layer DLP has to cover four things legacy DLP can't:

1. See the clipboard. Both the source (what was copied and from where) and the destination (where it's being pasted). Both sides are policy-relevant.
2. Evaluate in real time. Not a background scan two hours later. Before the paste completes, the evaluation has to return, and block if needed.
3. Understand the content classification. Regex-based PII patterns are 2014 technology. You need models that recognise client records, PHI, credentials, and source code in context.
4. Produce audit evidence that's legally defensible. Immutable, tamper-evident, exportable. Not a CSV you could alter before your auditor reads it.

What to ask your existing DLP vendor

If you're running any enterprise DLP product and wondering whether it has you covered on the CRM leak path, ask for a demo of the following specific scenario:

A sales rep opens a Salesforce account page with three client contact records. They copy one of the client's email addresses, switch to their personal Gmail tab, and paste it into an email draft. Show me, in your product, the event where this is prevented.

Legacy DLP vendors will either change the subject or propose an implementation that takes six months and doesn't really work. Some will tell you honestly they can't do it. The honest ones are more useful.

What this costs you

Every quarter I audited the path, roughly 12 per cent of the client records in our CRM had been copied out to a non-sanctioned destination in the preceding 90 days. Of those, maybe one in twenty was malicious; the other nineteen were legitimate-intent users taking shortcuts to get their actual jobs done.

The risk wasn't malice. It was entropy. And the only way to reduce entropy at the browser layer is to sit at the browser layer.