Zscaler ZIA Data Loss Prevention — Stop the Leak Before It Leaves

① Where DLP sits — and why SSL inspection comes first

Think of ZIA as airport security for outbound traffic. DLP is the bag scanner. But a scanner can only see what's opened. If a request stays inside a sealed TLS tunnel, ZIA sees a destination and nothing else — like a locked suitcase passing the X-ray belt.

That is the single most important fact about ZIA DLP: it is inline web DLP on the SSL-inspected egress path. SSL inspection decrypts the upload, DLP reads the now-visible payload, and the policy decides. No inspection, no payload, no DLP. This is the #1 "DLP isn't working" ticket on the Zscaler community.

② Engines vs dictionaries — the two-decision model

This is the part most people blur together. Keep them separate and DLP suddenly makes sense.

A DLP dictionary answers "what does sensitive data look like?" — a credit-card pattern, a list of project code-names, an SSN regex. A DLP engine answers "how strict is a match?" — it combines dictionaries with Boolean AND / OR / NOT. The rule then calls the engine.

Analogy: airport security. A dictionary is one rule ("no liquids over 100 ml"). An engine is the combined checkpoint logic ("valid boarding pass AND matching ID AND no banned items"). One liquid alone might be fine; it's the combination the checkpoint enforces.

Predefined vs custom dictionaries

• Predefined — Zscaler ships hundreds: PCI (credit cards), PII, SSN, HIPAA / health terms, and newer ones rolled out in 2025 such as CCPA, DPDPA (India's data-protection act) and Credentials and Secrets. Fast to switch on, but blunt.
• Custom — you define the match. Three flavours: Phrases (exact words, up to 256 per dictionary), Patterns (regular expressions for structured strings like an employee ID format), and a dictionary of words with a hit-count threshold (fire only after N matches) and an optional proximity (a high-confidence keyword must sit within a set character distance of the pattern, range 0–10000).

③ EDM vs IDM — fingerprinting your actual data (+ OCR, MIP)

Patterns and keywords are generic — they describe a shape of data. Sometimes you need to protect your specific records: this customer, that contract. That's where fingerprinting comes in.

EDM — Exact Data Match (structured data)

EDM protects structured data — a database export or a CSV of customers. An on-prem Index Tool hashes the sensitive fields (name, account number, card) and uploads only the hashes to the Zscaler cloud — never the readable PII. DLP then fires only when a real record's fields appear together. A random test card number won't trigger; your actual customer's exact combo will.

Analogy: EDM is an Aadhaar exact-match. It's not "looks like an Aadhaar number" — it's "this specific person's exact details". No match on a made-up number.

IDM — Indexed Document Match (unstructured data)

IDM protects unstructured documents — a confidential contract, a design doc, a board deck. You index the source files; ZIA detects full or partial copies, even reworded or trimmed. You set a match-accuracy threshold (e.g. flag at ~75% similarity). More flexible than EDM, but partial-matching means a higher false-positive risk — so tune the accuracy.

Analogy: IDM is the plagiarism checker. Even if a student reorders sentences from the original answer sheet, it still flags the overlap.

OCR and MIP labels — two more inputs

• OCR — Optical Character Recognition reads text inside images (PNG/JPG, screenshots, pictures embedded in a Word doc), then runs normal DLP classification on the extracted text. As of a 2025 update, OCR is configured once at the org level under Administration → DLP Advanced Settings — the old per-rule ocrEnabled toggle was deprecated. Image quality affects accuracy, so expect more false positives here.
• MIP / Purview labels — if your org uses Microsoft Information Protection, ZIA can match on the document's sensitivity label (e.g. "Confidential") instead of re-deriving sensitivity from content. You retrieve the labels from Microsoft into the ZIA MIP account, then use them as match criteria.

The four detection techniques — tap each card

Each card front names the technique; the back gives you the "so what" — when to reach for it.

④ Build a DLP rule — order, action, severity, ICAP, validate

You've got the detection pieces. Now wire them into a rule. A DLP rule has criteria, calls one or more engines, and applies an action. Rules evaluate top-down, first match wins — order matters, just like firewall rules.

The pieces of a rule

• Criteria — who and where: users / groups, locations, URL categories, cloud apps, and file types (ZIA inspects file type by Magic Bytes → MIME type → File Extension, so a renamed .txt that's really a .docx is still caught).
• Engine(s) — the AND/OR logic from Path 2, or an EDM/IDM template.
• Action — Allow, Block, Confirm (warn the user, let them proceed with justification), or Allow and log only (monitor mode — start here to measure before you block).
• Severity — Low / Medium / High / Critical, for incident triage and reporting.

ICAP incident receiver — where the evidence goes

When a rule fires, ZIA can forward the incident to an on-prem ICAP DLP incident receiver (or a third-party DLP). You choose how much it sends:

• MD5 only — just a hash of the offending content. Lightweight, privacy-preserving, but the auditor can't see what leaked.
• Full content — the actual payload, so an investigator can review the leaked data. Heavier, and the receiver must be secured because it now holds sensitive data.

Analogy: MD5-only is a CCTV logbook entry ("something happened at 2pm"). Full content is the actual footage. You keep the footage only where you can lock it down.

Administration → DLP Dictionaries & Engines → Add DLP Dictionary
  Name:        Custom-ProjectKavach
  Type:        Patterns
  Pattern:     PRJ-KAV-[0-9]{6}        # e.g. PRJ-KAV-004217
  Threshold:   Hit Count >= 3          # ignore a single stray mention
  Proximity:   30                      # keyword must sit within 30 chars (optional)

Dictionary "Custom-ProjectKavach" saved.
Match preview: 3 of 3 sample lines matched, 0 false hits on order-ID test set.
# If preview shows hits on your safe sample → tighten the regex / raise the threshold.

DLP Dictionaries & Engines → Add DLP Engine
  Name:   Engine-Kavach-Strict
  Logic:  ((Custom-ProjectKavach)) AND ((Confidential-Keyword))

Policy → Data Loss Prevention → Add Web DLP Rule
  Name:        Block-Kavach-Exfil
  Order:       1
  Criteria:    Groups = Engineering | URL Category = Personal Storage, Webmail
               File Types = Documents, Spreadsheets, Archives
  Engine:      Engine-Kavach-Strict
  Action:      Block
  Severity:    High
  Notification: end-user block page + ICAP incident (Full content)

Rule "Block-Kavach-Exfil" active at order 1.
Test upload (PRJ-KAV-004217 in a .docx to a webmail draft):
  Action: BLOCKED   Engine: Engine-Kavach-Strict   Severity: High
  Incident #88213 forwarded to ICAP receiver (full payload).

Analytics → Web Insights → Logs
  Filter:  User = aditya@org.in   AND   Action = Blocked   AND   last 1 hour
  Columns: Show "DLP Dictionary", "DLP Engine", "Rule", "Reason"

2026-05-31 14:22  aditya@org.in  Action: Blocked
  Rule: Block-Kavach-Exfil   Engine: Engine-Kavach-Strict
  Dictionary: Custom-ProjectKavach (5 hits)  Severity: High
  Incident: #88213 → ICAP receiver (full content)
# If "Reason" names a different rule → fix rule order. If no row at all → SSL inspection isn't decrypting it.