Open source SOAR for SaaS companies

A SaaS SOAR playbook has a second output besides containment: notices to customers whose tenants or data were affected. Automation can prepare that work well. From the case record in your case management tool, a Shuffle workflow can pull the affected tenant list from the SIEM or application logs, assemble a timeline of detection, containment and scoping steps with timestamps, and populate draft notice fields such as tenant identifier, data categories involved, and status of the investigation. The workflow should mark every field with its source and leave unknowns blank rather than guessing. What automation must not decide is whether an event is notifiable, when a contractual clock starts, or what the notice says about cause and impact.

Those decisions belong to named people who approve each step. Legal review checks the wording and the contractual notice periods in each customer agreement, which often differ between enterprise and standard plans. Regulator notices are a separate track: if the company is in scope of NIS2 or the Cyber Resilience Act, the team must confirm its role, the authority to notify and the deadlines before any workflow sends anything outside the company. Build the approval gate as a required step in the playbook with a recorded approver, and keep draft notices out of any channel that can send email to customers automatically. Confirm with counsel which deadlines apply to each customer contract before you configure timers.

Enrichment is where data protection obligations bite. Under GDPR Article 28(3), your processor contracts with customers and vendors define what you may do with customer data, including transfers, and require security measures under Article 32. If a playbook sends tenant identifiers, log excerpts or IP addresses to an external threat intelligence or lookup service, confirm that the processing is covered by a documented instruction or a sub-processor arrangement before the workflow goes live. A self-hosted enrichment path, with API keys stored under the Shuffle encryption settings and reviewed by the data protection lead, keeps that question smaller. Record the basis for each external call in the playbook documentation so the evidence exists when a customer asks.

The main cost of open source SOAR for a SaaS team is rarely the license, because the Shuffle open-source edition makes all features available without a per-seat fee for the platform. The recurring spend comes from four places: infrastructure for the Shuffle server and the Orborus workers that run each workflow, the one-time build of playbooks and apps, the ongoing work to keep connectors working as cloud and identity provider APIs change, and the time your own engineers or a partner spend testing before anything touches production. Ask for each of these as a separate line, because they are paid to different people and recur on different schedules. Infrastructure and connector upkeep recur every month, while playbook build is largely one-time until new alert sources are added.

Shuffle prices its paid tiers on app runs, which the Shuffle pricing article defines as actions that actually execute in a workflow. Triggers, skipped actions, users, apps and workflows are not counted. For a SaaS team, run volume follows directly from alert volume multiplied by the number of enrichment actions each alert triggers. A cloud login alert that calls an identity provider lookup, a threat intelligence check, an asset query and a ticket update produces several runs, while an alert closed by a suppression rule may produce almost none. Before comparing a paid tier, run the pilot playbooks for several weeks against real alert feeds from your cloud, identity and endpoint tools, then count runs per alert type. Confirm with Shuffle which edition limits apply to your chosen version, since the open-source and enterprise limits are enforced from v2.1.1.

When you request a quote from a partner, separate the one-time build scope from the recurring maintenance scope. The build scope should list each playbook, the connectors and apps it needs, the credentials handling for each tool, and the testing approach. The maintenance scope should state which connectors are covered, how API changes from cloud and identity providers are detected and fixed, and who responds to a broken workflow overnight. Also ask for the assumptions behind run volume: the alert sources in scope, the expected alerts per day, the enrichment steps per alert type, and the growth you expect over the next year. A quote built on different volume assumptions is not comparable with another, and the difference will show up later as either an unexpected run bill or an undersized worker pool.

Start with the alert types the partner will automate first, and ask how it measures triage time before and after each playbook goes live. A credible answer names the sources, such as cloud audit logs, identity provider sign-in events and endpoint alerts from Wazuh, and ties each playbook to a baseline the team already tracks. Ask who records that baseline, how often the numbers are reviewed, and whether a playbook that does not reduce triage time is retired. Ask also how the partner writes and versions Shuffle apps built from OpenAPI specifications, and who owns those specs after handover. Your company should hold the source repository, the spec files and the version history, not only a running instance. Confirm that each app is pinned to a versioned Docker image so that a change to one connector cannot silently alter a live workflow.

Ask where cloud and identity provider credentials live and how they rotate. Shuffle encrypts saved app credentials in OpenSearch using the SHUFFLE_ENCRYPTION_MODIFIER secret, and the configuration docs warn that losing or changing that value breaks every saved authentication. Ask who holds that secret, how it is backed up, and whether the partner will store it in a dedicated secrets manager such as OpenBao. Then ask how tests are run. The partner should describe a non-production Shuffle instance, test tenants at each cloud and identity provider, and a written promotion step before any workflow touches a customer tenant. For the SSO layer, ask how the partner will handle the move from SAML to OpenID Connect on Shuffle, which the vendor documents as the direction of travel on Shuffle Cloud, and who approves the cutover.

Ask how the partner limits app-run volume. Shuffle licenses on app runs, meaning actions that execute in a workflow, so a noisy detection that triggers a loop can raise cost quickly. Request the partner's approach to filtering, deduplication and run caps, and ask how it reports run counts to you each month. Ask how it plans Orborus scaling, since the Shuffle high availability guidance recommends more than one Orborus node so workflows keep running if one fails. Ask for the expected behavior during an identity provider outage. Next, ask what evidence the partner hands over for a SOC 2 examination. Useful items include workflow inventories, change tickets for playbook releases, approval records for destructive actions and logs of automated actions. Confirm that the partner prepares this evidence but that your auditor decides what it proves. Finally, ask how customer data is handled during enrichment: which fields leave your environment, whether third-party lookups receive personal data, and how those flows are documented for your data processing terms. Ask how connectors are maintained when a provider changes its API, including who watches vendor changelogs, how breaking changes are tested, and what service level the partner commits to in writing.