MDR vs SOC as a Service: which should you buy?

Capability versus function: the difference in one line

MDR — managed detection and response — is a bought capability. A provider deploys sensors, most commonly an EDR agent across your endpoints, watches what those sensors produce, and detects and responds to what they can see. SOC as a Service is a bought function. The provider runs the security operations centre itself: ingest from whatever sources you already have, correlation, triage, investigation, response, reporting, and the retained record of all of it. The consequence is scope. MDR tends to be deep and narrow — very good at what its sensors observe, largely blind to what they do not. SOCaaS is broader and, at its worst, shallower: more sources, more dashboards, and a genuine risk that breadth arrives without response muscle behind it. Neither shape is inherently superior. What decides it is whether your risk is concentrated where the sensors already sit, or spread across systems no agent will ever run on — network gear, industrial controllers, legacy line-of-business applications, cameras and access control.

Where MDR genuinely wins

There is a version of this comparison, usually written by SOCaaS vendors, in which broader is always better. It is not. For a large part of the Indian mid-market MDR is the better buy, and pretending otherwise wastes everybody's time. Most intrusions become visible at the moment something executes on a machine, and a service that does one thing very well will beat a service that does eight things adequately. Narrow scope is also a procurement advantage: a small surface produces a service level agreement you can actually read, test and enforce, which is more than can be said for many broad-spectrum contracts. The honest position is that breadth is only worth paying for once you have something outside the endpoint that genuinely needs watching, and someone who will genuinely be asked to look at it.

• Useful detection in days, against weeks of log-source onboarding and tuning
• Pricing tied to an endpoint count you already know and can forecast
• Analyst effort concentrated where intrusions usually surface first
• A small scope makes a tight, testable SLA
• Little internal engineering needed to keep the service fed

Who owns containment

This is the question that separates good providers from brochures, and it cuts across both categories. Ask precisely who is permitted to isolate a host, disable an account, kill a process or block an address in your environment, and under whose authority. MDR is generally stronger here by construction: the provider owns the agent, the agent can act, and the contract usually grants standing permission to contain within an agreed blast radius. SOCaaS varies enormously. Some providers hold real response authority across the estate. Many will investigate thoroughly, write an excellent case note, and then wait for your approval at two in the morning. That is not dishonest — advisory response is a legitimate product — but it is a different product and should not be priced like the other one. Whichever you buy, get the containment boundary in writing: which actions are pre-authorised, which need a named approver, who that person is out of hours, and what the provider does when nobody answers.

What happens to your logs, and whether you keep them

Under most MDR agreements the telemetry lives in the provider's platform, is retained for a period suited to their detection engineering rather than your auditors, and is not straightforwardly yours to export. Frequently that is fine. It stops being fine the moment somebody asks you to produce a six-month trail. SOCaaS is usually built around log management as a first-class deliverable — much of what you are paying for — so retention windows are longer, configurable and contractual, and reporting is designed to be handed to someone who will scrutinise it. Indian buyers should treat this as a decision input rather than a detail. CERT-In's directions expect ICT system logs to be maintained for a rolling window, held within Indian jurisdiction; RBI-regulated entities, SEBI's CSCRF and obligations under the DPDP Act each add their own evidentiary expectations. No provider, PrahiX included, makes you compliant with any of it. But a service whose retention quietly ends at thirty days makes the work materially harder, and that is better discovered before signing than during an audit.

Pricing shape: per-endpoint versus per-ingest

The two categories are priced on different units, which makes quotes hard to compare and easy to game. MDR is typically charged per endpoint per month, sometimes per user. It scales with device and headcount numbers you can forecast, and it is comparatively insensitive to how chatty your infrastructure is. SOCaaS is more often priced on ingest volume, asset count, or a blend of both — and ingest is the variable that surprises people, because one verbose source added during a migration can move the bill noticeably. Compare them by building the same twelve months twice. Take your real endpoint count and your real daily log volume, add the retention period you actually need rather than the one bundled in the base tier, and include the sources you already know you will add: a new plant, a cloud migration, an OT segment. Then ask each provider what happens when volume grows by half. That answer tells you more about your third-year cost than anything on the first-year quote.

MDR analyst vs SOC analyst

The job titles sound interchangeable and the underlying skills overlap, but the work is shaped differently. An MDR analyst works a deep, narrow queue: endpoint and identity detections, relatively high signal density, a well-defined playbook set, and authority to act on the customer's estate. The role rewards depth in adversary tradecraft, familiarity with forensic artefacts on the host, and speed of decision — is this real, and do I isolate it now. A SOC analyst, whether in an in-house centre or at a SOCaaS provider, sits across a wider and messier stream: firewall and proxy logs, cloud audit trails, identity, applications, sometimes OT and physical-security events. That role rewards correlation, environmental context, detection engineering and the patience to assemble a case from weak signals in several places. Tiering is more visible too, with triage, investigation, hunting and content development often handled by different people. For a buyer this matters in one practical way: ask which of the two shapes the humans on your account came from, because it tells you what they will be good at and where you will still need your own people.

Choose MDR if... choose SOCaaS if...

Most organisations know the answer once the question is framed by obligation and surface area rather than by feature grid. Two honest tests. First, what do you have to prove to somebody else — a regulator, an auditor, a customer's security questionnaire, an insurer after an incident? Second, how much of your risk lives somewhere an endpoint agent cannot go? If the answers are "not much" and "not much", buy MDR: you will get better detection per rupee and a service you can hold to account. If either answer is substantial, the broader function is what you need, and buying MDR alone will leave you quietly assembling the rest yourself out of spreadsheets and goodwill.

• Choose MDR if your estate is endpoint- and SaaS-heavy with no log-retention duty
• Choose MDR if you need coverage live in days and an SLA you can hold tightly
• Choose MDR if you have an internal team that already owns network and infrastructure
• Choose SOCaaS if you owe a regulator, auditor or customer a retained evidence trail
• Choose SOCaaS if real risk sits on network gear, OT, on-premise servers or physical security
• Choose SOCaaS if you need one incident timeline instead of several tools telling separate stories

How to test the claim that a provider "responds" — and the exit

Every provider in both categories says they respond. The word stretches from automated host isolation in seconds to an email suggesting you consider isolating the host. Test it before you sign rather than during the incident, and test the exit at the same time, because a provider confident about response is usually relaxed about departure. The cheapest test is a deliberately boring question: name an action, name a system, name a time of night, and ask who performs it and how long it takes. Vagueness is itself an answer. Then ask for a redacted incident timeline from a real engagement — not a case study, the timeline with timestamps — and look at the gap between detection and the first containing action, then ask what filled it. Lock-in is shaped differently in each. Leaving MDR means replacing an agent on every endpoint. Leaving SOCaaS means rebuilding a log pipeline and, often, losing the detection content written for your environment.

• Which actions are automated, which are analyst-initiated, and which need my approval?
• What is the SLA at 3am on a Sunday, and who is the named escalation contact?
• Show me a redacted incident timeline with timestamps, not a case study
• On exit, what can I export — raw logs, detection content, case history — and in what format?
• Do detections built for my environment leave with me, or stay with you?