SIEM vs MDR: What to Tell a Client Who Wants "Monitoring"

A client says "we want monitoring" and you have to decide what they meant, which is really the whole SIEM vs MDR question. Sometimes they mean somebody should be awake at 2 a.m. Sometimes they mean an auditor asked for twelve months of logs. Those are different products with different price shapes, and quoting the wrong one costs you the renewal. MSP Pentesting tests whatever you end up deploying, under your brand and channel-only, because neither of these tells you what it failed to catch.

Start by refusing to answer the question they asked.

Ask what has to be retained, what has to be detected, and who's allowed to pull the plug. The right answer falls out of those three.

What each one actually is

A SIEM is a product. It collects logs from wherever you point it, normalizes them, correlates across sources, stores them, and fires alerts against rules you or your vendor wrote. It's where data goes and where questions get asked. It doesn't include anyone to ask them.

MDR is an outcome sold as a service. Analysts you don't employ watch a detection stack you don't own, around the clock, triaging what fires and taking agreed actions when something's real. Most MDR offerings are anchored on endpoint telemetry and reach outward into identity, network and cloud for more money.

The confusion is understandable. Plenty of MDR providers run a SIEM underneath. The service layer sits on top of the technology layer, and what you're buying is the layer, not the box.

One more term clients mix in. The EDR vs MDR distinction is simpler than it sounds. EDR is the sensor and the control point on the endpoint. It's a component. MDR is the service that watches it and acts. Buying EDR and calling it MDR is how organizations end up with excellent telemetry nobody reads.

The real axis is not features

Feature matrices don't help here, because the categories overlap on almost everything. Both ingest logs. Both alert. Both ship dashboards nobody looks at.

Two questions actually separate them.

Who reads the alert at 2 a.m.? If the honest answer is nobody, a SIEM will produce a beautifully documented record of the incident you slept through. That's not a hypothetical failure mode, it's the most common one.

Who is allowed to isolate the host? Detection without authority to act is a notification service. If your MDR contract doesn't specify what the provider can do unilaterally at 3 a.m. on a Sunday, you don't have response, you have a phone call.

Get those two answered in writing and the rest of the vendor comparison collapses into a procurement exercise. You're no longer choosing a philosophy, you're choosing a supplier.

The rest of the comparison fits in a table.

Retention is the thing everybody forgets

Here's where MSPs get burned, and it happens after the sale.

MDR is priced around detection, not archival. The provider keeps enough telemetry to do their job, usually on a rolling window, and the raw log history you'd need for a compliance obligation or a forensic investigation isn't necessarily yours to keep.

That matters if the client has a contractual retention duty. PCI DSS v4.0.1 requirement 10.5.1 calls for at least twelve months of audit log history with at least the most recent three months immediately available for analysis. Requirement 10.4.1 expects daily review of specified logs. SOC 2 auditors working the common criteria around monitoring will ask similar questions about what you kept and who looked at it.

An MDR subscription can satisfy the review expectation while leaving the retention obligation completely unaddressed. Check the contract, not the datasheet. If the answer is thin, you're buying MDR for detection and something else for storage, and that combination needs to be in the quote from day one.

How the pricing actually works

Any conversation about MDR pricing stalls because the two categories aren't priced in the same unit.

SIEM is typically priced on data. Gigabytes ingested per day, or events per second, or a per-asset license. Costs scale with how noisy the environment is, which means a chatty firewall can move the bill without improving detection at all.

MDR is typically priced per endpoint, per user or per identity, per month. Costs scale with headcount, which is far more predictable and far easier to quote in a client conversation.

Comparing a per-gigabyte number to a per-seat number produces nonsense. Normalize both to annual cost per protected user before you show a client anything, then add the line nobody puts in a first quote.

The labor line. A managed SIEM that needs analysts to triage its alerts carries a real cost you're either absorbing or passing through. An MDR that needs nobody carries a higher sticker and possibly a lower total. Anyone who leaves labor out of the comparison isn't advising, they're selling.

Other lines that show up later: extended retention beyond the hot window, data egress if you ever want your logs back, onboarding for non-standard sources, and replacement costs if the provider requires their own endpoint agent alongside the one you already deployed.

Deciding by constraint

Stop asking which one's better. Ask which constraint the client's actually up against, because that's what decides it.

Two patterns cover most mid-market clients.

Small client, no security staff, endpoint-heavy risk. MDR. Time to value is weeks, pricing's predictable, and nobody internally has to learn a query language. Add log archival separately if a framework demands it.

Regulated client with odd data sources and an internal team. SIEM, usually co-managed. They need the data, they'll want to search it themselves, and the sources that matter are line-of-business applications no MDR provider onboards by default.

That second pattern is where the channel money is, and it has its own operating model. Which parts of the platform you run, which the client owns, and where the handoff sits are the questions that decide whether the margin survives. We covered that split in detail in the piece on what you own and what the client owns in a co-managed SIEM.

Turning "monitoring" into a scope

The discovery conversation matters more than the product comparison. Five questions, in this order.

Only the middle one's about technology. Retention is a legal and contractual question. Who acts and who can isolate are organizational questions. Who proves it works is a testing question, and that's the one clients never think to ask.

Write the answers down before you request a single vendor quote. It shortens the evaluation and it keeps the client from moving the goalposts halfway through.

What neither one tells you

Both categories report on what fired. Neither reports on what didn't.

That isn't a criticism, it's a structural limit. A detection stack can only tell you about events it alerted on. The dangerous gap is the technique that ran cleanly, produced nothing, and therefore doesn't appear in the monthly report at all. From the dashboard, silence and safety look identical.

Which is why the QBR slide showing zero incidents is the least informative slide in the deck.

Closing that gap takes deliberate testing against the stack you deployed. Run known techniques in a controlled window, then check three things. Did the sensor generate telemetry. Did the correlation rule fire. Did anyone act on it. Those three fail independently, and each failure has a different fix, so don't let a vendor collapse them into one number.

Do it after deployment, not during the pilot, and repeat it after major tenant changes. A white-labeled test delivered under your brand gives the client an independent read on coverage without you grading your own deployment, which is a conversation you'd rather not have during a renewal.

Questions clients ask when they say monitoring

Can we run both?

Frequently, and it's often correct. MDR for endpoint detection and response, a SIEM for retention, compliance reporting and the sources MDR won't take. Just don't pay twice for the same telemetry, and decide up front which one's authoritative during an incident. That argument's much worse at hour three of a real one.

Does MDR replace our SOC plans?

For most mid-market clients, yes, and that's the point. Staffing a real 24/7 rotation takes far more people than anyone expects once you've accounted for coverage, turnover and burnout. Very few clients under a thousand seats should be attempting it, and the ones who try usually can't sustain it past year two.

What happens to our data if we leave the MDR provider?

Ask before you sign, and get it in the contract. Export format, cost, timeline, and what happens to detections and case history. It's the single most commonly skipped question in the whole evaluation, and you won't get a good answer once you've given notice.

How do we know the MDR provider is actually watching?

You test them. Agree a validation window, run controlled activity, then measure time to detect and time to contact. A provider who won't agree to that has told you something useful for free.

Which one helps more in an insurance questionnaire?

Underwriters generally ask about 24/7 monitoring and endpoint response capability, which reads more like MDR. But they also ask about log retention. Answer both from a documented risk assessment rather than guessing what sounds strongest.

Answer the question underneath the request

Take your three biggest clients and answer the five questions for each of them, on paper, without opening a vendor site. Retention duty, detection scope, who acts overnight, who can isolate, who validates.

At least one of them's paying for the wrong shape right now, and it's usually the one who's been quietest.

Once you know what's deployed, find out what it misses. A detection validation window is a small engagement with an uncomfortable output, and it's the fastest way to settle the argument. Get a pentest quote when you're ready for that.