What should security teams ask before renewing an MDR contract?

Why This Matters for Security Teams

Renewing an MDR contract is not just a procurement exercise. It is a test of whether the provider can actually support the organisation’s detection, investigation, and response model under real operating conditions. Security teams often focus on service summaries and dashboard coverage, but the harder question is whether the MDR partner can show evidence of judgment, containment authority, and continuity of context across analysts.

This matters because MDR is frequently expected to bridge gaps between SIEM, EDR, identity telemetry, and incident response. If the provider cannot explain how it handles custom detections, escalation thresholds, and response handoffs, the contract may look healthy while the security outcome remains weak. That is especially important in environments where privileged access, API keys, service accounts, and other secrets create a faster attack path than endpoint malware. The NIST SP 800-53 Rev 5 Security and Privacy Controls framework makes clear that monitoring, response, and accountability have to work as connected controls, not separate service promises.

Teams also need to check whether the provider’s operating model matches their environment. A strong MDR service for a cloud-first company may still be weak for identity-driven compromise, SaaS abuse, or non-human identity sprawl. In practice, many security teams discover those limits only after a real compromise has already tested the provider’s response path.

How It Works in Practice

The most useful renewal questions are the ones that force the provider to describe what happens after an alert is created. Security teams should ask for evidence, not general claims. That means looking for sample investigations, escalation paths, containment authority, and the point at which the provider stops observing and starts acting. If the MDR service can only notify, but not isolate a host, disable an account, or block a token, the team should understand that limitation before signing again.

For identity-heavy environments, the operational test is whether the provider can correlate endpoint, cloud, and identity signals into a coherent incident story. That includes suspicious login chains, unusual privilege elevation, OAuth consent abuse, service account misuse, and secrets exposure. The OWASP Non-Human Identity Top 10 is useful here because it highlights how unmanaged machine identities and over-permissioned credentials become an attacker’s fast lane. MDR coverage should reflect that reality rather than focus only on human user compromise.

A practical renewal review usually asks the provider to explain:

• What percentage of alerts received full documented investigations, not just queue triage.
• How custom detections were created, tuned, and retained across analyst turnover.
• Which containment actions the provider could execute directly versus recommend only.
• How identity telemetry, cloud logs, and EDR findings were linked during incidents.
• What evidence exists that response time improved after onboarding and tuning.

Teams should also ask how the MDR service maps to control ownership. If the provider says it “monitors everything” but cannot identify which alerts are escalated, suppressed, or closed with rationale, the renewal conversation is missing the operational layer. These controls tend to break down in highly distributed environments with multiple identity stores, inconsistent log coverage, and outsourced admin rights because correlation becomes brittle and response authority is unclear.

Common Variations and Edge Cases

Tighter MDR requirements often increase cost and administrative overhead, requiring organisations to balance faster containment against the friction of broader provider authority. That tradeoff is real: a provider that can isolate endpoints, disable accounts, or revoke tokens may improve response speed, but only if the client has defined boundaries and approval paths.

There is no universal standard for how much action an MDR provider should take without explicit approval. Current guidance suggests the answer depends on the organisation’s risk tolerance, sector obligations, and identity architecture. Regulated environments may want stronger evidence of governed response workflows, while leaner teams may prioritise visibility and escalation quality over direct containment. The key is to avoid vague renewal language such as “24/7 protection” unless the provider can define what protection actually means in operational terms.

Edge cases matter most when the environment is dominated by SaaS, cloud control planes, service accounts, and automated workflows. In those settings, endpoint-only MDR may miss the real attack surface. Security teams should ask whether the provider understands non-human identity abuse, whether it can handle alert fatigue from automation-heavy systems, and whether its analysts can distinguish normal machine-to-machine activity from compromise. When that answer is unclear, the renewal should be treated as a redesign discussion, not a routine extension.

Related resources from NHI Mgmt Group

• What should teams ask before adopting a new security feature from a vendor webinar?
• What should procurement teams ask before renewing an identity platform?
• How should security teams test partner API onboarding before production?
• How should security teams govern API partner onboarding before access control starts?