Why consolidating SIEMs after a merger is a different job
This is consolidation under evidence obligations, not a fresh SIEM build. The short answer for most buyers is to extend the platform they already run, often a Wazuh or OpenSearch-based stack, bring the acquired business onto it, and retire the target's tool only after the new controls are proven. The first question is not which product is best but which tool the parent already operates well enough to take on another estate, and whether its licenses and support terms allow that growth. Confirm both before anyone plans a migration.
The timing pressure comes from two directions. For US registrants, SEC staff allow management to exclude a newly acquired business from its assessment of internal control over financial reporting, but only for a limited window and not beyond one year from the acquisition date. The excluded business and its significance must still be disclosed, so the parent needs to show that monitoring and IT general controls around that business are working inside that window. Meanwhile the acquired environment must stay monitored from the first day, whether or not its detection content has been reviewed. Ask legal and finance which exclusion period applies to your deal and which systems the auditors expect to see covered by the target's logs. The practical consequence is that you need a bridge: interim forwarding of the target's logs and alerts into the parent's platform, documented as a temporary control, while agents and log sources are onboarded in stages. Inventory the target's SIEM contract, its retention commitments and any export or deletion terms, because those determine whether historical logs can move and what must be preserved for investigations already open. Confirm these terms with the target's vendor and its legal team before the close date is fixed.
Which regulatory obligations shape the consolidation
This table maps each regulatory obligation that can apply during a SIEM consolidation to what it means for the build: log source coverage, access design, retention continuity and cutover documentation. Read each row against the regimes your group, the acquired company and its customers are subject to, because many of these rules apply only to specific entities. The main takeaway is that the acquired company's logs and access paths must remain provable throughout the transition, not only after it.
| Obligation | What it asks for | What it means for the build |
|---|---|---|
| SEC ICFR exclusion and ITGC evidence (Release 33-8810) | Management may exclude a newly acquired business from its ICFR assessment for up to one year, and must disclose the exclusion. IT general control areas include access to programs and data and computer operations. | Confirm which acquired systems feed financial reporting. Keep access logs and change records for those systems in the consolidated SIEM so controls can be evidenced at the first year-end assessment. |
| SEC Item 1.05 incident reporting and third-party oversight | Material cybersecurity incidents are reported on Form 8-K Item 1.05, generally within four business days after materiality is determined. Annual reports describe oversight of third-party service providers. | Alerts from the acquired environment must reach the same triage and escalation path within the group. Record which provider (including any partner running the SIEM) handles incident data and how it is overseen. |
| NIS2 competent authority notification of changes | Entities notify their competent authority of name, contact details, IP ranges, sector and service Member States, and notify changes without delay and in any event within two weeks. | Acquired IP ranges and new service locations change the registered scope. Add the new ranges to detection coverage and to the notification workflow before or at cutover, not at the next review. |
| DORA register of ICT arrangements and tested exit strategies | Financial entities keep a register of all ICT service arrangements. Services supporting critical or important functions need tested exit strategies and transition plans. | Treat the existing SIEM or SaaS tool as an ICT arrangement with an exit plan. Document the migration as a transition plan, and keep the old platform readable until retention and export are verified. |
| HIPAA audit controls and business associate flow-down | Audit controls record and examine activity in systems holding ePHI. Business associate contracts require Security Rule compliance, flow-down to subcontractors and incident reporting to the covered entity. | Where the target holds ePHI, its logs may contain patient data. Restrict analyst access by role, confirm that any partner or hosting provider is covered by a business associate contract, and keep audit records continuous through the move. |
| FTC Safeguards Rule MFA, encryption and activity logging | Covered financial institutions require MFA for any individual accessing any information system, encryption of customer information in transit and at rest, and logging and monitoring of authorized user activity. | Confirm MFA on the consolidated SIEM console and on acquired systems before their logs are centralized. Encrypt forwarding channels and log stores, and verify that user activity from the acquired estate is captured from day one. |
| GDPR processor instructions and Chapter V transfers | Processors act only on the controller's documented instructions, including on transfers. Remote access to EU personal data from a third country is a transfer requiring a Chapter V transfer tool. | If non-EEA acquirer staff can view EU log data, the access is a transfer. Define written instructions, limit access to pseudonymized or EU-hosted views where possible, and document the transfer tool before granting access. |
Which open source platforms fit a merged SIEM
A merger usually leaves two monitoring stacks, two directories and two sets of secrets that must work together for a period before one platform survives. The cards below cover the components most often considered for the consolidated SIEM and for the bridge during transition, with the license and deployment checks to run before committing.
Wazuh as the consolidation target
Wazuh combines agents, a server, an indexer and a dashboard, so one deployment can take agent telemetry from both legacy estates. Agents run on Linux, Windows, macOS, Solaris, AIX and HP-UX, and devices that cannot run an agent can send syslog. Cluster mode and remote agent configuration matter when two teams must manage one fleet. Check which agent versions the acquired company runs, whether its operating systems are on the supported list, and whether the GPL-2.0 license fits your distribution and internal use model with your counsel.
OpenSearch-based network monitoring
Security Onion bundles Suricata, Zeek, osquery and the Elastic stack, which suits an acquired site with sensors but no central monitoring. Its Elastic License 2.0 differs from the Apache-2.0 terms of OpenSearch itself, so confirm with counsel whether your planned use and any hosted service fall within its terms. Check sensor placement at the acquired network edge and whether its log formats can be normalized with the parent's rules.
OpenSearch Security for index-level separation
During a merger, analysts from both companies often need different visibility into the same cluster. OpenSearch Security provides role-based access control, document-level and field-level security, field masking and audit logs, so acquired-company indices can be restricted to named groups. Confirm that role mappings from the acquirer's directory work with SAML, OpenID Connect or LDAP, and that audit logs cover the access paths your regulators will ask about.
Keycloak or authentik for directory federation
Two directories rarely merge on day one, and SIEM analysts need one login path while both remain in service. Keycloak supports LDAP and Active Directory user federation and brokers OpenID Connect and SAML 2.0, so both user stores can sign in to the SIEM dashboard. authentik is MIT-licensed except its enterprise directory, so check which features your deployment uses. Confirm that disabled leavers in the acquired directory are removed from SIEM roles quickly.
OpenBao for moving secrets across environments
Forwarders, API tokens and agent enrollment keys from the acquired company must be re-issued or moved into your control without exposing them in configuration files. OpenBao stores, manages and distributes secrets, certificates and keys under MPL-2.0 and is hosted under the OpenSSF. HashiCorp Vault 1.15.0 and later uses the Business Source License 1.1, which is not an OSI-approved license, so review that choice with procurement. Confirm the migration plan covers rotation of every credential the SIEM uses.
How the consolidation rollout runs, phase by phase
The sequence moves the acquired estate from its own SIEM into the parent's self-hosted platform in controlled stages, with each phase leaving a record that the next one depends on. The end state is one alert pipeline, approved log access, and an evidence package that shows the old tool can be retired.
Inventory the acquired estate and log sources
Your team and the acquired company's IT and security staff list every system that produces security-relevant logs, including endpoints, servers, cloud accounts, identity providers, network devices and SaaS applications. The inventory records the owner, the current collection method, the daily volume where it is known, the retention period and whether the source holds personal data or regulated data. The output is a signed inventory that the SOC and the compliance lead both accept as complete for the agreed scope. Confirm with the target's administrators that no source sits outside the inventory, especially shadow tools and vendor-managed devices.
Map data flows and review cross-border access
Draw a data flow map that shows where each log stream is produced, transported, stored, searched and exported, including any copy held by the old SIEM provider. Legal and privacy counsel then review whether the parent's staff, including staff of a non-EEA acquirer, will see records that contain EU personal data, because remote access from a third country can count as a transfer under EDPB Guidelines 05/2021. Record each approved transfer tool, access grant and processing instruction. Where the target is subject to GDPR Article 28 or 30 obligations, update the records of processing. The output is an approved transfer and access register, and no acquired log source is forwarded until its entry exists.
Run interim forwarding alongside the old SIEM
Configure the acquired log sources to send copies to the parent's self-hosted platform while the existing SIEM keeps operating as the system of record. Forwarding often uses syslog relays or a collector in the target network, so confirm which transport, encryption and source identity controls apply to each path. Compare event counts and sample records between the two tools to find dropped fields, time skew and duplicate events. The output is a documented data flow in production and a list of known gaps with owners. Keep this phase open until the gaps that matter for detection are closed, not until a fixed date.
Onboard agents and parse source logs
Deploy Wazuh agents or agentless collection to the acquired endpoints and servers, using the same configuration management approach the parent already uses where possible. Agentless devices such as firewalls are reached through syslog collection and periodic API probing, which Wazuh supports, so plan those separately. Build or reuse decoders and rules so each source produces fields that the parent's correlation logic can read, and confirm that agent upgrades and remote configuration work on the acquired hosts. The output is a coverage report that lists each source as onboarded, partially parsed or deferred, with the reason for any deferral.
Normalize detection rules and map to parent content
Take the acquired SIEM's detection rules and export them to a common list. For each rule, decide whether the parent already has an equivalent, whether the rule should be rewritten against the parent's field names, or whether it should be retired because the source no longer exists. Keep the mapping to the parent's compliance dashboards where those views apply, such as the framework views the Wazuh dashboard provides for PCI DSS, GDPR, HIPAA and NIST 800-53. Run each rule against replayed or live events from both environments. The output is a parity test report that shows which alerts fire in both tools, which fire in only one, and the approved reason for each difference.
Cut over alert routing and write the runbook
Move alert notification, ticketing and escalation from the acquired tool to the parent platform in a planned change window agreed with the SOC. Keep the old tool's alert routes disabled but recoverable until the cutover is accepted. Document the on-call procedure, triage steps, escalation contacts, severity thresholds and the process for adding new sources. The runbook also covers what happens if the parent platform fails and who may approve a rollback. The output is a signed runbook and a cutover record that names the time of change, the approvers and the verification results.
Export evidence and retire the duplicate tool
Before the old SIEM is shut down, export the logs, alert history, rule versions, audit records and access logs that your retention obligations, legal hold requirements or assessor requests still need. Verify each export by checksum and by a sample search in the new location, and confirm where the exported data is stored and who can read it. Then remove agents from the old tool, revoke its credentials, delete or archive its data according to the retention and deletion rules, and cancel the license or subscription. The output is a decommission record that lists each system retired, the evidence export locations, the checksums, the deletion approvals and the date the old platform stopped receiving data. Ask your partner to confirm how this record will be handled for the auditor.
How to normalize detection rules without losing coverage
Start by inventorying both rule sets before anything is moved. Export the acquired company's detection content from its current tool and list each rule with its trigger logic, log source, severity, alert destination and the business owner who accepted it. Do the same for the surviving Wazuh deployment. Then map each acquired rule to an equivalent in the target platform, mark it as duplicate, adapted or unique, and record the reason. Rules that look identical often differ in field names, time windows or thresholds, so compare logic, not titles. Retire a duplicate only after its mapped equivalent is proven to fire on the same events. Confirm with the acquired SOC which rules are contractual or regulatory obligations, because those need an explicit owner in the new tool even when they duplicate something already present.
Test parity against replayed or known events, not against rule text. Pick a set of recorded events from the acquired environment, including known true positives and a sample of benign activity, then replay them through both tools and compare which alerts fire. Every difference is either a coverage gap to fix or a false positive to tune, and each outcome should be written down. On the Wazuh side, the decoders must extract the same fields the rules depend on, and the rules must reference them correctly. On the OpenSearch side, the index mappings must type those fields consistently across the acquired and target indices, since a field stored as text in one index and as a keyword in another will quietly break a query. Check how timestamps are parsed and time zones are normalized before trusting any comparison.
Keep the change history in a form an auditor can sample. For each rule, store the version, the author, the reviewer, the date of change, the mapped source rule, the replay results and the approval, preferably in version control so that edits leave a trail. Auditors reviewing an acquisition under SEC ICFR guidance, or a security control under a framework, will typically ask who decided a detection was retired and what replaced it. Confirm with your assessor which evidence format they accept and how long the acquired company's records must remain available, since those duties continue after the old SIEM is switched off. Keep the acquired tool's exports read-only until the retention obligation is met.
What buyers ask about merged SIEM consolidation
How long does it take to consolidate two SIEMs after a merger?
The duration depends mainly on how many log sources the acquired company runs, how many detection rules must be rewritten, and how much of its estate can be reached over the network before the systems are integrated. Teams usually sequence the work in phases: interim forwarding first, then agent and source onboarding, then rule normalization, then cutover and retirement. Ask any partner to show the phase plan with the sources in each phase and the dependencies between them. Timing also depends on change windows at the acquired company and on whether its staff remain available during the work. A fixed-scope written plan, agreed before work starts, is the right place to pin these down.
What does SIEM consolidation cost, and what is one-time versus recurring?
The cost has four main parts: engineering time to onboard sources and rewrite detections, storage and compute for the combined ingest, licenses or subscriptions for any paid editions or support, and ongoing operations staff. Engineering effort and migration work are mostly one-time. Storage, compute, support and staff time recur for as long as the combined SIEM runs. Costs rise with daily ingest, the number of sources, retention length and the number of custom rules. Wazuh is distributed under the GNU General Public License version 2, and OpenSearch under the Apache License, Version 2.0, so the software itself carries no license fee for the core products, but you should confirm what any paid edition or vendor support would add. Ask a partner for a quote that separates one-time work from recurring items.
Can our in-house security team consolidate the SIEMs without a partner?
Many teams can, but it depends on whether they have spare capacity and the skills for the specific platforms involved. The work covers agent deployment at scale, parsing and decoding unfamiliar log formats, rewriting correlation rules, testing alerts for false positives and false negatives, and running a cutover while the existing SOC keeps operating. An internal team should check whether it has enough people to do this alongside daily monitoring, and whether it has the experience to validate the result. A partner can carry some or all of that work under a written scope, and internal staff can keep ownership of detection content and runbooks. Either way, the team that runs the SIEM afterwards should be involved from the start.
How do we handle EU personal data in logs when the acquirer is outside the EEA?
Giving staff of a non-EEA acquirer remote access to logs or systems that contain EU personal data is treated as a transfer under EDPB Guidelines 05/2021, even when the access is for support or administration. That means a Chapter V transfer tool is needed before access is granted. The practical options are to keep the EU logs in EU infrastructure and limit remote access to named, controlled roles, to pseudonymize or minimize fields before any cross-border sharing, or to prepare the transfer mechanism in advance. Under GDPR Article 28(3)(a), a processor must act on documented instructions, including on transfers, and records of processing should describe the Article 32 security measures. Confirm these points with your privacy counsel before onboarding any source.
What happens to the acquired company's historical logs during consolidation?
Historical logs are usually kept in the system where they were produced, or exported to read-only archive storage, rather than being re-ingested into the new SIEM in full. The choice depends on what retention the acquired company is obliged to meet, how much data is involved, and whether any regulator or contract requires the logs to be searchable in the combined platform. Decide the archive format, the access controls on the archive, and who may query it before the old tool is switched off. Confirm the retention periods with your compliance lead. If you plan to load historical data into OpenSearch-based storage, check the supported upgrade and index compatibility paths in the OpenSearch documentation first.
How do we prove the cutover to auditors?
Auditors need a documented record that every in-scope source was onboarded, that alerts fire in the consolidated SIEM, and that the old tool stopped receiving logs on an agreed date. Keep the source inventory with owners and onboarding dates, the rule mapping from old to new detections with test results, a change record for each cutover step, and the forwarding configuration before and after. Retain samples of alerts generated during testing and the sign-off for each phase. For SEC registrants, the relevant ICFR scope needs to be evaluated for IT general controls, and an acquired business may be excluded from management's assessment only within the limits the SEC staff describe. Ask your auditor which evidence they will sample before the cutover, not after.
Should we keep the duplicate SIEM running during the audit period?
In most cases, keeping the old SIEM in read-only or limited mode for a defined period is safer than switching it off immediately, because auditors may need to see logs and alerts from before the cutover. The overlap has a cost in storage, licenses and staff time, so it should have an end date tied to the audit scope rather than an open-ended run. Define what the old tool still does during overlap, who can access it, and how its data is preserved when it is retired. Confirm the required overlap period with your auditor and with any regulator that applies to your sector. Decommissioning should follow a documented plan that covers data export, disposal and access removal.
Which evidence auditors request for the cutover
This table maps each piece of cutover evidence an assessor is likely to ask for to the system that produces it and the review record that shows it was checked. Read it as a checklist to agree with your auditors early, since DeployOpen prepares this evidence and independent auditors and certification bodies decide whether it is sufficient.
| Evidence item | Produced by | What the reviewer checks |
|---|---|---|
| Log source inventory for both legacy and merged environments | Wazuh server and indexer agent inventory, plus the change ticket that adds each source | Every in-scope system from the acquired company appears once, with an owner and a date it began sending logs |
| Forwarding configuration history | Version-controlled syslog and agent configuration, with change tickets | Each forwarder change is attributable to an approver and can be rolled back to a known prior state |
| Agent enrollment records | Wazuh server agent list and enrollment logs, reconciled against the asset inventory | Agents on acquired hosts are enrolled under the correct group, and gaps are listed with an exception record |
| Rule change log for normalized detections | Version control history for rules and decoders, with review tickets | Rules ported from the legacy SIEM show who changed them, why, and who approved the change |
| Parity test results | Test records from replayed or simulated events, stored with the ticket that approved cutover | Known test events fire the same alerts in the merged SIEM as in the legacy tool, and differences are documented |
| Access reviews on the merged SIEM | OpenSearch Security audit logs and role mappings, reviewed through the identity governance review workflow | Former acquired-company administrators lost access on schedule, and each role's membership was reviewed by a named owner |
| Retention proof for legacy logs | Archive index or exported storage records, with OpenSearch index lifecycle settings and checksums | Archived logs remain readable for the retention period the applicable rules require, and restore has been tested |
| Decommission record | Change ticket, final export manifest and sign-off from the system owner | The legacy SIEM was stopped only after its data was archived, its access removed, and the decision approved |
What to ask an implementation partner before signing
Start with the inventory. Ask the partner how they will list the acquired estate before any forwarding is built: every host with an agent or syslog source, every firewall, identity provider, cloud account and SaaS application that produces security events, and every alert route that currently ends in the acquired company's tool. Ask who owns each source on the acquirer's side and whether the partner will reconcile that list against the acquired company's asset records and network ranges. Ask for the inventory format and what happens to sources nobody can account for. A partner who cannot describe this step in concrete terms is not ready to estimate the cutover.
Next, ask how cross-border access will be handled before any analyst from the acquiring group logs in to the acquired company's SIEM. Ask whether the partner will check where the acquired company's security logs contain personal data, who will hold administrator and analyst roles during the transition, and whether any remote access from a third country needs a transfer tool under the GDPR. Ask how they will record the decision, and how they will keep the Wazuh or OpenSearch access model separate between the two tenants. For legacy logs, ask how they will keep the archive searchable with the same field names, and whether restored indices can be verified against the source tool before the old tool is switched off.
Finally, ask who writes, tests and signs off the normalized detection rules, and how a Wazuh or OpenSearch upgrade is handled mid-project. Request the rule mapping from each acquired detection to its replacement, with a test record showing the rule fired on replayed events. Ask how the partner will schedule upgrades so that a patch release such as those Wazuh published in the 4.14 line does not interrupt forwarding, and which pinned versions they will freeze during cutover. Then ask how the fixed-scope agreement defines cutover and exit: the written acceptance criteria, the date the acquired tool is set read-only, the export format for its data, and what support continues after go-live and at what level.
How DeployOpen scopes and delivers this consolidation
Who does DeployOpen work for when it consolidates two SIEMs?
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, documents and supports self-hosted open source platforms inside the client's own infrastructure. For a merger, that means the SIEM runs in your cloud accounts, data centers or air-gapped network, not in a DeployOpen-hosted environment. Your team keeps ownership of the platform, the log data and the detection content after handover. The work covers the planning of how the acquired company's logs and alerts move into the surviving platform, the integration with your identity, ticketing and alerting tools, the hardening of the new environment, the runbooks that document it, and the post-go-live support that follows. Ask any partner to state in writing which of these steps it owns and which remain with your staff.
How is the scope of a SIEM consolidation agreed?
Most DeployOpen engagements are fixed-scope, and the scope, deliverables and timelines are agreed in writing before work starts. For a SIEM consolidation, the written scope usually needs to list the log sources and agent counts in the acquired estate, the systems in scope for onboarding, the detection rules to be normalized, the interim forwarding paths, the cutover criteria and the decommissioning steps for the duplicate tool. Scope drifts most often when the acquired estate is not fully inventoried, so the first phase should produce that inventory before any dates are committed. Ask for a written statement of what is excluded, including any acquired systems you will not bring into the platform during the agreement.
How is the cost of consolidating two SIEMs quoted?
DeployOpen does not publish a price list. A quote follows from the written scope, so the inputs that move the number are the count of log sources and endpoints to onboard, the number of distinct log formats and detection rules to normalize, the amount of retained history to migrate or archive, and whether the work runs on existing or new hardware. Cost has a one-time part (inventory, onboarding, rule normalization, cutover and decommissioning) and a recurring part if you add retainers for upgrades, testing and support. Ask each bidder for the same written scope and for the separate price of each phase, so you can compare like with like. Ask what is excluded, such as new hardware, licenses for paid editions and staff time on your side.
Does DeployOpen issue the audit evidence for the merged environment?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. In a consolidation, DeployOpen can document how each acquired log source is onboarded, how alerts are routed, how log retention is configured and how access to the SIEM is restricted, so your assessor has records to sample. Before the engagement starts, confirm with your auditor which evidence they expect for the period in which the two environments run side by side, because that period is often where gaps appear in the record.
What does ongoing support look like after the SIEM goes live?
Ongoing support, upgrades and continuous testing are available as retainers, separate from the fixed-scope consolidation. Once the acquired estate is cut over and the duplicate tool is retired, the recurring work is patching and upgrading the platform, tuning detection rules, reviewing new log sources as the combined business changes, and re-running testing against the detection content. Ask the partner what a retainer covers in writing, including response expectations, which systems it applies to and how upgrades are scheduled. Confirm the response expectations against your own requirements, because DeployOpen's support terms are set out in each agreement rather than assumed from this page.
Can our own team run the consolidation without an outside partner?
Your team can run the consolidation alone if it has the skills to inventory log sources, write parsers, normalize detection content, plan a cutover and operate the platform. Many organizations keep ownership of the platform and detection content in-house and bring in a partner only for the phases where they lack capacity or experience. The main risks of doing it alone are underestimating the acquired estate, running two alerting paths for longer than planned and losing track of which rules still depend on the old tool. Whichever model you choose, write down who owns each phase before work starts, so no log source or detection rule falls between teams.
What should be documented before the duplicate SIEM is retired?
Before retirement, document every log source that still forwards to the duplicate tool, every detection rule and its replacement in the surviving platform, the alert routes and on-call contacts, the retention settings for historical data, and the access lists for both systems. Keep a dated record of cutover decisions so an auditor can see when each source moved. Confirm with your compliance lead which historical logs must remain searchable after the old tool is switched off, and where those logs will be stored. Ask the partner to produce these records as part of the written deliverables rather than as an informal handover.
