Data loss prevention: Endpoint, network and cloud DLP compared

Data loss prevention (DLP) helps stop sensitive information leaving an organisation in ways its policies don’t allow. Identifying a potential leak is one thing. Preventing it without disrupting legitimate work is another.

Broad detection rules can flag routine activity, from sending payroll files to sharing a contract with an external adviser. If policies generate too many false positives or block essential tasks, teams can become reluctant to enforce them.

Choosing between endpoint, network and cloud DLP is therefore as much an operational decision as a technical one. Each approach sees different activity, applies controls in different ways and places different demands on the team managing it.

Four questions can help shape the decision:

1. Where does sensitive data move, and which channels need protecting?
2. How accurately can the solution identify that data?
3. Can policies be enforced without disrupting legitimate work?
4. Will the solution fit your existing security tools and processes?

What does data loss prevention do?

DLP identifies sensitive information and responds when someone uses, transfers or shares it in a way the organisation hasn’t authorised. Depending on the policy, the response might be to log the activity, warn the user, request a business justification or block the action.

Two things determine how well DLP works: which activity the tool can see and how accurately it recognises sensitive data. The type of DLP you choose largely determines the first.

Endpoint, network and cloud DLP at a glance

Endpoint DLP

Endpoint DLP runs on the device itself, allowing it to monitor what people do with files. Depending on the product and operating system, this can include copying files to removable media, uploading them through a browser, pasting content into another application or printing documents.

For example, Microsoft Purview endpoint DLP supports controls for activities including copying to USB devices and network shares, printing, clipboard use and uploads to restricted cloud domains. Policies can audit, warn about or block supported activities.

Because the control runs on the device, policies can continue to apply when someone is working from home or using public Wi-Fi.

There are limits. Endpoint DLP only covers devices that are enrolled and managed, so personal and unmanaged devices may fall outside its reach. Supported activities also vary by operating system, with some features available on Windows but not macOS.

Agents need to be deployed, updated and tested. They can also generate a substantial volume of alerts if policies are too broad, particularly when they monitor everyday file handling across a large workforce.

Network DLP

Network DLP monitors data moving through the organisation’s network, typically at an email gateway, web proxy or perimeter control. This gives security teams a central place to apply policies without installing an agent on every device.

Encryption affects email and web traffic differently.

An email gateway can generally inspect message content when it processes mail before forwarding it to the recipient’s server, even if the connection between mail servers is encrypted. Messages protected with end-to-end encryption or password-protected files are harder to inspect.

Web traffic usually travels in an encrypted connection between the browser and the destination website. A network proxy can’t inspect the contents of an upload unless the organisation decrypts the traffic first, a process known as TLS inspection.

That decision needs careful consideration. Decrypting web traffic means inspecting what employees browse and upload, which has data protection implications, and the inspection proxy itself becomes a valuable target for attackers. The UK’s National Cyber Security Centre provides guidance on the security and privacy risks of TLS inspection, including the implications of introducing an intermediary that can decrypt traffic.

Network DLP also has blind spots. It won’t necessarily see a file copied to a USB drive or data uploaded directly to a cloud service through a route that bypasses the organisation’s inspection points.

Cloud DLP

Cloud DLP addresses activity that may never pass through the corporate network. If sensitive information sits in Microsoft 365, Google Workspace or cloud storage, the important questions might be who can access it, whether it has been shared publicly and what happens when permissions change.

Cloud DLP covers several different approaches.

API-based tools connect to cloud services to discover sensitive data and monitor sharing. Depending on the integration, they may be able to remove public links, change permissions or quarantine files. Because they operate through the service’s APIs rather than inspecting a user’s live traffic, they don’t add latency to the user’s connection. However, they may detect and remediate exposure only after it has occurred.

The timing depends on the service and integration. Microsoft Defender for Cloud Apps, for example, supports periodic scans for connected apps, with near-real-time scanning available for some.

Other controls are built directly into cloud platforms. Microsoft Purview DLP applies policies across supported Microsoft 365 workloads, while Amazon Macie helps discover sensitive data in Amazon S3 and reports potential risks.

Where an organisation needs to inspect and control activity as it happens across multiple cloud applications, an inline proxy delivered through a cloud access security broker (CASB) or security service edge (SSE) platform may be more suitable.

The key is to establish what each method can actually do. Finding an exposed file, alerting on a risky share and blocking an upload in real time are different capabilities.

How DLP identifies sensitive data

Knowing where a DLP tool operates is only part of the decision. It also needs to recognise sensitive information accurately. Poor classification can lead to false positives, especially once policies begin blocking activity.

Common approaches include:

• Pattern matching. Regular expressions identify data with a predictable format, such as payment card or National Insurance numbers. They’re relatively straightforward to configure but can match unrelated information with the same format, such as an order reference containing 16 digits.
• Exact data matching (EDM). This compares content with specific values from an organisation’s records, such as a customer database. In Microsoft’s implementation, reference data is hashed before upload, and the tool compares hashes to identify matches. This can be more precise than relying on generic patterns alone.
• Document fingerprinting. This identifies content derived from a particular document template, such as an HR form or standard contract. Microsoft Purview’s document fingerprinting is one example.
• Machine learning classifiers. These use examples of particular document types, such as source code or board papers, to recognise content that doesn’t follow a fixed format.
• Optical character recognition (OCR). This extracts text from images and scanned documents so it can be classified.

Each method has its strengths. Pattern matching is useful for structured identifiers, while document fingerprinting or classifiers may be better suited to unstructured content. Combining methods can improve accuracy, although the right mix depends on the data and the policy being enforced.

If broad patterns do most of the work, expect more false positives regardless of whether the tool operates at the endpoint, network or cloud level.

Why DLP projects can stall in monitoring mode

Even well-tuned classification rules can’t anticipate every legitimate way people use sensitive information. Problems often emerge when an organisation moves from detecting potential data loss to blocking it.

A finance team sending payroll files to an approved bureau, for example, might repeatedly trigger a generic policy. The same could happen when a legal team shares contracts with external counsel.

Common causes include overly broad classification rules, pattern matching where a more precise method would work better, and policies developed without input from the people who handle the data.

Over time, a high volume of low-value alerts makes it harder for teams to investigate the important ones. Tuning gets pushed down the priority list, while employees start to see DLP as an obstacle. The result can be a tool that records risky activity but rarely prevents it.

A staged rollout gives the project a clearer route to enforcement.

1. Monitor first. Run policies in audit or simulation mode against real activity. Microsoft’s DLP guidancerecommends monitoring outcomes and fine-tuning policies before introducing more restrictive controls.
2. Tune policies with business owners. Review matches with the teams responsible for each process. Narrow the scope, create appropriate exceptions for approved activity and replace broad patterns with exact matching or document fingerprints where suitable.
3. Introduce alerts and user guidance. Warn users when an action breaches a policy and, where appropriate, allow them to provide a business justification for overriding the warning. Override patterns can help identify legitimate workflows that need further review.
4. Block selectively. Begin with the data types, channels or user groups where classification is most reliable. Expand enforcement as the false positive rate falls and business owners agree that the controls are working.

Measure false positives from the start. Agree what each policy needs to achieve before moving to the next stage, including an acceptable error rate, documented exceptions and sign-off from the relevant business teams.

Integration and coverage: what to evaluate

Reducing false positives is only part of the job. Security teams also need to investigate alerts, understand the context and take action. A DLP tool should fit into the processes they already use.

• Identity context. Integration with Active Directory, Microsoft Entra ID or Okta can help tailor policies to roles and risk. For example, routine access by a finance employee may need to be treated differently from an unusual download by an account that is about to be deactivated.
• SIEM correlation. Feeding DLP events into a security information and event management (SIEM) platform lets analysts compare them with endpoint, identity and network signals. This can help distinguish accidental data sharing from activity linked to a compromised account.
• SOAR automation. Security orchestration, automation and response (SOAR) playbooks can handle routine tasks such as opening tickets or notifying the right team, leaving analysts more time for cases that need judgement.
• SaaS coverage. Check which applications the provider supports through APIs, native controls or inline inspection. Ask what each integration can detect and enforce, rather than relying on a general claim of cloud coverage.
• Policy consistency. Find out whether policies and classification rules can be managed across endpoint, network and cloud channels, or whether each needs separate configuration and maintenance.

A single platform with a shared policy engine may reduce duplicated work. Integrating DLP with an existing CASB or SSE platform, or extending tools already in place, may offer similar benefits. The right choice depends on your environment, your team’s capacity and where sensitive information actually moves.

Questions to ask a DLP provider

• Which classification methods are supported on each channel, and do any require additional licences?
• How will the pilot measure false positives using our own data and workflows?
• Which actions can be blocked as they happen, and which can only be detected or corrected afterwards?
• Who is responsible for tuning policies, and how much ongoing work should we expect?
• What will the solution cost over three years, including agents, TLS inspection capacity, integration work and analyst time?

How to choose the right DLP approach

The right approach depends on where your sensitive information is stored, how people access it and which activities pose the greatest risk.

• Prioritise endpoint DLP if you need to control what happens on managed laptops and desktops, including copying to removable media and local file transfers.
• Prioritise network DLP if inspecting outbound email and web traffic is central to your controls, and you’ve established an appropriate approach to TLS inspection.
• Start with cloud controls if most sensitive information lives in cloud services. Assess the controls already available within those platforms before deciding whether API-based or inline tools are needed.

Many organisations will need a combination of approaches. Before choosing a provider, consider what your existing tools already cover, how accurately the solution classifies data, which actions it can stop in real time and the work required to keep policies effective.

These questions are also useful starting points for discussions with suppliers. Cyber Secure Forum brings senior security and IT professionals together with cyber security providers through pre-arranged one-to-one meetings, alongside a seminar programme.

Attendance is funded for qualifying decision-makers who commit to the full event and their arranged meetings. If DLP is on your agenda, you can check whether you qualify for a funded buyer place.

FAQs

Can cloud DLP prevent data sharing in real time?

It depends on the method and service. Native cloud controls and inline proxies can enforce some policies as activity happens. API-based tools may scan in near real time for some services and periodically for others. In the latter case, they may identify and correct an exposure after it has occurred.

How long should DLP stay in monitoring mode?

There’s no standard period. Set clear criteria at the start, such as an acceptable false positive rate, agreed exceptions and sign-off from the relevant business owners. Monitoring should give you the evidence needed to decide when enforcement is appropriate, rather than becoming a permanent holding pattern.

Does DLP raise employee privacy considerations?

Yes. DLP can involve monitoring how employees handle information, so privacy needs to be considered during planning and deployment. The UK’s Information Commissioner’s Office guidance on monitoring workers covers transparency with staff, choosing the least intrusive approach and when a data protection impact assessment may be required.

Image credit: https://unsplash.com/photos/white-mesh-fabric-under-blue-light-11KDtiUWRq4