Comparing SOC providers: the neutral selection checklist
Comparing SOC providers works via verifiable criteria, not logos: data scope, response authority inside the customer tenant, evidence artefacts, response times and contract wording. This page lists the questions used to line offers up side by side. Deliberately without vendor names, so the checklist holds up even when ANOMAL is not on the shortlist.
How to read this checklist
The questions are written so any serious provider, ANOMAL included, must answer them. When a provider dodges, that is the answer. For the broader context, this page sits under SOC as a Service Switzerland. Are you still deciding whether a SOC is the right building block? Start with Managed SOC or in-house and What is a SOC.
This page does not name specific competitors. Vendor names age faster than selection criteria and skew the comparison. The criteria stay valid even when the market re-sorts.
Criterion 1: data scope and visibility
A provider that only sees endpoint telemetry cannot triage a cloud or identity attack. Check which sources are included by default and which cost extra.
- Endpoint (EDR or XDR), identity (Entra ID, Okta), cloud (M365, Google Workspace, AWS, Azure, GCP), network, SIEM, OT where relevant.
- Which sources sit in the base price and which are billed as add-ons?
- Are customer data processed in Switzerland or the EU? Ask for location and sub-processors in writing.
- Is customer-specific detection content maintained or only standard rules shipped?
Criterion 3: response times with proof
Marketing numbers on MTTD and MTTR are worthless without a reference point. A serious provider states target values per severity and delivers reports showing how often those values were met in recent quarters. For terminology see MTTD and MTTR in the SOC. For critical cases, ask for the contractual and the typical value separately.
- Are targets stated per severity (critical, high, medium) or only as averages?
- Is there a quarterly achievement report with values reached?
- How is the difference between a response target and a contractual SLA made transparent?
- At which escalation step is a named provider contact pulled in?
Criterion 4: evidence and audit readiness
In an incident or audit, what is written down counts. Regulators, insurers and boards read logs. For regulatory triggers see FINMA requirements for the SOC and ISG reporting duty.
- Are detection, triage and response documented per incident (who, what, when) in a traceable way?
- Are the evidence artefacts exportable into a customer-controlled system (not just a portal view)?
- Does the evidence scope match insurer requirements (MFA for privileged accounts, documented response, notification deadline up to 72h)?
- Is there a process for handing over evidence after termination? Evidence must remain available at contract end.
Criterion 5: commercial clarity
Offers only become comparable once scope and response mandate are clearly described. International MDR providers publish around USD 10 to 30 per endpoint per month in public price overviews (as of 2026). Swiss providers hardly publish prices; offers differ sharply by scope. Details on cost drivers and models on Pricing models and Managed SOC cost.
- Is billing tied to endpoints, log volume or users, and how does the price scale over 12 months?
- Which setup costs are one-off, which recurring, which hidden in the offer?
- How is the exit clause worded (notice period, data handover, assistance window)?
- Is there a defined onboarding framework with milestones or an ad hoc start?
Red flags in the provider conversation
- Response authority only with case-by-case approval, without fallback when business hours end.
- Achievement reports qualitative only, no hard numbers on MTTR targets met.
- Detection content limited to standard vendor rule packs.
- Evidence only in-portal, no export, no handover at contract end.
- Unclear scope of service: it remains open whether and under which mandate the provider responds.
How this compares to neighbouring topics
This page is the selection checklist. To learn how a SOC works in the first place, read What is a SOC. To decide make or buy, see Managed SOC or in-house. To understand round-the-clock operations, read How a 24/7 SOC works.
Frequently asked questions
Why does this page not name any providers?
A selection checklist based on names is wrong six months later. Criteria age more slowly than market positions. A page that disparages named competitors presents marketing disguised as neutral guidance.
How many providers should be on the shortlist?
The shortlist should contain three to five providers. Fewer create anchoring effects; more overload the evaluation. Applying the same criteria to every offer matters more than the number of providers. This avoids relying on criteria each provider promotes.
Does a proof of concept count as a selection criterion?
A PoC without real alerts says little. More telling is a time-boxed parallel run on a defined scope with real telemetry and an explicit evaluation grid. A provider that does not offer parallel operation often has a reason worth asking about.
How does ANOMAL relate to this checklist?
We wrote it so it tests us as well. If any provider, ANOMAL included, dodges one of these questions, that is a signal, regardless of the logo on the slide deck.
Do the criteria fit small companies equally?
Yes, the criteria apply with adjusted weighting. Data scope and evidence remain central. Commercial clarity gains importance because per-endpoint pricing has a greater impact at small scale. See [SOC for SMEs](/en/soc/soc-for-sme) for details for smaller organisations.
Related terms
- SOCaaS SOC as a Service (SOCaaS) is a SOC operated by an external provider and delivered as an ongoing service.
- MDR Managed Detection and Response (MDR) is a service that detects threats and actively contains them.
- MSSP A Managed Security Service Provider (MSSP) operates specific security services for its clients, such as firewalls or monitoring.
- SOC A Security Operations Center (SOC) is the team that constantly monitors an organisation's IT for attacks and intervenes during incidents.
- Tier-less SOC A Tier-less SOC is a model that operates without the traditional T1, T2, and T3 analyst hierarchy.