Open source SOAR for financial services

Why open source SOAR for financial services starts with the reporting clock

A SOC lead at a bank, payment institution or fintech usually inherits the same problem: an alert fires at night, and within hours someone must decide whether it is a reportable incident, which regulator's clock applies, and what evidence goes into the file. Self-hosted Shuffle can automate much of that classification and evidence gathering, with a human approval step before anything touches a payment or fraud system. The work is mostly sorting and collecting, which is where automation helps most, and the decision to contain or report stays with accountable staff.

Finance differs from generic SOAR use in four ways. Reporting is regulated: DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025 and requires a classification and an initial notification within a fixed window, so the playbook has to know the clock from the first alert. Third-party rules matter too, since DORA Article 28(3) requires a register of ICT contractual arrangements and Article 30(2) requires contracts that state where data is processed. Cardholder data scope is a third factor: PCI DSS applies to any system that could affect the cardholder data environment, so a playbook that queries a payment host can itself change audit scope. Finally, response is approval-heavy, because disabling an account or blocking a card flow can stop customer payments.

On platforms, the short answer is that Shuffle, licensed under AGPL-3.0, is a reasonable automation layer for these playbooks, with Wazuh supplying endpoint and log alerts and MISP supplying threat intelligence context. Whether that combination fits your environment depends on your connectors to payment and fraud tools, your approval model and your hosting constraints, and you should confirm each of these in a proof of concept before you commit. Review the Shuffle open source article against your run volume and support needs first.

Which financial regulations shape the SOAR build

This table compares the main financial regulations and attestation regimes that affect a self-hosted SOAR build, and what each one changes in playbook design, log retention or hosting location. Read each row against your entity type, since DORA, PCI DSS, the FTC Safeguards Rule and Swift CSCF apply to different organizations in different ways. DeployOpen prepares systems and evidence for these assessments but does not issue audit reports or attestations, so confirm the applicable regimes with your compliance function and assessor.

Regime and provision	What it means for the SOAR build	Evidence to keep and where it usually fails
DORA Article 28(3) register of information	Every SOAR vendor, hosting provider, app source and connector provider that supports ICT functions must appear in the register, so record each Shuffle component, worker host and third-party app as a contractual arrangement.	Incomplete registers that omit open-source components or cloud hosts used for workers. Confirm with counsel which contracts are in scope.
DORA Article 28(8) exit strategy and transition plan	If SOAR supports critical or important functions, design playbooks, app definitions and case data so they can be exported and rebuilt on another platform, and test that exit path.	Playbooks that depend on undocumented app credentials or vendor-specific logic with no tested fallback procedure.
DORA Article 30(2) contract terms	Contracts with SOAR hosting or support providers should state where services run and where data is processed, require advance notice of changes, and cover data return on termination or insolvency. Choose self-hosted workers in approved regions where possible.	Cloud-hosted orchestrators or Shuffle Cloud connections with processing locations not stated in the contract. Confirm locations for alert data that leaves your network.
PCI DSS v4.0.1 scope and incident response	Playbooks that touch payment, card data or cardholder data environment alerts must be in scope, and the incident response plan must cover alerts from intrusion detection, change detection and payment page monitoring. Isolate SOAR workers from the cardholder data environment where the design allows.	Automation that copies card data into case notes, chat channels or enrichment logs. Confirm scope with your QSA and the payment brands that apply to you.
PCI DSS response testing and evidence	Playbooks should be exercised as part of incident response testing, with recorded runs, approval outcomes and the Report on Compliance or Self-Assessment Questionnaire evidence that uses them. PCI SSC does not enforce compliance; the payment brands decide who must validate.	Playbooks never tested end to end, or test records not retained. Attestations of Compliance are issued by the assessed entity and assessors, not by DeployOpen.
FTC Safeguards Rule 16 CFR 314.4(c) MFA and logging	Access to the SOAR console, Orborus workers, OpenSearch and app credential stores needs multi-factor authentication unless the Qualified Individual approves an equivalent control in writing. Log the activity of authorized users on the SOAR platform itself.	Shared admin accounts on the SOAR console or unlogged manual changes to workflows. Applies to non-bank financial institutions under FTC jurisdiction, so confirm applicability.
Swift Customer Security Controls Framework v2026	If you are a Swift user, map SOAR controls to the relevant CSCF controls, such as protecting Swift-connected systems and detecting anomalous activity. Controls must be independently assessed and attested annually in KYC-SA.	Playbooks that act on Swift environment alerts without a documented scope boundary. The 32 controls (26 mandatory, 6 advisory) must be confirmed against the current Swift CSP pages.
SEC IT general control areas (Release 33-8810)	For SEC registrants, SOAR changes to workflows, app code and access to automation may fall under program change and access control areas of ICFR assessments. Keep change tickets and approvals for each workflow version.	Workflow edits pushed directly to production without a recorded change, which weakens the IT general control evidence.

Which systems and data the playbooks touch

Systems in the cardholder data environment (CDE) are where a SOAR playbook is most likely to create a compliance problem, because enrichment can copy card data into places that were never assessed. PCI DSS applies to entities that store, process or transmit cardholder data or sensitive authentication data, or that could affect the security of that environment. Which payment switch, card management, tokenization and payment page monitoring components fall inside that boundary must be confirmed with your QSA or internal assessor before any workflow is designed.

Alert data: Payment switch, card management and payment page monitoring alerts usually carry host names, source IPs, user IDs, file hashes and transaction references. Treat transaction references and any field that could carry a primary account number as sensitive.
Case record rule: Never copy full primary account numbers, card verification values, PIN data or sensitive authentication data into a case, ticket, chat message or Shuffle execution log. Store a token or masked value and a link to the source system instead.
Enrichment limits: Restrict lookups to asset inventory, vulnerability and change records. Do not send payment messages or full transaction payloads to third-party threat intelligence services.
Approval gates: Isolating a payment host, disabling a payment page script, or rotating a card management key should require a named approver and a change record, with a rollback step written in the playbook.
Check before build: Confirm the CDE boundary, which systems are in scope for logging and which teams may view raw logs.

Which open-source platforms fit a financial SOAR stack

A financial SOAR stack usually pairs an orchestrator with detection, evidence, threat intelligence, identity and credential tools. Each card below covers one component, what it contributes to triage and reporting, and what the reader must confirm before committing to it.

Shuffle as the SOAR orchestrator

Shuffle runs the playbooks that enrich alerts, collect evidence and route approvals. It is licensed under AGPL-3.0, and the latest release, v2.3.0, was published on September 28, 2026. Deployment can be Docker Compose, Docker Swarm, a hybrid with Shuffle Cloud and a local Orborus, or Kubernetes with Helm charts. For a bank or payment firm, confirm how the AGPL-3.0 terms apply to your internal modifications, and test the approval gates on payment and fraud actions before any production use.

Wazuh for detection and compliance views

Wazuh supplies endpoint agents, the analysis server and a dashboard with prebuilt views for PCI DSS, which is often the first evidence source for payment environments. Agentless syslog collection covers firewalls and devices that cannot run an agent. Wazuh is licensed under GPL-2.0, and v4.14.9 was published on October 15, 2026. Confirm which PCI DSS requirements the dashboards cover in your version, since the views support evidence gathering rather than certifying compliance.

Security Onion with Suricata and Zeek

Security Onion bundles Suricata for network intrusion detection and Zeek for network analysis, with the Elastic stack for search. It supplies packet-level and connection-level evidence that a SOAR playbook can attach to a case when a payment network segment is involved. Security Onion uses the Elastic License 2.0, Suricata uses GPL-2.0, and Zeek uses a BSD-style license. Confirm sensor placement on the cardholder data environment and the retention period your records policy requires.

MISP for indicator sharing

MISP stores indicators of compromise and shares them with sector peers, national CSIRTs and internal teams. A playbook can query MISP during enrichment, then push confirmed indicators back once an analyst approves them. MISP is licensed under AGPL-3.0, and v2.5.50 was published on October 10, 2026. Before sharing bank or card-related indicators, confirm the sharing community rules, the data classification your legal team accepts, and whether an approval step is required before outbound sharing.

Keycloak for SSO and MFA

Keycloak provides single sign-on, OpenID Connect, SAML 2.0 and multi-factor authentication for the people who operate Shuffle and the admin tools around it. The FTC Safeguards Rule requires MFA for any individual accessing an information system, unless the Qualified Individual approves an equivalent control in writing. Keycloak is licensed under Apache-2.0, and version 26.8.1 was published on October 13, 2026. Confirm which MFA factors your policy accepts and how Keycloak sessions map to Shuffle roles.

OpenBao for stored credentials

Shuffle stores saved app credentials and API keys encrypted in its database, protected by a single modifier secret that must not be lost or changed. OpenBao can hold the API tokens for ticketing, EDR, identity and payment tools so that they are not kept in plain text in workflows. OpenBao is licensed under MPL-2.0 and v2.7.1 was published on October 1, 2026. HashiCorp Vault 1.15.0 and later uses the Business Source License 1.1, which is not an OSI-approved license, so have legal review that before choosing it.

How a DORA-classified incident flows through Shuffle

A DORA-classified incident starts as an ordinary alert and only becomes a regulatory matter after classification, so the workflow is designed to produce a classification-ready record before any clock decision is made. Wazuh agents and network sensors send alerts into Shuffle, where the first workflow step enriches each alert by querying your MISP instance for indicators already known to your sharing communities and by checking internal asset data for owner, business service, data classification and whether the host supports a critical or important function. A classification step then assigns a draft category and writes a record with the timestamps that matter for the 4-hour initial notification: when the first alert fired, when the workflow ingested it, when an analyst was paged and when the draft was created. Confirm with your compliance lead which moment your internal policy treats as awareness, because the regulatory clock logic is your decision to document, not something the platform sets.

Automated evidence capture is what makes the later intermediate and final reports cheap to produce. The workflow should preserve raw log extracts from the indexer, hashes of collected artifacts, the list of actions taken and who approved each one, and a timeline that links these together. Report content and format come from the regulators and the implementing standards under DORA, and templates may change, so the playbook should export structured fields that you map to the current template rather than hard-code a layout. Treat the evidence store as sensitive: it will hold customer data and internal network detail. Any external report or containment action, such as isolating a host, disabling an account, blocking an IP at the payment network edge or freezing a card or fraud rule, must pass through a human approval gate in Shuffle before it executes. Shuffle stores saved app credentials and API keys in OpenSearch encrypted with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret. Record that value in your secrets vault with a documented owner and back it up with the database, because the Shuffle docs warn that losing or changing it breaks every saved app authentication, which would silently stop enrichment and containment during an incident. Test the restore procedure before go-live and confirm the rotation process with your implementation partner.

Deployment patterns that financial institutions can defend

A SOAR platform inherits the data location, availability and access rules of the systems it touches, so the deployment pattern is a compliance decision as much as a technical one. The four patterns below cover where Shuffle and its workers can run, and each one changes what an examiner or auditor will ask about.

Fully on-premises with Compose or Helm

Run the Shuffle server on your own hosts with Docker Compose for a single server, or on Kubernetes with the Helm charts Shuffle documents. Both keep alert data, saved credentials and workflow records inside your data center or cloud accounts, which is the simplest position to defend when DORA Article 30 asks where data is processed. Confirm which backup location, log destination and vendor support access paths are covered by the contract, and who holds the SHUFFLE_ENCRYPTION_MODIFIER value.

Distributed Swarm for scale

Docker Swarm spreads the Shuffle backend, frontend and workers across several servers when one host can no longer handle the execution volume. Scaling choices affect cost and resilience directly, so model peak workflow runs during a major incident, not an average day. Ask your partner how worker placement keeps payment and fraud workflows on hosts that meet your network segmentation rules.

Hybrid Orborus with no inbound ports

In the hybrid model, Shuffle Cloud hosts the management plane while a local Orborus node polls for jobs and starts workers inside your network, so no inbound firewall ports are needed. This suits institutions that prohibit inbound connections to security tooling. The hybrid model may conflict with DORA data location clauses, because workflow metadata and execution context leave your environment. Assess this against your register of information and your contractual data location terms before adopting it.

Air-gapped operation with offline repositories

Wazuh documents an offline installation guide for systems without internet connectivity, and vulnerability detection can use an offline vulnerability repository in place of the Wazuh Cyber Threat Intelligence platform. Plan the update path for both the software and the vulnerability data, because stale feeds weaken detection and evidence. Confirm with your partner how Shuffle app images and connector updates reach an isolated network.

High availability with OpenSearch and Orborus

The Shuffle configuration docs recommend an OpenSearch cluster for the document store, optional Memcached for a shared cache, NFS for shared files when several backends run, and scaled backend and frontend services across all servers. They also recommend more than one Orborus node so running workflows continue if one node fails. Ask for a tested failover plan, because an approval gate waiting on a failed node can stall a containment action during an incident.

How a financial SOAR rollout runs in phases

The sequence moves from regulatory scope and system inventory to a supervised first playbook, then to notification timing, approval gates for payment and fraud actions, credential control, and a documented handover. Each phase produces an artifact the next phase depends on. Durations are agreed in the written scope, not set by this page.

Confirm regulatory scope and entity type
Establish which regimes apply to the institution before any playbook is written: DORA if it is a financial entity under Regulation (EU) 2022/2554, PCI DSS if it stores, processes or transmits cardholder data or could affect that environment, and the FTC Safeguards Rule or SEC cyber disclosure rules where they apply to the business. The client's compliance lead and legal counsel confirm entity type and jurisdiction, and the partner records which regimes drive which playbook steps. Output: a signed regulatory map and a defined cardholder data environment boundary. The phase is complete when every reporting clock in scope has a named owner.
Inventory data sources, systems and ICT providers
List every alert source, log feed, identity directory, ticketing tool, payment and fraud system, and third-party ICT service the playbooks might touch, with its owner and whether it supports an API or an OpenAPI-described connector. Mark which systems support critical or important functions, since DORA's register of information and exit planning requirements apply to those contractual arrangements. Output: a system inventory with data classification, connector status and an owner for each item. The phase closes when the client signs off that no in-scope system is missing from the list.
Build the first playbook with enrichment only
Start with one low-risk alert source, such as a phishing mailbox or an endpoint detection feed, and build a Shuffle workflow that only enriches: it looks up indicators, pulls asset ownership and records the results in the case. No workflow in this phase changes a system state. Tests run against recorded or synthetic alerts first, then against live alerts with a human reviewing each output. Output: a versioned workflow, a test log and an analyst accuracy review. It is done when analysts trust the enrichment output enough to act on it without rework.
Draft classification and notification with tested timestamps
Add classification logic and draft notification templates for the reporting clocks confirmed in phase one. The workflow records the time each alert was detected, classified and escalated, so the timeline can be reconstructed later. Compliance and the incident response lead run tabletop exercises against the drafts to check that the clock starts and stops where the team expects. Output: classification rules, approved draft templates and tabletop results with timestamp discrepancies logged and fixed. Evidence gathering is part of this step, not an afterthought.
Set approval gates and separation of duties
Define which actions touch payment and fraud systems and place each behind an explicit approval step. Examples include blocking a merchant account, freezing a card or changing a fraud rule. Requesters, approvers and executors must be different people or roles, and the approval record is written to the audit trail. Output: an action register listing each automated action, its gate, its approver and its rollback step, reviewed by the fraud operations and payments teams. Nothing that alters a payment flow runs without a recorded approval.
Vault credentials and enforce single sign-on
Move every credential the workflows use into a managed store and connect Shuffle's administrative access to the institution's identity provider through OpenID Connect or SAML, with MFA enforced for every person who can edit or run a workflow. Shuffle encrypts saved app credentials, and the encryption secret must be backed up and kept under change control, since losing it breaks saved authentications. Output: an inventory of service accounts, a rotation schedule, and a test showing that a removed user loses workflow access. This step is complete when no workflow depends on a shared personal password.
Run a parallel period under change control
Run the new playbooks alongside existing manual processes for an agreed period, comparing automated outputs against analyst decisions and logging every divergence. Each change to a workflow, app version or connector goes through a documented change request with peer review and a test run, and Shuffle deployments pin specific versions instead of floating tags. Output: a parallel-run report, a change log and sign-off from the security, compliance and operations leads to move each playbook into production.
Hand over runbooks and operating evidence
Transfer ownership to the client's team with runbooks for each workflow, the action register, the tabletop results, the access review records and the backup and restore procedure for the Shuffle platform. Confirm that the client's staff can restart a stopped worker, rotate a credential and roll back a workflow without the partner present. Output: a signed handover pack and a retainer or support agreement if the client chooses ongoing support. The phase closes when the client has run one test incident end to end on its own.

Evidence auditors and regulators ask for from SOAR

This table maps each piece of evidence an assessor or regulator is likely to request to the component that produces it in a self-hosted SOAR stack for a financial institution. Read it as a starting inventory: confirm with your QSA, auditor or supervisor which items they sample and in what form. The main takeaway is that the evidence is only as strong as the change control, approval logging and retention you configure before the first incident.

Evidence item	Producing component	What to confirm before relying on it
Playbook execution history	Shuffle workflow execution records for each automated run	Retention period set in your environment and whether records can be exported unchanged for sampling
Workflow version and change control	Shuffle workflow versions and your Git or ticket records for each playbook change	Who approved each change to a playbook that touches payment or fraud systems, and that the approval predates production use
Approval records for gated actions	Shuffle approval steps linked to the analyst or manager decision that released the action	That approvers are named individuals, separate from the requester, and that rejected actions are also logged
Incident timeline for DORA classification	Case timeline in your case management tool, populated from Shuffle and SIEM alert records	Whether timestamps are synchronized and whether the timeline can be reconstructed for the initial notification clock
PCI DSS monitoring views and alert history	Wazuh alert history and the prebuilt PCI DSS compliance dashboard views	That alert retention covers the review period and that the dashboard mapping is reviewed by your QSA rather than assumed
Access control to SOAR and payment systems	Keycloak or authentik login and administrative event logs	Whether unique user identification is enforced for SOAR operators and service accounts are documented
Threat intelligence sharing record	MISP event records showing what was shared, with which community, and when	Your sharing rules, data classification approval and whether shared content excluded customer data
ICT third-party register entry	Your register of contractual ICT arrangements under DORA Article 28(3), covering Shuffle licensing, hosting and implementation partners	Whether the register lists the hosting location and exit plan, and that contract terms meet Article 30(2)

What financial institutions ask before hiring a SOAR partner

What drives the cost of a SOAR implementation for a bank or payment firm?

The main drivers are the number of playbooks in scope, the number of tools each playbook connects to, how many approval gates the design needs, where the platform is hosted, and how much testing the change process requires. Open-source Shuffle carries no per-seat fee, so most of the spend is people: engineering time to build and test playbooks, and the partner's fees for scoped work. Connector maintenance recurs, because every tool upgrade can break an app. Ask any partner for a quote that lists playbooks, connectors, approval design, hosting, test environments and a retainer for ongoing maintenance as separate lines, and confirm which of these are one-time and which recur.

How long does a SOAR rollout take in a regulated financial institution?

The timeline depends on how many playbooks come first, how many of the connected systems already have documented APIs, and how long your change control and model-risk reviews take. Playbooks that touch payment or fraud systems need staged testing and sign-off, which usually takes longer than read-only enrichment. Most engagements are fixed-scope, so the written scope should set the sequence, the deliverables and the dates before work starts. Ask the partner which playbook they would build first, what must be true before it goes live, and which of your teams must approve each stage.

What does our internal team need to provide for a SOAR project?

The partner can build the workflows, but your organization must supply the decisions behind them. That means a named system owner for each connected tool, approvers who can authorize destructive actions such as disabling an account or blocking a payment, and a regulatory contact who confirms which deadlines and reporting templates apply. Your team also owns credentials, network access and change approval for production. Agree these roles in the scope document before design starts, because missing approvers are the most common reason a playbook stalls at its approval gate.

Can our own engineers run Shuffle, and where does the partner's role start?

Yes, your engineers can run Shuffle on their own infrastructure, since all features are available in the open-source edition according to the Shuffle open source article. The partner's role is usually the work that takes specialist time: designing playbooks, writing and maintaining apps, setting up hosting and high availability, hardening the platform, and documenting the evidence your auditors will sample. Ask where the handover line sits, who maintains each playbook after go-live, and what the partner will do when an upstream tool changes its API.

How does Shuffle app-run licensing affect planning for a SOAR platform?

Shuffle's commercial licensing is priced on app runs, meaning actions that actually execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited, according to the Shuffle pricing article. This matters for financial services because high-volume enrichment, such as checking every alert against threat intelligence, consumes runs quickly. Estimate run volume from your alert rates and playbook designs, then ask the vendor how runs are counted in your specific configuration and what happens when you exceed a limit. Also confirm which features are limited in the open-source edition, since the Shuffle configuration docs say limits between editions are enforced since v2.1.1.

Can a SOAR partner replace our legal or regulatory reporting advice?

No. A partner can build playbooks that collect the evidence, timestamps and classifications your reporting process needs, but it cannot decide whether an incident is reportable under DORA, PCI DSS, the FTC Safeguards Rule or other rules. Those decisions belong to your legal, compliance and regulatory teams, who also confirm the templates and deadlines. Ask the partner to show where their work stops and where your advisers take over, and confirm that approval steps in the playbooks route those decisions to the named people.

How should we check a SOAR partner's approach to testing and credentials?

Ask how workflows are tested in a non-production environment before any change reaches payment or fraud systems, and who signs off each release. Ask how credentials for connected tools are stored. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret, and the configuration docs warn that losing or changing that secret breaks every saved app authentication. Your partner should explain how that key is generated, backed up and rotated, and how the change is recorded. Ask for a written test plan and a sample of the evidence it produces.

What to ask a SOAR partner before signing for a financial workload

Ask the partner to show, in writing, how each playbook maps to a reporting clock before any build starts. For DORA, the question is how the playbook captures the time the incident was detected, the time classification was decided and the time the initial notification left the entity, because those timestamps are what a supervisor will test. For PCI DSS, ask how the playbooks support the incident response plan and the 24/7 response capability described in Requirement 12.10, and which of those steps the partner runs in Shuffle versus which remain with your staff. A partner that cannot separate the automated steps from the human decisions is not ready to sign for a regulated workload.

Ask how payment and fraud actions are gated. Every action that blocks a card, reverses a transaction, disables an account or changes a payment rule should sit behind an explicit approval step in the workflow, with the approver's identity, the time and the reason written to the case record. Ask who holds each approval role and whether the approval path is tested with the same workflows that run in production. For Shuffle credentials, ask where the SHUFFLE_ENCRYPTION_MODIFIER secret is kept, who can read it, how it is backed up, and how a rotation is planned, since the Shuffle configuration docs warn that losing or changing it breaks every saved app authentication. Ask whether the partner rotates the API keys of connected tools on a schedule and what happens to running workflows during a rotation.

Ask how workflows are tested before they reach production, and whether the test environment uses the same Shuffle version, app versions and Orborus configuration as production. Ask how the partner plans Orborus nodes so that workflows keep running if one fails, how worker capacity is sized, and how run limits under the app-run licensing model will be monitored so that a noisy detection rule does not exhaust the allowance during an incident. Ask for their change control procedure for automated responses, including who approves a new or altered playbook and how versions are recorded. Finally, ask which evidence the partner will hand over, such as workflow definitions, execution logs, approval records and change tickets, and which they will not claim to produce, such as a DORA register entry, a Report on Compliance or a Swift attestation, which remain your responsibility and that of your assessor.

Risks that delay or weaken a financial SOAR deployment

Most failed financial SOAR projects break in the same few places: secrets, approvals, scope, contracts and connectors. Each risk below is a decision to make before the first playbook goes live, not a problem to fix afterwards.

Losing the encryption modifier

Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256, using the SHUFFLE_ENCRYPTION_MODIFIER secret. If that secret is lost or changed, every saved app authentication breaks, and the playbooks that depend on them stop working during an incident. Mitigation: store the modifier in a separate, backed-up secrets store with a documented recovery procedure, and rehearse restoring it on a non-production instance before go-live.

Automated containment without approval gates

A playbook that disables a card-processing account, blocks a payment gateway IP or isolates a host in the cardholder data environment can cause a payment outage faster than any analyst can intervene. Mitigation: require a named human approval step for every destructive action on payment and fraud systems, and limit automation on those systems to enrichment and ticket creation until the approval path has been tested.

Unclear cardholder data scope

A SOAR platform that connects to a payment system can itself bring that system, and the platform's own data stores, into the cardholder data environment. Playbooks that copy alert payloads into case records may also store cardholder data. Mitigation: map which systems store, process or transmit cardholder data before connecting them, and confirm with your assessor how the SOAR platform and its OpenSearch store are scoped.

Third-party hosting outside DORA contract terms

If a managed SOAR partner or hosting provider supports a critical or important function, DORA Article 30(2) requires the contract to state where services are provided and data processed, give advance notice of changes, and cover data return on termination. Mitigation: specify hosting location, sub-processors and exit terms in the contract, and document a tested exit plan that covers Shuffle workflows, app definitions and stored evidence.

Connector drift when tools update

Shuffle apps are versioned Docker containers built from OpenAPI specifications or the Python SDK. When a firewall, identity provider or ticketing tool changes its API, a playbook can fail silently or take the wrong action. Mitigation: pin app versions, test each playbook against a staging copy of every connected tool after an upgrade, and track Shuffle releases such as v2.3.0 against your deployed tag.

How DeployOpen scopes and supports financial SOAR work

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a financial SOAR program, that means the Shuffle server, its workers, the OpenSearch document store and the connectors to the SIEM, identity provider and payment or fraud tools are deployed in the cloud accounts, data centers or air-gapped networks the institution already controls. Nothing in the engagement requires moving alert data or credentials to a DeployOpen-hosted environment. Before work starts, the institution should confirm where each component will run, who holds the administrator roles on the Shuffle backend, and which team owns the SHUFFLE_ENCRYPTION_MODIFIER secret, since losing or changing it breaks every saved app authentication.

Most engagements are fixed-scope, and the scope, deliverables and timelines are agreed in writing before any build starts. For this use case, a useful written scope names the playbooks in the first release, the approval gates for any action that touches payment, card or fraud systems, the evidence each playbook must retain for DORA or PCI DSS review, and the test environment used before production. Quotes follow from that written scope, so the more precisely the institution defines the playbooks and connectors, the more precise the quote. Ask the partner to list which items are one-time build work and which recur, and to state how changes to scope are priced and approved. Ongoing support, upgrades and continuous testing are available as retainers, which suit the recurring work of keeping connectors current as the tools they call change.

DeployOpen prepares systems, controls and evidence for compliance assessments, including the playbook records, approval logs and retained tool output that a regulator or assessor may ask to see. It does not issue audit reports, attestations or certifications. A PCI DSS Report on Compliance or Attestation of Compliance comes from a Qualified Security Assessor or the entity's own assessment process, and DORA oversight sits with the competent authority. Institutions should ask their assessor early which evidence they will request, and confirm with their own compliance team which evidence the assessor accepts in its current form.