A Category-Wide Inspection Bypass That Quietly Disabled DLP
A financial services firm with 12,000 users runs ZIA with SSL inspection across all categories except one bypass rule. Last quarter a business-critical certificate-pinned mobile app began failing once inspection was enabled. An engineer added the entire 'Business and Economy' category to the Do Not Inspect rule, the app recovered, and the ticket was closed. Two weeks later the DLP team handled an incident: roughly 400 customer records had been uploaded over HTTPS to a sanctioned HR SaaS tool, which sits in a category ZIA inspects by policy, and no DLP alert fired. The DLP rule is enabled, scoped to the correct URL category, uses a PII dictionary, and is set to alert and block. Compliance is now asking whether any HTTPS upload is actually being inspected.
1. Using ZIA's evaluation logic, explain precisely why the DLP rule did not fire even though it is enabled and correctly scoped.
Read the worked answer
SSL inspection is decided before any content-based policy runs. When a destination matches the Do Not Inspect rule, the TLS session is passed through: ZIA still sees the CONNECT/SNI hostname and the server certificate, but not the request path, body, filenames or payload.
DLP is a content-inspection engine - it needs decrypted HTTP requests to match a PII dictionary against an upload. It cannot match a POST it never sees. Widening the bypass from one pinned FQDN to the whole 'Business and Economy' category therefore removed the HR tool, and every other SaaS upload in that category, from inspection.
The dangerous part is the UI: the DLP rule stays green and 'enabled', so dashboards and change reviews show coverage that does not exist. The same applies to Cloud App Control - without decryption ZIA can allow or block a destination, but cannot enforce in-app actions such as upload or download. Note the DLP rule's ordering is irrelevant here; the problem is upstream of it, which is why no amount of DLP tuning would have fixed it.
2. Redesign the exception so the pinned app works and inspection coverage is restored. What do you verify before declaring it fixed?
Read the worked answer
Replace the category exemption with a destination-level one:
- Enumerate the FQDNs the pinned app actually calls - pinned mobile SDKs typically use several domains, and missing one produces intermittent failures that look like a policy problem.
- Create a custom URL category containing exactly those FQDNs. Exempt categories by FQDN only, never by generic category.
- Order an SSL Inspection rule for that custom category set to Do Not Inspect above the general inspect rule; return 'Business and Economy' to inspection.
- Where the pinning problem only affects unmanaged devices, consider inspecting on managed devices via policy based on user/device context rather than exempting everyone.
Verification before closing:
- Upload a synthetic PII document to a non-exempt SaaS tool and confirm the DLP alert and block fire.
- Confirm the pinned app still connects on the affected device class.
- Confirm the exempt FQDN shows as bypassed, not inspected, in the SSL inspection logs.
- Record the exception with an owner, business justification and expiry date, and add a periodic review so it does not outlive its reason.
3. Compliance asks what now protects customer data uploaded to the *exempt* SaaS destination. What is your answer?
Read the worked answer
Be direct: content DLP cannot work on a destination you do not decrypt, so stop presenting the DLP policy as coverage there. Offer compensating controls and document the gap:
- API-based SaaS security scanning of that application's tenant, out of band. It sees stored objects regardless of TLS and catches exposure, oversharing and data-at-rest classification.
- Tenant-side controls: the app's own DLP, retention and sharing restrictions, and tenant restrictions to block personal instances of the same service.
- Endpoint DLP on managed devices, which inspects files before they are encrypted into the browser session.
- Hostname-level control at ZIA - allow only that destination, block look-alikes and unsanctioned tenants - accepting that this is coarse.
Then present a compensating-control matrix keyed by exempt destination, with residual risk signed off. The audit finding is not 'the bypass exists' - bypasses for pinned apps are legitimate. The finding is claiming inspection coverage that does not exist.