Managed detection and response is a staffed service: a provider’s analysts watch your environment around the clock, investigate what fires, and act on what turns out to be real. For a company of 10 to 200 people with no analyst on payroll, that staffing is the entire point. What most buyers never settle is the paperwork underneath it. Six terms decide whether an analyst at 2am can isolate a compromised laptop on their own authority or can only write you an email you will read at 8. Both get sold as managed detection and response, and only one acts while your office is dark. This guide covers the six traps we see in signed contracts, and the language that closes each one.
The Five Points That Decide Whether Your Provider Can Act
Here is what matters most in the contracts we review for small and mid-sized companies:
- Detection and response are two purchases, not one. Detection is watching. Response is doing something about it. A contract can deliver excellent detection and zero response, and still carry the letters MDR on the invoice.
- Containment authority belongs to you, so you have to grant it. No provider can isolate your finance server without permission. If nobody scoped that permission in advance, the default answer at 2am is to wait for you.
- The response clock usually measures the wrong thing. Most published response times measure how fast someone acknowledges an alert, not how fast the threat stops spreading.
- Automated containment has a blast radius. Isolating the wrong host can halt your business as effectively as the intrusion would. That is an argument for scoping isolation carefully, never for skipping it.
- This is a shared operating model, not an outsourced problem. The provider brings analysts and tooling. You bring decision rights, an accurate asset list, and a person who answers the phone.
Why Managed Detection and Response Fails Small Teams at 2am
Managed detection and response fails small teams at 2am because the service was designed around a customer who has someone awake to receive the handoff, and most companies under 200 people do not. Read a provider’s capability page and you will find continuous monitoring, threat hunting, and investigation. All of that is real work, and it ends at a boundary written in your contract rather than on the website.
Here is the pattern we see in the wild. An alert fires at 01:40 on a Saturday, an analyst confirms it is credential theft rather than noise, and then the process reaches the point where somebody has to disable an account or pull a machine off the network. If the agreement never granted that authority, the analyst does what the agreement allows: they open a ticket, send a notification, and try the phone number on file. By the time your operations manager sees it, the attacker has had six hours inside a network nobody was defending.
The failure is not laziness on the provider’s side. It is a permissions gap left open at signature that only becomes visible during the one event you bought the service for. Our guide to how managed detection and response works covers the mechanics of the service. This article covers the clauses that decide whether those mechanics reach your network at the hour you need them.
Three Managed Detection and Response Contract Traps That Hide in the Response Clause
The response clause is where managed detection and response contracts do most of their quiet narrowing, because the word “response” carries two meanings and vendors are rarely forced to pick one. Read it with a pen and treat every verb as a promise you will hold somebody to.
Trap 1: “Response” That Only Ever Means Notification
The first trap is a response clause whose verbs are all about telling you things. Look for words like notify, alert, escalate, advise, and recommend. Every one of those describes a message. None of them describes an action taken on your network. A contract built entirely from those verbs is a monitoring and notification agreement, and for a company with no security staff, the notification lands on a desk where nobody is qualified or awake to act on it.
The counterargument deserves a fair hearing. Some firms genuinely want notification only, because they have an internal team and real reasons to keep every hand on their own systems. For a 40-person accounting practice, that reasoning does not transfer. There is nobody to hand off to at 2am, so a notification-only agreement moves the hardest decision of the incident onto the least prepared person available.
The fix is to ask for action verbs in writing: isolate, disable, block, terminate, quarantine, revoke. Then ask the question that settles it. What can your team do on my network without calling me first? The answer tells you which product you are buying, whatever the cover page says.
Trap 2: Containment Scope Nobody Ever Defined
The second trap is granting containment authority in principle while never scoping it in practice. A provider given blanket permission to isolate anything will hesitate on your production database, and rightly so. A provider given no scope at all will hesitate on everything. Both hesitations cost you the same hours.
Scoping means writing two lists before an incident, not during one. The first is a pre-authorized list: endpoints, user accounts, and segments an analyst may act on immediately with no phone call. Laptops, workstations, and standard user accounts usually belong here, because isolating a laptop at 2am costs one person one morning of inconvenience. The second is the exclusion list: the domain controller, the line-of-business server, anything where an isolation would stop the company. Those stay call-first, with a named person to call.
Companies push back on this, and the objection is honest. Nobody wants to hand an outside analyst a switch that can take a server offline. That instinct is right, and the answer is a narrow written scope rather than no scope. An analyst who knows which machines they may touch moves in minutes. An analyst without that scope writes an email.
Trap 3: A Response Clock That Measures Acknowledgement
The third trap is an SLA whose numbers describe how fast a human notices, not how fast the threat stops. A fifteen minute mean time to acknowledge is a fine operational metric and a poor safety guarantee. Ransomware does not wait for acknowledgement, and neither does an attacker moving laterally with valid credentials.
What matters is a contracted mean time to respond, measured to the moment containment begins, with the measurement method written down. Ask which events the clock covers, since a number applying only to critical severity is worth little if the provider also owns severity assignment. Ask whether it runs at 3am on a holiday weekend at the same rate it runs on a Tuesday. Ask what the remedy is when the number is missed, because a target with no consequence is a marketing figure.
Providers will point out, fairly, that containment time depends partly on you. If your asset inventory is wrong or the agent was never deployed to half your machines, no clock survives that. The honest version of this term is mutual: they commit to a containment window, you commit to coverage and an accurate inventory. Our managed security services work is scoped that way on purpose.
Three Managed Detection and Response Terms Your Provider Needs From You
Managed detection and response is a shared operating model, so three of the six traps sit on the customer side. These are the terms a provider cannot write for you, and their absence is the most common reason a well-staffed service stalls at the moment of decision.
Trap 4: No Named Escalation Roster or After-Hours Decision Rights
The fourth trap is an escalation path that names a company instead of people. A clause saying the provider will contact the client is not a roster. A roster is names, mobile numbers, an order, and a rule for what happens when nobody answers.
That last rule is the one that gets skipped, and it is the one that decides your 2am. Write down what the analyst does after three failed contact attempts. The two honest answers are “proceed with containment inside the pre-authorized scope and document it” or “hold and keep trying.” Pick one deliberately. A contract silent on the point defaults to holding, because no analyst invents authority at 2am on a call nobody answered.
Keep the roster current, and give it a review date. Incidents slow down because the emergency contact left the company nine months earlier and no clause required anyone to notice. The split that works is the one in our breakdown of co-managed IT: the provider owns the watching and the acting, you own the decision rights and the phone tree.
Trap 5: No Definition of Contained, and No Handback Criteria
The fifth trap is a contract that promises containment without defining it. Containment can mean an account is disabled, a host is off the network, an attacker’s access is severed, or the incident is fully remediated and everything is back in service. Those are four different states, hours or days apart, and they are four different amounts of work.
Write the definition down, then write the handback. What does the provider deliver when the acute phase ends, on what timeline, and in what form? A written timeline of what happened, which machines were touched, what was contained and when, and what remains for your team or your IT partner to finish. Without that, a “resolved” ticket at 6am tells you nothing about whether you can reopen the office.
There is a reasonable opposing view: over-specifying states can turn an incident into a paperwork exercise while an attacker is live. The resolution is to define the states in advance so nobody is drafting definitions mid-incident. When the acute phase turns into a breach with notification duties, that is separate work with its own clock, which is why our data breach incident response and ransomware response engagements are scoped apart from routine monitoring.
Trap 6: Coverage You Assumed Rather Than Scoped
The sixth trap is assumed coverage, and it has four common shapes. Signal scope is the first: endpoints, identity, email, cloud, and network are separate feeds, and a contract covering endpoints alone will not see an attacker who signs in with valid credentials and touches no laptop. Ask which feeds are in scope.
The onboarding gap is the second. Between signature and full agent deployment there is a period, sometimes weeks, when coverage is partial. Ask when the response commitment starts, since a provider is not accountable for machines they cannot see. Data retention is the third: investigating a quiet intrusion means looking back, and a 7-day telemetry window cannot answer a question about last month. The fourth is exit. If you leave, does your history leave with you, and in what format?
Ask also how much of the triage is automated and how much is a person. Automation is what makes 2am coverage affordable, and our look at automated threat detection and response covers where it helps and where it needs a human. A provider who can show which decisions are automated, which are analyst-reviewed, and how their detections map to the MITRE ATT&CK framework is describing a real operation.
What a 2am Handoff Looks Like When the Terms Are Right
A correctly scoped managed detection and response engagement produces a boring 2am, and boring is the outcome you are paying for. An alert fires at 01:40. An analyst who is already awake and already staffed triages it against your environment and confirms credential theft rather than a false positive.
Because a pre-authorized scope exists, the analyst disables the compromised account and isolates the laptop it authenticated from, both inside the written boundary, without a phone call. Because an escalation roster exists, your operations lead gets a call anyway, and when nobody answers at 01:55 the analyst proceeds under the contact-failure rule rather than stopping. Because containment is defined, the ticket says what state was reached, and a written timeline is waiting when your team logs in, with the finance server flagged as untouched and call-first.
Nothing there required your presence, and that is the whole product. If you are still comparing vendors, our review of managed detection and response providers for mid-sized companies covers that side of the question.
Frequently Asked Questions
Is managed detection and response the same as an MSSP?
No. A managed security service provider typically monitors tools and forwards alerts to your team, leaving the decision about what to do next with you. Managed detection and response is staffed to investigate and, where your contract grants it, to contain. The practical difference shows up at 2am, when one model sends a message and the other takes an action.
Can an MDR provider contain a threat without asking me first?
Only if your contract says so, and only within a scope you defined. Containment authority is your permission to grant, so a provider with no written scope will default to notifying you and waiting. The workable arrangement is a pre-authorized list of endpoints and user accounts an analyst may act on immediately, plus an exclusion list of production systems that stay call-first.
Do we still need internal IT if we buy managed detection and response?
Yes, though the role changes. The provider brings the analysts, the tooling, and the overnight coverage. Someone on your side still owns the asset inventory, the escalation roster, patching, and the remediation work that follows containment. Most companies run this alongside their existing managed IT services rather than in place of them.
What response time should we hold a provider to?
Hold them to a contracted mean time to respond measured to the start of containment, not a mean time to acknowledge. Confirm which severities the number covers, whether it holds overnight and on holidays, and what the remedy is if it is missed. A response target with no consequence attached is a marketing figure rather than a commitment.
How long before an MDR service is actually protecting us?
Longer than the signature date, which is why the onboarding gap is worth asking about directly. Coverage begins when agents and log sources are deployed across your real inventory, and that takes days to weeks depending on how many machines and cloud accounts are in scope. Ask the provider to state in writing when the response commitment starts.
The Experience Behind This Guidance
We review these agreements often, usually for companies between 10 and 200 people who have just learned that the service they bought sends emails rather than takes action. The pattern repeats: the technology on offer is capable, and the authority to use it was never written down. That is a fixable paperwork problem, and fixing it before an incident costs a conversation rather than a weekend.
Mindcore has spent years running security operations for small and mid-sized companies across managed IT, cybersecurity, and compliance work, which is where this reading of the contract language comes from. Matt Rosenthal, our CEO, focuses the firm on operational security that a company without a dedicated security team can actually run day to day, because a control nobody can operate is not a control.
Settle These Six Terms Before Your Next Alert Fires
Managed detection and response earns its cost at the hour nobody is watching, and six clauses decide whether it does. Confirm the response clause carries action verbs rather than notification verbs. Write a pre-authorized containment scope and an exclusion list. Hold the clock to containment rather than acknowledgement. Name real people in an escalation roster and decide what happens when nobody answers. Define what contained means and what you receive at handback. Scope your signals, onboarding window, retention, and exit. None of that requires a security background, and all of it is cheaper to settle at signature than during an incident.
If you want a second read on an agreement you are about to sign, or on one already running, bring the contract to a free strategy call. You will leave knowing which of the six terms is missing and what language closes the gap.
