SOAR: Security Orchestration and Incident Response

SOAR (Security Orchestration, Automation and Response) is a category of platforms that connect an organisation's various security tools, automate repetitive response tasks and coordinate team work through codified procedures called playbooks. The term was coined by the Gartner consultancy in 2017 to describe the convergence of three technologies that had previously existed separately: security orchestration, automation and incident response management. The problem it solves is concrete and measurable: the security operations centre (SOC) receives more alerts than it can investigate manually, and every alert investigated by hand consumes precious minutes that an attacker can exploit.

The problem: alert fatigue and the human bottleneck

A modern SOC integrates dozens of sources: firewalls, EDR on endpoints, proxies, IDS/IPS, cloud logs and a SIEM that correlates everything. The result is thousands of alerts per day, many of them false positives. Alert fatigue is real and dangerous: when an analyst reviews the three-hundredth alert of a shift, their ability to distinguish a genuine threat declines sharply. The two indicators that SOAR aims to reduce are MTTD (Mean Time To Detect) and MTTR (Mean Time To Respond). Every minute counts: ransomware can encrypt a network in minutes, and the cost of an incident grows with containment time.

SOAR does not replace analysts; it frees them from low-value work. Mechanical and deterministic tasks — enriching an IP with threat intelligence, checking a file hash on VirusTotal, isolating an endpoint, blocking a domain on the proxy, opening a ticket — are automated. Human judgement is reserved for decisions that require it: confirming a compromise, authorising an aggressive containment action or declaring a major incident. This combination of automated steps with human decision points is known as human-in-the-loop.

Anatomy of a playbook: the codified response flow

The playbook is the heart of SOAR. It is a workflow that describes, step by step and in an executable form, how to respond to a specific type of incident. A well-designed playbook for a user-reported phishing case might follow this sequence: extract the URL and attachments from the email, detonate them in an isolated environment (sandbox), check domain and IP reputation against threat intelligence feeds, search the corporate mail system for other recipients of the same message, quarantine copies found, block the domain on the proxy and, finally, notify the user. The analyst intervenes only if the verdict is ambiguous.

The difference from a SIEM is important and frequently confused. The SIEM detects: it aggregates logs, correlates them and fires the alert. SOAR acts on that alert by orchestrating the tools. This is why the standard architecture has SIEM and SOAR working together: the SIEM as sensor and correlation engine, SOAR as the executing arm and case coordinator. XDR platforms incorporate some response automation, but SOAR retains its value when an organisation runs a heterogeneous ecosystem of vendors that must be orchestrated through connectors and APIs.

Reference frameworks: from incident lifecycle to the technique dictionary

SOAR does not operate in a methodological vacuum. Playbooks are designed on recognised frameworks. The NIST SP 800-61 guide defines the incident management lifecycle in four phases: preparation; detection and analysis; containment, eradication and recovery; and post-incident activity (lessons learned). The standard ISO/IEC 27035 provides an equivalent view oriented to the information security management system, and the ISO/IEC 27001 family requires response procedures as part of its controls.

For classifying attacker actions and mapping defences, the de facto standard is MITRE ATT&CK, a knowledge base of adversarial tactics and techniques observed in the real world. Tagging each playbook with the ATT&CK techniques it covers allows defensive coverage to be measured and gaps to be identified. On the European regulatory front, the NIS2 Directive, transposed into national law across member states, imposes on essential and important entities mandatory incident management and notification obligations within strict timeframes — an early warning within 24 hours and a full notification within 72 hours — making automated notification a direct SOAR use case.

Implementation: where to start without stumbling

A realistic SOAR adoption follows a maturity-based progression. First, measure: which alert types consume the most analyst time and are the most repetitive? Those are the candidates for first automation, because they offer the greatest return with the lowest risk. Second, automate enrichment (gathering context about an alert) before containment (acting on systems), because enrichment is low risk and accelerates the analyst's triage. Third, introduce containment actions with human approval, and only once the playbook has demonstrated reliability should full automation of the clearest cases be considered.

A concrete use case: EDR alert triage

To make theory concrete, consider a common scenario: an EDR alert flagging the execution of a suspicious process on an endpoint. Without SOAR, the analyst must open the EDR console, identify the machine and user, look up the binary hash in reputation feeds, check whether the process has appeared on other machines, review SIEM logs to reconstruct the chain of events and, only then, decide. Each of those steps involves switching tools, copying identifiers and waiting for responses; together, easily fifteen to twenty minutes per alert. Multiplied by the dozens of similar alerts in a shift, the SOC is swamped.

With a playbook, that same triage runs in seconds: the platform receives the alert via API, extracts the hash and machine name, automatically queries binary reputation and threat intelligence, checks process prevalence across the estate, retrieves correlated events from the SIEM and assembles an enriched case with a preliminary verdict and a confidence level. The analyst opens a single case with all the context already gathered and decides on what matters. If the verdict is clearly malicious and confidence is high, the playbook can propose — or execute with approval — endpoint isolation and incident ticket creation. This pattern, replicated for the most frequent alert types, is where SOAR demonstrates its return on investment.

The key is that every action is recorded: what was done, when, on what data and who approved it. That audit trail not only facilitates subsequent investigation but constitutes the documentary evidence that NIS2 obligations and security audits require. A well-governed SOAR is, in addition to an operational accelerator, a logging system that supports regulatory compliance.

Common mistakes when deploying SOAR

• Automating chaos. If the response process is not defined manually first, encoding it in a playbook only automates the disorder. Procedure before automation.
• Destructive actions without controls. A playbook that isolates endpoints automatically can become a self-inflicted denial of service if a false positive triggers mass isolation. High-impact actions should require human approval.
• Fragile connectors. SOAR depends on third-party APIs; a change in an API breaks the playbook silently. Integration health must be monitored.
• Vanity metrics. Boasting about the "number of automated alerts" without measuring real MTTR or the rate of contained false positives does not demonstrate value.
• Skipping lessons learned. NIST's post-incident phase feeds improvement of the playbooks; bypassing it freezes response capability.

Frequently asked questions

Does SOAR replace SOC analysts? No. It eliminates mechanical work and leaves analysts with the decisions that require judgement, context and investigation. The objective is for a small team to manage an alert volume that would otherwise be unmanageable.

What is the difference between SIEM and SOAR? The SIEM detects by correlating logs and generating alerts; SOAR orchestrates tools and automates the response to those alerts. They are typically deployed together: the SIEM fires, SOAR executes.

What is a playbook and who writes it? It is an executable response flow for a specific type of incident. It is designed by analysts and SOC leads starting from the existing manual procedure and drawing on frameworks such as NIST SP 800-61 and MITRE ATT&CK.

Does SOAR help with NIS2 or GDPR compliance? Yes, indirectly: it automates incident documentation and notification to authorities within the required timeframes, reducing the risk of missing the legal deadlines for breach communication.

Conclusion: SOAR is response discipline before it is technology

The trap when evaluating SOAR is buying a platform in the expectation that it will automate an immature SOC. The reality is the opposite: SOAR amplifies what already exists. If response procedures are written, rehearsed and measured, the platform executes them at machine speed and frees the analyst for what no automation can replace: understanding the adversary's intent and making decisions under uncertainty. If those procedures do not yet exist, SOAR merely accelerates the errors. The correct order is therefore to define the procedure, tag it against MITRE ATT&CK, automate enrichment first at low risk and reserve aggressive containment actions for a human-in-the-loop. Measured against real MTTD and MTTR — not vanity metrics — a well-governed SOAR programme transforms an alert-saturated SOC into a team that responds in minutes and learns from every incident. At Summum Sistemas we design that architecture: integration with the existing SIEM, playbooks aligned with NIST SP 800-61 and a governance model that keeps people at the centre of critical decisions.