Network data loss prevention inspects traffic leaving your network for sensitive content, such as card numbers or labelled documents, and blocks, logs or alerts on matches. It works best on traffic it can read. Encryption, personal devices and unmanaged apps limit what it sees, so it needs partners.
What does the definition say?
NIST's glossary, quoting CNSSI 4009, defines data loss prevention as a system's ability to identify, monitor and protect data in use, such as endpoint actions, data in motion, such as network actions, and data at rest, such as storage. It does this through deep packet content inspection and contextual security analysis of the transaction, looking at the originator, the data object, the medium, the timing and the recipient or destination, within a centralized management framework.
Network DLP is the data in motion part. It sits on a gateway, proxy or mail relay and examines what passes through.
How does it find sensitive data?
Three common methods. Pattern matching looks for structures, such as a number that passes a card checksum. Fingerprinting compares content to known sensitive documents. Classification labels, set by people or tools, tell the system to treat a file as restricted. Context then decides the action: sending a labelled document to a personal email domain is different from sending it to a partner.
The glossary's phrase contextual analysis matters here. Matching a pattern alone creates noise, because many strings look like sensitive data and are not.
Why does encryption limit it?
TLS 1.3, specified in RFC 8446, encrypts traffic between a client and a server so that devices in between cannot read it. A network DLP box on the path sees addresses and sizes, not content. To inspect, an organisation has to terminate TLS at a proxy using a certificate its devices trust, then open a new connection to the destination.
That works for managed devices but has costs: performance, privacy and legal considerations, and apps that pin certificates and break. It also adds a very sensitive device that can read everything. Treat the inspection proxy like a crown jewel system, and exempt categories you must not inspect, such as health or banking sites, by policy.
Where does it fall short?
Personal devices and unmanaged cloud apps are outside the path. Data can leave by a USB drive, a screenshot, a photograph of a screen or an approved sharing tool. Encrypted archives and custom encodings defeat content rules. And an authorised user with legitimate access can do harm by sending data they are allowed to see.
DLP detects mistakes and careless behaviour much better than a determined insider. Be honest about that when you set expectations.
A constructed example
A law firm configures its mail gateway to scan outbound messages. A paralegal sends a client file to a personal address to work from home. The gateway recognises a client matter number format and holds the message, and the paralegal gets an explanation and a link to the approved remote access service.
The same firm finds that staff had been using a free file sharing site. The proxy cannot inspect it because the site pins its certificate. The fix is policy rather than inspection: block the site category, provide an approved alternative and log attempts.
How do you roll it out without breaking work?
Start in monitor mode and tune the rules on real traffic before blocking anything. Begin with the highest value data and the most obvious channels: email and web uploads. Give users a clear reason and a way to request an exception. Measure false positives and fix rules weekly at first.
What belongs alongside it?
Classification so the system knows what is sensitive. Access control so fewer people can reach the data. Endpoint controls for removable media and screenshots. Egress filtering that limits where servers can send traffic, as in NIST SP 800-41's guidance on writing firewall rules. And logging, so that you can investigate what the tools did not stop.
Safeguard does not offer network DLP. It helps on the source side by finding secrets and dependency risk in code before they leave your repositories, and its guardrails can constrain what AI agents access.
How to check or apply this
- Write down which data classes you must keep inside and the channels they could leave through.
- Label that data, since the tool can only act on what it can recognise.
- Decide where inspection is legally and technically acceptable, and where TLS stays untouched.
- Run rules in monitor mode and review matches weekly.
- Move to blocking for narrow, high confidence rules first.
- Close channels DLP cannot see with policy, endpoint controls and approved alternatives.
- Review the inspection proxy's own security and access.
Quick check
Can network DLP read HTTPS traffic?
Only if the organisation decrypts it at a proxy with a trusted certificate. Otherwise it sees destinations and volumes, not content.
Is DLP enough to stop insider data theft?
No. It catches many accidents and some deliberate leaks, but a trusted user with access has many routes. Combine it with access limits and monitoring.
Sources
- NIST glossary, data loss prevention
- RFC 8446, TLS 1.3
- NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
Last reviewed: 18 October 2026.
