Which containment actions to automate first: identity, email, then endpoint

Every containing action trades speed for risk. The order in which you automate them should follow how easily each can be reversed and how much it can break if the trigger was wrong.

The rubric on this site uses a twelve-action catalogue across five domains: two for endpoint, three for identity, two for email, three for cloud and two for network. The point of a catalogue is that you can count. A platform that lists three of twelve actions in its own documentation has a different pilot from one that lists nine.

Here is the order that has worked for us in practice, from first to last.

Revoking active sessions and tokens for a suspected account is the cheapest containing step. The user signs in again. If the alert was wrong, the cost is a login prompt and a mildly annoyed person. If the alert was right, the attacker loses the stolen session, which is often the whole foothold in a phishing case.

Pair it with a forced password reset or MFA re-enrolment only after you have seen a few clean runs. Those are more disruptive, and a forced reset on an executive at 03:00 has a cost.

Pulling a malicious message from mailboxes after delivery shrinks the number of people who can click. Blocking the sender or domain stops the next wave. Both are reversible: a quarantined message can be released, and a block can be removed.

The risk is scope. A purge rule that matches on a subject line can pull a legitimate message from hundreds of mailboxes. Cap the number of mailboxes an automated purge may touch, and require approval above the cap. That cap is a blast-radius control, and we cover it in the guide on approvals and rollback.

Blocking an address, a domain or a URL is quick and reversible, and it fits automation well. The danger is shared infrastructure. A block on a cloud provider range can take down a business application. Check indicators against an allow list before the block runs, and put an expiry date on every block so that stale entries do not pile up.

Network isolation of an endpoint stops lateral movement, and it also stops the user working. On a laptop that is an inconvenience. On a server it can be an outage. Start with approval required, and automate without approval only for asset classes you have agreed in advance, such as laptops in a low-risk group.

Pay attention to the way the tool isolates. Some keep a channel open to the management console so you can still act on the host. Ask for this to be shown in a demo.

Disabling an account is stronger than revoking a session. It also breaks service accounts, scheduled jobs and anything that signs in as that identity. Automate it first for ordinary user accounts with a high-confidence detection. Keep privileged and service accounts behind human approval for as long as you run the platform.

Rotating an access key, disabling a credential, isolating an instance or restricting a security group can break production in ways that are hard to see from the security console. Do these last, with approvals, and only after you have a tested rollback path. A rotated key that an application still uses is an outage with a delay.

Public documentation differs a lot on what is a shipped action. The pages read on 2026-11-03 and 2026-11-04 show the spread.

• Splunk states 2,800+ automated actions and 300+ third-party tools on its SOAR page (read 2026-11-03). It is a vendor count; the page does not say how many are containing actions.
• Google's SOAR documentation describes a playbook as a trigger, actions and flows, and lists enrichment, notification and host isolation as example actions (read 2026-11-04).
• Microsoft's Sentinel automation rules have built-in actions for tasks, status, severity, owner, tags and closing an incident, and they call playbooks for anything else. The automation rules documentation (read 2026-11-03) puts containment in the Azure Logic Apps playbooks, which you build or adopt.
• Torq's knowledge base publishes a workflow template that clears Okta sessions for specific users through a Slack request (read 2026-11-03). It is a worked example of a reversible identity action wrapped in an approval conversation.
• Cyware's Orchestrate page (read 2026-11-03) does not use the word containment, and the CrowdStrike Agentic SOAR page (read 2026-11-03) names no isolate, disable or block action.

A scorecard of documented native actions per platform is the asset on this site for that reason. Where a vendor publishes no list, the rubric says "not documented" and asks you to request it.

Do not turn every action on at once. A workable sequence for the first 90 days:

1. Weeks 1 to 4: recommend only. The platform proposes session revocation, purge and block actions. Analysts click approve.
2. Weeks 5 to 8: auto-run for the first three actions, on a defined user population, with a daily review of every action taken.
3. Weeks 9 to 12: add host isolation with approval, then auto-run for low-risk asset groups.
4. Later: account disablement and cloud actions, only with a rollback you have tested.

Promote an action to the next level only when its last 30 runs show no wrong actions, or each wrong action had a clean rollback and a recorded cause.

• The twelve-action catalogue (or your own) is written down with an owner per action.
• Each action has a stated reversal procedure and a person who can run it.
• Session revocation, message purge and indicator blocks are first in the pilot.
• Every automated block has an expiry date.
• Purge and block actions have a cap on how many mailboxes, hosts or addresses one run may touch.
• Host isolation, account disablement and cloud actions require approval until their review record is clean.
• Privileged and service accounts are excluded from auto-run.
• Each vendor has supplied, in writing, its list of shipped actions for each product you own.