Platform Modules Plans Blog Request a demo
SOAR · Module

Response automation

Supervised playbooks. Traceable. Reversible. Explained.

Compare with 5 alternatives ↓

Overview

What SOAR does.

Response Automation runs supervised playbooks across every Protoxol module — isolate a host, revoke a token, pull a phishing mail from inboxes, open a ticket. Every action requires (or is auto-approved by) an analyst, every action is reversible where possible, every action is logged and exported to your audit trail. No standalone SOAR — automation lives where the signals are.

Features

Inside SOAR.

Native module actions

Isolate host (EDR), block IP (NDR), purge mail (MX) — no external auth.

Supervised approvals

Per-playbook approval requirements. Auto-approve safe actions, require human for risky ones.

Reversibility

Every action logs the undo step. Un-isolate, un-revoke, un-block.

Audit-grade logs

Who, what, when, why, approved-by. Exported to SIEM and ticket system.

Custom integrations

REST and webhook actions. Connect to ITSM, IdP, firewalls, custom tools.

Use cases

Where SOAR earns its keep.

Compromised account containment

Revoke sessions, force password reset, kill OAuth grants, isolate endpoints — one playbook.

Phishing remediation

Pull malicious mail from all inboxes, block sender domain, alert clicked users, audit.

Malware containment

Isolate host, collect memory image, block C2 IPs, ticket creation, all automated.

Technical specs

SOAR under the hood.

Action library 150+ pre-built actions
Languages YAML playbooks + Python escape hatch
Approval model Per-action, per-team, per-tier
Audit retention 10 years exportable to S3

Figures from internal testing; test method and date to be published.

Compare alternatives

Protoxol Response automation compared with five alternatives

A SOAR spares you from opening five consoles to answer one alert: isolating a host, revoking sessions, pulling a mail, opening a ticket. This comparison sets Protoxol Response automation against five relevant response-automation alternatives. It looks at how a playbook is defined, who approves an action before it runs, what the audit trail keeps, which integrations exist and how each product is licensed. Protoxol runs supervised playbooks over its own modules; it does not present itself as an orchestrator of hundreds of third-party tools.

What Protoxol offers

Comparison table

Each cell shows the status and the scope. Statuses are explained below the table.

Show alternative:

Scroll the table sideways to see every column.

Protoxol Response automation compared with five alternatives
CriterionProtoxol Response automationCortex XSOAR 8Splunk SOARGoogle Security Operations SOAR (formerly Siemplify)FortiSOARTines Stories
Playbook model AvailableYAML playbooks, with Python for what YAML does not cover. The pages do not mention a visual editor. AvailableVisual canvas with connected tasks: standard (manual or automated), conditional and sections. Supports sub-playbooks and scripts. ↗ AvailableCode-free visual playbook editor. The Python code behind each playbook can also be viewed and edited. ↗ AvailableNo-code drag-and-drop playbooks with reusable blocks. Custom integrations are written in a Python IDE. ↗ AvailableVisual drag-and-drop designer with a low-code mode and Jinja expressions. ↗ AvailableStory canvas with eight action types (HTTP, condition, webhook, AI and others) connected by events. ↗
Triggers and conditions Not confirmedThe pages do not describe how playbooks are triggered or which conditions they support. AvailableAutomations started by an incident or a scheduled job, plus conditional tasks inside the playbook. ↗ AvailablePlaybooks run by hand during analyst work or automatically per configuration; decision and filter blocks. ↗ AvailableStandard trigger on alert ingestion, and reaction triggers during an investigation (the latter in preview). ↗ AvailableEach playbook starts from a trigger; steps add variables, loops and conditions. ↗ AvailableWebhook, inbound email or a schedule starts a story; the Condition action compares event fields. ↗
Integrations AvailableNative actions on Protoxol modules plus REST and webhook actions towards ITSM, IdP or firewalls. No third-party catalogue is claimed. AvailableThe vendor cites more than 900 prebuilt integration and automation packs. ↗ AvailableThe vendor cites connections to 300+ third-party tools and 2,800+ automated actions. ↗ AvailableThe vendor says it orchestrates 300+ tools: EDR, identity, network security and more. ↗ AvailableThe data sheet cites hundreds of integrated technologies; full catalogue in Fortinet's Content Hub. ↗ Needs integrationConnects to other tools through HTTP actions and webhooks. An official catalogue size was not verified. ↗
Human approval AvailableThe playbook proposes the action and waits for analyst approval. Safe actions can be auto-approved; risky ones require a person. AvailableManual tasks inside the playbook hold the flow until an analyst completes them. ↗ AvailableThe prompt block asks a user or role to respond before the playbook continues, with a configurable response time. ↗ AvailableManual action assigned to a user or SOC role with a time limit. Approval links for people without platform access. ↗ AvailableApproval step for FortiSOAR users and a manual-input step for people without an account. ↗ AvailableHuman checkpoints: the story holds until someone decides, per the vendor's human-in-the-loop guide. ↗
Roles and permissions (RBAC) Not confirmedThe SOAR role model is not described. The pages only say approval is defined per team and tier. AvailableFull users depend on their assigned role; audit users are read-only. API keys can carry several roles. ↗ AvailableRoles grant or restrict system functions. Roles also group the people who approve actions. ↗ AvailableSOAR permissions are granted through Google Cloud IAM, and actions can be assigned to SOC roles. ↗ AvailableThe data sheet lists RBAC and MFA, and per-tenant isolation in the multi-tenant edition. ↗ Depends on licenceViewer, builder and manager roles; custom roles belong to Enterprise Tenant Management. ↗
Audit trail AvailableEvery action logs who, what, when, why and approved-by, and is exported to the SIEM and ticket system. AvailableManagement audit log, filterable and exportable to TSV or forwardable to syslog or email. One-year retention. ↗ Depends on setupOn-premises, the audit trail is enabled per area and downloaded as CSV; action and playbook runs are always logged. ↗ AvailableAudit page with user, module, activity type and new versus previous values in a JSON viewer. ↗ AvailableThe data sheet cites forensic-grade activity logging in war rooms and a full audit trail. ↗ AvailableAudit log of every data change in the tenant, two years by default, with S3 export every 15 minutes. ↗
Retries and error handling Not confirmedThe pages say nothing about retries, idempotency or what happens when an action fails. AvailablePer task: stop, continue or follow an error path. Task fields include retries and retry interval. ↗ Not confirmedA retry policy or per-action error handling was not verified in the documentation read. Depends on setupThe flow branches on step failure; if the assignee does not answer in time, the action fails. Automatic retries are not documented. ↗ AvailablePer-step ignore-error option and a do-until loop with retries (3 by default) and configurable delay. ↗ AvailableHTTP actions retry on status codes and, once retries run out, emit an error event another action can handle. ↗
Case management in the product Not confirmedCorrelated signals reach the queue as one incident, but SOAR-specific case management is not described. AvailableIncident management with a war room for collaboration, tickets and post-incident review. ↗ AvailableCase management with custom or standard templates, task segmentation, assignment and documentation. ↗ AvailableCase wall holding automated and manual actions, chats, tasks and files in an auditable repository. ↗ AvailableThe data sheet describes full case management, a war room, work queues and SLA tracking. ↗ Depends on licenceCases is a paid add-on and includes records and dashboards. One-time 45-day trial. ↗
Undoing executed actions AvailableEach action logs its undo step (un-isolate, un-block, un-revoke) wherever the action can be undone. Not confirmedNo mechanism for undoing executed actions was found in the documentation read; it depends on each integration. Not confirmedNo generic undo for executed actions was found; reverting depends on each app's action. Not confirmedPlaybooks have version control and rollback. Undoing an action that already ran is not documented. Not confirmedNo generic mechanism for undoing executed actions was found; it depends on the connector. Not confirmedNo undo for executed actions was found; each story defines its own reversing steps.
Hosting model AvailableSaaS in an EU region or self-hosted, with the same console, API and playbooks. The Enterprise plan carries the on-prem option. AvailableSaaS (XSOAR 8) or an on-premises virtual appliance; on-prem lacks the built-in auto-scaling and HA of SaaS. ↗ AvailableCloud, on-premises or hybrid. ↗ AvailableGoogle cloud-native service; the provisioning region is set in the contract. ↗ AvailableVirtual machine (VMware, AWS), Docker container or a hosted service on FortiCloud. ↗ AvailableSaaS or self-hosted in Docker containers, in the Business and Enterprise editions only. ↗
Licensing model Depends on licenceSOAR is an add-on in the Team plan and included in Enterprise. Modules switch on separately; pricing follows protected endpoints. Depends on licenceYearly licence per user, with Enterprise, TIM-only and Starter editions; a separate multi-tenant licence. ↗ Depends on licenceStandalone subscription, or inside Splunk Enterprise Security with a SOAR subscription. Pricing on request. ↗ Depends on licenceStandard, Enterprise and Enterprise Plus packages; base SOAR in all. Price depends on ingestion volume. ↗ Depends on licenceLicence by number of active users and by edition (Enterprise, HA or Multi-Tenant). Pricing on request. ↗ Depends on licenceCommunity, Business and Enterprise editions with limits on flows, teams and daily events, plus add-ons. ↗

What each status means

Available
Native feature of the product or plan compared.
Needs integration
Works through a connector or a third-party product.
Depends on setup
Exists, but its scope depends on deployment or configuration.
Depends on licence
Only in a higher plan or as a paid add-on.
Needs another product
Covered by a different product from the same vendor.
In development
Announced or being built; not generally available.
Not confirmed
Not enough evidence. It does not mean “no”.

Five comparisons

One per product, naming the plan that was compared.

Cortex XSOAR 8

Plan or edition: Enterprise Edition (SOAR + threat intel management), SaaS or on-premises; Starter (SOAR only) and TIM-only editions also exist

Cortex XSOAR 8 is sold as its own SOAR, separate from Cortex XSIAM. It does well what Protoxol does not promise: coordinating tools from many vendors (900+ packs, per Palo Alto), with tasks that retry, error paths and an exportable audit log. Protoxol has no comparable catalogue; its native actions cover its own modules, and everything waits for analyst approval by default. XSOAR fits if you already run EDR, firewall and mail from different vendors and someone maintains playbooks. Protoxol fits if you want supervised response from the same console that detects. Condition: XSOAR is licensed per user and edition, so team size shapes the quote.

Splunk SOAR

Plan or edition: Standalone subscription, Cloud or on-premises; also offered as a capability inside Splunk Enterprise Security

Splunk SOAR wins on one concrete point: if your SIEM is already Splunk, cases, alerts and playbooks live in the same ecosystem, and the vendor cites 300+ connectable tools and 2,800 actions. It has a visual editor, a prompt block that asks a user or role for approval, and permission roles. Protoxol reaches fewer external tools, but its native actions need no connectors or credentials from another product. Pick Splunk SOAR if you orchestrate a mixed estate from Splunk. Pick Protoxol if you want supervised response on the platform that detects. Condition: on-premises, the per-area audit trail must be switched on; check which areas are covered before production.

Google Security Operations SOAR (formerly Siemplify)

Plan or edition: Standard package with base SOAR included; multi-environment (MSSP) from Enterprise

Here the purchase is a whole platform: Google Security Operations bundles SIEM, SOAR and cases, and base SOAR ships in all three packages. Its strongest answer is approval outside the console: an approve or decline link that a customer's IT manager can open without an account, useful for an MSSP. Protoxol does not offer an equivalent according to its pages; it does require approval by default and stores the undo step. Google fits if you already ingest telemetry into Google SecOps or need multi-environment. Protoxol fits if you do not want a Google-cloud SIEM just to automate response. Condition: price follows ingestion volume, not team size.

FortiSOAR

Plan or edition: Enterprise edition (Multi-Tenant and HA editions also exist), licensed by users; documentation read for 7.6 and the 8.0.0 data sheet

FortiSOAR covers more than security: the data sheet pitches it as an automation hub for SecOps, NetOps, ITOps and OT, with case management, a war room, work queues and SLA tracking. For a team on FortiGate and FortiMail it is the short path, and its do-until loop with retries handles transient connector failures. Protoxol stays with security response and a logged undo step. Pick FortiSOAR if you also automate network or IT tasks and have people to run a platform of its own. Pick Protoxol if you want less surface to operate. Condition: licensing counts active users and edition, and the 8.0 data sheet includes AI agents that act without waiting for the analyst; review how they are configured.

Tines Stories

Plan or edition: Business Edition (Cases as a paid add-on); Community and Enterprise editions also exist

Tines does not start from ready-made security playbooks but from a canvas where you wire HTTP actions, conditions and webhooks. Its strength is freedom: the same tool handles a SIEM alert, a user deprovisioning or an IT task, and error handling on HTTP actions is explicit. The price of that freedom is that you build each integration yourself. Protoxol ships native actions on its modules and approval by default, but has no reach outside security. Tines fits teams with an engineering profile automating several domains. Protoxol fits small teams that want supervised response without building it. Condition: Cases, custom roles and self-hosting depend on the edition you buy.

When to choose Protoxol

  • You want every containment action to pass through an analyst and leave a record of who approved it.
  • Your signals already come from Protoxol modules and you prefer native actions to maintaining connectors.
  • You need to undo an isolation or a block from the same place where you approved it.
  • Your response automation is security work and stays within security.

When to consider something else

  • You orchestrate many tools from different vendors and need a large integration catalogue: Cortex XSOAR, Splunk SOAR or FortiSOAR.
  • You already run Splunk, Google SecOps or Fortinet products and want automation inside that ecosystem.
  • You need case management with SLAs, queues and a war room, or per-step retries and error paths: FortiSOAR or Cortex XSOAR document them.
  • You also want to automate IT or other teams' tasks with a flexible builder: Tines.

See the module in a demo

Questions about this comparison

01Does Protoxol run actions without an analyst approving them?

Not by default: the playbook proposes the action and waits for approval. The pages say safe actions can be auto-approved and risky ones can require a person, configured per playbook.

02Can I connect Protoxol SOAR to other vendors' tools?

Through REST and webhook actions, for example towards ITSM, identity provider or firewalls. The pages state no catalogue of third-party connectors and no size for one.

03What separates an embedded SOAR from a standalone one?

An embedded SOAR runs actions on the modules of its own platform with no connectors in between. A standalone one orchestrates tools from many vendors, but you maintain each connector and its credentials.

04What can I not confirm about Protoxol SOAR today?

The pages do not describe triggers, a SOAR role model, retries, idempotency or case management of its own. Ask for a demo with your specific case before deciding.

05How is each alternative licensed?

Cortex XSOAR by user and edition. FortiSOAR by active users and edition. Google SecOps by package and ingestion volume. Splunk SOAR and Tines by subscription or edition with limits. Protoxol: add-on in Team, included in Enterprise.

Sources and review date

Reviewed on October 2, 2026. Reviewed by The Protoxol team.

Protoxol capabilities are based on the current commercial documentation on this site and were not technically validated in this review; anything undocumented is shown as “Not confirmed”. Vendor data comes from each vendor's public documentation on the date shown and may have changed.

Selection

See SOAR against your data.

Thirty minutes. Your environment. The modules that fit. No slideware.