MDR only works when response ownership is clear.
Managed Detection and Response, or MDR, is an outsourced cybersecurity service that combines technology and human analysts to monitor security telemetry, investigate suspicious activity, validate threats, and support or perform response within the systems covered by the service.
MDR is only truly managed when responsibility is clear, because detection alone does not answer who owns alert validation, containment, evidence, communication, remediation, recovery, and the decision to return systems to normal operation.
Quick answer
Managed Detection and Response, or MDR, is an outsourced cybersecurity service that combines technology and human analysts to monitor security telemetry, investigate suspicious activity, validate threats, and support or perform response within the systems covered by the service.
Microsoft’s definition includes threat hunting, monitoring, human expertise, and rapid incident response. The detail buyers need to inspect is how much response the provider owns, which actions require customer approval, and where responsibility transfers to the MSP or internal team.
Before choosing any provider, ask one question:
Who owns detection, containment, evidence, communication, remediation, recovery, and the decision to resume operations after an incident?
The provider name matters less than the operating model, authority, handoffs, and evidence behind the service.
Strong technology and talented analysts still leave the customer exposed when response authority is unclear.
A note on MDR, MSSPs, SOCaaS, MSPs, and managed cybersecurity
The cybersecurity services market uses overlapping labels.
Some buyers search for Managed Detection and Response, or MDR. Others search for an MSSP, SOC-as-a-service, MSP cybersecurity services, a managed cybersecurity provider, or a cybersecurity services provider.
These terms are not interchangeable, but the services often overlap during the buying process.
MDR generally focuses on threat detection, investigation, and response. But a company may be called an “MDR provider” while offering expanded capabilities. An MSSP may provide MDR alongside services such as security tool management, vulnerability management, compliance support, broader monitoring or vCISO services. SOC-as-a-service provides access to an outsourced security operations capability. An MSP may also provide managed security services as part of a larger IT relationship.
For this guide, the MDR discussion applies to any managed security service that includes threat detection, investigation, escalation, containment, or incident response coordination. That may be delivered by a pure-play MDR provider, an MSSP with MDR capabilities, a SOC-as-a-service provider, or a combined managed cyber and IT offering.
The label matters less than the operating model.
The most important MDR question is not “Will someone detect the threat?” It is:
Who owns the next 30 minutes after detection?
I have seen companies buy Managed Detection and Response expecting peace of mind, then discover during an incident that “managed” meant “we will notify you.”
That is a painful time to read the fine print.
MDR should reduce time to validation, response, and, when authorized, containment.
For a mid-market company, that operating model is where most of the value lives.
Who this guide is for
This guide is for mid-market companies that carry more security risk than their internal team can comfortably operate alone.
That usually means some combination of:
• A lean IT or security team
• An MSP relationship
• Microsoft 365, cloud, endpoint, identity, and network exposure
• Cyber insurance requirements
• Compliance or client pressure
• No internal 24/7 SOC
• Leadership asking for clearer cyber risk answers
A mature internal SOC can use this guide to pressure-test a partner. A very small business buying basic managed endpoint protection may find some questions more advanced than it needs today. But the need to know "Who owns what?" applies no matter what size. Never make assumptions about services being provided.
What MDR is supposed to solve
Most mid-market companies cannot economically justify building and staffing a mature 24/7 security operations center on their own.
The cost is one problem.
Recruiting, training, tool tuning, playbook maintenance, and after-hours coverage create a second mountain behind the first.
Depending on the scope, MDR can give lean teams access to monitoring, investigation, human analysis, threat hunting, and response support without building the whole operation internally.
The word “managed” carries the promise. The service description defines how far it goes.
Some services validate an alert and call the customer. Others can isolate an endpoint, disable an account under pre-approved conditions, or coordinate the other response parties.
Those are different operating models wearing the same acronym. As a business you want to know that when something happens "everything" will be taken care of. That is rarely fully the responsibility of just the MDR provider, so better to ask the questions now, define roles and responsibilities before an incident occurs and avoid a finger pointing situation.
Why mid-market MDR decisions are different
Mid-market organizations often have more complexity, lack of visibility and exposure creating known and unknown risk to be addressed.
They may run Microsoft 365, cloud applications, on-premises systems, remote access, production technology, and a long list of vendors.
An MSP may control the firewall, endpoints, backups, identity, and ticketing. Internal IT may understand the business but lack overnight coverage. Leadership still expects a clear answer when operations stop at 2:13 a.m.
Mid-market organizations do not need another dashboard. They need accountable owners from detection through containment, followed by a defined handoff into remediation and business recovery.
A tool can identify suspicious behavior.
A service model has to decide what happens next.
Why generic MDR buying checklists fall short
Most MDR evaluations cover familiar ground:
• 24/7 SOC coverage
• Human analysts
• Threat hunting
• Endpoint monitoring
• Identity, email, cloud, and network telemetry
• AI-assisted triage
• Integrations
• Service-level commitments
• Reporting
Those capabilities matter. They show whether a provider can collect signals and investigate activity.
They do not answer whether the provider can contain malicious activity, limit the impact, preserve the facts, coordinate other parties, and support a controlled recovery.
Response ownership is the missing MDR question
NIST SP 800-61 Rev. 3 treats incident response as work that involves leadership, incident handlers, technology teams, legal, service providers, and other parties. It recommends documenting response responsibilities and giving each party the authority needed to perform its work.
That maps cleanly to MDR buying.
The worst time to define response ownership is during the incident.
Every buyer should know who validates the alert, determines severity, contacts the right people, contains the threat, coordinates the MSP, preserves evidence, communicates with leadership, verifies remediation, and clears the business to resume normal operations.
Response, remediation, recovery, and validation
These words are related. They are not interchangeable.
Containment prevents an incident from expanding and limits additional damage. Eradication removes malicious access, persistence mechanisms, and exploited entry points. Remediation fixes the weaknesses or control failures that allowed the incident to occur. Recovery restores systems and business operations in a controlled manner. Validation checks that containment, eradication, remediation, and restoration actions worked and that monitoring has not found continued malicious activity.
MDR contracts often describe investigation and containment more clearly than recovery. A provider may isolate a device in seconds while the MSP and internal team still own rebuilding it, restoring access, testing backups, and returning it to production.
That gap needs an owner too.
The MDR response ownership matrix
Use this matrix before signing the contract, not after the alert fires.
The goal is not to make the MDR provider own everything. The goal is to ensure every critical action has one accountable decision owner, even when several parties perform or support the work. Listed teams such as "security leadership" could be internal, service provider, fractional or other. This is also the place where you want to establish what providers can do with and without approval and what that looks like. An MDR provider could automatically contain a risk and remove account access or could be required to go though an escalation process you define.
This is an illustrative starting model, not a universal assignment of responsibility. Actual ownership depends on the environment, contract, authority granted, insurance requirements, and incident type.
Use this MDR response ownership matrix to define who owns each action before an incident happens.
|
Response activity |
Accountable owner |
Support and approval |
|
Alert validation |
MDR provider |
Internal IT provides asset, user, and business context |
|
Technical severity and confidence |
MDR provider |
Security leadership provides asset criticality and environment context |
|
Business incident classification and response activation |
Designated incident commander |
Business owners, legal, privacy, IT, and executives contribute based on impact |
|
Endpoint isolation |
Designated endpoint containment authority |
MDR executes the action when pre-authorized or routes it through the approved escalation process |
|
Account disablement or access revocation |
Designated identity administrator |
MDR provides evidence, urgency, affected accounts, and recommended scope |
|
Firewall or network block |
Designated network administrator |
MDR provides indicators, affected systems, and recommended scope |
|
Eradication and technical remediation |
Designated remediation lead |
MDR or the forensic team provides findings, affected assets, indicators, and recommended actions |
|
MDR records and telemetry preservation |
MDR provider |
The customer defines retention, access, and export requirements |
|
Forensic collection and evidence preservation |
Designated forensic lead |
Legal advises on privilege and legal hold requirements; IT, the MSP, and MDR preserve relevant records |
|
Executive notification |
Designated incident commander |
MDR provides a plain-English summary of known facts, actions taken, and open decisions |
|
Legal, privacy, and regulatory assessment |
Designated legal and privacy lead |
Security leadership provides verified facts, timelines, affected systems, and known data exposure |
|
Cyber insurer or broker notification |
Designated insurance contact |
Legal and security leadership support notice according to the policy terms |
|
Security validation before restoration |
Designated security validation lead |
MDR or the forensic team confirms that no known active threat remains within the observed scope |
|
Technical recovery and restoration |
Designated IT recovery lead |
The MSP, backup provider, system administrators, application owners, and security team support restoration |
|
Business validation and return-to-service authorization |
Designated return-to-service authority |
Business owners, system owners, IT, security, and the incident commander confirm readiness |
|
Post-incident review |
Designated incident commander |
Every involved party contributes actions, control gaps, unresolved risks, and lessons learned |
The role names in this example must be replaced with the actual people and providers responsible in your organization. Multiple roles can be filled by one person, these are not all industry defined roles, rather translated so you can easily understand the responsibilities being place on who and when.
“Internal IT or the MSP” is not an assignment until one party is named.
MDR, EDR, XDR, SIEM, MSSP, and SOC
The acronym debate can consume an hour and still leave response ownership untouched.
Here is the practical distinction:
|
Term |
What it is |
What it does not prove |
|
EDR |
Technology that monitors and responds to activity on endpoints |
That a human is watching it around the clock |
|
XDR |
Technology that connects detection across endpoint, identity, email, cloud, and other segments |
That an outside party owns the response |
|
SIEM |
A platform that collects, correlates, and analyzes security logs and events |
That alerts will be investigated or contained |
|
MSSP |
A provider that manages security tools and/or monitoring services |
The exact depth of incident response included |
|
SOC |
The people, processes, and tools that monitor and investigate security activity |
Whether the SOC is internal, outsourced, or authorized to act |
|
MDR |
A managed service combining technology and human expertise for detection, investigation, and response |
That every containment, recovery, or coordination task is included |
Microsoft’s guides to MDR, EDR and XDR, and the SOC function explain these distinctions.
Acronyms are useful labels.
They are terrible owners.
The business question is simple: Who turns the signal into a response decision, containment, usable evidence, and a controlled handoff to recovery?
Where MDR and MSP handoffs break
Many mid-market companies already have an MSP.
The MSP knows the environment and controls much of the infrastructure. That helps, but it can also create a response maze.
The MDR provider may detect compromised credentials. The MSP owns Microsoft 365. Internal IT knows the account belongs to the controller processing payroll. Leadership must weigh the disruption of disabling it.
Everyone has a piece of the truth. Without a written handoff, each party can assume another owns the next action.
A common 2 a.m. failure pattern
A suspicious login triggers an alert at 2:13 a.m.
The analyst confirms malicious activity. The account belongs to a finance leader. The MDR provider cannot disable it without approval. The MSP controls Microsoft 365. The primary IT contact is asleep. The insurance policy may require prompt notice under its specific terms. Payroll starts in six hours.
In that moment, the company does not have a detection problem.
It has an ownership problem.
- The MDR provider owns detection, investigation, containment guidance, and the incident records and telemetry within its service.
- The MSP owns infrastructure changes, endpoint access, firewall work, and recovery execution.
- Internal IT owns business context, approvals, and user coordination.
- The vCISO or security leader owns risk framing, executive reporting, compliance coordination, and lessons learned.
- Leadership owns decisions that can materially disrupt operations or create legal, financial, or client consequences.
The service needs to connect these parties before the pager goes off.
Contact trees, ticket routing, approval thresholds, and escalation times need to be tested.
Contract language to inspect before buying MDR
The sales deck explains the promise.
The service description defines the boundary.
Inspect the agreement for:
- Definitions of “response” and “containment”
- Included actions and covered data sources
- Actions that require customer approval
- Exclusions and customer responsibilities
- After-hours escalation terms
- Data retention and access to logs
- Incident report delivery times
- Extra incident response fees
- MSP or internal IT coordination responsibilities
- Authority to make or reverse changes
- Termination and data-export provisions
It is recommended that transferred response responsibilities, information flows, coordination, authority, and provider restrictions be clearly defined in contracts.
That is direct guidance for a problem buyers often leave to assumption.
What evidence MDR should produce
Detection without documentation leaves the business with a second problem: proving what happened and what was done about it.
NIST recommends preserving the integrity and provenance of incident records and retaining evidence according to the organization’s evidence-preservation procedures and data-retention policies.
Depending on the incident and service scope, an MDR incident record should include:
- Alert source and detection time
- Timeline of observed activity
- Analyst notes and severity decision
- Known or suspected affected users, devices, systems, and data
- Indicators of compromise
- Containment actions and who approved them
- Remediation actions observed or reported to the MDR provider
- Root cause assessment, when it can be established
- Control gaps found during the investigation
- Recovery checks, when the provider participates in or observes recovery
- Executive summary
- Open actions, owners, and due dates
A strong sample shows whether the provider can reconstruct the incident in language an engineer, insurer, auditor, attorney, and executive can use.
How MDR supports cyber insurance and board reporting
MDR can support cyber insurance readiness by producing records of active monitoring, incident investigation, containment actions, and response documentation.
It does not guarantee coverage, a favorable premium, or claim payment. The policy and the facts of the incident control those decisions.
Travelers’ cyber readiness guidance includes endpoint detection and response, MFA, backups, system updates, and an incident response plan among its recommended practices. Its incident response guidance also stresses a defined, coordinated approach that is tested before an incident.
Evidence that may support insurance conversations
The MDR provider may contribute part of this evidence. The organization, MSP, security leadership, backup provider, and other response partners may supply the rest.
- Proof of 24/7 monitoring
- Incident response plans and playbooks
- Endpoint, identity, cloud, and email coverage records
- MFA-related alerting or identity monitoring
- Backup and recovery validation records
- Incident timelines
- Containment and remediation records
- Post-incident findings
- Open risks and remediation status
Board reporting needs a different lens.
A technical alert export is not an executive risk report.
The MDR provider contributes operational facts and incident evidence. Security leadership must translate that information into enterprise risk and board reporting.
Security operations leadership should see
- Alerts and incidents investigated
- Confirmed incidents
- Time to validate
- Time to contain
- Repeat attack patterns
- Detection gaps
- Remediation status
Executives and boards should see
- Significant incidents and their business impact
- Critical services, data, or revenue processes affected
- Recovery performance against defined objectives
- Material control gaps and overdue remediation
- Accepted risks and unresolved executive decisions
- Trends in residual risk and business resilience
- Lessons that require investment, policy, or ownership changes
The board does not need every alert. It needs to know what could still hurt the business, what changed, and whether recovery is getting faster.
AI in MDR: speed cannot blur accountability
AI can help analysts correlate signals, summarize activity, prioritize alerts, identify anomalies, and recommend response actions. Rules-based automation, SOAR, EDR, or XDR workflows can isolate endpoints, block addresses, disable accounts, and collect investigation data when the service has the authority and approved rules to do so.
That speed is useful.
The buyer still needs to know who approved the action, why it happened, whether it can be reversed, and who owns the outcome.
The NIST AI Risk Management Framework calls for documented roles, clear lines of communication, executive responsibility for risk decisions, and defined human oversight.
Ask each provider:
- Which actions are AI-assisted, which are rules-based automation, and which can execute without human approval?
- Which actions require an analyst?
- Which actions require customer approval?
- Are automated and AI-assisted actions logged?
- Can containment actions be reversed quickly?
- Can the provider show the evidence and reasoning used to escalate an alert?
- Who reviews missed or misclassified incidents?
- Who is accountable when an automated decision is wrong?
AI can make MDR faster.
It cannot be allowed to make accountability blurrier.
The MDR scorecard for mid-market buyers
This viLogics scorecard is a practical model for comparing MDR operating models. It is not an industry certification or universal standard. Adjust the categories and weights to match your business, risk, internal resources, service providers, and response needs.
The goal is not to turn business leaders into security analysts. It is to help buyers understand what they are purchasing, who owns each responsibility, what is included in the agreement, and how the provider will show that the service is delivering the expected outcomes.
How to score each category
- 0% of points: The capability is missing, excluded, or cannot be clearly explained.
- 25% of points: The provider gives a general answer, but ownership, scope, or deliverables remain unclear.
- 50% of points: The service is clearly described in writing, including the basic process, responsibilities, and expected deliverables.
- 75% of points: The proposal, service description, or contract defines ownership, escalation, limitations, service expectations, and how the outcome will be reported.
- 100% of points: The responsibility is contractually committed, measurable, and supported by a clear onboarding and ongoing review process.
Do not award more than half the available points in any category without written evidence or a demonstrated workflow.
|
Category |
Points |
What a strong answer looks like |
|
Response ownership |
20 |
The agreement clearly defines what the provider can do, what requires approval, who is contacted, how escalation works, and what is excluded. |
|
Telemetry coverage |
15 |
The provider identifies which business systems and data sources are covered, which are not, and how gaps will be addressed. |
|
Human analyst model |
10 |
The service explains when analysts investigate, when issues are escalated, and what the client receives when action is required. |
|
MSP coordination |
10 |
Responsibilities, contacts, approvals, ticketing, and after-hours coordination are defined before the service begins. |
|
Incident documentation and evidence support |
10 |
The provider delivers usable incident records, timelines, actions taken, findings, and executive reporting, with retention responsibilities clearly stated. |
|
Automation and AI governance |
10 |
The provider explains where automation is used, which actions require human approval, how actions are logged, and how errors are corrected. |
|
Executive reporting |
10 |
Reporting shows business impact, meaningful trends, unresolved risk, response activity, and required decisions. |
|
Pricing and operating fit |
5 |
Scope, recurring fees, overages, incident costs, exclusions, and optional services are clearly stated. |
|
Security program integration |
10 |
The service connects monitoring and response with the client’s assets, vulnerabilities, identity, recovery plans, compliance needs, and security priorities. |
The best provider is the one whose operating model matches your people, vendors, risk, and decision-making reality.
A scorecard also exposes false bargains.
A lower fee becomes expensive when containment, log retention, coordination, or after-hours work sits outside the service.
Common MDR buying mistakes
Treating 24/7 monitoring as 24/7 response
Monitoring means the service is watching for activity and can surface an issue. Response means the provider has the authority, access, and process to act.
Assuming the MSP/IT and MDR provider have already coordinated
They may have no shared ticketing workflow, contact tree, approval model, or after-hours expectation.
A logo on an integration slide is not a tested handoff.
Buying tools instead of an operating model
Strong tooling helps.
It does not guarantee clean execution when the incident crosses identity, endpoints, backups, legal, insurance, and business operations.
Ignoring evidence until an audit, claim, or board question
Evidence should be created as the work happens.
Reconstructing the timeline later is slower, weaker, and more expensive.
Never testing the first hour
A tabletop exercise reveals dead phone numbers, missing permissions, vague approvals, and contract gaps before an attacker does.
When MDR is not enough
MDR is part of a cybersecurity program. It is not the whole program. A broader MSSP may provide or coordinate some of these capabilities.
That can reduce the number of handoffs during an incident and preserve context between monitoring, remediation, recovery, governance, and executive reporting.
The value is having those services work together with clear ownership, shared context, and tested workflows.
MDR does not replace:
- Security leadership
- Risk management
- Short- and long-term maturity roadmaps
- Asset inventory and visibility
- Business impact analysis and criticality
- Vulnerability and exposure management
- Backup and recovery
- Incident response planning
- Compliance governance
- Security awareness
- Executive decisions about risk
MDR can tell you that an attacker used an old administrative account.
It cannot decide why that account existed, who approved the exception, whether the business should accept the risk again, or which program should prevent a repeat.
That work belongs to governance and security leadership.
What good MDR response ownership looks like
A strong MDR operating model has five traits:
- The provider can explain exactly what happens after a critical alert.
- Those responsible for IT know when and how they are pulled in.
- High-impact actions have defined approval thresholds, emergency authority, and escalation paths.
- A usable incident record is created as the response unfolds
- Leadership receives a business-risk summary, not a technical alert export.
The model can be simple.
It must be clear.
Ten questions to ask before signing
- What happens during the first hour after a critical alert is confirmed?
- Who can (approve, execute) isolate a device, disable an account, or block network traffic?
- Which actions are automated, analyst-led, or client-approved?
- How do you work with our MSP and internal IT team?
- What evidence do you produce during and after an incident?
- Can we review a redacted incident timeline and executive report?
- How does your service connect to asset management, vulnerability management, identity, backup and recovery, insurance, legal, audit, and compliance processes?
- How does after-hours escalation work when the primary contact does not answer?
- What is included in the monthly service, and what triggers extra charges?
- Will you test the response model with us through a tabletop exercise?
If the provider cannot explain the first hour clearly, keep asking questions.
MDR should be evaluated by what it owns
MDR should reduce time to validation, response, and, when authorized, containment.
It should also reduce confusion.
For mid-market companies, the right service defines response before the incident, produces usable evidence during and after it, and gives leadership confidence that security operations are connected to business risk.
Anything less leaves “managed” doing more work in the proposal than it does during the incident.
Before choosing an MDR provider, map who owns detection, containment, remediation, evidence, recovery, and the decision to return the business to normal operations.
Not sure whether your cyber risk is fully managed? Find out before an incident answers the question for you.
Schedule a cyber risk review with viLogics to identify gaps in your current posture, clarify response ownership, and prioritize what should happen next.
