DLP Isn't Enough - Just Nobody Wants to Admit It
Dr. Mark Graham
Why do companies with enterprise security still shut down for months after a breach?
Marks & Spencer had Data Loss Prevention systems in place. Knights of Old, a haulage firm that survived 158 years, had security tools. JLR had sophisticated defences.
All three got breached. M&S shut down key operations for months. JLR’s production lines stopped while they figured out what data was at risk. For Knights of Old, the breach forced them into administration, resulting in the shutdown of the business.
Here’s what nobody in the industry wants to say out loud: They all had DLP, and it made absolutely no difference to their shutdown decisions.
It wasn’t that because DLP failed. It’s because DLP was never designed to solve the problem these companies faced when attackers got past their perimeter.
I’ve spent 40 years in cybersecurity, and I’ve seen this pattern repeat so many times I can predict it: breach detected, immediate panic, everything shut down, weeks or months offline while forensics teams try to find if data has walked out the door.
The bit that gets me? Most of these companies could have kept operating. They shut down because they had no confidence about what data was actually at risk. And without that confidence, shutdown is the only rational decision.
But it’s the wrong one. Because the shutdown destroys more business value than the breach ever could.
The pattern everyone sees, but nobody talks about
M&S wasn’t offline for months because of sophisticated attackers. But because their post-breach operational resilience was unable to answer three basic questions:
- Which applications transmitted data during the breach?
- Where did that data go?
- Was it legitimate or theft?
DLP can’t answer these questions. Not because it’s badly designed, but because it was never meant to. DLP monitors email and web traffic for accidental data leaks—sales reps emailing customer lists to their personal Gmail, marketing posting sensitive slides to LinkedIn, that sort of thing.
During an actual security incident, attackers don’t exfiltrate data via email.
They target what DLP can’t see: Word documents with strategic plans, Excel spreadsheets with financial models, CRM data with customer intelligence, finance applications with proprietary business information. Desktop applications where your actual competitive advantage lives.
The ICO’s own guidance on data breach notification talks extensively about detecting and reporting breaches. But there’s a gap in every framework: what do you do when you know you’ve been breached but don’t know what data is at risk?
You shut down. Because it’s the only defensible decision you can make.
Why this keeps happening
I did my PhD on malware detection. I’ve spent decades building security systems. And I’ll tell you something the vendor marketing won’t: we’ve been selling prevention theatre. Take the idea of “perfect perimeter security”, “zero trust architecture”, or “next-gen endpoint protection”. They are all useful and all necessary. Yet none of them will stop determined attackers from eventually getting through. That’s not a defeatist view. It’s reality.
Attackers have more resources, more time, and more motivation than your security budget. Eventually, some get through. Maybe it’s a zero-day vulnerability. Maybe it’s social engineering that bypasses every technical control. Maybe it’s a supply chain compromise that turns trusted software into an exfiltration channel.
Doesn’t matter how it happens. What matters is what you do next.
DLP was built for a different problem. In the early 2000s, the big regulatory fear was accidental PII exposure from personal data leaked via emails that would trigger GDPR fines. DLP solves this beautifully, through email content inspection, web traffic monitoring, and data classification to catch accidental leaks before they become reportable breaches.
But deliberate theft during active security incidents? That’s a different problem entirely.
Attackers don’t trigger DLP alerts because they’re not using the channels DLP monitors. They’re operating through application-to-application data flows that traditional security tools never see. This isn’t a DLP failure. It’s a scope limitation. We’ve been asking one tool to solve two completely different problems.
The shift nobody's making (but everybody should)
When I talk to IT Directors about operational resilience, I get the same response: “We’ve got backup and disaster recovery.” That’s recovery, not resilience.
Operational resilience means you can make strategic decisions during active incidents instead of panic responses.
M&S faced a binary choice: keep everything running and risk ongoing data theft, or shut everything down and accept immense, unavoidable revenue devastation. They chose to shut down because they had no confidence in what data was at risk.
But here’s what gets missed in most breach post-mortems: what if they could have kept customer-facing services running?
Not everything needs to shut down during a breach. Finance systems with sensitive data? Yes, isolate those. HR systems with employee records? Definitely stop those. But customer portals, service systems, operational platforms? If you had confidence that application data from these systems wasn’t being stolen, you could make a strategic decision to keep them live.
That’s operational resilience. That’s the shift we need to make.
The NCSC’s guidance on building a resilient organisation talks about understanding your critical functions and maintaining them during incidents. Good advice. But it assumes you have visibility into what’s actually happening to your data during those incidents.
Most companies don’t. So they shut down everything, just to be safe.
What confidence actually looks like
Knights of Old survived 158 years. One breach, one reaction shutdown, administration. They’re gone.
Could they have survived if they’d been able to keep some operations running? Maybe. We’ll never know. What we do know is that the shutdown killed them faster than the breach would have. This is the true cost of binary thinking during security incidents.
JLR stopped production lines. Not because they had to, but because they didn’t know if production systems were transmitting data to attackers. Daily revenue losses mounted as forensics teams attempted to determine the scope of the attack.
If they had actually known, not just assumed, which systems were safe and which were compromised, they could have made selective decisions. Keep production running on systems with confirmed data protection. Isolate systems where data flows look suspicious. This now becomes strategic triage rather than a wholesale shutdown.
That’s what changes when you have confidence in application data during incidents. It’s not “better security” or “faster detection”, but a different operational capability.
You remain operational for longer because you know which systems are actually at risk. You recover faster because you can restart systems with confidence that data wasn’t stolen. You maintain customer-facing operations while competitors are completely offline.
The FCA’s operational resilience requirements for financial services recognise this. They’re not asking firms to prevent all incidents. They’re asking firms to maintain important business services during incidents.
You can’t maintain services if you don’t know what data is being stolen.
The application data gap
So why don’t companies have this confidence?
Because there’s a gap in every security stack. DLP protects email and web data. That’s only about 20% of your data risk. The other 80% lives in desktop applications, and traditional security tools don’t monitor those flows.
Word documents, Excel spreadsheets, CRM systems, finance applications, HR platforms are business-critical application data flows that are invisible to DLP. Not because DLP is broken, but because it was never designed to look there.
When attackers breach your perimeter, this is what they go after. It isn’t your email archive. It’s your application data. Customer lists in CRM. Financial models in Excel. Strategic plans in Word. Proprietary information in business applications.
This gap is why companies shut down during breaches. Without visibility into application data flows, you can’t make confident decisions about what’s at risk.
I built ZORB to fill this gap. Not as a direct replacement for DLP – you still need email and web data. But as the missing piece that gives you confidence about application data during incidents.
Give us 10 devices and 10 days, and we’ll show you what application data flows your current security stack isn’t seeing. You’ll see actual data flows from Word, Excel, CRM systems, finance applications in your environment – not theoretical threats.
Then you decide. Fill the gap or accept the risk.
But at least you’ll know the risk exists. Most companies don’t realise they have this gap until they’re in the middle of a breach, making shutdown decisions with no data protection confidence.
What actually needs to change
The industry needs to stop pretending perfect perimeter security is achievable. It’s not. Determined attackers get through.
The question is, what happens next?
Right now, the answer tends to be panic shutdowns because companies have no confidence in application data protection. Operational resilience requires changing that answer. The answer is not “better DLP”. DLP already does what it’s designed to do, brilliantly.
Application data theft prevention complements DLP by filling the gap DLP was never meant to cover. Everything changes when you have process-to-flow visibility – i.e. knowing which application process is sending what data where. Application process-driven security enables strategic decisions: shut down the compromised finance system, keep customer-facing services running. Turn systems back on faster because you know critical data wasn’t stolen. This is operational resilience during incidents, not prevention theatre.
Because the alternative is watching more companies shut down for months after breaches, destroying revenue and customer confidence, all because they couldn’t answer the simple question: “What data is actually at risk?”
After 40 years in this industry, I know that this is a solvable problem.
First, we need to admit this problem exists.
Your Questions Answered
Q. Do I need to replace my existing DLP?
No. Application data protection complements your DLP, filling the gap without disruption. Your email/web DLP continues protecting that data; ZORB protects desktop application data. Defence-in-depth, not rip-and-replace.
Q. Can I see this gap in my own environment?
Yes. Our proof-of-value assessment shows actual unauthorised application data flows from your devices. This gives you real evidence, not theoretical risk. Most organisations discover flows they didn’t know existed.
Q. What data does DLP actually miss?
Word documents, Excel spreadsheets, CRM data, finance system exports, HR records. Around 80% of business-critical data resides in desktop applications. DLP was built for email and web data, not application data theft.
