Data loss prevention (DLP) is the set of controls that stops sensitive information leaving an organisation through email, web uploads, cloud apps and other channels. For European buyers, the question that matters most is not whether a platform has DLP, but where the inspection happens and whose laws govern it. Inspection means decryption, and decryption means someone, somewhere, can read your data in the clear.
This guide explains what DLP is, how it works once it moves inside a SASE platform, what it can and cannot do, and why the jurisdiction of your provider has become a data-protection decision rather than a technical footnote.
What is data loss prevention (DLP)?
Data loss prevention is a coordinated set of policies and technical controls that detect, monitor and block the unauthorised movement of sensitive data such as personal information, health records, financial data and intellectual property. It works by inspecting content and context, then enforcing a policy: allow, log, alert or block.
DLP has traditionally been deployed across three vectors:
- Network DLP, sitting at the perimeter to inspect protocols like email (SMTP), web (HTTP/HTTPS) and file transfer (FTP).
- Endpoint DLP, running as an agent on a laptop to govern local actions like USB copying, printing, screenshots and clipboard use.
- Cloud DLP, scanning data at rest inside SaaS suites and cloud storage, either through APIs or an inline proxy.
Detection relies on two complementary methods. Content-based inspection reads the payload itself using pattern matching for structured formats (credit card numbers, IBANs, national IDs), exact data matching against hashed database records, document fingerprinting, optical character recognition for text inside images, and machine-learning classification for unstructured documents. Context-based inspection looks at the signals around the event instead: who the user is, the device posture, the destination, the location, the time and the volume. A bulk download to an unmanaged device from an unusual location looks wrong even before anyone reads the file.
How does DLP work inside a SASE platform?
Inside SASE, DLP stops being a standalone product and becomes a shared service that runs in the same inspection pipeline as the other security engines. Traffic from users, sites and devices routes to the nearest point of presence, gets decrypted once, and is inspected simultaneously for threats and for sensitive data before being re-encrypted and sent on.
That single-pass model is what separates SASE DLP from the older approach. Legacy architectures chained tools together, so traffic was decrypted and re-encrypted at each hop, adding latency at every step. A SASE platform decrypts once and applies web filtering, firewall rules, cloud application policy and DLP in the same pass.
The clean way to understand where DLP fits is to keep it distinct from its neighbours. A secure web gateway inspects general outbound web traffic and blocks threats. A cloud access security broker governs which SaaS applications are in use and how data moves through them. DLP is the classification layer that both rely on. It is the engine that decides whether a given payload contains regulated data, and the SWG and CASB enforce the response. In a well-built platform they share one classification engine and one policy console, not three separate modules pretending to cooperate.
| DLP type | Where it inspects | Strengths | Limits |
|---|---|---|---|
| Network DLP (on-premises) | Perimeter egress, on local network segments | High throughput in the office, no endpoint software needed | Blind to remote workers, direct-to-cloud SaaS and physical media |
| Endpoint DLP (agent) | On the device operating system | Sees USB, printing, clipboard and off-network activity | Agent overhead, Windows/macOS focus, limited Linux support |
| Cloud/SASE DLP (inline proxy) | Distributed cloud points of presence | One policy engine across all hybrid traffic, no hardware, scales automatically | Cannot see local USB or printing without an endpoint component |
For most mid-market teams the practical takeaway is that SASE-delivered DLP closes the remote-work and SaaS gaps that on-premises appliances were never built for, while an endpoint agent remains the only way to police local channels like USB and printing. The two are complementary, not interchangeable.
What can DLP do, and what can it not do?
DLP is effective at catching known patterns in inspected traffic, but it is not a guarantee against every form of data loss. Being honest about the limits is part of deploying it well.
The first constraint is encrypted traffic. Inline inspection only works if the platform decrypts the session, and more than 95% of web traffic is now encrypted. Decryption carries a latency cost and a legal one: decrypting an employee’s private banking or medical session is a privacy problem in itself, which is why teams maintain bypass lists for sensitive categories. The second constraint is false positives. Pattern matching that runs without context flags product serial numbers as if they were national ID numbers, which buries security teams in noise and trains them to ignore alerts. This is the main reason the market is shifting towards context-aware detection.
The third constraint is the changing shape of leak paths. Data no longer leaves only through email attachments and USB sticks. It leaves through SaaS sharing, peer-to-peer apps, supply-chain APIs and, increasingly, generative AI prompts where staff paste source code or financial figures into a public tool. Static perimeter rules struggle with these nested, dynamic flows. The fourth is the operating-system gap: most endpoint DLP agents are built for Windows and macOS, leaving Linux workstations underserved and reliant on network-level inspection. And to be clear about scope, SASE DLP secures data in motion and in the cloud. It does not replace endpoint detection and response, which watches host-level events. The two solve different problems.
Why does jurisdiction decide DLP for European organisations?
For a European organisation, the hardest DLP question is not which patterns to match. It is who can legally read your data at the moment it is decrypted for inspection. This is where data residency and data sovereignty diverge, and where the choice of provider becomes a compliance decision.
Several frameworks converge on this point. The GDPR, in force since 2018, requires data protection by design and restricts transfers of EU personal data; Article 48 says a third-country authority’s demand for data is only enforceable through an international agreement such as a mutual legal assistance treaty. NIS2, with its transposition deadline of October 2024, mandates risk management and supply-chain security under Article 21, which makes foreign cloud custody a documented risk. DORA, applicable since January 2025, requires financial entities to secure information in transit, encrypt it and authenticate recipients under Articles 6, 9 and 14. In Belgium, the CyberFundamentals framework from the Centre for Cybersecurity Belgium is the audited pathway to NIS2, organised around six functions (govern, identify, protect, detect, respond, recover) and four assurance tiers from Small to Essential.
Here is the conflict. To inspect traffic for DLP, a SASE platform must decrypt it at the point of presence. At that instant the readable payload is under the custody and control of whoever operates the platform. If that operator is a US-headquartered company, the US CLOUD Act of 2018 lets US authorities compel disclosure of data under that company’s control regardless of where it is physically stored, and FISA Section 702, reauthorised in 2024, permits bulk interception from US providers. A data centre in Frankfurt does not change the company’s nationality. Residency tells you where the data sits. Sovereignty tells you whose laws reach it. Complying with a CLOUD Act warrant without an MLAT is exactly the unauthorised transfer that GDPR Article 48 prohibits, so the European customer is caught between two legal regimes.
This is where the operator matters more than the marketing. A SASE platform run by a European-headquartered company with no US parent sits outside CLOUD Act and FISA reach, so decryption, inspection and logging all happen under EU law. Jimber is built this way. As a Belgian company processing data inside the EU, its single-console inspection means the moment of decryption stays within European jurisdiction, which supports GDPR-aligned data control without sending sensitive content outside the EU and shortens the documentation a NIS2 or DORA supply-chain assessment demands. The reasoning extends to the broader question of cross-border data transfer in SASE, where the same EU-only data flow that answers the sovereignty question also feeds the audit evidence.
The compliance pressure is not theoretical. According to Mordor Intelligence, European regulators issued more than €1.2 billion in GDPR fines during 2025, up around 22% year on year. And the dependency risk extends beyond fines: there have been documented cases of US providers suspending services to European entities to comply with US sanctions, which turns a sovereignty question into a continuity question for any organisation that cannot afford an abrupt loss of access.
Where does SASE DLP earn its place in the mid-market?
For an organisation of 50 to 400 users with a small IT team, DLP inside SASE pays off in a handful of concrete scenarios rather than as an abstract control. Each maps to a regulatory obligation these teams already carry.
The most common is accidental sharing. According to the Verizon Data Breach Investigations Report published in early 2026, staff mistakes like sending data to the wrong recipient remain a persistent breach pattern, and in healthcare misdelivery sits among the top patterns. Inline DLP on outbound email can parse an attachment in real time and block a message carrying unencrypted patient or client data before it leaves the domain. The second is unsanctioned cloud uploads, where an employee moves a customer database or design file to a personal storage account; a platform with CASB integration can permit the upload to the corporate tenant while blocking the identical file to a personal one. The third is generative AI: the SWG can intercept a prompt and stop source code or financial projections being pasted into a public tool, allowing safe adoption instead of a blanket ban.
For finance and healthcare the stakes are sharpest. A wealth manager or insurer under DORA must show that information in transit is controlled, and DLP is part of that evidence. A clinic protecting patient records under GDPR needs the same. And for organisations running converged IT and OT environments, sensitive industrial telemetry, asset inventories, network traces and risk assessments are themselves data worth exfiltrating. Keeping that inspection inside European borders satisfies the NIS2 supply-chain expectation that critical operational data is not quietly handed to a foreign jurisdiction.
Frequently asked questions
What is the difference between data residency and data sovereignty?
Data residency is the physical location where data is stored, such as a server in Frankfurt or Brussels. Data sovereignty is the legal question of which country’s laws govern that data and who can compel access. A US vendor with an EU data centre gives you residency but not sovereignty, because the parent company remains reachable under US law.
Does GDPR require a DLP tool?
No. GDPR is technology-neutral. It mandates outcomes, protecting personal data from unauthorised access and disclosure, but does not name any specific technology. DLP is one practical way to meet those obligations, particularly the requirement for data protection by design, but the regulation does not prescribe it by name.
Why does SASE DLP need to decrypt traffic?
Because more than 95% of web and cloud traffic is encrypted, an inline DLP engine cannot read the payload without terminating the TLS session first. The platform decrypts at the point of presence, inspects against policy, then re-encrypts before forwarding. Without decryption, inline DLP is blind to most exfiltration.
Does SASE DLP replace endpoint DLP?
Not entirely. SASE DLP covers data in motion across web and cloud channels, but it cannot see local actions like USB copying or printing without an endpoint component. For organisations that need to police physical egress channels, an endpoint agent still has a role alongside the network and cloud layers.
How does DLP support DORA compliance?
DORA requires financial entities to secure information in transit, apply encryption and authenticate recipients under Articles 6, 9 and 14. Because misdelivered emails account for a meaningful share of breaches, inline DLP on outbound traffic is a practical technical control that helps evidence those requirements during a supervisory review.
How does Belgium’s CyFun framework relate to NIS2?
CyberFundamentals is Belgium’s official cybersecurity maturity model, developed by the Centre for Cybersecurity Belgium and modelled on standards like the NIST framework and ISO 27001. It is the audited route to NIS2 compliance in Belgium, organised across six functions and four tiers from Small to Essential, with a verification deadline in April 2026 for in-scope organisations.
Keeping sensitive data inside European jurisdiction is easier when the platform inspecting it operates under European law from the start. If your team is weighing how DLP fits a unified SASE platform without sending decrypted traffic outside the EU, book a demo and see how Jimber handles inline inspection, web security and cloud control from a single console.
