What to look for when choosing an MDR partner

01.1. Real 24/7 coverage

Ask who answers at 3 a.m. on a Sunday, and how fast. "Our platform monitors continuously" is not an answer, because platforms do not investigate. You want to know whether a named analyst role is awake, what the target response time is, and what happens on public holidays.

Ask how many analysts handle how many customers. Ask what happens if two customers have incidents at once. Good providers answer with specifics. Weak ones talk about technology.

02.2. Response, not just alerts

Some providers detect and then email you. That is monitoring, not response. Ask whether they can isolate devices and disable accounts, or only recommend it.

Check how that works in practice. What access do they need? Who approves actions? Can you set rules, such as "isolate any laptop automatically, but call first for production servers"? The more the provider can safely do on its own, the shorter your exposure.

03.3. Coverage of where you actually run

Your risk is not only on laptops. List where your business runs: endpoints, servers, cloud accounts, identity providers, email and SaaS apps. Then ask which of these the provider monitors, and at what depth.

A common gap is identity. Many breaches involve stolen credentials, so a service that ignores sign-in activity is missing the front door.

04.4. Clear escalation

Ask who they call, when, and what they need from you. Good escalation has named contacts, deputies, an order of calls and a fallback if nobody picks up. Agree severity levels and what each one triggers.

This is where tests reveal problems. An analyst can find a threat in minutes and then lose time trying to reach someone who can approve action. Work this out before an incident.

05.5. Plain reporting

Monthly reports should be readable by a non-specialist. They should say what happened, what was done, what trends appear and what you should fix. A report that lists thousands of blocked events tells you nothing.

Ask to see a sample report. If you cannot understand it, your board will not either.

06.6. Exit terms

You should own your logs and detection rules if you leave. Ask about data export, rule portability and notice periods. A provider that locks in your data is telling you how it expects to keep you.

07.How to test a vendor

Ask every vendor for a walk-through of a recent real incident, anonymised. How they tell the story tells you how they work. Listen for:

• A clear timeline: what was detected, when and by whom.
• The decisions the analyst made, and why.
• What the customer did, and what went wrong.
• What changed afterwards.

A vendor who can only describe features, or who cannot name a single thing that went wrong, has either little experience or little honesty.

You can also ask for a trial with simulated events, and time the response.

08.A comparison checklist

• Named 24/7 coverage and response times in writing.
• Actions they can take on their own, and those that need approval.
• Sources monitored, including identity and cloud.
• Escalation process with deputies.
• Sample monthly report.
• Ownership of logs and rules on exit.
• A recent anonymised incident walk-through.

09.Red flags during sales calls

• Vague answers about who is awake at night.
• No sample report, or only a polished dashboard screenshot.
• Promises of "zero false positives" or "complete protection".
• Reluctance to explain what they cannot do.
• Pressure to sign before you have seen how incidents are handled.

Any one of these deserves a follow-up question. Several together are a reason to walk away.

10.Fit for your size and sector

A twenty-person company and a manufacturer with plant systems need different things. The manufacturer needs a provider that understands operational technology and the cost of taking a machine offline. A software business needs strong cloud and identity coverage. Ask for examples from companies like yours, and be wary of generic answers.

11.After you sign

Treat the first ninety days as a trial. Review alert volume, response times and report quality. Run a simulated event and time it. Keep a list of what worked and what did not, and review it with the provider. A good partner welcomes this, because it improves the service.

12.Common mistakes

• Choosing on price alone. The cheapest service often means alerts only.
• Not defining who approves actions. Delays happen when nobody is sure.
• Ignoring onboarding effort. Tuning takes weeks, and your team must take part.
• Never testing after signing. Run simulated events and keep doing it.

13.Contract points that matter

Read the agreement for practical details, not marketing. Check what the service level promises, in hours and in response targets. Check what counts as an incident, and whether extra work is charged separately. Check liability and the limits on what the provider will do for you. Look at how changes of scope are handled, since your environment will change.

Ask what happens if the provider's own systems are compromised. A good answer covers access control, logging of analyst actions and notification duties. Providers hold powerful access to your estate, so their discipline is part of your risk.

14.Involve the right people

Do not leave the choice to IT alone. Include whoever owns risk, someone from operations who understands which systems cannot go offline, and a business lead who will approve actions at night. Agree internally who has that authority before you sign, because the first real incident is a bad time to find out.

15.Check the tooling question

Ask which tools the service runs on and who pays for them. Some providers bring their own platform, others work with the products you already own. Each is fine, but the cost, the data location and the exit terms differ. Ask for it in writing.

16.What to do next

Write your own list of what you run and what you need covered. Send it to two or three providers and ask them to answer the seven checklist points in writing. Compare the answers, then ask for the incident walk-throughs.

Brandsmashers provides senior analysts and detection engineers for teams that need monitoring and response without building their own operations centre. If you would like a second opinion on a vendor shortlist, we can help.