SecOps SOAR Where an MSSP operates this rather than the in-house team, this path is deliberately short and aimed at a different outcome: understanding the model well enough to read what they produce, judge whether it is good, and ask questions they cannot deflect.

oversight-focused3 tiersMSSP accountability

Tier 0 · Groundthe model

From alert to closed case

Module 0.1

The object model

Six nouns worth knowing

Object	Meaning
Alert	A detection arriving from the SIEM or a connected product
Case	The container analysts work in; multiple related alerts group into one case
Entity	The users, hosts, IPs, hashes and URLs extracted from alerts — what enrichment attaches to
Playbook	The automated workflow that runs against a case
Action	One step calling an integration (block IP, isolate host, look up hash, email a user)
Connector	What pulls alerts in from a source product
Job	Scheduled background work — syncing, closing stale cases, feeding lists

1Connector ingests an alert.

2Alert is grouped into a new or existing case by shared entities.

3A playbook triggers based on the alert type or case attributes.

4Enrichment actions run — reputation, asset owner, user context, EDR history.

5Automated containment where authorised, or a decision point pausing for a human.

6Analyst reviews, documents, and closes with a reason code.

Module 0.2

Playbook anatomy

Where the judgement lives

A playbook is a flow of actions with conditions and manual decision points. The security-relevant design questions are the same regardless of vendor:

What runs automatically vs what waits for a human? Enrichment should always be automatic. Containment that affects a user's ability to work — isolating a laptop, disabling an account — should have an explicit, agreed authorisation model.
What are the guardrails? Can a playbook isolate a domain controller or a payment server? There should be an exclusion list of assets automation may never touch.
What is logged? Every automated action is a change to production. It needs an audit trail you can read.
What happens on failure? If an integration is down, does the case stall silently or escalate?

Position: where an MSSP operates the platform, the important artefact is the agreed authorisation matrix — which actions they may take unilaterally, which require our approval, and the time targets for each. That belongs in the contract and the runbook, not in a conversation during an incident.

Checkpoint 0I can explain alert→case→playbook→action, and state which containment actions an MSSP may take without asking.

Tier 1 · Operatereading their output

Judging case quality

Module 1.1

What a good case looks like

A review checklist

A verdict in plain English — what happened, to whom, and what it means. Not a paste of the rule name.
Evidence attached — the specific events, entities and enrichment that led to the conclusion.
Scope stated — was this one host or many? Was a hunt performed across the estate, and what did it return?
Actions taken with timestamps, and by whom or by which playbook.
Handover — what they need from us, with a clear ask and deadline.
Closure reason from a controlled vocabulary — true positive, benign true positive, false positive, duplicate — because that vocabulary is what makes their metrics meaningful.

Warning signs in an MSSP case queue: a high proportion closed as "informational" or "no action required" with no reasoning; cases closed faster than any human could have investigated; no evidence of scoping beyond the alerting host; identical narrative text across many cases; and escalations that arrive with no recommended action. Sample cases monthly rather than reading the summary dashboard — the dashboard is built to look good.

Module 1.2

The metrics that mean something

And the ones that do not

Metric	Worth tracking?	Why
Alerts processed	Weak	Measures volume, not value; trivially inflated
Mean time to acknowledge / contain	Strong	Directly tied to impact, and contractually testable
True positive rate per detection	Strong	Shows whether tuning is happening
Escalations with recommended action	Strong	Distinguishes analysis from forwarding
% cases with documented scoping	Strong	The step most often skipped
Coverage of our log sources by rules	Strong	Reveals telemetry we pay to collect and nobody uses
Dashboard "security score"	Weak	Vendor-defined and unauditable

Tie the strong ones to the service agreement, review them monthly, and require a written explanation for trends rather than a colour change on a slide. Under FCA and PRA operational resilience expectations you remain accountable for the outcome regardless of who operates the tooling — so the evidence of oversight matters as much as the service itself.

Drill 1

Your MSSP reports 12,000 alerts handled this month, 99.4% closed automatically, mean time to close 4 minutes. Your reaction?

Sample the closed cases. A four-minute mean closure across twelve thousand alerts describes an auto-close rule, not analysis — which may be perfectly legitimate tuning, or may be a queue being emptied. The only way to know is to read a random sample of automatically-closed cases and check whether the closure reasoning holds. Volume metrics without a quality sample are unfalsifiable.

Checkpoint 1I can review a case for quality against six criteria, sample the queue meaningfully, and hold a monthly service review on metrics that resist gaming.

Tier 2 · Engineerthe boundary

Our side of the line

Module 2.1

Documenting the split

The artefact that prevents incident-time confusion

Whatever the split, write it down before you need it. A minimum viable version:

Activity	MSSP	In-house
Monitor and triage alerts 24/7	Owns	Reviews samples
Isolate an endpoint	Authorised (with notification)	Informed
Disable a user account	Recommends	Approves and executes
Change SIEM detection rules	Proposes	Approves
Change firewall / SSE policy	Recommends	Owns
Declare a major incident	Escalates	Declares
Regulatory notification decisions	Supports	Owns absolutely
Communications to clients	None	Owns

Then test it. A tabletop exercise where the MSSP participates finds the gaps in this table faster than any document review, and produces exactly the evidence of scenario testing that regulators and enterprise clients ask for.

Checkpoint 2The responsibility split is documented, agreed and exercised in a tabletop with an MSSP present.

Referencesearchable