Zscaler - Data Loss Prevention

What DLP Does

Data Loss Prevention (DLP) is a cybersecurity strategy designed to prevent sensitive or confidential data from being leaked, shared, or accessed by unauthorized individuals. DLP solutions monitor, identify, and control the flow of sensitive data across networks, devices, and endpoints using content inspection, contextual analysis, policy enforcement, and user activity monitoring. The goal is to ensure regulatory compliance, safeguard intellectual property, and reduce the risk of external attacks and insider misuse — since a breach can bring financial loss and lasting reputational damage.

In the Zscaler console (console.zscaler.com), signed into via the Zscaler Authentication Service, DLP policy lives under Data Security > Configuration > Data Loss Prevention. Rules are evaluated top to bottom and stop at the first match. A rule can reference several DLP engines at once, and its action fires if any one engine is triggered.

Engines and Dictionaries

Dictionaries and engines are managed separately from policy, under Data Security > Common Resources > Dictionaries & Engines. A dictionary defines a specific data pattern to detect — such as U.S. Social Security numbers or credit card numbers. Zscaler ships many pre-built dictionaries, though custom ones can be created with their own match patterns.

An engine is a collection of one or more dictionaries, and engines — not individual dictionaries — get attached to a rule (up to four per rule). This lets one engine detect content spanning multiple data types: an organization wanting to flag either Social Security or credit card numbers can build one engine referencing both dictionaries instead of writing separate rules.

WWT's lab environment illustrates this well. The "5 or more Credit Card Numbers" engine triggers on five or more matches against the credit card dictionary, and a "5 or more PII Identifiers" engine similarly groups several PII dictionaries under one threshold. For a multi-dictionary engine, a dropdown lets you choose whether the trigger requires any one dictionary to match, all dictionaries to match, or a cumulative match count summed across them.

Building a DLP Rule

From Data Security > Configuration > Data Loss Prevention, click Add Rule and choose whether it uses content inspection. With content inspection, ZIA's own DLP engines analyze traffic directly; without it, the rule matches on criteria like destination or application and forwards traffic to a third party via ICAP for inspection.

For a rule with content inspection, name the rule and select the engine(s) to evaluate — for example, "5 or more Credit Card Numbers," or a paired pattern such as Block_PII_ALL placed above an Allow_PII_HR rule for an authorized HR group, relying on top-to-bottom, first-match order. The rule then supports the usual criteria — URL categories, cloud apps, users, locations — plus a minimum data size field; leaving it at zero inspects all matching traffic regardless of size.

Incident Receivers and Notifications

A DLP incident receiver securely collects information when a violation occurs, configured at Data Security > Common Resources > DLP Incident Receiver. Choosing the Zscaler Incident Receiver provides an OVA file deployable on-prem or in a cloud VM; once deployed, its URI can be referenced by rules. A third-party receiver can instead be configured under ICAP settings.

Back in the rule, the action field is typically Block, though Allow is available to log matches for visibility without disrupting the user. The notification field specifies who is alerted — an existing auditor/editor user or an external email address — and a notification template controls message content, whether violating content is attached, and whether TLS is used (requiring a receiving SMTP server that supports it). Advanced DLP settings let specific traffic be exempted from monitoring by cloud application or URL.

Testing a DLP Rule

To validate a rule, use a test file with fictional sensitive data — names alongside credit card numbers — and try moving it through several channels. Attaching it to a webmail message, pasting its contents into the message body, and uploading it to a cloud storage service like Google Drive should all be blocked, each with an on-screen error. An FTP upload attempt shows that DLP also catches accidental exposure: a user who mistakenly grabs the sensitive file instead of an intended test file still finds the transfer blocked, with the reason surfaced in the block message.

Each blocked attempt notifies the configured auditor, including a copy of the violating file when the template attaches violating content — though routing that evidence to a dedicated incident receiver is generally more secure than an individual mailbox.

Monitoring and Analytics

DLP activity is visible under Analytics > Web Insights, which includes DLP-specific filters. Filtering by DLP engine — for example, selecting the "5 or more Credit Card Numbers" engine — surfaces logs for violating traffic and gives administrators a clear audit trail.

Together, engines, dictionaries, rules, incident receivers, and analytics form a complete workflow: define what sensitive data looks like, decide how to detect it, determine the response, and confirm enforcement through logging. Used well, DLP in ZIA is a powerful control for regulatory compliance, protecting intellectual property, and reducing the risk of data breaches.