Zscaler incident response in seconds, not minutes
Containment in Zscaler is slow because it spans separate consoles, depends on rule order and activation, and often waits for the one person who knows them. Write the runbook in advance: revoke identity first, decide block or isolate, apply a user-scoped change above every allow rule, confirm it is live, and record who approved it. Packaged as one command, that takes seconds.
Why containment is slow in Zscaler
Containing one compromised account in Zscaler usually means 15 to 25 minutes of console work, and most of that time has nothing to do with the decision itself. It goes on finding the right screens and doing things in the right order.
- Separate consoles. Private app access lives in ZPA, web access in ZIA, and the user's device in Client Connector. A full containment touches at least two of them, each with its own login, layout and vocabulary.
- Order matters. ZPA and ZIA both evaluate rules top to bottom and the first match wins. A block rule that lands below an allow rule looks correct and does nothing.
- Changes aren't live until activated. ZIA stages policy changes until someone activates them. A block that was saved but never activated protects nobody.
- One person knows how. In most teams, one or two people really know the Zscaler consoles. If the incident lands on someone else's shift, the first step is finding them.
- It happens at night. Credential compromise doesn't wait for business hours. Whoever is on call is working tired, alone, and often on a laptop that isn't their usual setup.
The fix is a runbook, written before you need it
Speed comes from deciding the steps in daylight, not from typing faster. A good containment runbook any team can apply has five parts.
- Identity first. Disable the account and revoke its sessions in your identity provider. Zscaler policy controls traffic; your identity provider controls who can sign in. Do both.
- Decide block or isolate. Confirmed compromise means block: no private apps, no web access. A suspicion you're still investigating can mean isolation instead, so the user keeps working inside a remote browser while you watch.
- Apply the Zscaler change the same way every time. Scope it to that one user, put it above every allow rule, and use a predictable name so the next person can find it. The details for ZPA and ZIA are in how to contain a compromised user in Zscaler.
- Check it's live. Activate ZIA, then confirm both changes actually applied. Don't assume.
- Record who approved what. Write down who asked, who approved, what changed and when. You'll need it for the incident report and for undoing the change cleanly.
Checklist for the on-call engineer
| Step | Done when |
|---|---|
| Revoke identity | Account disabled and sessions revoked in the identity provider |
| Block or isolate | Decision written down, with the reason |
| Private apps (ZPA) | User-scoped block or isolation rule sits above every allow rule |
| Web access (ZIA) | User-scoped rule in place and the configuration activated |
| Bad sites and IPs | Any phishing or command-and-control destinations blocked for everyone (see how to block a URL in Zscaler) |
| Record | Who requested, who approved, what changed, when |
| Way back | Undo steps written next to the change, so restoring access is as quick as removing it |
If the incident started with a link to a site Zscaler hasn't categorized yet, check it before you decide what to block: how to handle uncategorized URLs in Zscaler.
How Zmate does this from Slack
Zmate turns this runbook into one Slack command. /zmate lockdown user@company.com shows exactly what will change. A Zmate admin approves it with a 6-digit code from their phone, and the user is cut off from private apps and the internet while everyone else keeps working. From typing the command to a contained user takes under 10 seconds, timed end to end in testing. The channel keeps the record of who asked and who approved, and /zmate unlock restores access the same way. Zmate connects through Zscaler's official APIs, with access your team grants and can withdraw at any time.
FAQ
- How long should it take to contain a compromised user in Zscaler?
- Done by hand across the ZPA and ZIA consoles, containment typically takes 15 to 25 minutes, more if the person who knows the consoles isn't on shift. With a pre-written runbook run from a single command, the Zscaler part can take seconds. Identity revocation in your identity provider is a separate step and should happen first.
- What should a Zscaler incident response runbook include?
- Revoke the identity first, decide between blocking and isolating, apply a user-scoped rule above every allow rule in ZPA and ZIA, activate and check the change is live, block any malicious sites or IPs for everyone, record who approved what, and write down how to undo it.
- Can a junior engineer contain a compromised user in Zscaler without console training?
- Yes, if the steps are packaged so they can't be done in the wrong order. A runbook run from a single command, with a senior admin approving each change, lets whoever is on call act in seconds without knowing every Zscaler console.