11. 03. 2026
Blue Team, Log-SIEM, SEC4U, Threat Intelligence
SOAR for Controlled Response
SOAR is often described in broad terms: orchestration, automation, response, integration. That’s true, but it can also feel vague.
A simpler way to explain it is this: SOAR helps a SOC turn a decision into action without repeating the same manual steps every time.
This matters most when the action is sensitive.
Device isolation is a good example. When a host is compromised and there’s a real risk of further attacker activity, containment cannot wait. At the same time, isolating a machine is not a routine click. It affects a live system, may disrupt operations, and must be handled carefully.
That’s where SOAR becomes useful. Not because everything should be automated, but because some actions need to be executed in a controlled and repeatable way.
Why Isolation Matters
When an attacker gains access to an endpoint, the problem rarely stays limited to one machine. A compromised host can be used to move laterally, maintain access, or interact with other systems in the environment. In serious incidents, containment becomes the priority.
Isolation is one of the clearest containment actions a SOC can take. The goal is simple: Cut the device off from the network so the attacker has less room to operate, while keeping enough control to continue the investigation.
Different EDR and XDR products handle this in different ways. Some allow full isolation, while others offer more selective controls. The exact workflow depends on the platform, but the operational goal is the same: When a device is compromised, the SOC needs a reliable way to contain it.
That sounds simple until you try to do it in a real multi-customer environment.
The Challenge and the Workflow
A SOC rarely works with a single security stack. Different customers use different EDR and XDR products, and that creates friction during incident response. An analyst may know that a device must be isolated, but the next steps still depend on the customer’s tools. Which console should be used? Which workflow applies? What input does that platform require?
To solve that, we designed a workflow with a simple analyst entry point and product-specific logic handled in the background. The analyst provides the device name and triggers the action. The workflow then checks the asset inventory, determines which product path applies, and calls the relevant EDR or XDR API.
We implemented this logic in n8n as the orchestration layer. It lets us organize the steps, handle branching logic, and keep the process readable. The APIs exposed by the different products provide the execution layer. Together, they allow one operational action to work across different vendor platforms.
This keeps the analyst experience simple and consistent. The complexity still exists, but it sits in the workflow rather than in the analyst’s head.
Not Everything Should Be Fully Automated
It’s important to say this clearly: Device isolation is not a good example of blind automation.
It’s a containment action for serious situations. An analyst may decide it is necessary because the risk of leaving the host connected is too high. But that decision still depends on context. The exact process can vary by incident, customer, and asset.
That’s why the value of SOAR here is not automation for its own sake. The value is in making a sensitive action easier to execute once the decision has been made.
Many useful SOAR workflows follow this pattern. They don’t remove human judgment. They reduce operational friction around decisions that still belong to analysts.
Isolation Is Only Part of the Story
If a device can be isolated, it also needs to be released at the right time.
That second step is easy to overlook, but it matters. A host should not remain isolated just because the workflow to contain it exists. Once the incident has been handled and the conditions are in place to restore connectivity, the release action needs the same level of care.
For that reason, the workflow covers both sides: isolation and release. The logic is similar. The analyst triggers the action, the workflow identifies the correct product path, and the request is executed through the relevant API.
This keeps the process consistent. It also improves traceability, since both containment and restoration follow the same operational model.
Closing Thoughts
SOAR is often discussed at a high level, which can make it sound abstract. It becomes much clearer when tied to one concrete action.
Device isolation is a good example because it sits at the intersection of incident response, operational pressure, and tooling complexity. The decision remains in human hands. The execution can be standardized.
That’s what we set out to build: not flashy automation, but a practical workflow for a high-impact action in a mixed EDR/XDR environment.
For a SOC, that is often where SOAR delivers the most value. Not by replacing analysts, but by helping them move faster and with fewer manual steps when the action really matters.
These Solutions are Engineered by Humans
Did you learn from this article? Perhaps you’re already familiar with some of the techniques above? If you find cybersecurity issues interesting, maybe you could start in a cybersecurity or similar position here at Würth IT Italy.
Marco Fazio
Author
