SOAR

SOAR is the response layer of a security operations team. Where detection tooling ends with a scored case, SOAR begins with one and executes what happens next: isolate a host, disable an account, revoke a token, enrich the case from threat intelligence, open the ticket, notify the on-call analyst. The three words in the acronym describe three separate things. Orchestration is the coordination across systems that each have their own interface. Automation is executing the steps without a human typing them. Response is the containment itself. A platform can do the first two well and still leave every genuine response decision with a person, which is a legitimate design rather than a half-built one.

The unit of work is the playbook: a codified sequence of steps for a case type, written once and run consistently. That consistency is most of the value. An analyst handling a phishing report at 03:00 executes the same enrichment and containment as the analyst who handled one at midday, and the trail is identical in both cases. The constraint is that a playbook encodes whatever process you already have, so an organisation automating a response process it has never written down usually discovers it has automated its confusion. Writing the process is the work; the platform is the easy part.

The decision that matters most is the auto-execute boundary: which actions run without a human, at what confidence, and against which severities. Set it too conservatively and the platform becomes an expensive ticketing system. Set it too aggressively and it disables a director’s account at a board meeting on a false positive, which tends to be the last time anyone trusts it. The governance question is who owns that boundary, how changes to it are evidenced, and whether the automated decisions are logged well enough to reconstruct later. See NIST SP 800-61 for the incident-handling lifecycle these playbooks are automating.