Covering one analyst position around the clock takes 168 hours a week: 4.2 full-time equivalents at 40 hours each, before leave or training. But Managed Detection and Response (MDR) is not simply a way to extend monitoring outside office hours.
MDR combines security technology with analysts who monitor, hunt, investigate and take agreed action. The central buying question is therefore not whether alerts are watched 24/7, but what the provider can do when an incident occurs.
MDR, EDR and XDR: what are you buying?
Detection and response can be built internally, outsourced or split between an internal team and external provider.
The product category does not define who monitors the environment or who responds when something happens.
| Category | Practical distinction |
| MDR | Managed detection and response: technology plus analysts for monitoring, hunting, investigation and agreed action. |
| EDR | Endpoint detection and response: endpoint-focused technology, not inherently a staffed service. |
| XDR | Extended detection and response: technology connecting signals across security domains; a managed analyst team is separate. |
| MXDR | Managed XDR: a service operating XDR technology; check its actual coverage and response authority. |
| MSSP | Managed security service provider: a broad provider category; monitoring and response depend on the purchased service. |
| SIEM | Security information and event management: a platform collecting and analysing security events; staffing is separate. |
The comparison therefore needs to focus on coverage, investigation and response capability rather than the service label.
What should MDR detection include?
MDR should produce more than forwarded alerts.
A useful investigation should establish:
- What happened: The incident should be reconstructed from the available evidence.
- What is affected: Relevant accounts, endpoints, workloads or other systems should be identified.
- Why it matters: The report should explain the likely impact and severity.
- What remains uncertain: Gaps in evidence or telemetry should be visible rather than hidden behind a definitive conclusion.
A sample incident report provides a stronger test than a dashboard demonstration because it shows how the provider turns telemetry into an investigation.
Threat hunting extends that work beyond existing alerts. The service should define what triggers a hunt, which data sources analysts can use and how findings are reported.
Detection also needs ongoing maintenance. Responsibilities for rule tuning, priority-scenario testing and missing telemetry should be clear as the environment and threat landscape change.
Once detection capability is understood, the more important contractual question is what happens next.
What should “response” mean in an MDR contract?
An active response commitment should define what the provider is authorised to do, under which conditions and within what timeframe.
Five areas determine whether that commitment will work during a real incident.
1. Coverage and readiness
Twenty-four-hour monitoring only matters if the required systems are actually connected and ready for response.
The contract should define the endpoints, identities, cloud services and network sources in scope, alongside any exclusions. It should also state when coverage begins, who resolves missing integrations and how response permissions are tested before service commitments apply.
That creates a clear boundary between systems the provider can monitor and systems it can actively defend.
2. Authority to act
Response authority should distinguish between:
- Pre-authorised actions: Defined containment steps the provider can take without waiting for approval.
- Approval-required actions: Higher-impact changes that require a named customer decision-maker.
- Out-of-scope actions: Activities that remain entirely with the internal team or another supplier.
For example, an MDR provider may be authorised to isolate an employee laptop while requiring approval before isolating a production server.
The contract should define those boundaries, the conditions attached to them and the rollback process.
Terms such as “autonomous response” also need precision. They can refer either to an analyst acting under pre-agreed authority or to a fully automated control.
3. Measurable response times
Mean time to detect (MTTD) and mean time to respond (MTTR) are useful only when the underlying definitions are clear.
Each commitment should establish when the clock starts, what stops it, which severity levels apply, what exclusions exist and whether waiting for customer approval pauses the measurement.
“Response” itself also needs a definition.
Acknowledging an alert, beginning an investigation and containing a threat are different milestones. A fast acknowledgement does not demonstrate fast containment.
4. Out-of-hours escalation
Response plans need to account for incidents that occur when primary contacts are unavailable.
The escalation process should identify primary and backup contacts, communication methods and escalation deadlines. It should also define which pre-authorised actions can continue when nobody responds and which actions must wait.
Alternative communications are required where corporate email may itself be unavailable or compromised.
Those routes should be tested before an incident rather than discovered during one.
5. Incident response and recovery
Confirm whether digital forensics and incident response (DFIR) are included, separately retained or charged additionally.
Establish:
- Mobilisation times
- Included hours
- Evidence-preservation responsibilities
- Specialist handover arrangements
- Responsibility for root-cause analysis and remediation
- Who handles credential resets, rebuilding and restoration
A written incident summary should record outstanding actions and owners.
The contract can then be tested through a realistic scenario, such as an overnight incident affecting an endpoint and privileged account while the primary customer contact is unavailable. The exercise should make clear who investigates, who decides and who acts at each stage.
How to compare MDR providers
Contractual clarity still depends on the team and service behind it.
Analyst experience, shift handovers, access to senior investigators and support outside active incidents all affect how the service performs.
Three areas provide a useful basis for supplier comparison:
- Coverage: A coverage map should show which endpoint, identity, network and cloud sources provide telemetry, which detections apply and which response actions are available. Ownership of each integration should also be clear.
- Cost: Pricing should separate licences, onboarding, subscriptions, log ingestion, retention and additional incident support. Internal staffing that remains after outsourcing belongs in the same comparison.
- Data and exit: Retention periods, storage locations, export options and access for another incident responder should be defined before the contract begins.
The NCSC recommends specifying required log retention and access in service contracts.
Provider access to customer systems needs equivalent scrutiny. Privileged access should be restricted, logged and auditable.
Customer references and evidence from comparable environments can then help establish whether the operating model has worked beyond the sales demonstration.
Where identity controls fit
Identity controls and MDR solve different parts of the problem.
Reducing standing privilege limits permanently available administrative access. Just-in-time access makes elevation temporary. Passkeys change how users authenticate.
MDR determines how suspicious activity is detected, investigated and responded to.
Ask whether the service can investigate privileged-account activity and take authorised action against affected identities.
Keep identity administration, recovery and monitoring responsibilities explicit.
Bring a clearer requirement to your next conversation
MDR should provide more than 24/7 alert monitoring. The service needs clear visibility across the environment, defined authority to act and an agreed escalation path when an incident occurs.
Those requirements should establish what the provider can detect, which response actions it can take, how quickly it must act and which responsibilities remain with the internal team.
The Cyber Secure Forum brings security decision-makers together with relevant providers through pre-arranged one-to-one meetings.
Organisations reviewing MDR, SOC or incident-response services can meet providers against their detection and response requirements, using those requirements to guide supplier conversations.
MDR frequently asked questions
What is the difference between MDR and managed EDR?
Managed EDR centres on endpoint technology. MDR describes a detection-and-response service that may use wider data sources. Check actual coverage, hunting, investigation and containment rather than relying on the label.
Is MDR the same as an outsourced SOC?
Not necessarily. A SOC is an operational function; MDR can deliver defined parts of it. Check whether the service covers all the functions your organisation needs.
What should an MDR SLA guarantee?
Seek defined coverage, measurable service deadlines, response authority and escalation commitments, with reporting and remedies for missed targets. Have procurement and legal teams review the proposed wording.
Can MDR replace an in-house security team entirely?
Do not assume it removes internal responsibilities. Retain named owners for business priorities, risk decisions, provider oversight and actions outside the contracted scope.
Image credit: https://unsplash.com/photos/two-colleagues-collaborating-on-a-computer-screen-0xvyG-lW0oE
