What an MSSP should actually do for you

"Managed security services" covers arrangements that differ enormously in what is actually delivered. Two providers can use the same phrase and mean very different things, which is why comparing proposals is difficult and why some engagements disappoint despite everyone doing what they said they would.

The useful way to think about it is by function: which specific security jobs are being transferred, and what remains yours.

The functions worth outsourcing

Monitoring and detection outside working hours

This is the strongest case. Round-the-clock monitoring needs roughly five to six trained people to sustain once leave, illness, training and turnover are accounted for. Below a certain scale, building that internally is not a resourcing decision so much as an impossibility.

Attacks do not respect working hours, and the gap between an alert at eleven at night and someone looking at it the following morning is where most of the damage happens.

Alert triage

Security tools generate far more alerts than any team can investigate. Most are benign. Separating the ones that matter is repetitive, requires consistency more than brilliance, and benefits enormously from seeing patterns across many environments.

This is the function where an external team has a genuine structural advantage, because they see more.

Keeping detection content current

Detection rules decay. Attacker techniques change, your environment changes, and rules written eighteen months ago quietly stop catching things or start firing constantly. Maintaining them is ongoing work that internal teams tend to deprioritise because it is invisible until it fails.

Vulnerability scanning and reporting

Running scans is easy. Doing it on a schedule, tracking what was found, chasing what was not fixed, and producing evidence that the cycle is working is the part that lapses. It is well suited to being someone's contractual obligation.

First-line incident response

Containment steps in the first hour matter disproportionately. Having someone whose job is to take those steps, at any hour, against an agreed playbook, is worth more than most detection improvements.

What should stay with you

Deciding what matters

Only you know which systems the business cannot operate without, which data would be damaging to lose, and what risk you are prepared to carry. A provider can advise. They cannot decide, and an engagement where they appear to be deciding is one where nobody is.

Accepting risk

Every environment has exceptions: the system that cannot be patched, the legacy integration that requires a weak configuration, the process that would be safer but too slow. Each is a business decision. A provider can document them and remind you they exist. Signing them off is yours.

Authority over your own environment

Approving changes, granting access, and deciding what may be shut down during an incident are decisions with business consequences. The provider should be able to recommend and, where you have agreed in advance, act. The standing authority is yours to define.

The relationships

Regulators, customers asking security questions, insurers, and your own board. These are yours. A provider supports them with evidence and expertise; they do not own them.

The set-up question

There is a common assumption that a managed service arrives to run tools you already have. Often that is exactly the arrangement. Just as often, some of the tooling is not there yet, or is deployed but never properly configured, and part of the engagement is putting it in place first.

Both are normal. What matters is that the proposal is explicit about which it is, because the two have different timelines, different costs, and a different definition of what "live" means. An engagement priced as monitoring, that turns out to require three months of deployment first, disappoints everyone.

Ask directly: what is assumed to exist on day one, what will you deploy, and what does the service look like in month one versus month six.

Questions that separate proposals

Most proposals look similar. These questions produce answers that differ.

1. What exactly happens when something is confirmed malicious at 2am? Who is called, in what order, how long does each step take, and what are you authorised to do without waiting for us?
2. Who writes the detection rules, and how often are they reviewed? If the answer is that they came with the platform, the service is thinner than it appears.
3. What do we see? Access to the underlying platform, or only reports? Read access to your own security data should not be a premium feature.
4. What happens if we leave? Whether detection content, tuning history and case records come with you determines how locked in you are.
5. Who is on the team, and where? Not to be difficult, but because coverage claims depend on the answer.
6. What is explicitly out of scope? The most useful page in any proposal, and the one most often missing.

Measuring it once it is running

Volume metrics (alerts processed, tickets closed) measure activity, not value. Better:

• Time from detection to notification for genuine incidents. This is the number the service exists to reduce.
• False positive rate, trending. If it is not falling, tuning is not happening.
• Incidents found by the service versus found elsewhere. Anything discovered by a user, a customer or a third party is a detection gap worth understanding.
• Coverage. Which systems are actually monitored, checked against your own asset list rather than the provider's.

That last one drifts constantly. New systems get built and nobody tells the provider. A quarterly reconciliation catches it.

The honest summary

A managed security service buys you continuous attention, consistency, and the experience of a team that sees more than yours does. It does not buy you a security programme. The decisions about what to protect and what risk to accept remain yours, and the engagements that work are the ones where both sides are clear about that from the start.