The MXDR Standard: 7 Questions to Ask Your Security Provider

Choosing a managed detection and response partner is one of the higher-stakes decisions a security leader makes. You’re not buying a product. You’re handing someone ongoing access to your environment, your data, and your incident response chain — and trusting them to be competent, communicative, and genuinely engaged with your organization’s security outcomes.

The pitch decks all look similar. The capability claims often sound identical. So how do you actually evaluate the difference?

The questions below aren’t softballs. They’re the ones that reveal how a provider actually operates — not how they market themselves. Ask them directly. Pay attention not just to the answers, but to how a provider responds to being asked.

Before you start, though — take the time internally to decide what you want the right answers to look like for your organization. There are many wrong answers to these questions, but not every right answer looks the same. The best response depends on your team’s dynamics, your internal capabilities, and the kind of partnership you’re looking to build. These questions are designed to surface alignment — or the lack of it.

1. Where does your work end and ours begin — and how do you lean into our team?

Every MDR contract has a scope. The more important question is how the provider operates within it.

A red flag is a provider who consistently stays behind the glass — who surfaces findings through tickets and emails but treats your internal team as a hand-off point rather than a partner. The ticket might not be closed, but it’s been tossed over the fence for your team to deal with. That’s not partnership — that’s observation. Closure and resolution are two different things, and the providers worth signing with stay engaged through resolution, not just through documentation. The best providers build working relationships with your internal staff, understand your environment deeply enough to provide context alongside findings, and take ownership of outcomes rather than just observations.

Ask specifically: When you find something, what does your engagement with our team look like? Can you walk me through a recent example?

2. How have you modernized the way you communicate with clients?

Communication in managed security is often stuck in the past — email threads, monthly PDF reports, a ticketing system that creates more friction than it resolves.

The providers who are ahead on this have moved toward something that feels less like a vendor relationship and more like an extension of your own team. Look for shared workspaces, persistent communication channels, and a posture that allows for direct, real-time contact when it matters — not just a queue.

A red flag is any provider whose primary ongoing communication mechanism is email. When an incident is unfolding, you shouldn’t be waiting for an email response.

3. How often do we interact beyond incident handling?

Incident triage is table stakes. The question is whether the relationship extends beyond it.

A provider operating at the level your organization deserves should be meeting with you on a regular cadence — not just to review open tickets, but to walk through exposure observations, discuss changes in your environment, share relevant intelligence from across their customer base, and align on security priorities. If that cadence doesn’t exist, you’re paying for a reactive service and calling it proactive.

Ask specifically: What does our regular cadence look like, and what does the agenda cover?

A red flag answer: “We send you a monthly report.” A better answer includes regular working sessions, a defined agenda, and shared ownership of a forward-looking security program — not just retrospective incident review.

4. Beyond incident response, how do you help us prepare for what’s changing?

Your environment isn’t static. Neither is the threat landscape. A managed security partner who is only looking at what’s happening right now is missing half the job.

The best providers are actively tracking emerging risks and applying them to your environment specifically — not just blasting generic threat intel to their entire customer base, but curating what’s relevant to your technology stack, your industry, and your organizational posture. When something changes in the wild that affects you, you should hear about it before it becomes an incident.

A red flag is a provider who only engages reactively. If their value proposition is entirely incident-handling, they’re not a security partner — they’re a monitoring vendor.

5. How do you capture lessons learned across your customer base and apply them to my environment?

One of the clearest advantages a managed provider should offer is the breadth of their visibility. If they’re operating across dozens or hundreds of environments, they’re seeing things that any single in-house team never would. The question is whether they have a mechanism to operationalize that intelligence for you.

Ask specifically: When your team identifies a new attack pattern, technique, or configuration risk — how does that make its way back into the detection logic and recommendations for my environment?

A red flag is any answer that suggests each customer is treated in isolation. Good providers have internal processes for aggregating learnings, validating their applicability to each customer’s environment, and pushing improvements across their managed base — without requiring you to ask.

6. How detailed are your incident reports, and can I see an example?

Incident documentation tells you a lot about how a provider thinks. A templated report that states what happened and what was done is the floor — it’s the minimum. What separates good incident documentation from excellent is the analyst reasoning that sits underneath it.

You want to see: what the analyst saw, what hypotheses they considered, what they ruled out and why, what the chain of investigation looked like, and what the recommended follow-up is. The narrative of the investigation is what allows your team to learn from each incident and make informed decisions about your posture going forward.

Ask for a redacted example before you sign. If they can’t provide one, that’s a meaningful signal about the maturity of their documentation process.

7. How do you tailor your security delivery to our specific organization?

Scalable MDR services are often built on standardized processes. That’s not inherently a problem — standardized processes are how quality gets maintained at scale. But standardization has limits, and the providers who are honest about this are the ones worth talking to.

Your environment has specific technologies, specific user behaviors, specific risk tolerance, and specific regulatory context. A provider who delivers an identical service to a 200-person professional services firm and a 5,000-person manufacturer with an OT environment is either serving neither well or hasn’t thought carefully about the difference.

Ask specifically: What does tailoring your service to our environment actually look like in practice — and what’s an example of something you’ve done differently for a customer with a similar profile to ours?

A red flag is an answer that amounts to “our platform adapts automatically.” Tailoring is a human decision, made by people who understand your environment. Automation is infrastructure. The two are not the same thing.

One Final Note

These questions aren’t designed to catch a provider in a trap. They’re designed to give you a clear picture of what working with them actually looks like — day to day, not just during the sales process.

The right partner will welcome these questions. They’ll have concrete, specific answers. They’ll be able to point to real examples rather than general assurances. And they’ll recognize that a customer who asks hard questions up front is a customer who knows what a good partnership looks like.

That’s the conversation worth having.