Safeguard
Research•

What is managed detection and response, and what should you define first?

Managed detection and response outsources threat monitoring and response. NIST SP 800-61 Rev. 3 says what to settle: authority to act, access and handoffs.

Safeguard Security Team
5 min read

Managed detection and response (MDR) is a service in which an outside provider watches your environment for threats and takes part in responding to them. It is an industry term, not a NIST one. NIST SP 800-61 Rev. 3 treats such an arrangement as a shared responsibility that must be defined in a contract.

What does NIST say about outsourcing detection and response?

NIST SP 800-61 Rev. 3 (April 2025) lists incident handlers as one role in incident response and says they might be on staff, on contract, or available when needed. Its on-contract example is outsourcing a security operations center to a managed security services provider, and it says many organizations mix approaches, for example handling basic incidents internally and bringing in third parties for certain ones.

It then describes third parties filling a primary role, such as a provider performing incident detection, response and recovery. It calls this a shared responsibility model in which the organization transfers some responsibilities to a provider, and it says those responsibilities should be clearly defined in a contract. MDR sits inside this description, whatever a vendor chooses to call it.

What can a provider do better than you?

NIST notes that a service provider may detect malicious activity sooner than a single organization because it can correlate events across its customers, and may use knowledge from one customer's incident to prevent similar ones at others. For a small team without round-the-clock coverage, that scale and staffing can be real advantages. The claim to test is whether the provider's detections actually fit your environment.

What risks does outsourcing add?

NIST points out that service providers often have privileged access to systems and may see sensitive data. It says the risk of malicious insiders at the provider, or of the provider itself being compromised, should be considered, and suggests non-disclosure agreements and contract clauses to deter unauthorized disclosure. Your provider's access becomes part of your attack surface. NIST's profile also treats external service provider activity as something to monitor, and asks for suppliers to be known, prioritized and included in incident planning and response.

What should the contract and runbook define?

NIST specifically says to define the division of responsibilities, including information flows, coordination and authority to act on the organization's behalf. It also says to define restrictions on what the provider may do, giving as examples sharing sanitized incident information with other customers and making and implementing operational decisions such as immediately deactivating services to contain an incident.

That last point is the heart of an MDR decision. A provider that can isolate a laptop in minutes is useful. A provider that can disable a production service without asking is a risk you must accept deliberately.

A constructed example

A 120-person company with two IT staff signs with a provider for monitoring and response. Before go-live they agree a table. The provider may isolate a user's laptop from the network at any time, and must call the on-call IT lead within 15 minutes. It may disable a user account only after confirmation from the company. It may never touch production servers without a named approver. Alerts go into the company's ticket system, and the provider can see logs but not mail content. Three months later, on a weekend, a phishing click leads to a compromised laptop. The provider isolates it, calls, and the IT lead approves an account disablement within the hour. The pre-agreed limits mean nobody argues about authority during the incident.

How to check or apply this

  1. Decide what you need: detection only, or detection plus action, and during which hours.
  2. List the data sources the provider needs and the access it needs to act. Give the minimum, and log what it does.
  3. Define actions by tier: what it may do alone, what needs approval and what it may never do.
  4. Specify handoffs: who is called, how, in what time, and what information passes each way.
  5. Ask how detections are tested against your environment, and how false positives are handled.
  6. Require rights to export your data and the provider's findings, and plan an exit.
  7. Run a tabletop exercise with the provider, and update the plan afterward.

This is a different category from what Safeguard does. Safeguard works on software supply chain and application security, such as dependency scanning and reachability analysis, and does not provide detection and response services.

Quick check

Does hiring an MDR provider transfer my legal responsibility?

Not automatically. NIST describes a shared responsibility model in which you transfer some responsibilities, and says they must be clearly defined in a contract. You still own the outcome for your organization.

Should a provider be allowed to shut down systems on its own?

Only if you have decided so deliberately. NIST says to define restrictions on actions such as deactivating services to contain an incident.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.