"Does MXDR replace our SIEM?" Here's the honest answer.

We frequently get asked, "Do you replace our SIEM?"

When we poke into what that really means to the buyer, the question underneath is usually about data, not detection. Buyers tell us they need to keep logs for a year to satisfy a compliance requirement, to have them waiting if a forensics firm ever shows up, or to search them on their own. None of them are asking about correlation rules.

That's the useful starting point. MXDR handles the 24/7 detection work a SIEM was supposed to do. What's left is a different question: how long do you need to keep the underlying logs and alerts, and why?

First, the part a SIEM was bought for that MXDR does take off your plate.

Does MXDR cover what a SIEM was bought to detect?

That's the job MXDR exists to do.

A SIEM detects what its rules tell it to detect. Somebody has to maintain those rules and act on what fires, including at 2am on a holiday weekend. In a lot of mid-market environments, that somebody also runs the help desk. We covered why that breaks down in what "someone watching" misses.

Quorum AI ingests telemetry from endpoint, network, identity, SaaS and cloud sources, normalizes it to OCSF, and correlates activity across those sources. You don't write or maintain the detection rules. What reaches your team is a SitRep: the supporting evidence, a severity, and prioritized actions. Every SitRep is kept.

A SitRep is the record of what happened and what to do about it. It isn't the raw logs and alerts behind it. If you need those, the reason decides how long, and how searchable, they have to be. For most mid-market teams, there are three possible reasons, and each one needs something different.

Reason 1: Do you need logs for compliance?

Then the requirement is set for you, and it's usually measured in months.

PCI DSS 4.0 requirement 10.5.1 calls for at least 12 months of audit log history, with the most recent three months immediately available for analysis. Other mandates come from cyber insurers, customer contracts, or regulators in your sector.

Two details matter. The first is length. The second is access. "Retained" and "searchable" aren't the same thing, and a requirement like 10.5.1 asks for both. Logs sitting in an archive that takes days to restore don't meet the "immediately available" part.

Test for this reason: Can you show an auditor 12 months of history, and search the last three of them today?

Reason 2: Do you need logs for forensics?

Then you need enough history to reconstruct what happened, step by step.

After an incident, the question isn't only "what did they do?" It's "how did they get in, and what did they touch on the way?" Answering that means rebuilding the attacker's path through your environment: initial access, credential use, lateral movement, the systems they reached. Then you can close the specific gaps they used, so the same path doesn't work twice.

The catch is timing. The first step of an attack often happens well before anyone notices the last one. By the time an incident is confirmed, an outside forensics firm engaged, and the investigation underway, a short retention window may already have rolled past the step that matters most.

Test for this reason: If you found an intrusion today, would you still have the logs from the day it started?

Reason 3: Do you want to hunt on your own?

Some mid-market teams have real security expertise in house and want to use it. Not to replace their MXDR provider's 24/7 coverage, but to do their own investigative work alongside it: following a hunch, testing a hypothesis, checking whether a technique they read about has ever shown up in their environment.

That needs two things. Enough history to make the search meaningful, and the ability to query it freely, without filing a request with someone else.

It also changes what you can do with new threat intelligence. When an indicator of compromise is published today, a long searchable window lets you check whether it was already in your environment months ago, not just last week.

Test for this reason: Can your team run its own query across months of data, today, without asking anyone?

What about logs nobody needs to monitor?

All three reasons can involve logs outside your MXDR scope. Application logs, database audit trails, systems your provider doesn't watch. You may need to keep and search them without needing an analyst to triage them.

That's a legitimate need, but be clear about what you're buying. Storing a log and monitoring it are different services. If a provider accepts logs you bring to the platform, ask whether those logs are in scope for detection, correlation and analyst triage, or only for storage and search. The answer changes what you can rely on during an incident.

What does "SIEM included" usually mean?

Several MDR/MXDR vendors now say SIEM is included, or free. Read the fine print, because it usually means one of three things:

1. A capped ingest allowance. A set amount of log data per day at no charge, then per-GB pricing. Once firewall and identity logs are flowing, a mid-market environment can pass the cap quickly.
2. A short default window. Search is included, but only for days or weeks. Longer retention is a separate line item.
3. Retention folded into the service price. This one can be a real inclusion. Ask how long, and whether the data is searchable or just archived.

Run any of them against your reason. Compliance cares about length and access. Forensics cares about length. Hunting cares about length and the freedom to query.

What should your team think through first?

1. Which reason is actually yours? Compliance, forensics, hunting, or some combination. Teams often assume compliance when the real driver is wanting to see further back after an incident.
2. What do your mandates really require? PCI DSS, cyber insurance, customer contracts, internal policy. Note both the length and how quickly the data has to be searchable.
3. How far back could you see today? If an intrusion started two months ago, could you reconstruct it with what you keep now?
4. Would anyone hunt? Hunting is only worth the history if your team has the skill and the time to use it.
5. Which logs need watching, and which just need keeping? Those are different needs, and they're often treated as one.
6. What does "retention" mean in each tool you already own? How long, how searchable, and whether anything is metered. The answers are often less than people assume.

Where does Gradient Cyber fit?

Quorum AI handles the detection job: cross-source correlation, 24/7 monitoring, and SitReps your team can act on. Every SitRep is kept.

For the three reasons above, DataDepth, expected later in 2026, keeps a rolling 365 days of logs and alerts alongside your SitReps, searchable across the full window. It's priced separately. It supports:

• Compliance: a full year of history, searchable throughout, for auditors and insurers
• Forensics: breach reconstruction and post-incident review across the whole window, with alerts linked to the remediation actions taken
• Threat hunting: your own queries across the full year, and retroactive lookups of new indicators against past data

DataDepth can also store logs you bring to the platform, searchable alongside your MXDR data. Those customer-supplied logs are not in scope for detection, threat intelligence enrichment or analyst triage. They're kept and searchable. We say that up front, because it matters during an incident.

Quorum AI isn't a SIEM, and we don't sell it as one. For many mid-market teams, MXDR plus DataDepth covers what they originally bought a SIEM to do. For some, keeping the SIEM is the right call:

• You have an in-house security team that writes and maintains its own detection content
• Other teams depend on the SIEM as their system of record
• You need custom correlation across application sources outside any MXDR scope

Frequently asked questions

Does MXDR replace a SIEM?

It can take over the detection job. Keeping logs for compliance, forensics or hunting is a separate question. Whether you still need a SIEM depends on which of those you bought it for.

How long should we keep security logs?

As long as your strictest reason requires. For compliance, that's set by your mandates; PCI DSS 4.0 requires 12 months, with the most recent three immediately available. For forensics and hunting, longer history means more of an attack you can reconstruct or find.

Isn't the SitRep enough of a record?

For what happened and what was done about it, often yes. For an auditor asking for raw log history, or a forensics firm rebuilding an attack path, no. They need the logs and alerts behind the SitRep.

If we send logs to a provider, are they monitored?

Not necessarily, so ask. At Gradient Cyber, customer-supplied logs stored through DataDepth are searchable but not monitored for threats.

MXDR takes over detection. What's left is why you keep the data: compliance, forensics, or threat hunting. Know which ones are yours, and buy exactly that.