How to use a SOAR requirements checklist before you choose a platform
A SOAR requirements checklist turns a vague wish to stop manual alert triage into a written scope that a platform, a partner or an internal team can be measured against. It covers the alert sources and the playbooks to automate first, the enrichment and response actions each playbook needs, the tools that must be reached through a connector or an OpenAPI-based app, the approval steps required before destructive actions, the case record, the audit trail of automated actions, and the places where automation workers are allowed to run. Work through each area and record, for every item, who owns the decision, which systems are involved and what would count as done. The output is a scope document, not a product selection.
Your team's alert volume, tool mix and data handling rules will shape the answers more than any feature list, so treat each requirement as a hypothesis to test. The most useful check is a proof of concept built on your own alert data, with a few representative playbooks run end to end: how an alert arrives, what enrichment it receives, which approval gate it hits and what the audit record looks like afterward. Confirm during that test whether each connector you need exists, how credentials for connected tools are stored and what happens to the workflow when a tool's API changes. This group centers on Shuffle, an AGPL-3.0 security automation platform, so the checklist below uses its architecture and app model as the reference, while the same questions apply to other options.
Use the completed checklist to write the statement of work and to compare build, partner and commercial approaches on equal terms. Ask each candidate to show, not describe, how they handle the items your scope marks as mandatory, including where workers run, how the platform is recovered after an outage and how an automated action is traced back to the alert and the person who approved it. Requirements that cannot be demonstrated in the proof of concept should be recorded as open risks with an owner and a decision date, so the rollout does not depend on assumptions nobody has tested.
Functional requirements: which alerts and playbooks to automate first
This table compares the functional requirements a SOAR deployment should meet before the first playbook goes live, from ranking alert sources to creating cases. Read each row as a question to answer in your own environment: the why-it-matters column explains the risk, and the how-to-verify column shows what to test before production. The main takeaway is that the first playbooks should target high-volume, low-risk triage and enrichment, with containment gated by approval.
| Requirement | Why it matters | How to verify |
|---|---|---|
| Rank alert sources by volume and risk | Automating the noisiest source first saves analyst time, but a rare high-impact source such as identity compromise may matter more to automate early. | Export 30 days of alert counts per source and tag each by severity and asset criticality, then agree the top three with the SOC lead. |
| First playbook: alert triage | Automated triage can enrich and close known benign alerts, which reduces queue load without touching systems. | Replay historical alerts through the playbook and compare its dispositions with analyst decisions before enabling it. |
| First playbook: enrichment | Enrichment adds asset owner, user context, reputation and threat intelligence to each alert before a human reads it. | Confirm each enrichment source returns data for a sample alert and that failed lookups are logged, not silently skipped. |
| First playbook: containment | Isolating a host or disabling an account stops an attack but can disrupt operations, so it needs the strictest controls. | Test on a non-production asset, confirm rollback steps work, and check that approval is required before any destructive action. |
| Trigger types from SIEM, EDR and identity tools | Each source emits events differently (push webhooks, polled APIs, syslog), which affects latency and missed-event risk. | Document the trigger method for each tool and test a live alert end to end. Confirm each connector against your exact tool versions. |
| Example source: Wazuh alerts (illustrative) | Wazuh stores alerts in its indexer and can be queried for triggers, so it is a common starting point for host and endpoint alerts. | Confirm the alert export or API method in the Wazuh version you run, and test the connector with a sample rule firing. |
| Example source: MISP indicators (illustrative) | MISP holds indicators that can enrich alerts, such as matching hashes or IPs, but it is an enrichment source rather than an alert source. | Confirm the MISP API key scope and the attribute types your playbook queries, then test lookups against known indicators. |
| Case creation and linking | Every automated action needs a case record so analysts can see what ran, why, and what was changed. | Verify that each playbook creates or updates a case with alert IDs, action outputs and timestamps, and that cases can be searched. |
| Connector versions | Connectors break when vendors change APIs, so a working playbook can fail silently after an upgrade. | Ask the implementation partner for a connector test schedule and a list of the tool versions each connector was built against. |
Connectors or OpenAPI apps: how to judge each integration
Prebuilt apps are ready-made integrations that ship with the platform or are published for common tools. They are the fastest route to a working enrichment or ticketing step, but their quality depends on who wrote and tests them. Before you rely on one, confirm the vendor or community owner, the version pinned in your environment and the last date the app was changed.
- Ownership: Confirm whether the app is maintained by the Shuffle project, by the tool vendor or by a community contributor, and who answers when it fails.
- Container updates: Apps run as versioned Docker containers, so check which image tag your workflows call and whether updates are pulled automatically or only on your schedule.
- Breakage on API change: When the vendor changes an endpoint, field name or authentication method, the app can fail silently in a workflow. Ask how failed runs surface to your on-call team.
- Coverage gaps: Prebuilt apps often cover only the common actions. Map each playbook step to an actual action in the app before you commit to the design.
- Run cost: Each action that executes counts as an app run, so a prebuilt enrichment step that is called on every alert adds to the licensing metric in Shuffle's pricing article.
Before approving a prebuilt app for production, test it against a non-production instance of the tool and record its version and image tag in your change log.
Shuffle can build an app from an OpenAPI specification in the App Creator, which is useful when a tool has a documented REST API but no published app. Your team, or your implementation partner, owns the generated app from that point, so the specification quality and the test coverage determine how durable it is. Ask who will maintain the specification when the vendor publishes a new API version.
- Ownership: Your organization owns the app and its specification, so assign a named engineer and a review step for every change.
- Container updates: Each app version is a versioned container, so a new specification revision should produce a new version rather than overwriting the one in use.
- Breakage on API change: Deprecated endpoints, renamed fields and changed authentication flows break workflows that depend on them. Subscribe to vendor API change notices and rerun tests after each one.
- Credential handling: Saved API keys are encrypted in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret, so plan key rotation and that secret's custody before go-live.
- Run cost: Every action in a workflow that calls the generated app counts as an app run. Design enrichment to cache results where the tool allows, and check how many calls each alert will generate.
Ask for a test suite that covers each generated action against a sandbox of the tool before any version reaches production.
Custom Python apps, written with the Shuffle app SDK, suit integrations that need logic beyond a single API call, such as paginated lookups, multi-step enrichment or proprietary systems with unusual authentication. They give the most control and the most responsibility. The codebase, its dependencies and its security review belong to your team or your partner, and every dependency becomes part of your supply chain.
- Ownership: The team that writes the app must also version it, test it and retire it. Document the owner in the app metadata and in your runbook.
- Container updates: Build each release as a versioned Docker image, pin base images and dependencies, and roll out new versions with the same promotion path as other production code.
- Breakage on API change: Library upgrades and vendor changes can break the code in ways a specification would not reveal, so keep integration tests that run on a schedule against the tool's test environment.
- Secrets and logging: Keep credentials in the platform's encrypted store, never in code, and make sure logs written by the app do not capture personal data or tokens.
- Run cost and performance: Batch lookups inside one action where possible, because each action that executes is counted as an app run and long-running code holds worker capacity.
Confirm who signs off on code changes, how dependencies are scanned, and how the app is removed when the tool it connects to is retired.
Most playbooks use all three paths. The decision is about the cost of ownership for each integration, not only the speed of the first build. A prebuilt app carries vendor risk, an OpenAPI app carries specification upkeep and a custom app carries the full software lifecycle. Make the choice per tool and record the owner, the test method and the expected run volume in the playbook inventory.
- High-volume enrichment: Calls made on every alert add the most app runs, so favor the path that lets you cache, batch or filter before the call.
- Rare, high-impact actions: Containment or account disablement steps need the most testing and an approval gate, which may justify a custom app with tighter review.
- Tools with stable APIs: A well-documented REST API with versioning suits an OpenAPI-built app, which keeps the maintenance surface small.
- Tools with few options: When no prebuilt app exists and the API is unusual, plan for a custom app and budget engineering time for its lifecycle.
- Inventory: Keep one list of every app, its path, owner, version and last test date so that a vendor change can be traced to the workflows it affects.
Ask your implementation partner to show this inventory for a sample playbook before agreeing on a fixed scope.
Approval gates and an audit trail for automated response
Every automated action that changes the state of a host, an account or a shared control needs a human approval gate in front of it. The usual candidates are isolating an endpoint, disabling or suspending a user account, and blocking an indicator at a firewall, DNS resolver or proxy. Each can stop a business process, lock out a legitimate user or cut off a clinical or payment system, so the playbook should pause, present the evidence and the proposed action to a named responder, and wait for an explicit decision. Enrichment, tagging and ticket creation can usually run without a gate. For each destructive step, record who may approve it, how long the request waits before it escalates, and what happens on timeout (for example, whether the action is dropped or routed to a second approver). Write a rollback path for each one as well: how to restore network access, re-enable an account or remove a block, and who is authorized to run it.
The platform must keep an audit record of every automated action, not only of the final outcome. For each step, the record should capture the workflow and version that ran, the trigger, the inputs passed to the action, the raw output returned by the connected tool, the decision taken at any gate, and the identity that approved or rejected it. Shuffle stores execution data in its OpenSearch document database, and saved app credentials are encrypted there with the SHUFFLE_ENCRYPTION_MODIFIER secret, so the key itself must be backed up and kept separate from the data. Confirm with your chosen Shuffle version exactly which fields it writes to execution history, how long that history is retained, whether it can be exported unchanged, and whether an administrator can edit or delete past runs. Test this with a sample destructive workflow before relying on it as evidence, and have the compliance owner confirm that the record meets the retention and review rules of your framework.
Security requirements for the automation platform itself
A SOAR platform holds credentials for every tool it touches, so it becomes a high-value target. The cards below set out the controls to specify before deployment: how saved credentials are encrypted and recovered, how users sign in, what access the connected tools grant, where workers sit on the network, and how workflows move from test to production.
Encryption key for saved credentials
Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256, using the key set in SHUFFLE_ENCRYPTION_MODIFIER. Losing or changing this value breaks every saved app authentication. Confirm where the value is stored, who can read it, how it is backed up separately from the database, and what the change procedure looks like before any rotation is planned.
Single sign-on with OpenID Connect
Shuffle added SAML single sign-on in version 0.9.16 and OpenID Connect in 1.0.0, with per-tenant SSO enforcement. SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect, so new on-premises deployments should be designed around OpenID Connect. Ask the partner to confirm that local administrator access is kept for recovery and that enforcement is applied to every tenant.
Least-privilege service accounts
Each connected tool should get its own service account with only the actions its playbooks need. A containment playbook may need to disable an account or isolate a host, while an enrichment playbook only needs read access to a threat feed. Keep these accounts separate so one compromised credential cannot reach every system, and record which account each app uses.
Worker network placement
Orborus starts a worker for each workflow execution, and the worker starts app containers. Decide which network segment hosts the workers, which tools they may reach, and which outbound destinations they need. Shuffle's hybrid model with a local Orborus needs no inbound firewall ports, which can simplify approval from network teams. Confirm this with the architecture you choose.
Rotation of connected tool secrets
Saved API keys and tokens for each connected tool need a rotation schedule that matches the owner's policy. Each rotation changes the credential stored in Shuffle, so the workflow owner and the platform team should agree on the steps and on a test run afterward. Ask the partner how rotations are logged and how a failed rotation is detected before a playbook is needed in an incident.
Separation of production and test workflows
Shuffle's docs recommend the latest Docker tag for stable releases and the nightly tag for experimental changes, so platform versions should also be separated by environment. Run test workflows against sandbox tools with test credentials, and promote only reviewed workflows into production. Confirm how the partner versions workflows, restricts who can edit production playbooks, and keeps a record of each promotion.
Where workers can run: deployment patterns and their limits
Shuffle documents four deployment architectures, and the choice decides where your playbook data, saved credentials and worker execution live. The first is a single server with Docker Compose, which suits a pilot or a small team. The second is distributed Docker Swarm, which spreads services across several hosts. The third is a hybrid model that pairs Shuffle Cloud with a local Orborus, the component that polls the backend for jobs and starts a worker for each workflow execution. The fourth is Kubernetes with Helm charts. For each option, answer three questions before you pick it: where the OpenSearch document database and the encryption secret sit, whether the network allows inbound connections to the Shuffle backend, and how a worker reaches tools on isolated or air-gapped segments.
The hybrid model deserves the closest review in regulated settings. Shuffle documents that a local Orborus needs no inbound firewall ports, because it initiates the connection to the cloud backend. That is useful for an organization that cannot open inbound paths, but it means playbook definitions and execution metadata leave your network, and the cloud side then holds the workflow record. Confirm with Shuffle which data is stored in the cloud component, where it is hosted, and how long it is retained. For air-gapped or segregated tools, self-hosted architectures keep the backend, the database and the workers inside your boundary, and the worker needs a network route to each target. Test that route from the exact host that will run the worker, not from an administrator workstation.
High availability is a separate decision from deployment architecture. Shuffle's configuration docs recommend an OpenSearch cluster rather than a single node, optional Memcached for a shared cache, and NFS for shared files when several backends run. They also recommend more than one Orborus node, so workflows keep running if one fails. Shared storage has its own risk: NFS shares must be backed up and access-controlled like any other store holding playbook files. Plan the SHUFFLE_ENCRYPTION_MODIFIER secret as part of this design, because the docs warn that losing or changing it breaks every saved app authentication. Ask your implementation partner to document where that secret is kept and how a restore from backup is tested before go-live.
Operational requirements and how to verify them
How do we confirm run limits and scaling are planned before go-live?
Ask the implementation partner to document expected app runs per month, the peak execution rate, and the worker capacity planned for it. Shuffle licenses on app runs, meaning actions that actually execute in a workflow, while triggers and skipped actions are not counted, so the planning input is the volume of executed actions, not the number of users or workflows. Your security engineering lead should verify the estimate against a replay of real alert volume from your SIEM. Confirm which edition you are running, because since v2.1.1 the limits between the open-source and enterprise editions are actively enforced. Ask the partner to show the scaling plan in the architecture: a single Docker Compose server, a Docker Swarm, a hybrid with Shuffle Cloud, or Kubernetes with Helm charts.
What should be tested before a Shuffle workflow runs in production?
Every workflow should pass a staged test in a non-production environment with recorded inputs, expected outputs and a rollback path before it is allowed to take a response action. Ask the partner to show test cases for each branch, including the failure paths when an enrichment API times out or returns an empty result. Destructive steps such as isolating a host or disabling an account should be tested against a dedicated test asset, not production. Your SOC lead should sign off on the test evidence, and your change control owner should approve the promotion. Confirm that workflow versions are retained so a faulty change can be reverted.
How should Shuffle upgrades and patch cadence be planned?
Plan upgrades as a scheduled, tested change rather than an automatic update. Shuffle recommends the latest Docker tag for stable releases and the nightly tag only for experimental changes, so production should pin a stable tag that your team has tested. Confirm the release you are running against the published Shuffle release list, and ask the partner for the upgrade runbook, including how saved workflows and apps are checked after the change. The same discipline applies to the components around it: the Wazuh, MISP or identity platforms your playbooks call. Your platform owner should verify the upgrade in a staging copy first and keep a record of each version change for audit.
What must be backed up for Shuffle, including the encryption key?
Back up three things together: the OpenSearch data that holds workflows and execution history, the configuration, and the SHUFFLE_ENCRYPTION_MODIFIER secret. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using that secret, and the documentation warns that losing or changing it breaks all saved app authentications. Store the secret in your approved secrets vault, separate from the backup set, and record who can retrieve it. Ask the partner to run a restore test into a clean environment and confirm that saved credentials work afterward. Confirm the backup frequency and retention with your operations team, since those depend on your recovery objectives.
How do we monitor the health of Shuffle workers and Orborus?
Monitor the backend, the frontend, the OpenSearch cluster and each Orborus node, because workflows stop running when the runtime that polls for jobs fails. Shuffle's architecture uses Orborus to poll the backend for jobs and start a worker for each workflow execution, so a stalled Orborus node looks like silent playbook failure. The configuration guidance recommends more than one Orborus node so execution continues if one fails. Your operations team should alert on queued jobs that are not picked up, failed worker starts and OpenSearch cluster status, and test that an alert fires by stopping a node in staging. Ask the partner to show the dashboards and alert routes they configured.
Who should be on call when an automated playbook fails?
Define a named escalation path for three cases: the platform is down, a playbook is failing, and a playbook took a wrong response action. The platform on-call engineer handles infrastructure, the SOC on-call analyst handles alert handling and manual fallback, and the playbook owner decides whether a workflow is paused or changed. Confirm the coverage hours with your own SOC staffing model, since the right window depends on your alert volume and reporting obligations. Ask the implementation partner whether support is covered by a retainer, which is available from DeployOpen, and what response expectations are written into that agreement. Your security leadership should approve the runbook before go-live.
Who owns each playbook after the implementation is handed over?
Every playbook needs one named business owner who approves its logic and one technical owner who maintains its apps and connectors. The business owner is usually the SOC manager or incident response lead, and the technical owner is the engineer who keeps the Shuffle apps working as the connected tools change. Record the owner, the connected systems, the approval rules for destructive steps and the date of the last test in a register that your auditors can sample. Ask the partner who writes and maintains the apps, how those apps are versioned as OpenAPI-based or Python-based containers, and what handover documentation is delivered. Confirm that ownership transfers to your team in writing at the end of the engagement.
Compliance evidence a SOAR platform can support
A SOAR platform can produce records that support parts of several obligations, but it does not satisfy any of them on its own. The HIPAA Security Rule's technical safeguards at 45 CFR 164.312 call for audit controls that record and examine activity in systems holding ePHI, and the FTC Safeguards Rule at 16 CFR 314.4 requires covered financial institutions to monitor and log the activity of authorized users. In both cases the organization owns the control, its scope and its conclusion. The useful question for a CISO is which of the platform's logs fall inside the scope of those controls and who is accountable for reviewing them.
The evidence worth keeping from a Shuffle deployment falls into four groups: alert intake (which source sent the alert, when it arrived and which workflow picked it up), approvals (who approved a destructive action, through which step and at what time), actions taken (each enrichment lookup and response call, with its inputs, outputs and the credential identity it used) and case timelines (the order of triage, escalation and closure). Confirm with your implementation partner that workflow execution history is retained for the period your policy requires, that it is exported to a store your audit team can read, and that the records cannot be edited by the people whose work they describe. Test this by reconstructing one incident end to end from the records alone before an assessor asks.
DeployOpen prepares systems, controls and evidence for compliance assessments, including the playbook documentation, access settings and log retention described above. DeployOpen does not issue audit reports, attestations or certifications. Those come from independent auditors or certification bodies, and the organization's own compliance team decides how the evidence maps to its obligations. Agree the evidence list in writing during scoping, so that retention, export and review responsibilities are assigned before the first assessment.
How much work is a SOAR requirements review and who should do it
What drives the cost of a SOAR requirements review?
The main drivers are the number of alert sources, the number of playbooks to automate first, how many tools need a connector or a custom app, how many approval paths sit in front of destructive actions, and how constrained the deployment is. Each alert source adds field mapping and sample review. Each playbook adds decision logic, evidence steps and test cases. Air-gapped or regulated networks add design work on where workers run and how credentials are held. A review is usually a one-time effort that produces a written requirements set, while the ongoing cost of keeping connectors and playbooks working as tools change recurs. Ask for the scope list, the assumptions behind it and the deliverables before comparing any figures.
How long does a scoped SOAR requirements phase take?
The duration depends on how many alert sources, playbooks and tools are in scope and how quickly your team can answer questions. No duration figure is available for this topic, so confirm the timeline with any partner in writing before work starts. Ask for the phases, the dependencies on your staff, the review checkpoints and the point at which the requirements are handed over. A fixed-scope engagement should state its schedule in the agreed scope, which is the document to compare across proposals.
What does the internal team need to provide for a requirements review?
The review needs three kinds of input from your side. Alert samples from each source, ideally with the fields your analysts actually read, let the team see real formats and volumes. Tool owners for the systems that will be connected can confirm APIs, accounts and change windows. Named approvers for destructive actions, such as isolating a host or disabling an account, must decide which steps need a human gate. Provide a list of the playbooks analysts already run by hand, since these are often the first candidates for automation. Your team should also state reporting obligations, because they change what evidence the workflows must capture.
Can an internal team write the SOAR requirements alone?
An internal team can write requirements if it has security operations experience, access to tool owners and time to test assumptions against real alerts. The gaps usually appear in three places: connector feasibility, the design of credential storage and worker placement, and the test plan that proves a playbook behaves safely before production. Shuffle's source is licensed under AGPL-3.0 and its releases, including v2.3.0 published on September 28, 2026, are public, so the platform itself is accessible without a contract. Whether to bring in outside help depends on your staffing and on how much a mistake in an automated response would cost your organization.
Which parts of a SOAR requirements review carry the most risk?
The highest risk sits in approval steps for actions that change production systems, such as blocking traffic, disabling accounts or isolating endpoints. A playbook that triggers on a noisy alert can cause an outage or lock out staff, so requirements must define thresholds, rollback steps and a human gate. The second risk is credentials. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret, and its documentation warns that losing or changing that secret breaks all saved app authentications. The requirements should name who holds that secret and how it is backed up.
What should a written quote for a SOAR requirements review include?
A quote should follow from a written scope and list the alert sources, playbooks, connectors and OpenAPI or Python apps in scope, plus the deployment model and any air-gapped or regulated constraints. It should state the deliverables, such as the requirements document, playbook specifications, approval matrix, credential handling design and test plan, and it should say which items are excluded. Ask whether the price is one-time or recurring, what happens when a requested change falls outside scope, and what assumptions about your staff and access apply. DeployOpen does not publish a price list, and its engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts.
How do licensing and run limits affect the requirements?
Shuffle prices its licensing 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 its pricing article. Because of this, the requirements should estimate how many actions each playbook executes per alert and how alert volume varies over time. Shuffle also states that all features are available in the open-source edition, while paid tiers differ in feature limits, scaling and support. Confirm the current terms with Shuffle before you plan around them, since the requirements should reflect the edition you actually run.
What evidence should the requirements specify for audit purposes?
The requirements should state that every automated action is logged with the workflow version, input, output, approver and timestamp, so an auditor or incident reviewer can reconstruct what the platform did. Regulated organizations often also need evidence that access to the SOAR platform is controlled and monitored. Under the HIPAA Security Rule at 45 CFR 164.312, audit controls must record and examine activity in systems containing ePHI, and the FTC Safeguards Rule at 16 CFR 314.4 requires monitoring and logging of authorized user activity. Confirm with your assessor which evidence they will sample before you finalize the audit trail design.
How DeployOpen scopes and delivers a SOAR implementation
The sequence turns a requirements checklist into a written, fixed scope and a self-hosted Shuffle deployment that the client's own team can run, change and audit after handover. Each stage ends with a document or test result the client can check.
Review the requirements checklist with your team
DeployOpen works through the checklist with your security operations, identity and platform leads. The group confirms which alert sources, tools and playbooks are in scope for the first phase, which ones are deferred, and who approves destructive response actions. The output is a draft requirements list that names each alert source, each tool needing a connector or OpenAPI app, and each owner. Work does not move forward until your leads have signed off on that list.
Verify requirements against your environment
Before any scope is priced, DeployOpen checks the draft against your actual systems. This covers API access and permissions for each connected tool, where the alert sources send data, network paths from the workers to those tools, and which connectors already exist as Shuffle apps or would need an OpenAPI-based app. Gaps, such as a tool with no usable API or a network rule that blocks a worker, are recorded with a proposed workaround. The output is a verification report that you review and accept.
Agree a fixed written scope
DeployOpen converts the verified requirements into a written scope that lists deliverables, playbooks, integrations, approval steps, the case management and audit trail approach, and the acceptance criteria for each. Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before work starts. Ask the quote to separate one-time build work from any recurring retainer. The signed scope is the baseline for every later change request.
Deploy Shuffle inside your infrastructure
DeployOpen installs the Shuffle server and workers inside your cloud accounts, data centers or air-gapped network, using the deployment architecture chosen in the scope. Credentials for connected tools are stored in Shuffle with its encryption setting, and the encryption secret is recorded in your secrets process before any app is configured. Worker placement, scaling and high availability settings are set to match the scope. The output is a running environment with a documented architecture and a list of configured components.
Build and test playbooks and connectors
DeployOpen builds the agreed playbooks and connectors, then tests each one against sample alerts and in a staging environment that mirrors production. Tests cover enrichment results, decision branches, error handling when a connected tool is unavailable, and every approval gate for destructive actions. Your team reviews the test evidence and signs off each playbook before it is promoted. The output is a test record per playbook showing the inputs, expected outcomes and observed results.
Harden access, logging and recovery
DeployOpen applies hardening to the Shuffle platform and its connected access paths, including authentication for users (with single sign-on where your scope requires it), least-privilege service accounts, logging of automated actions, and backup and restore of the configuration and stored credentials. A restore test confirms that the platform and its saved app authentications can be recovered. The output is a hardening checklist with each setting, its owner and the result of the restore test.
Document and hand over to your team
DeployOpen writes operating documentation for the platform, each playbook, each connector and the approval procedure, and runs a handover session with the staff who will maintain it. Documentation covers how to add a playbook, how to rotate credentials, how to respond when a connector breaks and how the audit trail is reviewed. The output is a document set and a recorded handover that you can check against the acceptance criteria.
Continue with an optional support retainer
After handover, you can choose a retainer for upgrades, security patches, connector maintenance and ongoing support, or run the platform in-house. Retainers are priced separately from the build, and their scope, response arrangements and service terms are agreed in writing. Ask for a clear list of what a retainer covers, including how upgrades to Shuffle and its connected tools are tested before they reach production. The output is an agreed support arrangement, or a documented in-house ownership model.
