SOC status:Duty analyst on shift

UK Cyber Defence

Free resource · Choosing a managed SOC or MDR provider

Twenty questionsto ask a SOC provider.

Every provider claims 24/7 monitoring, experienced analysts and rapid response. These are the questions whose answers cannot be improvised, with what a good answer looks like beside each one. Ask every provider the same questions, in the same order, and write the answers down.

20 questionsFive themesScore each 0–2Free to use and share

01How to use it

Score the answers, not the brochure.

Give every answer a mark out of two and add them up. The total matters less than the pattern: a provider that scores well on coverage and badly on response is a monitoring service, however it is labelled, and one that scores well on everything but evidence is asking you to take it on trust. Where an answer can be checked — a certificate number, a sample report, a reference — check it before the second meeting.

2
A specific answer with evidence you can verify
1
A general answer, plausible but unsupported
0
No answer, or an answer to a different question
Under 24
Monitoring dressed as a SOC; keep looking
24 to 32
Ask for two references in your sector before going further
33 and above
Move to contract terms, starting with question 20

The checklist

The twenty questions

Coverage

  1. Which of our systems will you actually watch: endpoints, identities, cloud tenants, network, SaaS, OT?

    A good answer names each source, says how it is collected and lists what is out of scope. Identity (Entra ID, Okta, Google Workspace) should be included rather than sold as an add-on: most intrusions now begin with a login, not a file.

  2. What is our MITRE ATT&CK detection coverage today, and where are the gaps?

    A good answer is a coverage map for an environment like yours, with the gaps named and a dated plan to close them. "Full coverage" is not an answer; nobody has it.

  3. Which of our existing tools can you ingest, and which will you ask us to replace?

    A good answer ingests most of what you already have and replaces a control only where one is missing, with the reason written down. Be wary of a proposal that begins with a platform migration.

  4. Show us a detection you wrote or tuned for an environment like ours.

    A good answer is a real rule, the noise it produced before tuning, what changed and who owns it now. If the detections are whatever the platform shipped with, you are buying a licence, not a SOC.

People

  1. Who looks at an alert at 3 a.m., and do they work for you?

    A good answer describes the shift pattern, where the analysts sit and who employs them. Subcontracted overnight cover is not disqualifying, but you should learn about it before the contract rather than during an incident.

  2. What is your analyst-to-client ratio, and what qualifications do the analysts hold?

    A good answer is a number and a list (CREST, GIAC, vendor certifications), with how experience is spread across the shifts. A ratio the provider will not share is usually a ratio you would not like.

  3. Will we have a named analyst who knows our estate, and how often will we see them?

    A good answer is a name, a deputy and a monthly review already in the calendar. The named analyst is how an external team learns the things about your environment that nobody wrote down.

  4. How much of your triage is automated or AI-assisted, and what can the automation do on its own?

    A good answer is specific: automation enriches, correlates and drafts; a person decides; every containment action is logged and attributable to someone. Ask to see the audit trail for a real alert.

Response

  1. What containment actions can you take without waiting for our approval?

    A good answer is a pre-agreed, revocable list (isolate a host, lock an account, block a destination) with evidence captured before each action. "We alert you and await instructions" is the 3 a.m. email that nobody reads until nine.

  2. What are your mean time to detect and mean time to respond, and how are they trending?

    A good answer is measured per client, published and shown as a trend rather than a single best-case figure. Anything measured in hours is monitoring with a delay.

  3. How do you escalate to us, and when did you last test the call tree?

    A good answer is a written escalation path with named people and alternates, tested at least quarterly. A provider who has never phoned your out-of-hours number does not know that it works.

  4. What happens when an incident needs more hours than the contract includes?

    A good answer is a pre-agreed overage rate or a retainer option written into the contract, and a commitment to keep working while the paperwork catches up.

Intelligence and testing

  1. How many threat hunts did you run for clients last quarter, and what did they find?

    A good answer is a number and two anonymised examples. Hunting is the part of a SOC most easily promised and least often done.

  2. Where does your threat intelligence come from?

    A good answer includes the provider's own sources (honeypots, deception telemetry, sector reporting, adversary infrastructure tracking) alongside the commercial feeds it buys. A resold feed is not intelligence about you.

  3. How do penetration-test findings reach your detection and response posture?

    A good answer is a defined loop: finding, detection written, detection validated, finding closed. If testing and monitoring never meet, you are paying for two things that should be one.

Evidence and governance

  1. What do we receive each month, and would our auditor accept it?

    A good answer is a sample monthly report and a sample incident report, written for people who do not read dashboards, with the evidence a regulator or insurer will ask for attached: ISO 27001, DORA, the FCA's operational resilience rules, NIS.

  2. Which accreditations do you hold, and how can we verify them?

    A good answer is a list you can check on a public register: CREST for the SOC and the testing team, ISO 27001 and ISO 9001 with certificate numbers, Cyber Essentials Plus. A logo on a slide is a claim; a register entry is evidence.

  3. Where is our data stored, who can see it, and how is it protected?

    A good answer names the country, the platform, the access controls and the sub-processors, and explains how the provider's own security is assured. Your SOC will hold the most sensitive record of your organisation there is.

Commercial

  1. What will the first year cost in total, including onboarding, licences and overages?

    A good answer is one figure, an explanation of the pricing model (per endpoint, per user, per gigabyte, or by the size of the estate) and what would change it. Ask separately what an incident that runs to fifty hours would cost.

  2. If we leave, do we keep our logs, our detections and our data, and what does that cost?

    A good answer is yes, in a usable format, within a defined period, at no charge. Exit terms are the cheapest way to lose a negotiation three years from now.

The question to end on

When the scoring is done, ask one more: "What is the single biggest risk you see in our environment today?" There is no mark for it. A provider who replies with a sentence about your organisation, rather than a dashboard about their platform, has been listening, and is worth another meeting.

Red flags

Six answers that should worry you

01

"Everything is in scope."

A provider who cannot name what is out of scope has not looked at your estate. Every SOC has edges; the honest ones know where theirs are.

02

"Alerting" in the contract, "response" in the pitch

Read which word the contract uses. Twenty-four-hour alerting and twenty-four-hour response are different services at different prices.

03

Alert volume as proof of value

Two hundred alerts a month is not diligence; it is untuned detection. A SOC that sends you three things a month, all real, is doing more work, not less.

04

No sample report

If the provider cannot show you last month's report for another client, anonymised, there may not be one. Reporting is where the evidence for your auditor comes from.

05

A three-year term before a test

A service that has not been tested against a simulated intrusion should not be bought for three years. Twelve months, with a tabletop in the first quarter, is reasonable.

06

Exit terms nobody can explain

Logs and detections you cannot take with you are a lock-in, however friendly the account manager. Get the answer to question 20 in writing.

About this checklist

This checklist expands the ten questions in What should a board expect from a modern SOC provider? and is the companion to our guide What is a managed SOC, and what does SOC as a service cost in the UK?. It is free to use, print and share inside your organisation; if you publish it elsewhere, a link back is appreciated. Last reviewed September 2026. Corrections and suggestions to hello@cyber-defence.io.

Start a conversation

Want to hear our answers?

Thirty minutes with the SOC lead, working through the twenty questions against SOC365. You leave with our answers written down, whether or not you go further.