Which open-source pieces replace TDR Orchestrator automation?
No single open-source product is a one-to-one match for ThreatQ TDR Orchestrator, so replacing it means assigning its work to three components: OpenCTI for the knowledge graph and enrichment playbooks, MISP for sharing and exports, and Shuffle for actions in SIEM, EDR and ticketing tools. Teams whose orchestration is driven by scores and pushes to detection tools should expect to rebuild those rules explicitly rather than expect a direct port. The split follows the job. OpenCTI stores intelligence as STIX 2 objects and offers playbooks on its Enterprise Edition, which is licensed separately from the Apache 2.0 Community Edition, so confirm early whether the playbook features you rely on sit in the edition you would deploy. MISP handles distribution levels, sharing groups, synchronization and exports to formats such as Suricata, Snort and Zeek, and it exposes a REST API and PyMISP for scripted use. Shuffle, licensed under AGPL-3.0, runs the workflows that push data into external tools through apps built from OpenAPI specifications or the Python SDK.
The gaps are where the migration work sits, and each one needs a named owner. Scoring and decay logic from ThreatQ does not transfer automatically, so the team must decide which score fields become OpenCTI scoring, which become MISP attribute flags, and which become Shuffle conditions. Confirm whether each SIEM, EDR and ticketing connector you use has a Shuffle app, or whether you must write one. Plan for Shuffle's own operating model: encrypted app credentials depend on the SHUFFLE_ENCRYPTION_MODIFIER secret, so losing it breaks every saved authentication, and high availability requires an OpenSearch cluster and more than one Orborus node. Shuffle's licensing is metered on app runs, and the Enterprise limits are actively enforced from v2.1.1, so model expected workflow volume before you choose a tier. Finally, check the OpenCTI and MISP versions you deploy against their current lifecycle, since OpenCTI LTS releases require a license key.
How each TDR Orchestrator capability maps to open-source options
This table maps each intelligence-driven automation capability to the open-source component that covers it, and marks where the match is partial or needs custom build. Read it as a coverage map, not a feature-parity list. Confirm each connector and app against your own SIEM, EDR and ticketing versions before you commit.
| Capability | OpenCTI | MISP | Shuffle |
|---|---|---|---|
| Enrichment of indicators | Enrichment connectors can add context from external sources. Check which sources you need are available as connectors. | Enrichment modules and the correlation engine add context. Coverage depends on the modules you enable and configure. | Workflow actions call enrichment APIs through apps. Confirm an app exists for each source or build one from an OpenAPI spec. |
| Scoring-driven triggers | Scoring and playbooks can drive follow-on steps. Playbooks are an Enterprise Edition feature, so confirm the trigger logic you need. | Scoring is limited. Tags, taxonomies and galaxies can drive filtering, but thresholds usually need a script or Shuffle workflow. | Workflows branch on any field in the execution data. Score thresholds must be defined in the workflow, not inherited from the platform. |
| Dissemination to consumers | Export connectors and stream consumers push data out. Confirm the target format and cadence for each consumer. | Exports include Suricata, Snort, Zeek, RPZ, STIX, CSV and OpenIOC, plus the REST API. Verify each consumer accepts the format. | Sends data to downstream tools through apps. Requires a configured app and credentials for each destination. |
| Sharing with partners and communities | Sharing is organization-based segregation in Enterprise Edition. Confirm it meets your partner trust model. | Distribution levels, sharing groups and automatic sync between instances are built in, down to individual attributes. | Not a sharing platform. Shuffle can move data to a partner channel, but trust and access controls must be designed separately. |
| Export to detection tools (SIEM and EDR) | Connectors and exports cover common formats. Confirm the exact SIEM or EDR input format and version. | Native NIDS and detection-format exports exist. Other SIEM or EDR formats may need a custom export or a Shuffle step. | Pushes indicators and actions to SIEM and EDR through apps. Confirm each vendor's API and app version before the cutover. |
| Action execution in SIEM, EDR and ticketing | Does not execute response actions. Pair with an automation layer for any containment or ticket creation. | Does not execute response actions. Pushes data to tools, but ticket creation and containment usually run through an automation layer. | Core strength for this capability. Confirm apps for your ticketing and EDR tools, and build custom apps where none exist. |
| Audit trail and approvals | Audit logs are an Enterprise Edition feature. Approval gates for playbooks need to be confirmed against your process. | Logging and sharing history depend on instance configuration. Confirm what is recorded and how long it is kept. | Workflow execution history is available. Approval steps typically need a designed manual gate, so plan and test it. |
When OpenCTI, MISP or Shuffle fits each automation job
ThreatQ TDR Orchestrator combines intelligence-driven automation with actions in outside tools. In open source, no single product covers that span, so each job tends to land in a different place: enrichment and dissemination inside the knowledge graph, sharing and network exports in MISP, and actions in SIEM, EDR and ticketing systems in Shuffle.
OpenCTI playbooks for enrichment
OpenCTI playbooks run actions on objects already inside the knowledge graph, such as enriching an indicator with related reports, linking it to an intrusion set or sending it to a connector. This fits teams whose automation mostly concerns the intelligence itself. The trade-off is scope: playbooks act within OpenCTI, so pushes to a SIEM or ticket queue need another tool. Check whether the playbook features you need are in the Community Edition or the Enterprise Edition, since the Enterprise features list includes playbooks. You will operate Elasticsearch or OpenSearch, Redis, RabbitMQ and MinIO alongside the platform.
MISP workflows and network exports
MISP suits automation built around sharing and detection content. Its correlation engine, distribution levels, sharing groups and automatic synchronization handle who receives an indicator, while exports cover MISP JSON, STIX, CSV, OpenIOC and NIDS formats for Suricata, Snort, Zeek and RPZ. The trade-off is that MISP is an event store, not a general action runner, so pushes to EDR or ticketing tools require a REST API client such as PyMISP or an orchestrator. You will need to curate taxonomies, decide which feeds to enable and maintain the sync partners yourself.
Shuffle workflow actions in external tools
Shuffle is a SOAR platform that runs workflows against SIEM, EDR and ticketing APIs using apps built from OpenAPI specifications or the Python SDK. It fits the ThreatQ orchestrator job of acting on intelligence in other systems. Under the Shuffle pricing article, the open-source edition's commercial metric is app runs, meaning actions that execute in a workflow, while triggers and skipped actions are not counted. Confirm current limits with Shuffle, because the open-source and enterprise limits are enforced since v2.1.1. You will operate the OpenSearch document store, Orborus runtime nodes and credential encryption key.
Running the replacement alongside the rest of ThreatQ
The first decision is which workflows stay in ThreatQ during the overlap and which move, because every automated action needs exactly one owner. Keep a written register that lists each TDR Orchestrator workflow, the trigger it uses, the detection tool it pushes to (SIEM, EDR or ticketing) and the system that will own it after cutover. Until a workflow is moved, ThreatQ remains its owner. Once a workflow is rebuilt in Shuffle, with enrichment in OpenCTI or MISP feeding it, ThreatQ's copy must be disabled, not left running in parallel. Indicator ownership follows the same rule: decide which platform is the system of record for each indicator class, and make sure a feed is ingested into one place only, or the same indicator will carry two scores and two expiry dates.
Duplicate pushes are the most common failure during this period. A SIEM rule or EDR blocklist that receives the same indicator from ThreatQ and from a Shuffle workflow can create duplicate tickets, double-counted alerts or conflicting block and allow decisions. Check each destination for its ingestion path and deduplication behavior, and confirm with the owner of that tool which source wins when both send the same value. Shuffle's app credentials for those tools should also be scoped so that one workflow can write to a given ticket queue or blocklist at a time. Keep the ThreatQ push disabled per destination as you migrate it, rather than disabling everything at once, so each change can be tested and rolled back on its own.
Some points depend on your ThreatQ and Securonix contract, and you should confirm them with ThreatQuotient or Securonix before cutover. Ask whether TDR Orchestrator actions can be paused without losing configuration, whether any native integration with a Securonix product routes alerts or indicators independently of your own workflows, and what support covers a mixed state. Also confirm how long ThreatQ retains exported history, because you may need it for investigations that span the overlap. Finally, the overlap period is a risk in itself: schedule a test that fires a known indicator through both paths in a non-production environment, and record which system acted and which did not. That test result becomes the evidence that the handover is complete.
Which integrations to keep, move or retire first
Each existing TDR Orchestrator path falls into one of three groups: keep it where it already works, move the action logic to Shuffle, or rebuild the enrichment and dissemination logic as an OpenCTI playbook. Start with the paths that carry the most production traffic and the fewest hidden dependencies, and test each one against its current output before you cut over.
SIEM push
Pushes of indicators or enriched context into the SIEM are usually the highest-volume path and the easiest to keep running during the move. Keep the existing connector until the replacement proves identical records, then move the action to a Shuffle workflow if the SIEM also needs enrichment before the push. Test field mappings, deduplication and how expired indicators are removed, since a silent change in any of them can flood or blind detections. Confirm the SIEM's own API version and authentication method with the vendor before you rebuild the connector.
EDR blocking
Actions that block hashes, domains or IPs on endpoints carry the most operational risk, because a wrong action stops real work. Move these to Shuffle with an approval step rather than rebuilding them as automatic playbooks. Test with a short list of known-benign test indicators in a non-production group, and confirm that the EDR vendor's API credentials are stored and rotated correctly. Confirm how the EDR product handles block expiry and rollback before cutover.
Ticket creation
Automatic ticket creation for high-confidence matches is a good first candidate for a Shuffle workflow, since the logic is mostly conditional routing and field mapping. Check that each ticket carries the indicator, source feed, confidence and a link back to the intelligence record, so analysts can act without reopening the source. Test duplicate suppression, because a feed that repeats an indicator can open the same incident many times. Confirm the ticketing system's API rate limits before you run a bulk replay.
Sharing feeds
Dissemination to partners, ISACs or internal teams is where OpenCTI playbooks and MISP sharing groups fit best, because they carry distribution rules as data rather than as script logic. Rebuild these as OpenCTI playbooks for enrichment and outbound export, and keep MISP for community sharing where your partners already use it. Test that each recipient receives only the objects its distribution level allows, and that TLP markings survive every export format. Confirm with each partner which formats they consume before retiring a feed.
Custom scripts and approval steps
Undocumented scripts are the most common hidden dependency in an intelligence-driven automation setup, and they need an inventory before any migration. List each script, its inputs, its schedule and the person who maintains it, then decide whether it becomes a Shuffle app built from an OpenAPI specification or a Python app using the Shuffle SDK. Test approval steps by checking that a workflow pauses, notifies the right approver and fails closed when no answer arrives. Retire scripts that nobody can explain, after you have confirmed their output is no longer consumed.
How to move orchestration logic out of ThreatQ
This sequence moves TDR Orchestrator's intelligence-driven automation into separate, self-hosted components, so each enrichment, dissemination and action path can be tested against the old behavior before ThreatQ is switched off. The result is a documented map from each trigger to its new owner.
Inventory existing playbooks and triggers
The platform or security engineering lead exports a list of every TDR Orchestrator workflow, the trigger that starts it (new indicator, score change, feed update, or manual action), the enrichment sources it calls, and the destination tools it writes to. Record the credentials each integration uses and who owns it. The step is complete when every workflow has one row with a trigger, a purpose, a downstream system and an owner, and when you can confirm the list against the ThreatQ administration console. Workflows nobody can explain are flagged for review rather than copied.
Export indicators and their context
The threat intelligence team exports indicators, adversaries, related objects, sources and scores from ThreatQ in a format the target platform can import, and keeps a checksum and record count for each export. Confirm the export method and its limits with ThreatQuotient or your administrator, because the available formats depend on your version and deployment. The step is complete when the record counts reconcile with the source data for a sample of indicators, and the export is stored in a restricted location that the migration team controls.
Stand up MISP or OpenCTI
The infrastructure team installs the chosen platform inside your own environment. MISP 2.5 is the recommended version for new deployments and the project recommends Ubuntu 24.04 with its provided installer, with Docker, RPM, Ansible and Puppet as alternatives. OpenCTI needs Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, and its documentation gives sizing for each component. The step is complete when the platform passes a login test through your identity provider, backups run, and a test indicator round-trips through the API.
Rebuild enrichment as connectors and playbooks
The intelligence engineer maps each enrichment path to its new home: OpenCTI connectors for import and enrichment, OpenCTI playbooks for automated enrichment and dissemination, or MISP feeds and workflows for the same job. Some TDR Orchestrator logic will not have a one-to-one equivalent, so record each gap and decide whether it needs custom development or a manual procedure. The step is complete when every enrichment path in the inventory has a target, each gap has a named owner and decision, and a test indicator produces the same enrichment result in both systems.
Recreate action workflows in Shuffle
The security engineer builds the SIEM, EDR and ticketing actions in Shuffle, using OpenAPI-based apps or the Python SDK for tools without one. Store each app credential in Shuffle only after the encryption modifier has been backed up. Shuffle encrypts saved credentials and API keys in OpenSearch with AES-256 under the SHUFFLE_ENCRYPTION_MODIFIER secret, and the documentation warns that losing or changing it breaks every saved app authentication. Record that backup in your secrets vault, confirm it can be restored into a test environment, and only then add credentials. The step is complete when each action runs in a test workflow with a restored-from-backup check passed.
Run both paths in parallel
The operations team keeps TDR Orchestrator and the new pipeline running on the same feed of indicators, with the new actions sending to a staging SIEM or ticket queue. Compare the outputs for each trigger, including scores, tags, enrichment results and tickets opened, and log every difference with its cause. Confirm the Shuffle deployment's high-availability arrangement, such as more than one Orborus node, before the parallel period is judged complete. The step is complete when differences are either resolved or accepted in writing by the owner of each workflow.
Cut over and retire TDR Orchestrator
The platform lead switches production triggers to the new pipeline, one workflow at a time in the order of the inventory, and keeps the ThreatQ workflow disabled rather than deleted for an agreed rollback period. Update the runbook so each trigger lists its new owner, and remove the old credentials once the new ones are in place. Confirm the retirement terms and any data retention obligations with ThreatQuotient or your contract owner before turning off the instance. The step is complete when every production trigger runs from the new pipeline, the rollback path has been tested, and the runbook has been signed off.
Questions buyers ask before replacing TDR Orchestrator
Can we replace TDR Orchestrator without outside help?
Yes, if your team already has the skills to run a SIEM or SOAR, but most of the work is integration rather than installation. Every component here is open source and can run in your own environment: OpenCTI for storage and enrichment playbooks, MISP for sharing and workflows, and Shuffle for actions in SIEM, EDR and ticketing tools. The harder parts are specific to your estate: mapping your scores and feeds, rebuilding each action against your SIEM and ticketing APIs, and testing that automation does not close the wrong ticket. A team that has not run this kind of stack before may want an implementation partner working to a fixed scope agreed in writing. DeployOpen plans, implements, integrates and hardens self-hosted platforms in your infrastructure on that basis.
What makes the replacement effort grow or shrink?
Three things drive most of the effort: the number of playbooks, the number of integrations and the volume of data. Each playbook is a workflow with its own inputs, decision points and failure handling, so a large catalog takes longer to rebuild than a short one. Each integration needs credentials, field mapping and testing against a live SIEM, EDR or ticketing tool. Data volume sets the infrastructure: OpenCTI's documented sizing starts at 2 cores and at least 8 GB RAM for the platform, 2 cores, 8 GB RAM and 16 GB SSD for Elasticsearch or OpenSearch, and at least one platform node for every 3 workers. Ask for an inventory of playbooks, integrations and daily indicator volume before anyone quotes the work.
What skills does the team need for this migration?
Three roles carry most of the work, and one person can hold more than one. Threat intelligence analysts own the data model: which feeds matter, how indicators are scored and expired, and which sharing groups and taxonomies apply. Integration engineers own the connections: Shuffle workflows that call your SIEM, EDR and ticketing APIs, and OpenCTI or MISP connectors for each feed. A platform owner runs the stack after go-live, covering upgrades, backups, access control and the choice of OpenCTI release line. That choice sits between regular releases and LTS releases, which need a specific license key. Name the platform owner before the project starts, because automation without a clear owner tends to drift out of date.
How long does a replacement take for our scope?
The duration depends on the scope you agree, and no single timeline fits every estate. A small set of feeds and a few actions is a different project from a full playbook catalog wired into several SIEM, EDR and ticketing tools. Time goes into confirming the data model, standing up the platforms, rebuilding each playbook and action, and running old and new automation side by side until results match. Parallel running is where teams most often underestimate effort, so plan for it explicitly. DeployOpen works to a fixed scope, with deliverables and timelines agreed in writing before work starts, and it issues a quote from that written scope. Ask any provider, including us, to break its estimate into those phases.
Which licensing costs recur for each open-source piece?
Most of the open-source components carry no license fee, but recurring costs still exist. OpenCTI Community Edition is licensed under Apache 2.0, while the Enterprise Edition uses a proprietary license, so check which edition your playbook design needs. MISP is licensed under AGPL-3.0, and its taxonomies and galaxy data use CC0 1.0 or the 2-clause BSD license. Shuffle's code is licensed under AGPL-3.0, and its paid tiers differ in limits, scaling and support. Recurring costs are therefore infrastructure, staff time, any paid support or retainer, and any license key or subscription your chosen tier requires. Ask each vendor in writing which costs recur and which ones depend on usage.
Do Shuffle app runs or OpenCTI Enterprise features change the total?
Yes, both can change the total, so confirm them before you compare with TDR Orchestrator. Shuffle prices its paid 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. Shuffle states that all features are available in the open-source edition, with paid tiers differing in limits, scaling and support. For OpenCTI, playbooks are part of the Enterprise Edition feature set alongside audit logs, organization-based segregation and SSO, so a design built on playbooks may need that edition. Review the OpenCTI Enterprise Edition documentation and request the license terms in writing.
Can the new stack use our existing single sign-on?
Usually yes, but confirm the protocol and the edition for each component. Shuffle added SAML single sign-on in version 0.9.16 and OpenID Connect in 1.0.0, available on premises and in the cloud, with per-tenant enforcement. SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect, so new integrations should start with OpenID Connect. MISP provides an OidcAuth plugin for OpenID Connect. OpenCTI lists OpenID, LDAP, SAML, certificate and header authentication among its Enterprise Edition features. Map which users need which roles in each tool, and test a disabled account in every system, not only in the identity provider.
What happens if we lose the Shuffle encryption secret?
Every saved app authentication breaks, and automation stops until credentials are re-entered. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256, using the SHUFFLE_ENCRYPTION_MODIFIER secret. The Shuffle configuration docs warn that losing or changing that value breaks all saved app authentications. Store it in your secrets manager, back it up with the rest of the stack, and record it in your change process before any workflow goes live. Test a restore in a non-production environment to confirm the secret and the data still match. Run more than one Orborus node as well, so workflows keep running if one fails.
What the open-source stack costs to own and run
The main cost of this stack is the infrastructure and people that run it, not the software licenses. Each component has its own footprint. For OpenCTI, the documented sizing gives the platform 2 cores and at least 8 GB RAM, Elasticsearch or OpenSearch 2 cores, 8 GB RAM and 16 GB SSD, and at least one platform node for every 3 workers, according to the OpenCTI deployment overview. Redis, RabbitMQ and S3-compatible storage such as MinIO sit alongside these, and each needs its own sizing, backup and patching. Shuffle adds its own OpenSearch document database, a backend and frontend, and Orborus nodes. Its high availability guidance calls for an OpenSearch cluster, shared files over NFS when several backends run, and more than one Orborus node, so the Shuffle footprint roughly doubles when HA is required. MISP runs on a single server or as a Docker, Ansible or Puppet deployment. Confirm each sizing figure against your own feed volume and retention, since the documented numbers are starting points, not a capacity plan.
Separate the one-time build from recurring operations when you compare quotes. The build covers architecture, installing and hardening each platform, writing and testing connectors and Shuffle workflows, integrating SIEM, EDR and ticketing actions, configuring SSO and backups, and documenting the result. Recurring costs are cloud or data center capacity, licenses for any Enterprise Edition features you need (OpenCTI Enterprise Edition is proprietary, and LTS releases require a license key under the OpenCTI product life cycle), staff time to upgrade and maintain connectors and playbooks, and retainer support if you buy it. Shuffle licenses its paid tiers on app runs, so ask whether your automation volume would move you off the open-source edition. Staff time is usually the largest recurring line, so ask who owns connector maintenance after handover.
Risks to plan for in automation replacement
Replacing intelligence-driven automation with separate open-source components moves logic, licensing and secrets into your own hands. The cards below cover the places where a migration can silently lose capability or stop working, with the check to run for each.
Lost scoring logic
Scoring and decay rules in a commercial platform often live in configuration that nobody documents. OpenCTI and MISP score and rank indicators differently, so a playbook that escalated on a ThreatQ score may not trigger on the same condition. Export the current scoring thresholds and test them against a sample of known indicators before cutover. Confirm with your analysts which scores drive SIEM blocks and which only drive reports.
Unnoticed gaps in action coverage
Each commercial automation action maps to a specific Shuffle app or a custom workflow step, and some may have no equivalent. A gap shows up only when an alert needs that action at 2 a.m. Build an inventory of every existing trigger and action, mark each as covered, partial or missing, and run a test workflow for each covered item against a staging SIEM, EDR and ticketing instance.
Shuffle edition limits enforced
Shuffle states that all features are available in the open-source edition, but its paid tiers differ in feature limits, scaling and support, and since v2.1.1 those limits are actively enforced. Pricing counts app runs, so a high-volume enrichment workflow can reach limits that a low-volume test never does. Before committing, confirm with Shuffle which limits apply to your planned workflow volume and whether your self-hosted deployment is affected.
OpenCTI LTS license requirement
OpenCTI LTS releases are distributed as container images, but they require a specific LTS license key to run. After a one-month stabilization period, an LTS line receives only critical bug and security fixes. If your change process requires LTS, budget for the license and confirm with Filigran who issues the key, how renewals work and which LTS line is current before you pin a version.
MISP version support
MISP 2.5 is the recommended version for new deployments, and MISP 2.4 is end of life with security fixes only. The project advises against installing new 2.4 instances and provides an upgrade script for Ubuntu. Confirm that your current MISP instance can move to 2.5 without breaking your synchronization partners and PyMISP scripts, and plan the upgrade on your own schedule rather than during an incident.
Credential loss breaks integrations
Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256, using the SHUFFLE_ENCRYPTION_MODIFIER secret. Losing or changing that value breaks every saved app authentication at once. Store the secret in your secrets manager, record it in your backup procedure, and test a restore into a clean environment to confirm that connections to your SIEM, EDR and ticketing tools still authenticate.
How DeployOpen scopes and delivers the module replacement
The sequence moves from a fixed-scope agreement to a documented, tested set of MISP, OpenCTI and Shuffle workflows running in your own infrastructure, with a clear handover and an optional retainer for ongoing support.
Agree a fixed scope in writing
Before any work starts, DeployOpen and your team agree the scope, deliverables and timeline in writing. The scope lists each ThreatQ TDR Orchestrator workflow you rely on, such as feed-driven enrichment, indicator scoring, dissemination to detection tools and ticket creation, and marks which ones move to OpenCTI, which to MISP and which to Shuffle. Your team should ask the quote to separate one-time implementation effort from any recurring retainer. The step is done when both parties sign off the workflow inventory and the list of in-scope systems.
Map current workflows and data flows
DeployOpen works with your analysts and the owners of each SIEM, EDR and ticketing system to document how indicators move today: which feeds are ingested, what enrichment runs, which scores or thresholds trigger an action, and which credentials each integration uses. Gaps in the current automation, such as steps that exist only in an analyst's habits, are recorded so they are not lost during the move. The step is complete when every workflow has a documented trigger, input, output and owner.
Build the platforms inside your infrastructure
DeployOpen deploys MISP, OpenCTI and Shuffle in the cloud accounts, data centers or air-gapped networks you specify. For OpenCTI, this covers the platform, workers, connectors and the Elasticsearch or OpenSearch, Redis, RabbitMQ and MinIO dependencies. For Shuffle, it covers the server, Orborus runtime nodes and the encryption secret handling. Your team confirms the chosen deployment architecture and the OpenCTI release line, including whether you need an LTS license key. The step is done when each platform starts cleanly, the sizing matches the documented minimums, and access is limited to named roles.
Rebuild enrichment, sharing and playbooks
DeployOpen configures the MISP and OpenCTI connectors and feeds, recreates the enrichment and dissemination logic, and sets distribution levels and sharing groups so that data reaches only the intended recipients. Shuffle workflows are built to execute the actions, such as pushing indicators to the SIEM or opening tickets. Where a feature depends on an OpenCTI Enterprise Edition capability, such as playbooks, the scope states that dependency and the license your team must hold. The step is complete when each workflow runs against sample data and produces the expected output.
Test integrations with SIEM, EDR and ticketing
DeployOpen tests each connection end to end: indicator export to SIEM and EDR tools, enrichment responses, and ticket creation and updates in your ticketing system. Tests use agreed test indicators and non-production targets first, then a controlled production check. Failures are logged with the workflow, the app version and the error, and are fixed or escalated before go-live. The step is done when your team signs off a test record showing each integration passing and the rollback path confirmed.
Harden, back up and document the platform
DeployOpen applies the hardening in the agreed scope, which typically covers SSO configuration, role separation, network restrictions and secret handling. The Shuffle encryption secret is stored and backed up under controlled access, because losing or changing it breaks saved app authentications. Backup, restore and upgrade procedures are written and tested, and runbooks describe each workflow. The deliverables include configuration records and evidence that supports your compliance team, though DeployOpen does not issue audit reports or certifications. The step is complete when a restore test has been run and the documentation is accepted.
Hand over and support with a retainer
DeployOpen runs a handover session with your operations and analyst teams, covering daily use, the runbooks and the escalation path. After handover, ongoing support, upgrades and continuous testing can be contracted as a retainer, which covers release tracking for MISP, OpenCTI and Shuffle and the connector maintenance that keeps integrations working. Your team should ask the quote to state what the retainer includes and what remains with internal staff. The step is done when your team has accepted the handover and the retainer scope, if chosen, is signed.
