Zscaler Internet Access (ZIA): policy, security and data protection
Policy is a stack, not a single page
ZIA enforces several policy types, each with its own ordered rule list: URL Filtering and Cloud App Control for web and SaaS, File Type Control, Firewall Filtering, IPS and Advanced Threat Protection, Sandbox, DLP, and Bandwidth Control, plus SSL/TLS Inspection and Forwarding Control, which determine what can be seen and where traffic goes. Within each policy, rules evaluate top-down and the first match wins. Across the stack, TLS inspection must succeed before content-based controls (DLP, CASB, file-type, sandbox) can act on HTTPS.
Elements every rule shares
Principal (users, groups, departments, locations), destination (URL categories, cloud apps, IPs, services), action, and rank. Prefer user and group criteria over IP addresses, because IP rules break for roaming users and require surrogate IP to preserve identity.
Data protection
DLP engines combine predefined dictionaries, custom dictionaries, Exact Data Match, Indexed Document Match, and sensitivity labels. Actions range from allow-with-notification to block. Cloud App Control actions include allow, block, caution (user override with justification), and isolate.
Traps
- 'We enabled DLP but nothing blocks' - inspection is bypassed for that destination by a Do Not Inspect or Do Not Decrypt entry.
- Broad exception lists silently create visibility gaps; keep them narrow and reviewed.
- Blocking an app's URL instead of using Cloud App Control leaves alternate domains and APIs reachable.
- A broad rule ranked above a specific one shadows it.
Worked example
Uploads of card numbers to a SaaS app are not blocked. First ask: is that app decrypted? If it sits in a Do Not Decrypt list, add a narrowly scoped SSL inspection rule above it, then confirm the DLP rule's rank and that its engine contains the matching dictionary. Verify with the policy test tool.