Managed detection & response services

The service is defined by authority, not by tooling

Detection is easy to claim and hard to prove. The differentiator in a response service is the authority granted to the people watching: whether they may act on a suspicion or only report it, which actions are pre-authorised, and how long they may wait for a decision before escalating. A provider that can only generate tickets is a monitoring service with a stronger name, and the business carries the response burden at the exact moment it is least able to. Ask for the action list in writing — what may be done without approval, what requires a call, and what is explicitly out of scope — and confirm that the people who will actually use it agree with it.

• Actions permitted without approval, listed individually.
• Actions requiring a named approver, and how that approver is reached.
• How long the provider may wait before escalating.
• What is explicitly out of scope, in writing.

Telemetry: what the service can actually see

Coverage is decided by the data the provider receives, so the useful question is not whether monitoring is included but which sources feed it. Endpoint telemetry shows what ran on a device; identity telemetry shows who signed in and from where; email telemetry shows what arrived; network and cloud telemetry show traffic and configuration changes. Most serious incidents appear in more than one of those streams, and a provider watching only one has a partial picture by design. The blind spots are the systems nobody thought to instrument: an on-premises server supporting a legacy application, a site with no agent deployed, a cloud tenancy nobody connected. Ask for a list of instruments and the systems not covered by them.

• Which telemetry sources are connected, and which are not.
• Which systems have no agent, and who owns installing it.
• How long the provider retains the data it collects.
• What the provider cannot see, stated plainly rather than implied.

Triage, tuning and the alert-volume problem

A service that forwards every alert to a shared mailbox has moved the work rather than removed it. What matters is what happens between detection and decision: who triages, against what criteria, how false positives are identified, and how the rules are tuned as the environment changes. Tuning is not a one-off installation activity; it is the mechanism by which a service gets quieter and more accurate over months. Ask how severity is defined, what the provider's target is for acknowledging a high-severity detection, how an analyst distinguishes a real incident from noise in your particular environment, and how tuning requests are raised and tracked.

• Who triages, and against criteria agreed with you.
• How severity levels are defined, by impact rather than by alert type.
• The target time to acknowledge a high-severity detection.
• How tuning is requested, prioritised and recorded.

Response actions and who is allowed to take them

Response usually moves through containing the threat, removing it, and restoring normal operation, and each stage has an action that somebody must be authorised to perform. Containment may mean isolating a device, disabling an account, blocking a domain or terminating a session — all of which interrupt somebody's work and some of which may be irreversible in the moment. Decide in advance who may authorise each, including outside working hours, and what the provider may do if nobody answers. Preserving evidence is part of the same decision: containment that destroys the artefacts needed to understand the incident costs you the ability to close it properly.

• Each containment action, and who may authorise it.
• Behaviour when the named approver cannot be reached.
• What the provider does to preserve evidence during containment.
• How the business is told, and by whom.

Hours, escalation and what round-the-clock means

A claim of continuous coverage should be tested against the mundane question of who is awake. A follow-the-sun model staffs several regions so somebody is always on shift. An on-call model pages one person, which works when the rota is real and degrades when it is nominal. Both are legitimate, provided the arrangement matches the severity of what you are protecting. Ask what happens to a medium-severity detection at two in the morning, whether response outside covered hours is included in the service or billed as an incident, and whether the provider has the capability to investigate on site if something requires hands rather than analysis.

• Follow-the-sun, on-call rota, or business hours only.
• What happens to each severity level outside working hours.
• Whether after-hours response is included or charged separately.
• Who attends a site if physical action is required.

Proving it works after onboarding

The first weeks of a monitoring service are noisy, because the platform is learning what normal looks like in your environment. Treat that period as an onboarding phase with a defined end, rather than as evidence the service is failing. After it, measure the relationship on the things you agreed: detections acknowledged inside the target, the proportion that turned out to be genuine, the time from detection to containment, and what changed as a result of tuning. Then test the whole arrangement once — a tabletop exercise in which the provider walks through a plausible incident with your team, ending with the actions it would take and the decisions it would need from you.

• An onboarding period with a stated end and tuning expectations.
• Reported measures: acknowledgement time, true-positive rate, time to contain.
• A tabletop exercise with your team, once per year at minimum.
• A named person on your side accountable for the relationship.

MDR is one layer, and every layer needs an owner

A monitoring subscription answers two of the six functions in the framework most security programmes are now measured against. The NIST Cybersecurity Framework organises the work as Govern, Identify, Protect, Detect, Respond and Recover, and a detection and response service delivers Detect and Respond: it watches, investigates and escalates. Protection still lives with the business — endpoint protection, identity and multi-factor authentication, protected backups and security awareness — and governance and asset identification sit above all of it. For a distributed company the procurement test is not whether a provider offers the MDR label but whether every function, at every site, has a named owner, because it is the gap in Protect that generates the incidents Detect then has to catch.

• List the six framework functions and name the owner of each, including the provider's share.
• Confirm the endpoint population the service actually receives telemetry from, site by site.
• Check MFA coverage per application and per site, not only for remote access.
• Treat backups and their restoration tests as a service with its own accountable owner.

What changes when the estate is distributed

A headquarters-centric security programme has a blind spot exactly where a multi-site business is most exposed: the weakest location. An assessor or an underwriter evaluating a distributed company looks past the head office to the branch with a flat network, a shared local administrator account, an unsupported firewall and a backup nobody has restored, because that is where an intruder enters and where a stolen credential finds a path sideways. Two structural changes matter most. Identity becomes the control plane: in a distributed estate it links users, devices, applications and remote access, so a compromised administrator, service account or federated session can bypass branch controls that look adequate on their own. And segmentation has to be tested between sites, not only at the internet edge, by confirming that a machine at one location cannot reach the backup console, the directory or another branch's systems. Remote and home workers belong in the same inventory as the branches: a home router, a personal device and a shared household network are part of the estate, and a programme that covers the office but not the spare room has no answer for how a credential was stolen. Keep the site list and the user list in one picture rather than treating remote access as a networking footnote.

• Keep site-level records of endpoint, identity, backup and perimeter coverage, with exceptions named.
• Separate administrative and service accounts from ordinary user identities, and log both.
• Test whether a workstation at one site can reach backup or management systems at another.
• Centralise logs outside the domain a compromise would reach, and keep clocks synchronised.

Writing the split of duties between providers

Two providers can each do their own job correctly and still lose an incident to the seam between them. A managed service provider runs infrastructure, endpoints, identity and backups; a monitoring and response provider watches telemetry and investigates. The failure mode is an alert nobody owns: the detection service sees malicious activity, but the endpoint agent, the identity directory and the firewall it would need to contain it all sit with the other provider, and each waits for the other. Write the split as an authority matrix rather than a description — which actions each side may take without asking, which require your authorisation and from whom, the order in which affected site managers are contacted, who preserves and hands over evidence, the notification window for a confirmed incident, the hours each side covers, and who keeps the data when the contract ends. Then rehearse it once, because a matrix nobody has walked through is a document rather than a capability. Name the person on each side — not the provider entity but the role — so that at two in the morning there is a human to reach, not a support queue.

• Name who may isolate an endpoint, disable an account or block a domain, and who must approve it.
• State the notification window for a confirmed incident and the out-of-hours contact path.
• Assign evidence preservation and hand-over to one provider explicitly, in writing.
• Agree who owns logs, telemetry and evidence after the contract ends.

PUT THE OPTIONS SIDE BY SIDE

Your comparison checklist

Common questions