DLP Across Cloud and On-Premises Environments
- Hybrid DLP enforces one set of data policies across on-premises and cloud channels, including AI tools.
- A single classification scheme is the foundation; without it, consistent DLP policy is impossible.
- Combine patterns, exact data matching, document fingerprinting, OCR, and ML classifiers for accurate detection.
- Start in monitor mode, validate with test data on every channel, then enforce in phases.
- Generative AI is now a major DLP channel, with shadow AI common in 2026 breach research.
Hybrid DLP is a data loss prevention program that detects and controls sensitive data consistently across on-premises systems and cloud services. Instead of running separate DLP products for the network, the cloud, and endpoints, each with its own rules, a hybrid DLP program defines data classes once and enforces them at every point where data can leave.
This article is part of the Hybrid Cloud Security guide.
Why DLP breaks in hybrid environments
DLP breaks in hybrid environments when each channel uses a different product with its own rules, dictionaries, and exceptions.
Traditional DLP was built for a perimeter: an email gateway, a web proxy, and an endpoint agent inside one network. In a hybrid estate, data moves through:
- On-premises web gateways and cloud web gateways
- SaaS applications, both through inline traffic and data already stored in them
- Private applications reached through ZTNA
- Endpoints on and off the network
- Browser sessions and generative AI tools
When each channel uses a different product, organizations end up with different dictionaries, different thresholds, and different exception lists. A document blocked at the office proxy may upload freely from home.
The AI channel adds urgency. Verizon’s 2026 Data Breach Investigations Report found that 45% of employees now use AI regularly on corporate devices, 67% of users accessing AI services on corporate devices do so with non-corporate accounts, and shadow AI became the third most common non-malicious insider action in DLP datasets, with source code the data type most often submitted to external generative AI tools. OWASP likewise ranks sensitive information disclosure among the top risks for large language model applications.
Supported channels to cover
Evaluate DLP coverage across eight channels, from on-premises web uploads to generative AI prompts.
| Channel | Where enforcement runs | What to control |
|---|---|---|
| Web uploads (on premises) | Local gateway, which forwards to the Skyhigh cloud where DLP policy is applied | File uploads, form posts, paste to web apps |
| Web uploads (remote) | Cloud secure web gateway | Same as above for remote users |
| SaaS inline | CASB proxy or web gateway | Uploads, sharing actions, downloads to unmanaged devices |
| SaaS at rest | CASB API | Files already stored and shared externally |
| Email gateway or SaaS API | Attachments and message content | |
| Private applications | Zero Trust Access brokered locally; DLP applied through the cloud path | Downloads from internal apps |
| Endpoints | Endpoint DLP agent | USB, print, local sync, clipboard |
| Browser and AI tools | Browser controls or proxy | Prompts, pasted content, file uploads to AI services |
Use common classifications and policy intent across supported channels, and validate each channel’s controls and enforcement behavior. This channel inventory describes a DLP program; endpoint, email, and other capabilities may require separate products or supported integrations.

Classification: define data once
Define each data class once, with an owner, before deciding how to detect it.
Typical classes include regulated personal data, payment card data, health data, intellectual property, source code, and financial reporting.
Use detection methods suited to each class:
- Patterns and dictionaries for broad identifiers such as card numbers, national IDs, and medical terms.
- Exact data matching (EDM) to fingerprint records from structured sources such as customer databases, so DLP matches your actual data rather than anything that looks like it.
- Indexed document matching (IDM) to fingerprint specific documents, such as contracts, designs, or board materials, and match full or partial copies.
- Optical character recognition (OCR) to find sensitive text in images, such as scanned IDs or screenshots.
- Machine learning classifiers for document types that are hard to describe with rules.
Where fingerprints are created matters for sovereignty. Ask each vendor where fingerprints are generated and what is transmitted, since some approaches generate fingerprints inside your environment and send only hashes to the DLP service.
Data discovery should feed classification. DSPM identifies where sensitive data lives and how exposed it is, which tells you which classes and repositories to prioritize. See How DSPM and SSE Work Together to Reduce Data Risk.
Policy examples
Good DLP policies pair a specific data class with the channels where it can leave and a proportionate action.
| Policy | Data class | Channels | Action |
|---|---|---|---|
| Customer records leaving to personal destinations | EDM match on customer database | Web, SaaS, email, AI tools | Block; notify user |
| Source code to generative AI | Source code classifier | Browser, web gateway | Block for unsanctioned AI; allow for approved enterprise AI with logging |
| Board materials shared externally | IDM fingerprint | SaaS API, email | Remove external share; alert owner |
| Card data in uploads | Payment card pattern with validation | Web, SaaS | Block; incident to PCI team |
| Scanned identity documents | OCR plus identity patterns | Web, SaaS, endpoint | Block upload to unsanctioned services |
| Bulk downloads from private apps | Volume threshold plus classification | ZTNA, endpoint | Require justification; alert on anomaly |
Each policy should be defined once and applied to every relevant channel, not rebuilt per product.

Exceptions
Exceptions are necessary, but unmanaged exceptions are where DLP programs fail, so record each one in detail:
- The business owner and justification
- The specific users, destinations, or data classes it covers
- The channels it applies to
- An expiry or review date
- Compensating controls, such as logging or encryption
Prefer narrow exceptions, such as a specific partner domain for a specific data class, over broad ones such as an entire department.
Validation
Validate DLP by testing classifications first, running in monitor mode, and confirming the expected policy outcome on every supported channel.
- Build a test corpus. Include true positives from each data class, near-misses that should not match, and images and large files.
- Test classifications before policies. Confirm that detection works for each class and channel.
- Run in monitor mode. Measure matches and false positives on real traffic before blocking.
- Review false positives with data owners and tune thresholds or fingerprints.
- Enforce in phases, starting with the highest-risk class and channel.
- Test every supported channel. Upload the same test file through the office gateway, remote access, SaaS, email, and an AI tool, and verify the expected detection and action for each configured path.
- Re-test after changes to classifications, channels, or platform versions.
On-premises DLP vs. cloud DLP
On-premises and cloud DLP differ in where content is inspected and evidence is stored, not in what policy should say.
On-premises DLP, where a vendor offers it, inspects data on infrastructure you control. Skyhigh applies data protection in its cloud, while the on-premises gateway enforces web and private application policy locally. Traffic requiring DLP is forwarded to the Skyhigh cloud. For platforms that offer both local and cloud DLP, evaluate inspection location, policy behavior, and supported channels separately. Where full content evidence is stored should follow the same residency rules as the data itself. See Data Sovereignty in Hybrid Cloud Security.
How Skyhigh delivers hybrid DLP
Skyhigh delivers hybrid DLP with shared classifications and a cloud-applied data protection service for traffic from local and cloud enforcement points.
Skyhigh uses shared DLP classifications across supported web, SaaS, AI, and private-application channels; endpoint and other channel coverage depends on the selected products and integrations (Skyhigh Security). Skyhigh Advanced DLP combines EDM, IDM, and OCR with machine learning classification, supports scanning of files up to 250 MB, and uses machine learning to reduce false positives (Skyhigh Advanced DLP data sheet). Through Skyhigh Hybrid SSE Mesh, the on-premises gateway enforces web and private application policy locally and forwards the relevant traffic to the Skyhigh cloud, where the same DLP policy is applied. Policy is authored once and applies wherever the user is, and agentless Secure Browser Controls extend data protection to prompts and uploads in supported browsers. Skyhigh states that all of its DLP capabilities, including EDM, IDM, and ML auto-classifiers, are covered by FedRAMP High authorization (Skyhigh Advanced DLP data sheet).
Sources
- Verizon. 2026 Data Breach Investigations Report. https://www.verizon.com/business/resources/reports/dbir/
- Skyhigh Security. Skyhigh Advanced Data Loss Prevention data sheet. https://www.skyhighsecurity.com/wp-content/uploads/2025/11/ds-data-loss-prevention.pdf
- Skyhigh Security. “Modernizing Your Symantec Edge Secure Web Gateway With Skyhigh Hybrid SSE Mesh” (July 15, 2026). https://www.skyhighsecurity.com/industry-perspectives/modernizing-your-symantec-edge-secure-web-gateway-with-skyhigh-hybrid-sse-mesh.html
- OWASP. LLM02:2025 Sensitive Information Disclosure. https://genai.owasp.org/llmrisk/llm022025-sensitive-information-disclosure/