Next-Gen SIEM vs. Legacy SIEM: Why the Gap is Growing

Joint guidance from ASD's ACSC and CISA makes a plain observation: "it is common for personnel to feed a SIEM increasing amounts of log data over time to improve the platform's visibility." That is good practice. The same guidance notes that most SIEM pricing is based on how much data the SIEM ingests, so good practice also raises the bill. How a platform handles that tension is one of the clearest lines between legacy SIEM and next-gen SIEM.

The pressure to collect more keeps growing. In Verizon's 2026 Data Breach Investigations Report, exploited vulnerabilities passed stolen credentials as the top way into a breach for the first time in the report's 19 years, at 31% of breaches. Catching that kind of entry takes logs from more places. For an MSP, that decision gets made again for every client, and so does the cost.

The more useful question is where the operating cost of a SIEM lives, and what happens to your margin as you add clients. The sections below cover how a modern SIEM differs, how to plan a SIEM modernization without losing coverage, and where cloud SIEM becomes a service line you can sell.

What separates a next-gen SIEM from a legacy SIEM

Every SIEM does the same basic job: collect logs from across the environment, correlate them, alert on what matters, and keep the evidence. If you want a refresher on the fundamentals, our complete guide to SIEM covers them. Where the generations differ is who does the work behind those jobs, and what it costs to keep doing it as you grow.

Where the data lives: cloud-native SIEM vs. hardware you maintain

A self-hosted SIEM means collectors, indexers, and storage you size, patch, and replace, with capacity planning and upgrades on your team. The practitioner guidance lists the choice between on-premises and Software as a Service as one of the first decisions a SIEM project has to make, because it determines who owns that infrastructure for the life of the platform.

A cloud-native SIEM removes the question. There is no cluster to expand before onboarding a new client and no hardware refresh to budget.

How detection gets written and tuned

In a legacy deployment, detection content is largely your job. The same practitioner guidance says the SIEM "should be continuously configured and tuned over time, as the environment, platform features, and threat landscape continually change." The executive guidance is blunter about the stakes: without accurate alerting, teams "may be operationally overwhelmed by false alerts from the SIEM or miss real events/incidents because of the absence of alerts."

Next-gen platforms ship detection content that the vendor maintains and pair rules with behavioral analytics. The event logging best practices published by ASD's ACSC with CISA, FBI, NSA, and partners describe user and entity behavioral analytics as enabling "automated detection of behavioral anomalies on networks, devices, or accounts." That matters because attackers who live off the land use tools a static rule cannot distinguish from administration.

How the platform prices your data, and what SIEM cost does over time

The executive guidance notes that "it is common for personnel to feed a SIEM increasing amounts of log data over time to improve the platform's visibility." Under ingest-based pricing, that healthy instinct is also a cost escalator. The practitioner guidance adds that ingesting too many logs "can be costly, lead to false positive alerts and strain the platform's data processing capacity." A legacy model makes visibility and budget pull in opposite directions. Before you renew, ask what your bill looks like if every client doubles its log sources, because that is where good security practice takes you.

Why legacy SIEM problems compound every year you keep it

None of these problems is fatal on day one. Each one accumulates.

Tuning debt accumulates with every exception

Every suppression rule written to quiet a noisy alert is a small decision that is easy never to revisit. Across a portfolio of clients, those exceptions add up to a detection posture that is hard to explain or audit. Each one is also a place a real attack can go unnoticed.

How many people it takes to run a legacy SIEM

The executive guidance says executives "should expect that multiple personnel will need to work on implementing the SIEM and/or SOAR on a full-time basis," and that these skills "are in high demand." It also notes that operating these platforms "can also involve long periods of highly stressful work." For a small MSP, several full-time SIEM specialists is a significant hire to make for one tool.

What happens when your SIEM vendor sells the product

Legacy platforms also change hands. In May 2024, IBM agreed to sell its QRadar SaaS assets to Palo Alto Networks, with SaaS subscribers' deployments transferred to Cortex XSIAM and no-cost migration offered to qualified customers, while IBM continued to support on-premises QRadar. Customers who had built detection content on one platform were now planning a move they had not scheduled. When you evaluate any SIEM, ask how portable your detections, dashboards, and retained data are if the product's direction changes.

How a cloud SIEM changes the math across your client tenants

An enterprise running a legacy SIEM has one environment, one set of baselines, and one budget. An MSP has dozens of each, and the legacy model multiplies every cost by the number of clients.

Why legacy SIEM fails MSPs as the client count grows

On a single-tenant platform, each new client means its own instance or index, its own log forwarding, its own copy of the detection rules, and its own suppressions. Under ingest-based pricing it can also mean a larger ingestion commitment. That work repeats with every client, and copies of the same rules drift apart over time.

The deeper problem is that nothing you learn in one tenant helps the next. An investigation pattern your best analyst figured out lives in that analyst's head. Legacy SIEM makes an MSP pay the full setup and learning cost again for every client.

What SIEM scalability means when you add a client

For an MSP, SIEM scalability means the marginal cost of each new client falls. That requires a multi-tenant architecture where tenants are isolated from one another but managed from one console, detection content that is deployed once and updated everywhere, and search that respects tenant boundaries. Janus SIEM Search, for example, uses a tenant-specific LLM instance so each client environment is queried in isolation. Whatever platform you evaluate, ask how it keeps one client's data out of another client's answers.

What a modern SIEM needs from you in the first 90 days

Even a platform that carries its own infrastructure needs decisions only you can make.

Start with the log sources that carry the most signal

The priority logs guidance puts endpoint detection and response logs first, network device logs second, and Microsoft domain controllers third. It says higher priority sources "should be ingested into new SIEM deployments first and their health should be regularly checked," and recommends "gradually building up the number and types of data sources ingested by the SIEM, rather than adding them all at once." For each client, map those three categories before anything else, and set a health check so you learn when a source goes quiet before an incident teaches you.

How long your SIEM should keep logs

The practitioner guidance says "the retention period needs to accommodate the organisation's mean time to detect threats." The event logging best practices add a sobering reference point: it "can take up to 18 months to discover a cyber security incident." Then layer on each client's regulatory floor. Our compliance reporting overview lists minimums across frameworks, from one year under PCI DSS to seven under SOX. Write each client's retention period into the contract.

Normalize fields before you write correlation rules

Correlation fails quietly when the same thing has two names. The practitioner guidance gives the example of standardizing "src_ip" and "sourceAddress" across collected logs. The same guide recommends a SIEM that can "analyse and correlate log data from multiple sources, such as legacy information technology (IT) and cloud environments." If your clients run a mix of on-premises servers and Microsoft 365, confirm the platform maps both into one schema before you trust any rule that spans them.

Test detection before you promise it

The practitioner guidance says organizations "should conduct exercises to test the performance of their SIEM and/or SOAR platform." Run a known technique in a test tenant and confirm the alert fires, reaches a human, and carries enough context to act on. How SIEM supports each phase of incident response is a useful map for what those exercises should cover.

How to plan a SIEM modernization without losing coverage

The riskiest week in any SIEM migration is the one where the old platform is off and the new one is not yet trusted. The plan below is built to make sure that week never happens.

Run both platforms in parallel on your highest-risk clients

Pick the clients with the most sensitive data or the strictest compliance obligations and forward their priority log sources to both platforms for a defined window of several weeks. Compare what each one alerts on. Every alert the old platform raises that the new one misses is either tuning debt you can retire or a coverage gap you need to close before cutover.

How to run a next generation SIEM vs. legacy SIEM comparison

Skip the vendor comparison grid and score both platforms on the work your team does every week. How long does it take to onboard a new client end to end? How many alerts per day reach a human, and how many of those are actionable? How long does it take a tech to answer a scoping question such as whether a given user signed in from anywhere unusual last month? What happens to the bill if a client adds cloud logs? Those four numbers, measured on your own tenants, tell you more than any analyst ranking.

What to ask a Splunk alternative before you sign

Whether you are leaving a large enterprise platform or outgrowing an open source SIEM, the questions are the same. Who writes and maintains detection content, and how often does it change? Is pricing tied to ingestion, and what happens when you exceed a commitment? How are tenants isolated, and can you manage all of them from one console? Can you export your retained data if you leave? The executive guidance adds items worth putting in the contract, including "the division of responsibility and liability for detecting and responding to cyber security incidents."

Decide what happens to historical data

Retained logs from the old platform may be the only evidence for an incident discovered months from now. Before you decommission anything, decide whether to migrate history, keep the old platform in a read-only state until the retention period lapses, or export to archive storage.

Where cloud SIEM becomes a service line you can price

SIEM often starts as a cost: a compliance requirement a client needs met. It becomes a service line when you can deliver it the same way across clients and charge for what the client gets: coverage, retention, and response. The difference between the two is usually covered in how SIEM, XDR, and MDR fit together for an MSP, and the packaging tends to follow the same layers.

The base tier is visibility and retention: priority log sources collected, normalized, retained for a contractually defined period, with compliance reports on a schedule. That is what regulated clients need to answer an auditor, and it is the easiest tier to price because the deliverables are concrete. The next tier adds monitored detection, where alerts are triaged against a defined response window. The top tier adds investigation and response: scoping an incident across a client's identity, endpoint, and cloud activity, and taking containment action.

Price each tier per client or per user, so your margin holds when a client adds a log source. That only works if your own platform cost is also set per client or per user, which is one more reason the pricing model belongs near the top of your evaluation. A managed cloud SIEM also shortens the sales conversation, because you can describe the service in terms the client cares about: what is watched, how long evidence is kept, and how fast someone responds.

The part of a modern SIEM your team cannot staff alone

Most of what separates a working SIEM from shelfware is decisions: which logs to prioritize, how long to keep them, how fields get normalized, how detection gets tested, what the contract promises. You can make all of them this quarter. Two things resist that. Detection content has to be tuned continuously as every client environment and the threats against it change, the kind of ongoing work the guidance expects multiple full-time personnel to carry. And someone has to be awake to triage what fires, across every tenant, every night, because the time attackers need to exploit a known vulnerability is shrinking toward hours.

Those are the two an MSP cannot justify building for each client, and the two a legacy SIEM leaves entirely with you. Todyl's Managed Cloud SIEM carries the first: a cloud-native, multi-tenant platform with a library of pre-built, continuously tuned detection rules and behavioral detection alongside them, flexible retention up to five years of searchable storage, and the hosting, maintenance, and tuning handled for you. Todyl MXDR carries the second, with a 24/7 analyst team working out of the same SIEM your techs use, so every case is visible to you. The return is a monitored-detection tier you can put in a contract and hold, at a margin that stays steady as your clients add data. See the platform.

Frequently asked questions about next-gen SIEM

What is a next-gen SIEM?

A next-gen SIEM collects, correlates, and retains security logs like any SIEM, but moves the operating burden into the platform. That typically means cloud-native infrastructure, vendor-maintained detection content, behavioral analytics alongside rules, and for MSPs, multi-tenant management from one console.

Is a cloud SIEM the same as a next-gen SIEM?

Not always. Hosting a legacy architecture in the cloud removes the hardware but can leave ingestion pricing, single-tenant design, and manual tuning in place. Ask whether the platform was built for the cloud or moved there.

What is the difference between SIEM and SOAR?

A SIEM gathers and correlates log data to detect threats. A SOAR platform acts on what the SIEM finds, and CISA describes it as a way to streamline incident response "by automating predefined actions." Many modern platforms build response actions into the SIEM console itself.

Does a next-gen SIEM replace EDR?

No. EDR is a source the SIEM depends on, and joint government guidance lists EDR logs as the highest priority source for SIEM ingestion. The SIEM adds correlation across identity, network, and cloud activity that an endpoint tool cannot see on its own.

Can a small MSP run a SIEM without a dedicated SOC?

It can run the platform, but it will struggle to watch it around the clock. The practical options are a managed SIEM with the provider carrying detection engineering, or pairing the SIEM with a managed detection and response service. Todyl's Detection and Analysis Engine and Anomaly Framework are examples of the kind of automation that narrows what a human has to review.