Security automation after a merger

Security automation after a merger: why integration is different

After an acquisition closes, the job is to connect the two security stacks, deduplicate triage and set a dated path for retiring duplicate tools, while the legal entity boundary, data location and reporting duties still apply to each company separately. Shuffle works well as the automation layer during that period: it can receive alerts from the acquired company's existing SIEM or endpoint tools, run one shared triage playbook against both estates, and open tickets in whichever case system the integration plan keeps. The existing SIEM, identity provider and case tools are then kept or replaced according to that plan, not according to which vendor happens to be newer. Before any connector is built, confirm which alert sources exist on each side, which identity provider issues accounts for the acquired staff, and which case tool is the system of record for incidents that may be reported to a regulator.

Integration is harder than a greenfield build because the acquired company usually has its own tenants, credentials and approval chains that have not yet been reconciled. Credentials for the acquired company's tools should be stored in Shuffle under a separate tenant or workflow scope, with the encryption secret handled under the same change control as any other production secret, since the Shuffle documentation warns that losing or changing SHUFFLE_ENCRYPTION_MODIFIER breaks every saved app authentication. Map who may approve destructive response actions on each side before the first shared playbook goes live. Where the acquirer's staff need to view the target's alert data, check the data location rules with counsel first. If EU personal data is involved, remote access from a non-EEA acquirer is itself a transfer under EDPB Guidelines 05/2021, so the access model must be designed before anyone is granted it.

Reporting duties often change during integration in ways that automation must reflect. A newly acquired business may be excluded from the acquirer's internal control assessment for a limited period, but the exclusion must be disclosed, so the evidence trail for the acquired estate needs to stay intact while its tools are still running. For regulated entities, retiring a duplicate ticketing system should wait until open incidents, retention obligations and the timelines in each applicable regime are mapped to the replacement. Ask any implementation partner to deliver a dated retirement plan for each duplicate tool, with the playbooks that depend on it listed and a rollback path documented, so the decommissioning does not remove the record that a notification deadline was met.

Which obligations shape the merger playbooks

This table maps each supplied regulatory obligation to the SOAR build decision it affects during integration: where the automation runs, who can see acquired-company data, and what evidence the playbooks must produce. Read each row as a design constraint to settle before the first shared playbook is switched on. The main takeaway is that the regulator's clock and data-access rules usually fix the architecture before the playbook logic is written.

Obligation	What it asks for	Build decision for the SOAR	Evidence the automation must produce
SEC ICFR scope exclusion	Management may exclude a newly acquired business from its internal control assessment for up to one year, and must disclose the exclusion	Keep acquired-company IT general control logic separate from the parent until it is brought into scope, so access and change records stay attributable by entity	Per-entity logs of who ran which automated action, and when the acquired tools were first connected
SEC Item 1.05 incident disclosure	A material cybersecurity incident is disclosed on Form 8-K, generally within four business days after materiality is determined	Route acquired-company alerts into the same case record with a materiality decision step that a named person approves	Timestamps for detection, escalation and materiality decision that can be reconstructed from the case record
SEC IT general controls	Program changes and access to programs and data are the areas management tests when they affect financial reporting	Version playbooks and connectors under change control, and limit who can edit production workflows	Change tickets linked to workflow versions, and access reviews for SOAR administrators
NIS2 change notification	Entities notify the competent authority of changes to their details and IP ranges without delay, and within two weeks at most	Update asset and IP range inventories in the SOAR when the acquired network joins, and tie the update to the notification task	Dated record of inventory changes and of the notification that followed
DORA register and exit strategy	Financial entities keep a register of ICT service arrangements and tested exit and transition plans for critical functions	Document each acquired-company SaaS connector as an ICT service in the register, and keep a playbook path that can be switched off or moved	Register entries for SOAR-connected services and a recorded test of the transition steps
GDPR Article 28 and EDPB remote access	Processors act only on documented instructions, and remote access from a third country to EU personal data is a transfer	Block acquirer staff outside the EEA from opening EU case data or connector credentials unless a Chapter V transfer tool covers it	Role mapping that shows who could view EU personal data in cases, and the transfer basis on file
HIPAA business associate terms	Business associate contracts must require Security Rule compliance, flow terms to subcontractors and report incidents to the covered entity	Keep ePHI-bearing playbooks and their enrichment connectors inside the covered entity's environment, with subcontractor hosts listed	Contract clauses mapped to each connector that touches ePHI, and incident notices sent to the covered entity
FTC Safeguards MFA and logging	Covered financial institutions require MFA for any individual accessing an information system and must log and monitor authorized user activity	Require SSO with MFA for every SOAR and case tool login from the acquired company, and log admin and analyst actions in one place	Login records showing MFA use, and an activity log of user actions in SOAR and case management

Which platforms fit a merged security estate

A merger rarely leaves two identical stacks. The platforms below cover the four layers that usually need stitching together: orchestration, alert sources, shared threat intelligence and identity. Licenses matter as much as features, because the acquired company's contracts and the combined entity's obligations may differ.

Shuffle as the orchestration layer

Shuffle is a SOAR platform that can sit above both estates and run one set of triage and enrichment playbooks against alerts from either side. It is licensed under AGPL-3.0, which carries source-disclosure duties if you modify and expose the software over a network, so confirm that with counsel before customizing it. Check whether the acquired company already runs a SOAR and how its connectors and credentials will be migrated.

Wazuh as an alert source

Wazuh provides SIEM and XDR capabilities and can be a natural alert source if the acquired company already runs agents on its endpoints and servers. Its core repository is licensed under GPL version 2, so review how it will be deployed and distributed across the two entities. Confirm agent coverage, log retention and whether alerts can be forwarded to the orchestration layer without duplicating ticket creation.

Security Onion as an alert source

Security Onion suits an acquired company that monitors network traffic with Suricata and Zeek and needs a hunting and log management console. It is licensed under the Elastic License 2.0, which has usage restrictions that differ from GPL or AGPL, so confirm that the intended use is permitted. Check sensor placement at the acquired site and whether its alerts map cleanly into the shared triage playbooks.

MISP or OpenCTI for shared indicators

MISP and OpenCTI both hold indicators, campaigns and sharing rules, and they let the combined entity decide which intelligence the two former companies may exchange. MISP is licensed under AGPL-3.0, while OpenCTI's Community Edition uses Apache License 2.0 and its Enterprise Edition falls under a separate license. Map which feeds and sharing agreements each entity already has, because those agreements may not transfer automatically at close.

Keycloak for identity federation

Keycloak supports OpenID Connect, SAML 2.0, and LDAP and Active Directory user federation, which makes it a common choice for federating two directories during a transition. It is licensed under Apache-2.0 and is a Cloud Native Computing Foundation incubation project. Confirm how it will map accounts across the two directories and how it will handle users who appear in both.

authentik, ZITADEL or midPoint for account mapping

authentik, ZITADEL and midPoint each address part of the transition: authentik and ZITADEL for brokering login across directories, and midPoint for identity governance and account correlation. authentik is MIT licensed except its enterprise directory, ZITADEL is AGPL-3.0, and midPoint uses the European Union Public License 1.2 or later. Choose based on whether you need login brokering, lifecycle governance or both, and confirm which directories each one must reach.

How Shuffle connects two stacks without moving data across entities

The core decision in a post-merger SOAR design is where the workers run, because that determines which alert data has to leave which entity. Shuffle separates the control plane from the execution plane. The frontend and the Go backend API on port 5001 hold workflow definitions, cases and results, with an OpenSearch document database behind them. Orborus is the runtime component: it polls the backend for jobs, starts a worker for each workflow execution, and the worker starts the app containers that call your tools. Shuffle's architecture documentation lists a hybrid option in which Shuffle Cloud coordinates a local Orborus that needs no inbound firewall ports. For an acquisition, that means an Orborus node can sit inside the acquired company's network and reach out to its SIEM, EDR and ticketing APIs, while the central record lives where your governance team wants it. Confirm with Shuffle which hybrid option matches your licensing and hosting terms before you design around it, and have your security architects confirm where alert payloads will be stored between the two sides.

Two controls in the same design deserve attention before any connector goes live. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret, and the configuration documentation warns that losing or changing that value breaks every saved app authentication. In a merger, that secret is effectively a key handed between two companies, so it should be generated and stored in the acquiring company's secrets manager, shared only with the named operators who need it during cutover, and rotated after the handover is complete. Plan a documented restore test for the OpenSearch data and the modifier together, since either one alone cannot recover the credentials. Also decide, with legal counsel, who holds the Shuffle administrator role for each entity, because in the first months both companies' staff may need access to the same workflows while the target's identity provider is still being connected.

Deployment choices when the acquired company stays on its own network

The target keeps its own network, identity provider and tools for the whole integration period, and the acquirer runs a separate Shuffle deployment that reaches into the target only through agreed paths. Data stays in the target's environment, and the acquirer receives only the alert fields and case records that its playbooks need. This is the most conservative choice when the target's regulator, customer contracts or data transfer rules limit who can see its logs.

Data location: Alerts and evidence remain in the target's cloud accounts or data centers, with only summarized results sent to the acquirer's Shuffle.
Staff access: Acquirer analysts work through a documented break-glass or delegated role, and each access is logged in the target's audit trail.
SSO: The acquirer's Shuffle uses OpenID Connect against its own identity provider, and target users are not added to it.
High availability: Run more than one Orborus node on the side that executes actions, so a single node failure does not stop workflows.
Credentials: Keep app credentials for target tools in the target's environment and rotate the encryption secret on a documented schedule.

Confirm with legal counsel which target data may leave its boundary and whether a Chapter V transfer tool is needed for any EU personal data accessed from outside the EEA.

Both companies use one Shuffle server, with tenants or workflow ownership separated so each side sees only its own apps, workflows and execution history. This reduces the number of platforms to operate during integration and lets the teams share one library of triage playbooks. The trade-off is that every tenant depends on the same server, database and worker pool, so access boundaries and change control must be designed before data is connected.

Data location: Both companies' execution records sit in one OpenSearch cluster, so the hosting location must satisfy the stricter of the two data rules.
Staff access: Assign roles per tenant and confirm that a target analyst cannot open acquirer workflows or the reverse.
SSO: Shuffle supports OpenID Connect with per-tenant SSO enforcement, so each side can keep its own identity provider.
High availability: The Shuffle docs recommend an OpenSearch cluster, a shared cache, NFS for shared files when several backends run, and more than one Orborus node.
Encryption: Saved credentials for both companies are protected by one SHUFFLE_ENCRYPTION_MODIFIER value, so the secret must be stored and backed up under strict control.

Ask the implementation partner to show how tenant separation is tested before any target tool is connected.

Phased rollout for stitching triage together

The sequence moves from an inventory of both estates to a retired duplicate ticketing queue, with a written output at each phase so that no alert source or data flow changes without an agreed record. It keeps the acquired company's alerts visible throughout and gives the integration a rollback path at cutover.

Inventory both estates and their sources
Your team and the acquired company's security engineers list every alert source, ticketing queue, identity directory, SIEM or EDR tool, threat intelligence feed and on-call route in both environments. Record the owner, data classification, network path and any connector or API each one exposes. The output is a source register that both security leads sign off, and the step is done when every alert source has a named owner and a known way to reach it from the Shuffle environment.
Agree the legal and data boundary
Counsel, the privacy office and both security leads confirm which personal data, customer records and regulated logs may move between the two companies, and under what written instructions. Where an acquirer's staff may remotely access systems holding EU personal data from outside the EEA, confirm the transfer mechanism before any integration work starts. Also confirm which regulator notification duties apply to each entity and who must be told of changes. The output is a signed boundary memo and a list of controller instructions, and the step is done when every data flow in the register is marked allowed, restricted or blocked.
Build shared playbooks in a test workflow
Engineers build the common triage and enrichment playbooks, such as phishing triage, impossible travel checks and malware hash lookups, in a separate Shuffle test instance that holds no production credentials. Each playbook is tested against replayed or sample alerts from both estates, and any action that changes state, such as disabling an account, requires an approval step. The output is a tested playbook set with recorded test results, and the step is done when the owners of both estates have reviewed the outcomes and accepted them.
Route acquired alerts in parallel
Connect the acquired company's tools to the new queue while their existing ticketing and monitoring continue to run, so analysts on both sides see the same alerts for an agreed period. Compare the case records, enrichment results and response times between the two paths and log every mismatch. The output is a routing record that lists each alert source, its destination queue and the date its parallel run began, and the step is done when the mismatch log shows no open items that affect triage decisions.
Cut over with a rollback path
Switch each alert source to the new queue one group at a time, starting with the lowest-risk sources, and keep the old routing in a documented state that can be restored quickly. Confirm that Shuffle's stored app credentials were migrated with the encryption secret handled under change control, since losing or changing that secret breaks every saved app authentication. The output is a cutover log and a tested rollback procedure, and the step is done when a rollback has been rehearsed and each source has been confirmed in the new queue for the agreed observation window.
Retire duplicate ticketing with an exit plan
Once the new queue has carried live alerts for the agreed period, plan the retirement of the duplicate ticketing system. Export case history and evidence the retention schedule requires, move open cases to the surviving queue, and confirm that no integration still writes to the old system. The output is a retirement checklist covering data export, retention, access removal and decommissioning, and the step is done when the owner of each retained record has confirmed where it now lives and the old system is switched to read-only.

Evidence auditors and regulators will ask for

This table lists the evidence a reviewer is likely to request when two security stacks are joined through SOAR during an acquisition, which component produces each item, and what to confirm before the evidence is needed. DeployOpen prepares the records and controls, but independent auditors, regulators and certification bodies issue any audit report or attestation. Read each row as a question to answer in advance rather than a finished file.

Evidence item	Produced by	What the reviewer checks
ICFR scope exclusion record for the acquired business	Finance and compliance team, with IT input on systems in scope	Disclosure of the excluded business and its significance, and that the exclusion stays within the permitted period and reporting cycles
Register of ICT service arrangements	Third-party risk owner, populated from procurement and contract records	Acquired tools, SaaS ticketing and SOAR integrations listed as arrangements, with the acquired entity included at the right consolidation level
Playbook change history for shared triage playbooks	Shuffle workflow version history and the change ticket that approved each edit	Who changed each playbook, when, why, and whether the change was tested before it ran in production
Shuffle execution logs for automated actions	Shuffle backend and OpenSearch execution records for each workflow run	Each automated containment or enrichment action traceable to a workflow, input alert and operator approval where one is required
Access review for SSO users from the acquired company	Identity provider (for example Keycloak or midPoint) reports and the reviewer's signed attestation	Acquired users mapped to unique identities, MFA enforced, and stale or duplicate accounts removed after the cutover
Credential and secret inventory for connected tools	Shuffle app credential store and the secrets manager that holds encryption keys	Saved app credentials for acquired tools are encrypted, key custody is documented, and rotation after transfer is recorded
Exit plan and retirement record for the old ticketing tool	Project owner, with the ticketing administrator and the data export log	Open cases migrated or closed, retention data exported, and the date access to the retired tool was removed
Cross-border access approval for acquirer staff	Privacy office and legal, with access logs from the target systems	Whether remote access by staff outside the EEA to EU personal data was covered by an approved transfer tool before access began

Questions to ask an implementation partner before the merger work starts

Ask first how the partner will inventory both estates before any playbook is written. The inventory should list every alert source in the acquired company (EDR, identity provider, cloud logs, email security, ticketing), who owns each one, the data it sends and whether the acquirer's SOC already receives it. Ask for the inventory format and who signs it off. Ask how the partner will record credentials for the acquired company's tools: the Shuffle app credentials are encrypted in OpenSearch with the SHUFFLE_ENCRYPTION_MODIFIER secret, so ask where that secret is stored, who holds it, and what happens to saved app authentications if it is lost or changed. Also ask whether service accounts for the target's tools will be scoped per playbook and rotated under a documented procedure.

Ask how playbooks will be tested before cutover, and whether the test plan runs against replayed or synthetic alerts from the acquired estate, not only the acquirer's. Ask who approves each destructive action, such as host isolation or account disablement, and whether approval steps are built into the workflow. Ask how data will stay inside the agreed boundary. If the acquired company is in the EU, ask how the partner will prevent staff in a non-EEA acquirer from viewing personal data from the target's systems without a Chapter V transfer tool under EDPB Guidelines 05/2021, and how the GDPR Article 28(3)(a) instructions are documented. Confirm the target's regulatory obligations (for example NIS2 contact notices or HIPAA business associate terms) before the partner designs any data flow.

Ask how worker placement and run limits will be planned for the combined alert volume. The Shuffle docs describe the Orborus runtime and recommend more than one Orborus node for resilience, so ask where workers will run in each network segment, whether the hybrid model with no inbound firewall ports is acceptable, and how app-run counts are forecast from the playbooks before go-live. Ask how the old ticketing tool will be exited: the cutover order, how open tickets are migrated or closed, how historical records are retained, and how the exit is documented. Finally, ask whether the engagement is fixed-scope, with deliverables, acceptance criteria and a named owner for each acceptance test written into the agreement, and what is excluded from the fixed scope, such as later connector changes.

What do teams ask about merger security automation?

How much effort does stitching two security stacks together with SOAR take?

Effort depends mainly on how many source tools feed alerts into the acquirer's automation, how many playbooks are in scope, and how cleanly the two identity directories map to each other. A target running one SIEM and one ticketing tool is a very different job from one running several EDR consoles, a cloud provider and two case systems. Ask any partner to split the estimate into connector work, playbook work, identity mapping and testing, so you can see which line moves when your scope changes. No effort figure is given here because it depends on the environment, and a written scope should set it.

What does Shuffle licensing cost after a merger?

Shuffle's open-source edition includes all features, and its paid tiers differ in feature limits, scaling and support. The commercial licensing is priced on app runs, which the Shuffle pricing article defines as actions that actually execute in a workflow, while triggers and skipped actions are not counted, and users, apps and workflows are unlimited. Merged alert volume is the main driver, so a combined SOC can see run counts rise quickly. Ask for a run forecast from your alert volumes before choosing a tier, and confirm the current price with Shuffle directly.

Which costs are one-time and which recur after the integration?

One-time costs usually cover discovery, connector and app building, playbook development, identity mapping and testing. Recurring costs include the infrastructure that runs Shuffle and its workers, the OpenSearch backend and any high availability components, licensing for the chosen Shuffle tier, and the upkeep of connectors when the source tools change their APIs. Who is paid for each line matters: internal staff time, a partner's fixed-scope work, and your cloud or data center bill are separate budgets. Ask for the quote to list each item with its owner and whether it recurs.

How long does it take to merge two SOAR and alert workflows?

No duration is fixed here, because the timeline depends on scope, the number of source tools, the change approval cycle and how many playbooks must be proven before cutover. A practical sequence is to first route the acquired company's alerts into a shared triage playbook, then move enrichment and response actions, and only then retire duplicate ticketing. Acquisition rules matter too: SEC staff guidance allows management to exclude a newly acquired business from its internal control assessment for a limited period, so finance and audit teams often set a deadline that the security team must work back from. Ask any partner for a phased schedule tied to written milestones.

What does our team need to provide during the integration?

Expect to provide read access to the acquired company's tools, service accounts or API credentials with scoped permissions, and named data owners who can confirm which logs and alert fields are sensitive. Your change board must approve each automated response action, especially anything that isolates hosts or disables accounts, and your legal or privacy team should confirm what data moves across entities. If the target is in the EU, transfers and remote access by staff from outside the EEA may need a transfer tool under GDPR Chapter V, so involve counsel early. Agree these inputs in the written scope so delays do not become hidden schedule risk.

Can our own security engineers build this without an implementation partner?

Yes, if your team already runs Shuffle or similar automation, has capacity for connector work, and can own testing and change control. The open-source platform is available without a license fee, but the build work is the expensive part and it recurs as vendor APIs change. A partner is useful when the merger adds several unfamiliar tools at once, when you need the work finished against a fixed date, or when the internal team is already busy with the integration itself. DeployOpen plans, implements, integrates, hardens and documents self-hosted platforms in the client's own infrastructure under fixed-scope agreements, and ongoing support is available as a retainer.

Where should Shuffle run and how are the target's credentials protected?

Shuffle documents four deployment patterns, including a single server with Docker Compose, Docker Swarm, a hybrid with Shuffle Cloud and a local Orborus that needs no inbound firewall ports, and Kubernetes with Helm charts. For a merger, a hybrid or on-premises worker in the target's network often avoids opening new inbound paths while the two networks are still separate. Saved app credentials are encrypted with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret, and losing or changing that value breaks every saved app authentication, so back it up in your secrets store. Confirm the exact network and key handling with your partner before the first connector goes live.

How DeployOpen scopes and runs merger security integration

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a merger, that means connecting the acquired company's alert sources and ticketing to Shuffle playbooks in your environment, with each step agreed in writing before work starts.

How we scope

Inventory alert sources, ticketing tools and identity providers on both sides of the merger before naming any playbook.
Agree in writing which triage and response playbooks are in the first phase and which wait for a later phase.
Record who may approve destructive actions, and which data stays within each entity's own environment during integration.
Confirm with your counsel and compliance leads which regulatory notifications, if any, the new playbooks must support.

How we build

Deploy Shuffle in the client's cloud account, data center or air-gapped network, using the architecture the scope agrees.
Build connectors for the acquired company's SIEM, EDR and ticketing tools as Shuffle apps, with credentials stored encrypted in the platform.
Test each workflow against sample alerts in a non-production environment before any action can change a live system.
Set run limits, worker counts and approval gates so routing changes can be rolled back without disrupting the parent company's queues.

How we hand over

Document each playbook with its trigger, inputs, approvals, actions and the owner who maintains it after handover.
Provide a phase-out plan for duplicate ticketing, listing which queues move, which close and the order of cutover.
Run a walkthrough with the security operations team so they can change playbooks and rotate integration credentials themselves.
Deliver an audit trail of automated actions and configuration records that your auditors can sample during integration reviews.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope phase ends.
Keep Shuffle and its connectors current as the parent and acquired tools change versions or APIs during integration.
Repeat security testing of the integrated workflows and connected systems as the two stacks converge.

Security automation after a merger