SOAR: Automating Security Operations Without Losing Control

The analyst spends more time on plumbing than on the threat

Watch an analyst work a single alert and count the manual steps. Copy an IP into a threat-intelligence portal. Pivot to the EDR console to pull the process tree. Switch to the identity provider to check the user's recent sign-ins. Open a ticket, paste in the findings, and message the endpoint team on a separate channel to isolate the host. Ten minutes of investigation buried under twenty minutes of swivel-chair data gathering, repeated hundreds of times a week. The threat is not what exhausts a security team — the plumbing is.

Security orchestration, automation, and response (SOAR) exists to remove that plumbing. It connects the tools a security operations center already runs — SIEM, EDR, identity, email security, ticketing, threat intel — and executes the repetitive gather-and-act steps as code. Done well, it collapses that thirty-minute alert into a two-minute review of an enriched, pre-investigated case. Done carelessly, it becomes an automated way to isolate the wrong server at scale. The difference is entirely in how you scope what the machine is allowed to do.

Orchestration, automation, and response are three different things

The acronym bundles three capabilities that are worth separating, because most of the value arrives before you automate any decisions.

• Orchestration is the integration layer: API connections to every tool in the stack so a single workflow can query the SIEM, the EDR, and the identity provider without a human touching three consoles. This is where SOAR earns its keep first.
• Automation is executing tasks without a human — enriching an indicator, pulling logs, opening a ticket, tagging a case. Most of these are read-only and carry almost no risk.
• Response is taking action that changes state — disabling an account, isolating a host, blocking a domain at the firewall. This is where automation gets powerful and where it gets dangerous.

A useful rule: automate enrichment aggressively, automate response deliberately. Gathering context is reversible and low-risk; a wrong enrichment wastes seconds. Containment actions have blast radius. A playbook that auto-isolates any host matching a broad rule will, on the day the rule misfires, take a domain controller or a production database offline faster than any human could have. Keep the two categories mentally and architecturally distinct.

Playbooks are software — build them like it

A playbook is the codified version of a runbook: an ordered set of steps that respond to a specific trigger. The teams that succeed treat playbooks as software with a lifecycle, not as macros recorded once and forgotten.

Start where the volume is. The classic first targets are high-frequency, low-ambiguity workflows:

• Phishing triage. A reported email arrives, and the playbook detonates attachments in a sandbox, checks URLs against reputation feeds, searches the mail environment for other recipients, and pulls the matching messages — assembling a full case before an analyst opens it.
• Alert enrichment. Any SIEM alert is automatically decorated with asset criticality, user role, geolocation, threat-intel reputation, and related recent alerts, so the analyst reads a story instead of a raw event.
• Commodity malware containment. A confirmed known-bad detection on a non-critical endpoint triggers isolation and a ticket, with the action logged for review.

Every playbook needs the same engineering discipline you apply to any code: version control, testing against real historical cases before it touches production, error handling for when an API times out, and a defined owner. A playbook that silently fails halfway — enriching the ticket but never isolating the host it promised to isolate — is worse than no playbook, because responders trust it to have acted.

Figure: a SOAR playbook is a pipeline of conditional steps — enrichment runs automatically, but state-changing actions pass through a decision gate before they execute.

Keep the human in the loop where it counts

The fear that stops teams from adopting SOAR is legitimate: nobody wants software making irreversible containment calls autonomously. The answer is not to avoid automation — it is to design the approval boundary deliberately. Three patterns cover most cases.

1. Full automation for reversible, low-risk, high-confidence actions. Enrichment, ticket creation, blocking a domain already confirmed malicious by multiple sources. The cost of being wrong is trivial and easily undone.
2. Human-in-the-loop approval for state-changing response. The playbook does all the investigation and then pauses, presenting the analyst a one-click decision — isolate this host? disable this account? — with the full context attached. The machine does the work; the human owns the decision. This single pattern resolves most of the "we can't automate response" objection.
3. Fully manual for anything touching crown-jewel systems, executive accounts, or actions with legal or safety implications. Some decisions should always be a deliberate human act.

Match the automation level to the reversibility and blast radius of the action, not to how clever the workflow is. The goal is to remove keystrokes from investigation, not judgment from response.

Measure whether it actually helps

SOAR is easy to buy and easy to let rot. Playbooks drift as tools change their APIs, and a workflow that quietly broke three weeks ago erodes trust the first time a responder notices. Instrument the program the way you would any production system:

• Time saved per case, measured as analyst-minutes removed, not vanity counts of "actions automated."
• Playbook health — the share of runs that complete successfully versus error out midway. A silently failing playbook is a liability.
• Mean time to respond, tracked before and after, to confirm the automation moves the number that matters.
• False-action rate — how often an automated or approved response hit the wrong target. This should be near zero, and every occurrence should feed back into tightening the trigger.

Tie these to the outcomes your SOC already reports. Faster containment lowers breach impact, and automation that measurably shortens the path from detection to incident response is the justification that survives a budget review.

Where to start

Do not begin by trying to automate response. Begin by automating investigation. Pick the two or three highest-volume alert types your team handles, build enrichment playbooks that assemble the full case automatically, and let analysts feel the swivel-chair work disappear. Add human-in-the-loop approval for containment only once the enrichment is trusted. Automate a response action fully only after you have watched it approved correctly dozens of times.

intSignal runs SOAR as part of a co-managed or fully managed SOC: playbooks engineered against your stack, response gated by approval where blast radius demands it, and delivered inside a broader detection and response practice that tunes the automation as your environment changes. Talk to our team and we will map which of your alert workflows are ready to automate first — and which should stay in human hands.