Data loss prevention (DLP) and encryption are not rivals, and you do not choose one over the other. Encryption makes data unreadable to anyone without the key. DLP watches how data moves and stops it leaving by routes you have not approved. Encryption protects the data itself. DLP controls what people and systems do with it. A UK business handling personal or client data normally needs both, plus the monitoring that ties them together.
This guide explains what each control does, where each one fails, how UK regulator guidance treats them, and how to decide where to spend first.
TL;DR
- Encryption protects confidentiality: if a laptop, backup or database is stolen, the contents stay unusable without the key.
- DLP provides visibility and policy enforcement: it spots and blocks sensitive data being emailed, uploaded, copied to USB or exported in bulk.
- Encryption does little once a user is logged in and the system is running. DLP is built for exactly that gap.
- DLP without a phased rollout creates friction. Start in monitor mode, then move to blocking.
- Neither works well in isolation. Centralized monitoring, such as managed SIEM, shows you what actually happened when something goes wrong.
Table of Contents
- What encryption does, and what it does not
- What data loss prevention does
- Data loss prevention vs encryption side by side
- How the two work together
- What UK guidance expects
- The missing third layer: monitoring
- A practical order of priorities
- Perspective: what we see in practice
- How Zero Through can help
- FAQ
- Sources
What encryption does, and what it does not
Encryption converts readable data into ciphertext using an algorithm and a key. Only someone holding the right key can turn it back. The UK regulator, the ICO, describes it as an example of an appropriate technical measure under the UK GDPR, depending on the nature and risks of your processing. It is most useful in two places:
- Data at rest: laptops, phones, USB drives, backup media, databases and file servers. The ICO says encrypting stored personal information gives effective protection against unauthorised access to that data.
- Data in transit: traffic between a browser and a server, or between offices. The NCSC’s guidance on using TLS to protect data explains that well-configured TLS stops a third party eavesdropping or tampering, and that only TLS 1.3 gives protection against quantum attacks when configured correctly.
The limits of encryption
Encryption has a blind spot that matters a great deal in daily operations: it protects data from people who do not have access, not from people who do. The ICO’s guide to data security is clear that encryption does not replace access control policies, staff training and incident response planning. Once a system is booted and a user is logged in, storage-level encryption has largely done its job. An attacker who takes over a running session, or a member of staff who attaches a customer list to a personal email, is working with decrypted data.
There is a practical illustration in the ICO’s own personal data breach examples. An employee lost a briefcase holding a laptop and paper files from a sensitive court case. He believed the laptop was encrypted. It was not, and that changed the breach from one that looked unreportable to one that had to be reported to the ICO and to the people affected. The lesson is not only to encrypt. It is to be able to prove that you did.
Key management is the weak point
Encryption is only as good as the handling of its keys. NIST’s guide to storage encryption for end user devices warns that using a single-factor authenticator for both operating system login and storage encryption weakens security, because one stolen credential opens everything. It recommends enterprise-level authentication, preferably with two factors.
The ICO adds two further points in its encryption guidance: do not invent your own encryption, because it will lack the scrutiny that widely used, independently tested algorithms have had, and pair the technology with an encryption policy and training on how staff manage keys.
What data loss prevention does
NIST defines DLP as a system’s ability to identify, monitor and protect data in use (endpoint actions), data in motion (network actions) and data at rest (storage), using deep packet content inspection and contextual security analysis of things like the originator, the data object and the recipient.
In plain terms, DLP answers questions encryption cannot:
- Is someone emailing a spreadsheet of client records to a personal address?
- Is a user copying thousands of files to a USB stick?
- Is a document marked confidential being uploaded to an unapproved cloud service?
- Is a bulk export running at 2 a.m. from an account that normally never does that?
NIST’s data confidentiality project describes the split neatly: DLP detects abnormal patterns such as bulk exports or USB use, while encryption ensures that if a breach does occur, the captured data remains effectively unusable.
Where DLP goes wrong
DLP projects fail less often on technology than on rollout. Switching on blocking rules on day one stops legitimate work: finance cannot send a payroll file to the accountant, a solicitor cannot share a bundle with counsel. People then find workarounds, which is worse than having no control.
The ICO’s data protection audit toolkit on system and network security is a useful anchor for this thinking, and the sensible approach is phased:
- Discover: work out what sensitive data you hold and where it sits.
- Monitor: run policies in alert-only mode and learn how data actually leaves the business.
- Tune: remove false positives and adjust rules to real workflows.
- Enforce: block only the movements you are confident are wrong, and give users a clear way to request an exception.
If you run several offices or countries, rules also need to vary by location and regulator. We cover that in more detail in our piece on data loss prevention across locations.
Data loss prevention vs encryption side by side
| Question | Encryption | DLP |
|---|---|---|
| Main job | Make data unreadable without a key | Detect and control data movement and use |
| Core value | Confidentiality if data is stolen or lost | Visibility and policy enforcement |
| Typical scope | Disks, devices, databases, backups, network traffic | Endpoints, email, web, cloud apps, removable media |
| Protects against | Lost laptops, stolen drives, interception | Accidental leaks, insider misuse, bulk exfiltration |
| Weak against | Authorised or logged-in misuse, poor key handling | Encrypted channels it cannot inspect, badly tuned policies |
| Main cost | Key management and device coverage | Policy design, tuning and ongoing review |
| Evidence value | Shows data was unusable if lost | Shows what left, who sent it and where |
Read the table as two halves of one control set. One reduces the damage if data escapes. The other reduces the chance it escapes.
How the two work together
A common objection runs: if everything is encrypted, why monitor it? Because encrypted data has to be decrypted to be used, and the point of use is where most leaks happen. The reverse objection is just as common: if DLP blocks leaks, why encrypt? Because DLP cannot see a stolen backup tape, a lost phone or a drive removed from a decommissioned server.
Consider three realistic situations.
A lost laptop. Full-disk encryption is the control that matters. Without it, you may have a reportable breach. With it, you can show the data was protected and record the incident.
A departing employee. The laptop is encrypted, but the employee is logged in and authorised. DLP flags a sudden transfer of client files to a personal cloud account. Encryption would not have stopped it.
An email to the wrong recipient. The message may be sent over an encrypted connection, but the content goes to the wrong person in plain view. DLP policies that scan for client identifiers or account numbers can warn the sender before it leaves.
A subtler interaction also exists. Encrypted traffic is invisible to inspection tools unless they sit at the right point, such as on the endpoint or at a managed gateway. DLP architecture therefore has to be designed with your encryption in mind, not bolted on afterwards.
What UK guidance expects
UK GDPR does not name a product. Its security principle asks for appropriate technical and organisational measures, which means risk analysis, policies, training and testing as well as tools. Encryption is a named example of such a measure. DLP is not named, but it is a way to evidence control over how personal data moves.
The NCSC’s 10 Steps to Cyber Security data security guidance frames the aim as protecting data in transit, at rest and at end of life, which includes effectively sanitising or destroying storage media. It also warns that when you use cloud services or work within a supply chain, you cannot rely only on your own controls. You need assurance from providers about what protection they apply, such as encryption by default. Our guide to the cloud shared responsibility model sets out who secures what, and the question matters for any firm that has moved files into SaaS tools.
Retention is the other half of end-of-life. Data you should already have deleted is data you can still lose. Sector rules show how specific this can get: transport firms, for example, have to think about proof-of-delivery retention policy and when to pause deletion. A DLP programme works best when it knows which data is meant to exist and for how long.
For firms operating in several jurisdictions, the rules also differ by country. Our overview of data protection laws for multinationals is a starting point, and the wider information security guide for multinational businesses covers how to organise controls across sites.
The missing third layer: monitoring
Neither control tells you the full story of an incident. NIST’s data confidentiality guidance argues that a robust strategy must integrate log collection, collation and correlation. DLP alerts on anomalous activity and encryption protects stored data, but a centralized monitoring capability is what lets a security team establish how far a breach extended and contain it. The same guidance pushes organizations to stop treating tools in isolation and move to an integrated architecture.
In practice that means DLP alerts, endpoint events, identity logs and cloud activity feeding one place where someone is watching them. Without that, a DLP alert is one more notification in a queue. If you want to understand what this involves and what it costs, our article on managed SIEM monitoring, costs and what to check goes through it.
When something does go wrong, you also need a tested plan for the response itself, which is not the same as disaster recovery. We explain the difference in incident response vs disaster recovery.
A practical order of priorities
If you are starting from a patchy position, this sequence usually gives the most risk reduction for the effort.
- Know your data. Identify where personal, financial, client and health data lives, including cloud storage and personal devices used for work.
- Encrypt the baseline. Full-disk encryption on every laptop and phone, encrypted backups, encrypted databases that hold sensitive records, and TLS everywhere. Keep an inventory so you can show what is covered.
- Fix authentication and keys. Separate the credentials for device login and disk unlock where you can, use multi-factor authentication, and decide who can recover or revoke keys.
- Deploy DLP in monitor mode. Start with email, web uploads and removable media, which are the usual leak paths. Review what the alerts reveal.
- Tune, then enforce. Move specific high-confidence rules to blocking. Keep monitor mode for the rest.
- Centralize the logs. Send DLP, endpoint and cloud events into a monitored platform with someone responsible for triage.
- Test it. Run a security audit or penetration test to check that controls work as intended and that nobody has quietly bypassed them.
Sector matters. Firms handling privileged client material, such as law firms, need particularly careful policies on what leaves matters and by what route. A real example from our own work is how a law firm closed a critical client data exposure before an audit.
Perspective: what we see in practice
We work with businesses that operate across several locations, often in regulated sectors such as financial services, healthcare, retail and law. The pattern we meet most is not a total absence of controls. It is controls that were bought one at a time and never joined up. Encryption is on most laptops, DLP is licensed but running in a default state nobody reviews, and the alerts go to an inbox no one owns.
Our view is that the question “DLP or encryption?” is the wrong frame. The better question is: if data left this business tomorrow, would we know, could we stop it, and could we show it was unreadable? Encryption answers the third part. DLP answers the first two. Monitoring is what makes the answers timely.
We also think findings should be explained in plain terms and turned into a roadmap, not a generic checklist. A tool that blocks everything gets switched off. A tool that is tuned to how your teams really work gets kept. That is why we adapt services to each client’s operations and industry, and scale support as the organization grows.
— Shirish
How Zero Through can help
If you want to know where your data controls stand, an IT security audit reviews what is actually in place and gives you a prioritised plan. If alerts are your bottleneck, our managed SIEM services bring logs from across your sites together under expert monitoring. For wider support across several offices, see our global IT support.
FAQ
Is DLP a replacement for encryption?
No. DLP monitors and controls how data is used and moved, while encryption makes stolen or lost data unreadable. NIST treats them as complementary: encryption gives the confidentiality baseline and DLP gives the visibility and policy enforcement layer. Dropping either leaves a gap the other cannot fill.
Does encrypting data stop data leaks?
Not by itself. Encryption protects data at rest and in transit from people without the key, but it does not stop an authorised or logged-in user from sending data out. The ICO notes that encryption does not replace access controls, training and incident response. DLP is aimed at those misuse and accidental leak scenarios.
Do I need DLP to comply with UK GDPR?
UK GDPR does not require a specific product. It requires appropriate technical and organisational measures based on your risks, and encryption is one named example. DLP is a common way to show control over how personal data leaves your business, but whether you need it depends on your data, your size and your risk assessment.
Where should a small or mid-sized firm start?
Start with encryption on every device and backup, multi-factor authentication and an inventory of where sensitive data lives. Then run DLP in monitor-only mode on email and removable media before you block anything. Add centralized monitoring once you have alerts that someone needs to act on.
Sources
- A guide to data security | ICO
- Encryption | ICO
- Encryption and data storage | ICO
- Personal data breach examples | ICO
- System and network security | ICO
- 10 Steps to Cyber Security: data security | NCSC
- Using TLS to protect data | NCSC
- Data loss prevention glossary | NIST CSRC
- Data Confidentiality: Detect, Respond to, and Recover from Data Breaches | NCCoE
- NIST SP 800-111: Guide to Storage Encryption Technologies for End User Devices
