How to Choose a Managed SOC Provider: The 7 Questions That Separate Coverage From Capability

How to Choose a Managed SOC Provider: The 7 Questions That Separate Coverage From Capability

How to choose a managed SOC provider comes down to coverage, not capability. Ask which data sources the provider monitors, how often tuning happens, what the alert-to-close SLA measures, and who is on shift at night. Demand evidence, not adjectives: sample detections, tuning records, and one worked incident response. A provider that can't show these is selling dashboards, not security operations.

A security team is comparing three managed SOC proposals. All three are 24/7. All three have an "AI-driven" platform. All three list the same certifications. The difference is buried in a sentence nobody circled: which of your data sources are actually in the monitoring scope.

This is where SOC selection fails, and the cost of failing it is now documented in plain language. On September 28, 2026, the Department of Defense disclosed that a breach of the Defense Manpower Data Center exposed Social Security numbers and job details for 2.76 million living people and another 294,000 who are deceased [4]. The unauthorized access ran from October 2025 to July 2026, about nine months, before the vulnerability was discovered and patched [4]. Nine months is not a gap a better scanner closes. It is a monitoring failure.

The broader trend points the same way. Mandiant's M-Trends 2026, built on more than 500,000 hours of incident response work in 2025, puts the global median attacker dwell time at 14 days, up from 11 days in the previous period, and in cyber espionage and North Korean IT worker cases the median dwell time was 122 days [2]. Attackers are not the only side getting slower to be found. The defenders are, too.

In our onboarding and assessment work, the first week with a new client is usually spent discovering which data sources are not actually flowing. Forwarding dies quietly: an expired API credential, a license tier change, a platform nobody remembers onboarding. A managed SOC can only watch what reaches it, and the RFP almost never asks what actually reaches it.

Clone Systems' position: the value of a managed SOC is the data flowing into it, and the questions you ask before you sign decide how much of your environment is genuinely being watched. Everything below is about making those questions concrete.

What Is a Managed SOC Actually Responsible For?

A managed SOC is responsible for collecting, analyzing, and acting on your environment's security telemetry around the clock: monitoring a defined set of data sources, tuning detections so alerts mean something, triaging what fires, escalating confirmed incidents, and producing the record that proves all of it happened.

That is four separate jobs, and most evaluations blur them into one.

• Collection and monitoring. Agents, connectors, and log forwarding feed a defined list of sources: endpoints, identity provider sign-in logs, network and firewall telemetry, email security, and SaaS and cloud control-plane logs.
• Detection engineering. Rules and models that turn raw events into candidate incidents. Some are imported from a marketplace; some are written for your environment.
• Triage and response. An analyst, human or AI-assisted, decides what is real, contains it where the contract allows, and escalates the rest.
• Evidence and reporting. The written record your auditors, insurers, and board will eventually ask for.

NIST's Cybersecurity Framework 2.0 organizes security work into outcomes, and its quick-start guides are built around specific common goals rather than product names [3]. A managed SOC is the outsourced performer of the monitoring and response work behind those outcomes. The framework is not a vendor list. It is a set of outcomes you must be able to evidence, whoever performs the work.

Here is the problem with the current operating model. In the Omdia study behind Microsoft's State of the SOC research, 300 security professionals running mid-market and enterprise SOCs in the US, UK, and Australia, analysts pivot across an average of 10.9 consoles, and only about 59% of tools push data to the SIEM [1]. The rest is ingested manually. When we take over a monitoring environment, the gap between "we have these logs" and "these logs are being analyzed" is wider than the client believes, and it is almost never in the list the vendor promised to monitor.

Why Most Managed SOC RFPs Ask the Wrong Questions

Most managed SOC RFPs are written from a capability checklist: 24/7 coverage, AI platform, certifications, analyst credentials, platform brand. These are necessary conditions. They are not discriminating conditions, because every serious provider will say yes to all of them.

The Omdia data shows what happens when a capability-first SOC runs. An estimated 46% of alerts are false positives, and 42% of alerts go uninvestigated entirely [1]. Sixty-six percent of SOCs lose 20% of their week to manual aggregation and correlation work, and 75% of security leaders worry the SOC is losing pace with new threats [1]. None of those numbers are fixed by a better logo on the cover page. They are fixed by tuning, triage discipline, and a defined alert-to-close process, which is exactly what the capability checklist never asks about.

In our evaluations, the claim that fails first is the response time. We have seen an RFP where a vendor promised a "15-minute response" and could not say what time zero was: ticket creation, analyst assignment, or a confirmed incident. A response-time number without a clock attached is a marketing figure. The same applies to detection claims. "AI-driven detection" is not a detection. Ask who wrote the rule, when it was last tuned, and what it caught last quarter.

The compliance gap runs both ways. A clean questionnaire from a SOC provider proves nothing about what is actually being watched, the same way a clean questionnaire from a software vendor does not prove that vendor is patched Why a Clean Vendor Security Questionnaire Doesn't Mean Your Vendor Is Patched. The document describes an intent. The evidence describes a system.

The 7 Questions That Separate Coverage From Capability

This is the Clone Systems 7-Question SOC Provider Evaluation Rubric. Run it in the RFP, in the demo, and in the reference calls. Score each answer at one of three levels: documented (they can tell you), demonstrated (they can show you on a live environment), evidenced (they can produce records from a production customer environment). A provider that answers only at the documented level on two or more of these is selling a brochure.

1. Which of our data sources are in scope, and which are not? Ask for the source list as line items, not categories. "Endpoints, identity, network" is a category. "Your Okta system logs, your Microsoft 365 audit logs, your three SaaS tenant admin logs, your VPN concentrator, and your two legacy apps" is a scope. A strong provider will tell you which of your sources it does not recommend monitoring, and which will fail forwarding unless the contract includes an integration level that supports them.

2. How do you tune, and can you show a tuning decision from the last 30 days? With 46% of alerts estimated as false positives [1], tuning is the difference between a SOC that watches and a SOC that drowns. Ask for the record of a recent tuning decision: the alert, the change, the reason, and the before and after volume. If the answer is "our AI handles it," ask what the AI changed and when a human reviewed the change.

3. What does your SLA actually measure? Define the clock. Start and end of response, per severity. The definition of "close." What happens to an alert triaged as benign: is it a closed incident, or does it feed back into tuning? Ask for the metric's last 90 days, not the target.

4. Who is on shift at night, and what is the escalation path? Not the average FTE count. Who actually works the 3 a.m. queue, how many analysts are cross-trained on your stack, and what the escalation path looks like when the first analyst is stuck. If the provider will not name the level and experience band of the night analyst, treat that as an answer.

5. Show me a detection you wrote, not imported. Imported content is a floor, not a service. Ask for one custom detection built for a customer in your industry or on your stack, the threat it targets, and when it last fired. The providers that can show this have a detection engineering practice. The ones that cannot are reselling marketplace rules.

6. What happens after an alert is closed? A SOC that closes the ticket and moves on will see the same event again in six weeks, and the attacker knows it. Ask how closure feeds back: recurring event correlation, root-cause notes, threat-intel updates that change the rules. Ask for a specific example where a closed alert changed a detection.

7. What evidence do we get after an incident? When something real happens, you need a file: the timeline with timestamps, the evidence preserved, the actions taken and who approved them, and a handoff you can pass to a forensic firm or an insurer. Ask to see a sanitized incident report from a real engagement, not a template.

The point of the rubric is not to interrogate vendors. It is to force answers into a shape you can compare. Two vendors, same seven questions, same scoring sheet, and the decision becomes a lot easier to defend.

If you are already drafting the RFP, the fastest de-risking move is to have a second set of eyes run the seven questions against it before it goes out. Contact our team and we will walk your draft RFP through the rubric in a 30-minute call.

Managed SOC vs In-House SOC: Which Do You Actually Need?

The comparison every evaluation eventually runs into: buy 24/7 coverage, or build it?

An in-house SOC makes sense when you already staff 24/7, when you have a detection engineering practice you intend to grow, and when data residency or regulatory constraints make a third party impractical. It makes less sense when "24/7" means a pager that gets answered on business hours, or when the triage queue routinely outlives the shift.

A managed SOC makes sense when the job is coverage plus evidence: you want the sources monitored, the alerts tuned, the incidents documented, and the record available when an auditor, insurer, or board asks. The NIST CSF 2.0 framing is useful here, because the framework defines the outcomes you must evidence, not the staffing model that produces them [3].

In our engagements, the teams that build working in-house SOCs share one trait: they define "monitored" in writing before they hire. The teams that buy a managed service to fix a broken in-house SOC usually outsource the same undefined scope, and inherit the same gaps with an invoice attached.

Speed is the third variable. AI is compressing the attacker timeline, and the window between a vulnerability appearing and being exploited keeps shrinking How AI Is Shrinking the Window to Fix Vulnerabilities. A SOC that can triage in hours but not minutes is already behind the threat model Mandiant describes, where the median hand-off from initial access to a secondary actor collapsed from more than 8 hours in 2022 to 22 seconds in 2025 [2].

How to Verify the Answers in 30 Seconds

Before you spend a week on the full rubric, run the Clone Systems 30-Second Provider Sanity Test. Three yes-or-no questions. If the answer is no to any of them, do not move forward.

1. Can the provider name a data source of yours that is not monitored, and explain why? An honest provider will list gaps, including ones you have not thought of. A provider who says "everything" is guessing.
2. Can they show a tuning decision from the last 30 days, with the before and after? Not a policy document. A change, dated, with volume.
3. Can they walk through one real incident from first alert to close, with timestamps? Not a case study deck. A walkthrough, with times.

The pattern below is what a weak answer and a strong answer look like on question 1.

Note what the strong answers share. They are specific, they admit limits, and they come with numbers. Those three traits are the cheapest filter you will use all day.

How Clone Systems Can Help

Clone Systems runs the managed SOC the way we evaluate one: defined sources in writing, tuning with a record, response with a clock, and evidence for every step.

• Managed SOC service. 24/7 monitoring and triage across your defined sources, with the escalation path and response SLAs documented before onboarding, not after Managed SOC service.
• AI SIEM & SOC as a service. You get the same dashboard our SOC uses, with AI-assisted alert triage on top, so the alert volume you buy is the alert volume you can actually work AI SIEM & SOC as a Service.
• Managed SIEM & EDR and managed intrusion prevention, where the monitoring stack itself is the service, and the data flows to the SOC that watches it Managed SIEM/EDR service.
• Pricing you can check before the call. Our managed SOC is priced per endpoint with a 50 endpoint minimum, published on the pricing page, so the "how much" question does not need a sales meeting Managed SOC Pricing.

If you are mid-evaluation, bring your shortlist and your RFP. We will run the 7-Question Rubric against the answers you have, and tell you honestly where the gaps are. Talk to our team or schedule a demo to see the coverage report on a live environment.

Frequently Asked Questions

What should a managed SOC provider monitor? At minimum: endpoint detection and response telemetry, identity provider sign-in and audit logs, network and firewall logs, email security events, and the control-plane logs of your SaaS and cloud platforms. Identity and SaaS logs expire at the source within days unless forwarded, so a provider that cannot forward them on day one leaves a coverage gap no amount of analyst time can close.

How do you evaluate a managed SOC provider? Use the 7-Question Rubric above and score each answer as documented, demonstrated, or evidenced. A provider that answers only at the documented level on two or more questions is describing a brochure, not a service.

What is the difference between a managed SOC and MDR? A managed SOC monitors, tunes, and triages across your full set of data sources, while MDR adds hands-on endpoint response such as isolating a host or terminating a process. The line is blurry in the market, so ask exactly which actions the provider takes without your approval and get them in the contract.

How fast should a managed SOC respond to an alert? The number matters less than its definition, so ask what clock starts and what "response" means at each severity level. A 15-minute response to an unconfirmed alert is often triage noise, not containment.

What does a managed SOC cost? Most providers price per endpoint or per monitored asset, and Clone Systems prices its managed SOC per endpoint with a 50 endpoint minimum. Get onboarding fees, data-volume thresholds, and major-incident response terms in writing before you compare quotes.

How do I know if my current managed SOC is actually detecting? Ask for the last 30 days of tuning records and one custom detection built for your environment, and ask what it caught. If the provider cannot show recent activity on your data, you are paying for a dashboard, and the 7-Question Rubric is the fastest way to find out.

Conclusion

The provider with the best deck will lose to the provider with the best data. Attacker dwell time is up to 14 days globally and 122 days in espionage cases [2], the DMDC breach ran for about nine months before discovery [4], and nearly half of all alerts in a typical SOC go uninvestigated [1]. Every one of those numbers is a function of what is being watched, who is watching it, and whether the watching can be proven. Ask the seven questions, score the answers, and choose the provider whose evidence survives the rubric. Start at www.clone-systems.com.

References

[1] Microsoft Security Blog: "Unify now or pay later: New research exposes the operational cost of a fragmented SOC," reporting the Omdia-commissioned State of the SOC study (N=300, US, UK, Australia and New Zealand, June 25 to July 23, 2025), February 17, 2026. https://www.microsoft.com/en-us/security/blog/2026/02/17/unify-now-or-pay-later-new-research-exposes-the-operational-cost-of-a-fragmented-soc [2] Mandiant (Google Cloud): "M-Trends 2026: Data, Insights, and Strategies From the Frontlines," March 23, 2026 (full report is a PDF; figures from Mandiant's own summary page). https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026 [3] NIST: Cybersecurity Framework (CSF 2.0). https://www.nist.gov/cyberframework [4] ABC News: "Pentagon breach exposed sensitive data on nearly 3 million people," September 28, 2026. https://abcnews.com/Politics/pentagon-breach-exposed-sensitive-data-3-million-people/story?id=136832909 [5] Clone Systems: In our onboarding and assessment work, the first week with a new client is usually spent discovering which data sources are not actually flowing, because forwarding dies quietly, and the providers that fail evaluation are the ones whose answers stop at the platform name. [6] Clone Systems: Why a Clean Vendor Security Questionnaire Doesn't Mean Your Vendor Is Patched. www.clone-systems.com/blog/why-a-clean-vendor-security-questionnaire-doesnt-mean-your-vendor-is-patched [7] Clone Systems: Managed SOC service. www.clone-systems.com/managed-soc-service [8] Clone Systems: AI SIEM & SOC as a Service. www.clone-systems.com/ai-siem-soc-as-a-service [9] Clone Systems: Managed SOC Pricing. www.clone-systems.com/managed-soc-pricing [10] Clone Systems: Contact and consultation. www.clone-systems.com/contact [11] Clone Systems: Schedule a demo. www.clone-systems.com/schedule-a-demo