What should businesses look for when choosing a managed security service provider (MSSP)?

The wrong way to choose a managed security service provider is to start with its tool list.

The right question is not:

“How many alerts can you see?”

It is:

“What can you own when one of those alerts turns into a business incident?”

That distinction matters because the threat landscape is moving beyond problems that another dashboard can solve. Businesses do not simply need more security tools. They need to shorten the path from a weak signal to a confident action.

An MSSP should therefore not be treated as a cheaper way to operate a security operations centre. It is a delegated operating model for part of the organisation’s cyber risk.

That changes how a provider should be evaluated.

Start With Your Failure Modes

Many MSSP selection processes begin with a long list of features:

SIEM. EDR. Threat intelligence. SOAR. Vulnerability management. 24/7 monitoring.

That is backwards.

Start with the events that could seriously hurt the business.

What happens if a privileged cloud identity is compromised?

What if an internet-facing application is exploited?

What if ransomware begins moving across endpoints?

What if sensitive data starts leaving a SaaS platform?

What if a third-party connection becomes an attack route?

These are much more useful buying questions because they expose what the provider must actually be able to detect, investigate and act on.

For every high-risk scenario, ask the provider one simple question:

What exactly would you see, what would you do, and what would still be our responsibility?

The quality of that answer will tell you more than a 50-page capabilities presentation.

Test What They Can See

An MSSP cannot defend what it cannot observe.

This sounds obvious, yet many organisations discover their visibility gaps only after the contract is signed.

Important identity logs may be missing.

A newly acquired cloud environment may not be onboarded.

SaaS activity may sit outside the detection model.

Network telemetry may arrive too late to support a useful response.

Ask prospective providers to build a visibility map before promising outcomes.

It should show:

• Which data sources are available
• Which are actually being monitored
• How quickly telemetry reaches the security platform
• How long security data is retained
• Where the remaining blind spots are

The assessment should cover more than endpoints.

Cloud identities, authentication tokens, privileged access, SaaS activity and administrative actions are now critical parts of the attack surface.

One of the strongest signs of a mature provider is the willingness to say:

“We cannot see that yet.”

The follow-up matters.

Can the provider explain the risk, how the gap will be closed and who owns the action?

Measure Decisions, Not Alerts

Security dashboards are easy to demonstrate.

Decision quality is harder.

A provider may detect thousands of events and still leave the customer exposed if the important incident gets lost in noise, reaches the wrong person or arrives without enough evidence to support action.

Ask the MSSP to walk through a real, sanitised incident timeline.

Look for clear answers to questions such as:

• When did the first signal appear?
• When did a human review it?
• When was malicious activity validated?
• Who was contacted?
• What action was recommended?
• How long did containment take?
• What changed afterwards to prevent the same pattern from recurring?

These questions reveal more than a headline SLA.

Traditional metrics such as mean time to detect and mean time to respond remain useful, but businesses should look deeper.

Measure:

• Time to human validation
• Time to a confident decision
• Time to containment
• Recurring root causes that are actually eliminated

The real objective is not to make alerts move faster through a queue.

It is to make the right decisions sooner.

Define Authority Before Incidents

One of the most dangerous gaps in an MSSP relationship is unclear authority.

Imagine a compromised administrator account at 2:00 a.m.

The provider has strong evidence that an attacker is active.

Can it disable the account?

Can it revoke the session?

Can it isolate the endpoint?

Can it block the infrastructure being used by the attacker?

Or can it only send an email?

There is no single correct answer.

Some organisations will allow pre-authorised containment. Others will retain approval for every disruptive action.

What matters is that the decision is made before the incident.

Create a clear responsibility model for the actions most likely to be required during a crisis.

Define:

• What the MSSP can do independently
• What needs customer approval
• Who has the authority to approve action
• What happens when the primary approver cannot be reached

Shared responsibility should not mean blurred responsibility.

The worst time to negotiate authority is while an attacker is moving through the environment.

Inspect the Human Layer

“24/7 monitoring” describes a schedule.

It does not describe a capability.

Buyers should ask who will actually investigate an alert at 3:00 a.m.

How experienced is the first analyst who sees it?

What triggers escalation?

Who can call the customer?

Is there an incident commander for major events?

How are cases handed over between shifts or regions?

Does the team understand the organisation’s industry and technology environment?

An analyst following a generic playbook may recognise suspicious activity.

A mature team understands what that activity means in context.

A privileged account behaving unusually in a retailer, hospital, bank or industrial environment may carry very different operational consequences.

Context changes priority.

This is why businesses should meet the service leadership and security operations team during selection, not only the sales team.

Ask how analysts are trained, how investigations are reviewed and how the provider retains knowledge of the customer environment.

The human operating model still matters.

AI has not removed that requirement.

Ask How AI Is Governed

Almost every modern MSSP now has an AI story.

That is not a differentiator by itself.

AI can help correlate signals, summarise investigations, speed up threat hunting, recommend actions and automate well-defined playbook steps.

Those are useful capabilities.

But buyers should ask what sits behind the “AI-powered” label.

Ask:

• Which AI models are being used?
• Where does customer data go?
• Is that data used to train external models?
• How are customer environments separated?
• Which outputs require human verification?
• Which security actions can the system take autonomously?
• Is there a complete audit trail?
• Can an automated action be reversed?

These questions matter more as both attackers and defenders increase their use of AI.

The purpose of AI in a security operation should be to improve the speed and quality of decisions without weakening accountability.

An MSSP that claims to be AI-powered but cannot explain its control model is selling an adjective.

Audit the Provider as a Target

The MSSP itself is part of the attack surface.

It may have privileged access, administrative tooling, security telemetry and connections into multiple customer environments.

That makes the provider a critical supply chain dependency, not just a supplier.

Businesses should therefore inspect the MSSP’s own controls.

Ask:

• How is privileged access protected?
• Are administrative environments separated between customers?
• How is remote access secured?
• Are privileged sessions logged?
• How quickly are critical vulnerabilities addressed?
• Which subcontractors can access customer data?
• What happens if the MSSP itself suffers an incident?

Certifications and audit reports matter.

But they should be treated as evidence, not as the conclusion.

The more useful question is:

What happens between audits?

Make the Contract Operational

A weak MSSP contract defines service availability.

A strong one defines behaviour under pressure.

The agreement should be clear about:

• Scope and exclusions
• Data ownership
• Log retention
• Evidence preservation
• Incident notification requirements
• Subcontractor access
• Offboarding

Response commitments should also distinguish between an automated acknowledgement and meaningful human engagement.

The contract should answer uncomfortable questions.

Who owns the telemetry if the relationship ends?

In what format can it be exported?

What support is provided during an active investigation?

How quickly must the provider disclose a security incident affecting its own environment?

What happens when log volume or cloud usage grows sharply?

These details often look administrative during procurement.

During an incident, they become operational.

Demand Proof Before Signing

A polished demonstration shows what a provider wants you to see.

A useful evaluation shows how the provider behaves when the signal is incomplete.

Where practical, run a time-boxed proof of value using real telemetry and a small number of high-risk use cases.

Follow it with a tabletop exercise or controlled attack simulation.

Do not evaluate only whether an alert was generated.

Look at:

• How the provider investigated it
• What evidence was presented
• How the case was escalated
• Whether the team improved the detection afterwards

Then ask one final question:

Show us something your security operation learned recently and what you changed because of it.

Cyber defence is not static.

The right MSSP should become better as it learns the customer environment and as attackers change their methods.

Choose Fit Over Fame

The largest provider is not automatically the right provider.

A global business may need scale, follow-the-sun coverage and support across several regulatory environments.

Another organisation may need deep expertise in cloud identity, operational technology, healthcare, financial services or a particular technology stack.

The right fit also depends on the internal security team.

Some businesses need a fully outsourced capability.

Others need a co-managed model that strengthens an existing SOC.

Some want the MSSP to operate their current tools.

Others need help reducing tool sprawl before monitoring can improve.

A good provider adapts its operating model to the customer’s risk and maturity.