Understanding SOAR

Security Orchestration, Automation, and Response (SOAR) connects security tools and executes repeatable workflows. It helps teams enrich alerts, coordinate decisions, perform approved response actions, and preserve an audit history.

What you will learn

By the end, you should be able to explain how a SOAR playbook works, place a safe human-approval boundary, handle a failed action without repeating containment, and judge automation by its safety and reliability.

Beginner terminology used on this page

Playbook

A recorded workflow that defines inputs, decisions, actions, and failure handling.

Integration

A controlled connection that lets SOAR exchange information or request an action from another tool.

API

Application Programming Interface: a structured way for software systems to communicate.

Enrichment

Adding context, such as file reputation, user details, or asset importance, before making a decision.

Containment

A bounded action that limits harm, such as quarantining a message or isolating an endpoint.

Rollback

The tested method for reversing an action and restoring the earlier state.

Idempotency

Designing a step so a safe retry does not repeat or multiply its effect.

Orchestration, automation, and response

1 Orchestration Connect tools, APIs, data, and teams so information and actions can move between them.

→

2 Automation Execute validated, repeatable steps without requiring an analyst to perform each one manually.

→

3 Response Apply a decision to the incident, notify stakeholders, and record the result.

SIEM, SIRP, and SOAR

These capabilities often overlap within products, but their primary responsibilities differ.

Platform	Primary responsibility	Typical output
SIEM	Detect and correlate suspicious activity	Prioritised alert
SIRP	Manage investigations, evidence, ownership, and decisions	Structured case
SOAR	Execute and coordinate response workflows across tools	Completed playbook actions

A common flow is:

SIEMAlert → SIRPCase and decision ↔ SOAREnrichment and action

SOAR may enrich or validate a detection, but detection and correlation are primarily SIEM responsibilities. The SIRP remains the record of the investigation and its decisions.

What SOAR is not

SOAR is not an automatic substitute for analyst judgement, a source of truth, or permission to take an action. A playbook can execute the wrong decision very quickly when its input is incomplete, its scope is too broad, or its approval boundary is missing. The connected security tools remain responsible for their own data and actions; SOAR coordinates the workflow and records the result.

How a playbook works

This example shows a suspicious-email workflow. The approval stage protects potentially disruptive actions.

1. ReceiveAccept the alert and validate required fields.Source: email security
2. ExtractCollect sender, URLs, attachments, hashes, and recipients.Action: parse evidence
3. EnrichQuery reputation, threat-intelligence, identity, and asset sources.Action: gather context
4. DecideEvaluate the evidence using documented playbook conditions.Action: choose branch
5. ApprovePause for an authorised analyst before disruptive containment.Control: human decision
6. ContainQuarantine matching messages and block confirmed indicators.Action: limit impact
7. NotifyInform the case owner and relevant operational teams.Action: coordinate
8. RecordWrite inputs, decisions, actions, results, and errors to the case.Action: preserve audit trail

Build and run a response playbook

Work through a synthetic suspicious-email case. Review the evidence, choose what automation may do safely, place the human approval boundary, and recover from a failed case-record update without repeating containment.

Try it: contain only what the evidence supports

Complete all four stages. This exercise rewards a controlled, reviewable response—not the largest or fastest action. Open the stronger hint whenever you need it; using guidance is part of learning the workflow.

Synthetic training case · SOAR-1042Contain a confirmed phishing campaignTwelve matching messages are present. No recipient has opened the attachment.

Step 1 of 4

Your roleTraining Analyst Your goalRemove 12 confirmed matching messages Safety ruleRead automatically; approve changes; never repeat containment

1. 1Evidence
2. 2Design
3. 3Approve
4. 4Run and recover

Beginner goalSelect each card once to reveal and review its evidence.

1. Open all three cards; reviewed cards turn green.
2. Then select Continue to design.

Why review every record?

Automation needs both confidence and exact scope. Here, the malicious hash establishes confidence and the tenant search identifies precisely which messages may be contained.

Message authenticationOpen record Attachment reputationOpen record Tenant searchOpen record

Reset missionContinue to design

ReadyReview the evidenceOpen all three evidence records before continuing.

Exercise debrief

Safe SOAR design separates read-only enrichment from disruptive action, pauses at a clear approval boundary, records the exact approved scope, and resumes from a failed step without repeating work that already succeeded. Full automation is appropriate only after those behaviours are tested with representative inputs and failure conditions.

Automatic does not mean appropriate

End-to-end automation should be reserved for well-understood, tested, reversible, and sufficiently high-confidence scenarios. The appropriate approval boundary depends on business impact and operational risk.

What should be automated?

Good starting candidates

• Enrich indicators and identities
• Deduplicate and group alerts
• Create or update a case
• Retrieve asset and user context
• Collect defined evidence
• Send routine notifications

Often require approval

• Isolate a critical system
• Disable a privileged account
• Block a broad network range
• Delete messages or data
• Revoke organisation-wide access
• Notify an external party

Safety and governance

• Least privilege: Give integration accounts only the permissions required by each playbook action.
• Input validation: Treat alert fields, API results, and user-supplied values as untrusted input.
• Approval boundaries: Require authorised review before disruptive or difficult-to-reverse actions.
• Safe retries (idempotency): Ensure a retry resumes from the failed step and does not repeat an action with additional unintended impact.
• Timeouts and rate limits: Bound execution and prevent workflows from overwhelming connected services.
• Failure handling: Record partial execution, notify an owner, and provide rollback or recovery instructions.
• Secrets management: Keep credentials out of playbook code and rotate them using an approved process.
• Testing and versioning: Test with representative cases, review changes, and preserve previous playbook versions.
• Manual fallback: Document how analysts continue safely when automation or an integration is unavailable.

Measuring automation quality

Completion rate

The proportion of playbook runs that reach the intended outcome without unhandled errors.

Failed-action rate

Actions that time out, receive invalid data, lose authorisation, or produce an unexpected result.

Approval wait time

How long workflows pause for a human decision and whether the correct approver is available.

Reversed or incorrect actions

Response actions later undone or judged inappropriate—the clearest signal that scope or decision logic needs improvement.

Optimise for dependable outcomes

Time saved is useful only when the workflow remains correct, observable, and recoverable. Measure reliability and analyst effort alongside execution speed.

Shuffle platform profile

Shuffle is an open-source automation platform for building workflows that connect security products and APIs.

Area	Evaluation starting point
Best suited to	Teams that want a visual workflow approach and are prepared to design, test, and maintain their own automations
Workflow model	Triggers, application actions, conditions, variables, and branching workflow logic
Integrations	Existing applications plus API-based connections created for the team's environment
Operational planning	Authentication, secrets, network access, logging, worker capacity, upgrades, and failure monitoring
Security review	Permissions, input handling, approval gates, third-party applications, and the impact of every automated action

Open Shuffle guide ›

Continue learning

• Explore Shuffle to build and test security workflows.
• Understand SIRP to review case management and incident triage.
• Understand SIEM to review how alerts are created and correlated.