Cisco’s Splunk deal and the case for owning your security logs outside the SIEM

The week

On September 21, 2023, Cisco, best known for networking equipment, announced an agreement to acquire Splunk in an all-cash deal valued at about $28 billion. The deal was among the largest in security software.

Cisco offered $157 a share in cash. Both boards had approved the deal unanimously, but it still needed Splunk shareholders and regulators to agree. Cisco expected it to close by the end of the third quarter of calendar 2024 and said Splunk’s chief executive would join its executive leadership team. Its stated rationale was to combine its own security and observability products with Splunk’s data platform, and to move its business further toward recurring software revenue.

Many executives outside the technology function had never heard of Splunk, but their security teams almost certainly had. Splunk was a security information and event management and observability company. A security information and event management system is usually shortened to SIEM and pronounced “sim.” It is the central place where an organization collects the activity records produced by its computers, networks and applications. The SIEM searches those records and connects the dots between them to spot attacks. Observability is the related job of watching those same records to keep systems running smoothly.

Every server, laptop, firewall and cloud service produces a constant stream of logs: brief entries recording who signed in, which file was opened, which connection was refused. On their own they are noise. Gathered in one place and searched intelligently, they become the record that shows what happened and, ideally, raises the alarm while it is still happening.

Splunk was widely deployed in banks, health systems and government agencies as the place where security logs were collected, searched and correlated, and where many security operations centers wrote their detection rules. A security operations center is the team that watches for attacks around the clock; detection rules are the instructions that tell the SIEM which patterns of activity should trigger an alert.

Those rules and searches were written in Splunk’s own Search Processing Language, usually called SPL. Over a decade or more, many large security teams had built libraries of searches, dashboards and alerts in it, along with add-ons that parsed particular log sources. Splunk had also been moving customers from perpetual licenses toward subscriptions and its cloud service. Many contracts were therefore already in transition when the announcement came.

The announcement did not arrive in isolation. It came as other consolidation was under way, including Broadcom’s acquisition of VMware, announced in 2022, which would close that November. VMware’s software runs servers in many corporate data centers, and its customers were already wondering what a new owner would mean for their contracts.

The announcement touched more than one team. Observability buyers, usually IT operations rather than security, often used the same Splunk platform to watch application performance, so in many organizations the news reached two budgets at once. Cisco also sold security products of its own, including firewalls and an extended detection and response service. Splunk customers had to consider how a networking vendor would treat data from competing products.

Logging itself had been in the news that summer. In July, Microsoft disclosed that a China-based group it calls Storm-0558 had used a forged authentication key to reach email accounts, including at U.S. government agencies. A federal agency spotted the intrusion using audit records available only at a higher license tier. Under pressure from CISA and others, Microsoft said it would expand the logging included in its standard cloud tier, with the rollout starting in September 2023. The episode had already shown CISOs that a vendor’s commercial terms can decide which records an organization is able to see.

For federal agencies, the timing had another edge. OMB memorandum M-21-31, issued in August 2021, set four tiers of event-logging maturity. Agencies were expected to reach the most advanced tier within two years, which meant by August 2023. Agencies that had built those capabilities on Splunk heard about its sale a few weeks after that deadline passed.

Cisco said Splunk would strengthen its security and observability portfolio. The transaction needed regulatory approvals and was expected to close in 2024. Nothing changed for Splunk’s customers that week, but the announcement prompted a question most had never needed to answer: if we ever had to leave this platform, what would it actually take?

An acquisition announcement gives customers an option to price their exit, and that applies to any platform. When a supplier you depend on changes hands, the new owner may change prices, products or priorities. You may be perfectly happy to stay. But the announcement is the moment when understanding the cost of leaving is most useful, because it is before anything has changed.

A security information and event management system has a particular kind of lock-in, which the Cisco and Splunk announcement made visible to every CISO who runs one. The license is the smallest part of it. A SIEM holds three things that are hard to move, and together they account for nearly the whole cost of leaving: the retained logs, the detection content, and the integrations that feed and act on it. Each can be taken out of the platform’s exclusive control, at a price, before the next change of owner.

Inside the security control room

A SIEM works much like the control room of a large building’s security system. Cameras, door sensors and alarms all feed into it. Staff watch the screens, a set of rules decides which events deserve a closer look, and recordings are kept in case anyone needs to review an incident later.

In an organization’s computing environment, the cameras and sensors are logs. Small programs called collectors or forwarders sit on servers and other systems and send their logs to the SIEM. Connectors pull logs from cloud services. Parsers read each type of log, which may come in dozens of different layouts, and break it into fields the SIEM can search, such as user name, time and destination.

Once the data arrives, the SIEM indexes it, organizing it so it can be searched quickly without reading every record. Detection rules run continuously against this data. A rule might say: if the same account fails to sign in twenty times and then succeeds from a new country, raise an alert. Analysts in the security operations center investigate the alerts and record what they find in case management records. They may also trigger automated response playbooks, prewritten sequences of steps such as disabling an account or isolating a laptop.

Many SIEMs price their licenses by how much data they take in each day. That matters for what follows: every gigabyte of logs stored inside the SIEM carries a cost, and every rule is written in the platform’s own query language. Over years, the SIEM stops being merely a tool and becomes the home of the organization’s security memory.

Many organizations share the platform between teams. Security uses it for detection and investigation, while IT operations uses the same data to watch application performance and troubleshoot outages. Sharing spreads the license cost, but it also doubles the number of stakeholders in any decision to move. A migration plan has to satisfy both the security operations center and the operations engineers whose dashboards and alerts would also need rebuilding. The budget for the platform is often split in ways that make the true cost hard to see.

How pricing shapes the lock-in

SIEM vendors charge in a few different ways, and each creates a different pull. Ingestion pricing charges by the volume of data taken in each day. It rewards teams for filtering data out, and it makes long retention inside the platform expensive. Workload or compute pricing charges for the searching and processing the customer runs, so storage is cheaper but heavy investigation and many scheduled rules cost more. Per-user or per-asset pricing is predictable, but it can hide the true cost of storage until renewal.

Every model shares one feature. The data the customer has paid to bring in is stored in the vendor’s format, under the vendor’s retention settings, and searched with the vendor’s language. Most SIEMs now offer cheaper storage tiers, and some keep older data in cloud object storage behind the scenes. Those tiers lower the bill. They do not change who can read the data, because the files remain in a layout that only the vendor’s software interprets well.

Licensing terms add a further layer. Some contracts tie the license to a particular deployment, so moving from the vendor’s on-premises software to its cloud service, or back, is itself a negotiation. Multi-year commitments buy discounts but lengthen the period in which a new owner’s decisions bind the customer.

Years of logs the rules say you must keep

Regulated organizations keep security logs because rules and contracts require it. Federal agencies work under OMB memorandum M-21-31 of 2021, which set log retention periods of 12 months in active storage and a further 18 months in cold storage for many log types. Active storage is readily searchable; cold storage is cheaper and slower. Merchants and processors under PCI DSS, the security standard for organizations that handle payment cards, keep a year of audit logs with three months immediately available. Banks and health systems have their own examination expectations, investigation needs and litigation holds, the legal instruction to preserve records once a lawsuit is reasonably anticipated.

Retention rules differ by sector

The obligations are not uniform, and they are often misread. Federal civilian agencies follow M-21-31 and their own records schedules. The memorandum also expects agencies to provide logs to CISA and the FBI on request during an investigation, which makes retrieval speed an obligation as well as a convenience. State and local agencies that handle criminal justice information follow the FBI’s CJIS Security Policy, which requires audit records to be kept for at least one year. Their other records fall under state retention schedules that vary widely.

Financial firms licensed by New York’s Department of Financial Services must keep audit trails designed to detect and respond to cybersecurity events for at least three years under its cybersecurity regulation. Federally chartered banks and credit unions face examination expectations rather than a single numeric rule, so their retention periods usually come from internal policy, investigation needs and counsel’s advice. Broker-dealers keep required books and records under SEC Rule 17a-4. Security logs are not usually among those records, though investigations that touch communications or order data draw on both.

Health systems are a common source of confusion. The HIPAA Security Rule requires audit controls that record activity in systems holding electronic protected health information. Its six-year retention requirement applies to required documentation, such as policies and risk analyses, not explicitly to every log. Many health systems keep access logs for six years anyway, because patient privacy complaints and investigations can reach back that far. The access audit trail of the electronic health record deserves the same care as security logs. It records who looked at which patient’s chart, and it often lives in yet another vendor’s system. Each organization should settle its periods with counsel and write them down, so the architecture can be built to a known target.

When the only searchable copy of that history sits inside a SIEM’s proprietary indexes, the retention obligation turns into a commitment to the vendor. Proprietary here means the data is stored in a format only that vendor’s software reads well. Leaving means either paying two platforms during the overlap or re-ingesting years of data. Suppose a health system that must keep two years of logs decides to switch SIEMs. It either keeps paying the old vendor until the oldest logs age out, or it pulls years of data out of the old format and loads it into the new one, paying again for ingestion. Either way, the regulation has turned into a vendor bill.

The architectural answer is to make the organization’s own storage the system of record. Raw logs land first in object storage the organization controls, in an open format, with retention and immutability set there. Object storage is the inexpensive, very large-scale storage cloud providers offer for files of any kind. An open format is one that many tools can read, so the data is not tied to one product. Immutability means the records cannot be changed or deleted before their retention period ends, which matters for evidence.

The SIEM then reads from that store, holding only the recent, hot data it needs for detection. Retention policy is enforced once, independently of the analytics vendor, and a legal hold applies to the store rather than to a product.

What the organization’s own store must get right

An independent store is only useful if it is built carefully. Logs should be written in a columnar open format such as Apache Parquet, which many query engines can read. They should be organized by date and source so that a search for one week of firewall logs does not scan everything. A shared schema, such as the Open Cybersecurity Schema Framework that a group of vendors launched in 2022, gives the fields consistent names.

Immutability should be enforced by the storage itself. The major cloud providers offer write-once settings: Amazon S3 Object Lock, for example, has a compliance mode in which no user, including the account’s administrators, can delete an object before its retention date. The same feature supports legal holds on specific objects. Encryption keys should belong to the organization, and the accounts that can change retention settings should be few and closely watched, because attackers delete logs to cover their tracks.

The store needs a restore drill like any backup. Once a quarter, a team should retrieve logs from a date at least a year back, query them with a tool other than the SIEM, and record how long it took. A retention rule that can only be met in theory does little for an examiner or a court.

The trade-off is real. A separate store means another system to secure and pay for, and searching cold data may be slower than searching a fully indexed SIEM. For most regulated organizations, a modest storage bill buys the right to change analytics platforms without breaching a retention rule. It also lowers ingestion-based license costs, because only the data needed for live detection flows into the priced tier.

Cloud economics add a caveat. Storage is cheap, but reading data back out can carry query and transfer charges, and those costs arrive during an investigation, when nobody wants to wait for approval. The store should therefore live in the same cloud region as the tools expected to query it, with query costs estimated in advance for a realistic investigation.

Rules written in one vendor’s language

Over years, a security team writes hundreds of correlation searches, alerts, dashboards and reports in the SIEM’s own query language. That content encodes the organization’s threat model, its picture of who might attack it and how, and its regulatory reporting. It is also the main reason migrations take a year or more, because every rule has to be rewritten and re-tested against new data structures.

Rules written only in one vendor’s query language have to be retranslated, one by one, and each checked to confirm it still catches what it used to.

Detection engineering can be run like software. Rules can live in a version-controlled repository, a system that keeps every version of every file along with who changed it and why. Each rule can carry a description of the behavior each one detects, the data sources it needs and the test events that should trigger it. Where practical, rules can be written first in a vendor-neutral format such as Sigma and translated into the platform’s language. Sigma is an openly published way of describing detection rules that can be converted into the query languages of many SIEMs.

A coverage map against a public framework such as MITRE ATT&CK shows which detections matter most. MITRE ATT&CK is a widely used public catalog of the techniques attackers use, organized so that defenders can see which ones they can detect and which they cannot. These steps do not remove migration work, but they turn an archaeological dig into a planned translation with tests.

Why translation is harder than it looks

Rewriting a rule means more than changing its syntax. The field that holds a user name may be called something different on each platform. Rules often depend on lookup tables, saved macros, time windows and joins between data sources that have no direct equivalent elsewhere. Many teams also run risk-based alerting, in which individual rules add points to a user’s or host’s score and an alert fires only when the score crosses a threshold. That scoring logic is rarely documented anywhere except in the platform itself.

Sigma helps most with single-event patterns, such as a particular command line or a known malicious file. Multi-step correlations and scoring logic are harder to express in a portable way, so a realistic aim is to keep the intent portable even where the code is not. Each rule’s record should state, in a sentence, what behavior it looks for and why the threshold is what it is.

Testing closes the gap. A library of sample events that should trigger each rule, stored with the rule, lets a team replay those events on any platform and confirm the alert fires. Open test libraries mapped to MITRE ATT&CK, such as Atomic Red Team, give teams a starting point. Two useful measures follow: the share of rules with a stored test, and the share that passed it at the last run.

Who owns the rules

Ownership varies with the type of organization. A large bank or federal department may have a detection engineering team that writes and maintains its own content. A community bank, credit union or small health system often relies on content packs supplied by the SIEM vendor, or on rules written by a managed security service provider.

That second arrangement creates a less visible form of lock-in. If the provider wrote the rules, the contract may treat them as the provider’s intellectual property, and they leave when the provider does. Smaller organizations should check whether custom detections, tuning and documentation produced for them are deliverables they own. If they are not, the next renewal is the time to change that.

The content also lives in people. In many security operations centers, two or three engineers understand why a rule was tuned the way it was, and a change of vendor often coincides with their departure. Documenting the reasoning behind each tuning decision, in the same repository as the rule, protects the organization against both risks at once. It also helps auditors and examiners, who increasingly ask how an alert threshold was chosen and who approved it.

The plumbing, and the case files

The third part is plumbing. Collectors and forwarders on servers, connectors to cloud services, parsers for each log type, automated response playbooks, and the case management records that document past investigations all tend to be built around one vendor. Each was configured to talk to one platform in its own way, and each would need to be rebuilt or reconfigured to talk to another.

Collection is the hardest of these to change at scale. A large bank or health system may run agents on tens of thousands of servers and laptops, and reinstalling or reconfiguring them requires change windows, testing and coordination with every application owner. Network appliances, building systems and medical devices often send their logs by the older syslog protocol to a fixed address, configured by hand years ago. Agencies with mainframes or legacy case systems face similar constraints. Routing all of this through a relay layer the organization controls means a change of destination happens in one place rather than on every device.

Case records deserve particular care, because they are the evidence of how incidents were handled, and regulators or plaintiffs may ask for them years later. If those records exist only inside a product the organization no longer licenses, producing them could become difficult and expensive at exactly the wrong moment.

The response side of the wiring

Automated response playbooks are tied to the platform in ways that are easy to overlook. A playbook that disables an account, isolates a laptop or opens a ticket calls the interfaces of other systems, using credentials stored in the SIEM or its orchestration module. Moving platforms means rebuilding each integration, re-storing each credential securely and re-testing each action against live systems, often with change approvals for every one.

Case records raise a chain-of-custody question too. An investigation file holds the analyst’s notes, the alerts, the queries run and often attached evidence such as files or screenshots. Exported in a form that preserves timestamps, authorship and attachments, it remains evidence. Exported as a flat summary, it may not satisfy a regulator or a court asking how a decision was reached.

Three practical steps help. Standardize collection on agents or pipelines that can send data to more than one destination, so switching or adding a platform is a configuration change rather than a reinstallation across thousands of servers. Normalize data into a common schema before it reaches the SIEM; a schema is an agreed layout for data, so that “user name” means the same field whatever system the log came from. Export closed case records on a schedule into the organization’s own document store.

Contracts can support the architecture: a right to export all stored data and content in a usable format at any time, at no more than cost; notice of any change of control; and preservation of existing license types and price protections for a defined period after one. These terms cost little to ask for when a contract is signed or renewed, and they are hard to obtain once an acquisition has been announced.

Contract terms, in more detail

Export rights are only useful if they are specific. The contract should define the export format, covering raw logs, parsed fields, rules, dashboards, case records and attachments. It should also set the time the vendor has to deliver an export, a cap on its cost, and a period of termination assistance during which the old platform stays available while the customer moves. A written certification that the vendor has deleted the customer’s data after the move belongs in the same clause.

Change-of-control language can require notice within a set number of days and keep existing license metrics, discounts and support levels for a defined period afterward. Some customers also seek a right to terminate without penalty if a new owner discontinues the product or materially changes its terms. Vendors resist these clauses, and bargaining power depends on size. A large bank may win them; a small credit union buying through a reseller often will not, and should then rely more heavily on the architectural measures.

Public agencies face their own limits. Federal buyers usually purchase through government-wide contract vehicles whose terms are largely fixed, and state and local agencies often use cooperative purchasing agreements. Both make bespoke clauses harder to obtain. For them, keeping data in agency-controlled storage is the more dependable protection.

Two banks hear the same announcement

Take two regional banks of similar size, both running the same SIEM, on the morning their vendor announces it is being acquired.

The first bank has done what most organizations do by default. Every log goes straight into the SIEM, which is the only place three years of required records can be searched. Its few hundred detection rules were written directly in the vendor’s query language over a decade, by a changing cast of engineers; the reasons behind most thresholds are not written down. Collectors on its servers speak only to this vendor’s platform. Investigation case records live in the SIEM’s built-in case module. The contract says nothing about export rights or a change of control.

When the CISO is asked by the chief executive what the acquisition means, the honest answer is: we do not know, and we cannot easily find out. Any future price increase will have to be accepted or met with a migration that could take a year or more. That migration would bring overlapping licenses, re-ingestion of years of logs, a rewrite of every rule and a scramble to preserve case records for possible litigation.

The second bank made a few different choices over the previous few years. Its raw logs land first in object storage it controls, in an open format, with retention and immutability set there; the SIEM holds only recent data for live detection. Its rules sit in a version-controlled repository, each with a note on what it detects, what data it needs, which test events should trigger it and why it was tuned as it was. Newer rules were written in Sigma and translated. Its collection pipeline can send data to a second destination with a configuration change. Closed case records are exported monthly to the bank’s own document store. Its contract includes export rights, change-of-control notice and price protection for a defined period.

The second bank’s CISO can give a very different answer. Retention obligations are unaffected by anything the vendor does. Moving to another analytics platform would mean translating and testing rules from a well-documented library and pointing the pipeline at a new destination. The price protection buys time to evaluate the new owner’s plans. The bank may well decide to stay, but it will be staying by choice, and its procurement team will negotiate the next renewal from a position of strength.

The second bank’s position was not free. It pays for a storage account, a pipeline and the engineering time to keep schemas and rules documented. Its analysts sometimes search two places instead of one. Its detection engineers spend hours writing tests that the first bank’s engineers never write. Those costs are steady and modest, and they buy the bank an exit it may never use.

The difference between the two banks did not come from a single expensive project. It came from a series of modest decisions about where data lives, how rules are written down and what contracts say, each made before anyone needed them.

Four costs that land outside the security team

For a chief executive, chief financial officer or general counsel, SIEM lock-in shows up in four ways.

Cost. Ingestion-based licensing means storing long-term logs inside the SIEM can be expensive, and a migration that requires overlapping licenses or re-ingesting data adds to it. A change of owner can also change pricing.

Compliance. Retention obligations do not pause during a vendor change. If the only searchable copy of required logs is in a platform you are leaving, staying compliant depends on that vendor’s cooperation.

Legal exposure. Litigation holds and regulator requests can reach back years. Case records and logs need to be retrievable regardless of which products the organization uses at the time.

Negotiating position. An organization that could realistically leave negotiates differently from one that cannot. The ability to exit is valuable even if never used.

Detection gaps. A migration carries security risk of its own. During cutover, some rules will have been translated and others not, and some log sources will feed one platform but not the other. Running both platforms in parallel for a period reduces the gap, at the price of paying for both. Without that overlap, the organization may be partly blind for weeks. A forced, hurried migration makes that window longer and harder to manage, which is one more reason to plan the exit before it is needed.

These costs also land differently by type of organization. A publicly traded bank holding company must weigh a forced migration against its budget guidance and its examiners’ expectations. A health system on thin operating margins may simply be unable to fund overlapping licenses for a year. A federal agency may find that a price change in the middle of a contract period collides with appropriations that were set long before. A county or city often has the least room of all, because its security budget is a small line inside a broader IT budget.

Owning the data, the rules and the wiring

A well-prepared organization keeps its raw security logs in storage it controls, in an open format, with retention and immutability set there. Its SIEM holds only the recent data needed for live detection. Its detection rules live in version control with documented intent, data sources and test events, and new rules are written in a neutral format where practical. Its collectors can send data to more than one destination. Closed case records are exported regularly. Its contracts guarantee export rights, notice of a change of control and price protection afterward.

A few measures let a risk committee track progress without reading the architecture. One is the share of required logs held in organization-controlled storage, against the share held only inside the SIEM. Two more are the share of detection rules with a written purpose and a stored test, and the time taken to produce a case record from three years ago at the last drill. The last is the number of months remaining on each critical security contract, alongside whether it carries export and change-of-control terms. Each figure can be reported once a quarter, and each should improve over time.

Organizations that end up stuck usually made the same handful of errors. They equated the license with the lock-in, when the license is the smallest part and the data, rules and plumbing are the expensive parts. They let the vendor be the archive, so retention obligations became vendor commitments. They kept rule logic in people’s heads, and tuning decisions left with the engineers who made them. They ignored case records, which are evidence and may be needed years after an incident. And they waited for a price increase before planning, when the organization has the least time and the fewest options, and the vendor knows it.

A CISO can test readiness with one exercise. Pick a single high-value detection and trace it end to end: where its data is stored, in what format, how long it is kept, how the rule would be rewritten, and what playbook it triggers. If any step depends on knowledge held only inside one product, that is where an acquisition will cost the most.

The case for staying put

The strongest counter-argument deserves a fair hearing. Consolidation has benefits. A single vendor that owns the network, the endpoint agents and the SIEM can correlate signals that separate products struggle to combine, and it offers one support line when things break. Cisco made a version of that argument when it announced the deal.

Independence also has costs beyond money. An organization that runs its own log store, pipeline and rule repository takes on engineering work that a fully managed SIEM would otherwise absorb. It must secure the store, maintain the schema and keep the pipeline running. For a small credit union or a rural hospital with two security staff, that burden may outweigh the benefit, and a managed service with strong export terms can be the wiser choice.

The argument still holds for most regulated organizations because the measures are scalable. Owning the archive of required logs, writing down what each rule is for, and securing export rights are cheap compared with a forced migration. A larger organization can go further with its own pipeline and data lake. A smaller one can stop at the contract and a scheduled export. Neither needs to leave its SIEM to gain the option of leaving.

The first ninety days after an announcement

When a critical supplier announces a sale, a short sequence helps. First, find the contract’s renewal date and termination terms, and check what it says about a change of control. Second, run the end-to-end trace on two or three high-value detections to size the exit. Third, ask the vendor in writing about product roadmaps, license metrics and support commitments. Fourth, decide whether to extend the contract early for price protection.

That last decision is a real trade-off. A longer commitment at today’s prices protects the budget, but it also extends the period in which the customer is bound to the new owner’s choices. Organizations with a credible exit can afford a shorter term; those without one are often pushed toward the longer one. That asymmetry is the practical value of the preparation described above.

Before the next acquisition announcement

1. Could we meet our retention obligations if we stopped paying our SIEM vendor tomorrow?
2. How many of our detection rules are in version control with a written explanation, and how many exist only in one vendor’s language?
3. Can our log collectors send data to a second destination today, without reinstalling anything?
4. Where are our closed investigation case records, and could we produce one from three years ago?
5. What do our contracts say about exporting our data, notice of a change of control, and price protection afterward?

With hindsight

Cisco completed the Splunk acquisition in March 2024. The change of owner moved from possibility to fact, and with it the questions customers faced about where their data and rules lived.

Splunk’s shares stopped trading the morning the deal closed, and its chief executive became the general manager of the Splunk business inside Cisco. From then on, prices, product direction and support commitments were decisions for Cisco to make.

SIEM consolidation continued that year. Palo Alto Networks agreed to acquire IBM’s QRadar SaaS assets, and Exabeam and LogRhythm merged, leaving many customers facing migrations they had not planned. QRadar customers in particular had to decide where their retained data and rules would go. The exercise stopped being hypothetical: they had to work out, under time pressure, how to carry years of required logs and hundreds of detection rules to a new home.

The terms of the IBM arrangement, announced in May 2024, showed how a change of control reaches customers. The price was not disclosed. Qualified QRadar SaaS customers were offered no-cost migration to Palo Alto’s Cortex XSIAM platform, while IBM said it would keep supporting the on-premises product for those who stayed. Customers received a supported path to the buyer’s platform and a support commitment for staying put, but the long-run direction was now set by others.

Broadcom’s ownership of VMware, with its move to subscription bundles and reported price increases, kept change-of-control risk on board agendas. Executives who had treated software suppliers as stable utilities saw that a new owner can reshape the terms of a relationship quickly, and that customers with no credible exit have the weakest hand.

Some customers went to court. AT&T sued Broadcom in 2024 over the renewal of support for VMware products it had bought under perpetual licenses, and the two companies settled later that year. Few organizations can litigate their way to better terms, which is why the contract language and the exit plan matter more.

On the federal side, the logging deadline proved hard to meet. In December 2023 the Government Accountability Office reported that most of the large civilian agencies it reviewed had not fully met M-21-31’s logging requirements. Agencies that had not finished the work were also the ones least able to absorb a change of platform.

The architectural shift held up. Separating security data storage from analytics, often described as a security data lake or data pipeline layer, spread among larger organizations through 2024 and 2025. A data lake, in this sense, is simply a large store of raw data the organization owns, from which different tools can read. Pipeline products that route logs to several destinations grew as a category, a sign that the market itself recognized the value of not sending everything to a single platform.

Open formats gained ground as well. The Open Cybersecurity Schema Framework, launched in 2022 by a group of vendors that included Splunk and AWS, became the native format of Amazon Security Lake and was adopted by a growing list of tools. Competing schemas remained in use, though, and converting between them still took engineering effort.

The pipeline layer then began to consolidate in turn. By 2025, several large security platform vendors had bought log pipeline companies of their own. The routing layer that was supposed to preserve independence could change hands too. Open formats in storage the organization controls proved more durable protection than any particular pipeline product.

The data lake model also showed its costs as it spread. Searching cold data in object storage during an investigation can be slow and can carry per-query charges. Teams that skipped the restore drills sometimes discovered those limits only when they needed old data quickly.

Organizations that had already done so faced the 2024 changes as a choice of analytics tool rather than a data migration. When the data, the rules and the plumbing belong to the organization, a vendor change becomes a procurement decision. When they belong to the platform, it becomes a project measured in months and budgets.

The same test applies well beyond security logging. Any critical platform can be examined for which parts of the organization’s own knowledge and records live only inside a vendor’s product, and what it would take to hold them independently. The time to ask is before the next acquisition announcement.