MDR Guide: Choosing and Working with a Provider

Managed detection and response (MDR) buys you analysts who watch and act on your environment around the clock, but it also hands an outside organisation privileged access to your systems and a say in what happens during your worst day. Most disappointing engagements fail on scope and authority rather than skill: telemetry never received, actions nobody pre-approved, escalations to the wrong phone at 3am, provider accounts that outlived the contract. This guide compares MDR with MSSP, SOC as a service, managed XDR and co-managed SIEM, and covers scope, response authority, onboarding, service levels, provider access as privileged third-party identity, and exit. It is vendor-neutral and written for security leaders, SOC managers and procurement teams buying or running an MDR service.

Key takeaways

• Outsourcing operations does not outsource accountability. CISA puts it plainly: "Outsourcing IT services does not absolve executives of risk management responsibilities." Write down what the provider does and what stays with you.
• Response authority is the most important clause. List the actions the provider may take without asking, those that need your approval, and those it must never take, with named approvers and timeouts.
• Coverage is defined by telemetry. A provider can only detect what it ingests; map log sources and endpoints to the threats you care about and track the coverage percentage monthly.
• Provider accounts are privileged third-party identities. Require MFA, least privilege, time-bound delegated access, separate named accounts and auditing, and remove them at exit. The joint MSP advisory says customers should ensure MSP accounts "are not assigned to internal administrator groups".
• Plan the exit at signature. Agree data export formats, retention and deletion, revocation of every account and agent, and transition timeframes before go-live, when you still have leverage.

What MDR is, and how it differs from related services

MDR is an outcome-based service: the provider runs detection on your telemetry, investigates with its own analysts, hunts, and takes or directs response actions. NIST SP 800-61 Rev. 3 recognises the model, listing "outsourcing a security operations center [SOC] to a managed security services provider [MSSP]" as a sourcing option and describing "a shared responsibility model in which the organization transfers some of its responsibilities to a provider", adding that "These responsibilities should be clearly defined in a contract". Market labels overlap, so compare services by what they actually do.

MDR is not incident response for a major breach. Many MDR contracts stop at containment and handover, with full investigation, forensics and recovery bought separately; check yours. In the UK, NCSC assures incident response companies under its Cyber Incident Response (CIR) scheme at Standard and Enhanced levels against its CIR Technical Standards, and advises that "all UK organisations should use an NCSC-assured Cyber Incident Response provider". See the Incident Response Guide.

Defining scope and shared responsibility

Start from the threats and assets that matter, then decide which telemetry the provider needs. NIST's ID.AM-04 guidance says "inventories of the services provided by the organization's suppliers should be available"; for MDR that inventory is the scope schedule.

• Telemetry: endpoints and servers (by operating system), identity provider and directory sign-in and audit logs, email, cloud control planes, SaaS audit logs, network and DNS, OT where relevant. State the percentage of assets covered, not just the source types.
• Use cases: which detections the provider runs and whether it will build custom detections for your crown jewels and business applications.
• Hunting: whether it is proactive and scheduled, triggered by intelligence, or only after an alert. Canada's Cyber Centre asks buyers to check whether a provider offers "proactive threat hunting and reactive incident response capabilities".
• Exclusions: what is not covered (unmanaged devices, OT, personal devices, some SaaS), written into the contract so nobody assumes coverage.

NCSC's guidance on choosing a managed service provider recommends exactly this kind of responsibilities matrix and says to "insist on clear, detailed contracts that specify responsibilities, response times, and liability".

Response authority and pre-approved actions

NIST SP 800-61 Rev. 3 expects organisations to understand the "restrictions on what the service provider can do". Make them explicit in a response authority matrix, reviewed quarterly.

• Named approvers and deputies: by role, with phone numbers that work out of hours, tested at onboarding and after staff changes.
• Timeout rule: decide whether an unanswered request escalates, proceeds or lapses. Nobody answers at 3am, which is the case for pre-approving workstation isolation when ransomware precursors appear.
• Exclusion list: safety-critical systems, payment and trading platforms, domain controllers and break-glass accounts that are never touched without approval.
• In-tenant work follows your process: where the provider works inside your tooling, the Canadian contract guidance suggests it should "adhere to the Client's incident response procedures and timelines".
• Machine-made decisions: ask which triage verdicts and actions are automated or AI-driven, and how the provider measures what its automation closes incorrectly.

Where identity fits: provider access as privileged third-party identity

An MDR provider needs standing access to your EDR console, SIEM, identity provider and often cloud accounts, and its sensors run with system privileges on every host. That makes the provider's accounts, API keys and agents some of the most powerful identities in your estate, and an attractive route in. MITRE ATT&CK T1199 Trusted Relationship describes it: "Adversaries may breach or otherwise leverage organizations who have access to intended victims", with procedure examples of groups such as menuPass and APT29 using managed service providers' access. The BeyondTrust breach showed how one stolen API key for a remote support platform became an incident at the US Treasury.

The 2022 joint advisory from the UK, US, Australian, Canadian and New Zealand agencies (AA22-131A) sets the baseline for customers:

• MFA on every provider account: "Contracts should also require MFA to be enforced on all MSP accounts used to access customer environments."
• Least privilege: MSP accounts should "only have access to the services/resources being managed by the MSP", and must not sit in internal administrator groups.
• Audit use: "Verify, via audits, that MSP accounts are being used for appropriate purposes and activities."
• Remove at exit: "Customers should be sure to disable MSP accounts that are no longer managing infrastructure."

Platform mechanisms make this practical:

• Microsoft 365 and Entra: granular delegated admin privileges (GDAP) replace the old blanket delegated access. Relationships are role-scoped and time-bound, with a maximum duration of two years; auto-extend adds six months and cannot be used with the Global Administrator role. Grant only the security roles the service needs, and review relationships quarterly.
• AWS: give the provider an IAM role to assume, not IAM users with long-term keys. AWS's guidance is "Do not give Example Corp access to an IAM user and its long-term credentials", and the trust policy should require sts:ExternalId to prevent the confused deputy problem, with the external ID generated by the provider and unique per customer.
• Named individuals, not shared logins: provider analysts sign in as individuals through federation or invited guest accounts, so you can see who acted and remove leavers.
• Ingestion credentials: API keys, service principals and webhook secrets that ship your logs are non-human identities; vault, scope to read-only and rotate them.
• Verify provider staff: agree how your help desk verifies a caller claiming to be from the provider. The Marks and Spencer cyberattack involved impersonating a third-party user.

See the Third-Party Access Guide and the Privileged Access Management Guide.

Onboarding step by step

1. Kick-off and scope schedule: confirm in-scope assets, log sources, exclusions, crown jewels and business hours versus 24x7 expectations.
2. Provision access: create named, MFA-protected, least-privilege provider accounts and roles (GDAP, cross-account roles, EDR console roles); record each in your PAM or third-party inventory with an owner and end date.
3. Deploy sensors and connectors in rings: pilot group first, then workstations, then servers, checking performance and conflicts with existing security tools. Keep the uninstall procedure and tamper protection settings documented for rollback.
4. Verify telemetry: for each source, confirm events arrive, are parsed and trigger a test detection. A source that is connected but not parsed is not covered.
5. Baseline and tune: expect a learning period; supply admin tools, scanners and service account behaviours so the provider can tune noise instead of suppressing whole detections.
6. Agree the runbook: contacts, escalation tree, response authority matrix, communication channels and severity definitions.
7. Test before go-live: run benign attack simulations and a tabletop exercise in which the provider escalates and requests approval out of hours. AA22-131A asks customers to ensure incident response and recovery plans "are tested at regular intervals".
8. 30, 60 and 90 day reviews: coverage gaps, false positive themes, escalation quality and any actions taken.

Service levels and metrics

Agree definitions as carefully as the targets. The Canadian contract guidance gives a template clause to "commence remediation actions within [insert specified timeframe]" and recommends monthly performance reporting on detection, response times and outcomes.

NCSC's MSP guidance gives "under 1 hour for urgent issues" as an example response time; set your own per severity, and tie service credits to notification and containment, not only acknowledgement.

Data residency, logs and access to your data

• Where data lives: the provider's platform, its analysts' locations and its sub-processors. Canada's guidance asks buyers to assess "data residency considerations and security measures" for stored monitoring data. Under UK and EU GDPR the provider is usually a processor, so an Article 28 contract applies, including authorisation of sub-processors and return or deletion of personal data at the end of the service.
• Your access to raw data: AA22-131A recommends that "all organizations store their most important logs for at least six months", and CISA advises customers to "maintain their own offsite backups of essential records and network activity logs". Do not let the provider's platform be the only copy.
• Retention: NCSC advises that "Any specific log retention periods required for your business should be detailed in your contract." See the Log Management and Retention Guide.
• Secondary use: whether your telemetry trains the provider's models or feeds shared intelligence, and in what form.
• Provider's own incidents: NIST GV.SC-05 asks that supplier agreements include "incident disclosure and information sharing"; require notification when the provider itself is breached. The Okta support system breach shows how customer data held by a vendor's support function can expose many customers at once.

Exit and data return

1. Notice and transition: notice periods, transition assistance and overlap with the next provider so monitoring never stops. Canada's guidance recommends defining "timeframes and processes for migration activities" and addressing data ingress and egress costs.
2. Data export: raw logs, alerts, case records and reports in documented, machine-readable formats, within an agreed number of days.
3. Deletion: written confirmation of deletion of your data, including backups and sub-processor copies, after export.
4. Revoke every identity: provider user accounts, guest accounts, GDAP relationships, cross-account roles, API keys, service principals and VPN or remote access accounts. Reconcile against the onboarding record.
5. Remove sensors: uninstall agents (which may need provider-held uninstall tokens) and replace coverage before removal.
6. Detection content: agree in advance whether custom detections built for you transfer, and in what format.

Evaluation criteria

NCSC recommends MSPs with "recognised certifications such as Cyber Essentials Plus"; whatever the certificate, check its scope covers the service you are buying.

Decision guidance

• Small organisations: MDR is usually the only realistic route to 24x7 detection. Prioritise endpoint and identity coverage, generous pre-approved containment and a simple escalation tree.
• Mid-sized organisations: co-managed models keep detection knowledge in-house while the provider covers nights and weekends.
• Large or regulated organisations: MDR often covers specific estates (subsidiaries, OT, out of hours) alongside an internal SOC. Insist on integration with your case management and SIEM so there is one incident record.
• Provider-supplied tools versus your own: bundled tooling is faster to deploy but deepens lock-in; using your EDR and SIEM makes exit easier and keeps the data yours.

Monitoring the provider

NIST DE.CM-06 says "External service provider activities and services are monitored to find potentially adverse events". Treat the provider as you would any privileged administrator.

• Log and alert: provider account sign-ins from unexpected locations or outside agreed IP ranges, role changes on provider accounts, new GDAP relationships or cross-account trusts, sensor uninstall or tamper events, and bulk data exports.
• Validate: run attack simulations quarterly and compare what was detected, escalated and contained with the contract.
• KPIs: telemetry coverage percentage; time to notify by severity; time to contain for pre-approved actions; share of escalations judged actionable; simulated techniques detected; provider accounts with MFA, an owner and an in-date review (target 100%).

Framework mapping

Common failure patterns

• Assumed coverage: cloud, SaaS or server logs were never onboarded, and the provider detected nothing because it saw nothing.
• Authority not agreed: the provider saw ransomware staging, could not reach an approver and waited.
• Over-privileged provider access: a shared provider admin account in the domain admins group, without MFA.
• Single copy of logs: logs lived only in the provider platform and were lost or locked at contract end.
• Orphaned access after exit: GDAP relationships, cross-account roles and API keys survived the contract by months.
• Alert forwarding sold as MDR: escalations without investigation, leaving your team doing the real triage.

Practitioner checklist

• Write a scope schedule listing in-scope assets, log sources, coverage percentage and exclusions.
• Agree a responsibilities matrix and a response authority matrix with named approvers and timeout rules.
• Provision provider access as named, MFA-protected, least-privilege, time-bound accounts and roles, recorded in your third-party inventory.
• Keep your own copy of critical logs for at least six months.
• Contract for time to notify and time to contain by severity, with monthly reporting.
• Test escalation and approval paths out of hours before go-live and twice a year.
• Monitor provider accounts, delegated relationships and sensor tampering in your own SIEM.
• Validate detection with quarterly attack simulations.
• Document exit: export formats, deletion confirmation, revocation of every account and key, sensor removal.

Standards and references

• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NCSC, CISA and partners: Protecting Against Cyber Threats to Managed Service Providers and their Customers (AA22-131A)
• NCSC: Choosing a managed service provider (MSP)
• CISA: Risk Considerations for Managed Service Provider Customers
• Canadian Centre for Cyber Security: Recommended contract clauses for security operations centre procurement (ITSM.00.500)
• NCSC: Cyber Incident Response (CIR) scheme
• MITRE ATT&CK: T1199 Trusted Relationship
• AWS: Access to AWS accounts owned by third parties

Related NHI Mgmt Group resources: Third-Party Access Guide · Privileged Access Management Guide · Incident Response Guide · SIEM Guide · Detection Engineering Guide