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.

All

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.

Vendor names deliberately omitted

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 2: response authority in the customer tenant

Visibility without the authority to act is an alert forwarder. The contract must state which actions the provider may execute, which need customer approval, and how that approval is documented under pressure.

ActionShould be covered by default
Host isolation on the endpointYes, without per-case sign-off
Disable user session, revoke tokensYes, with documented approval chain
Change EDR or firewall rulesOnly with explicit approval
Force password reset, re-register MFAProcess pre-defined

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.

Continue reading in this cluster
SOC as a Service in Switzerland: The Complete Guide
SOC as a Service is an externally operated Security Operations Center that monitors your environment around the clock, detects attacks and triggers the response. According to Mandiant M-Trends 2026, attackers went undetected for a median of 14 days in 2025. With a SOC that detects and assesses around the clock, typical detection time becomes much shorter.
Managed vs in-house SOC: which model pays off in Switzerland, and when
An in-house 24/7 SOC needs 8,760 hours of cover per seat; at roughly 1,700 productive hours per full-time role, that means at least 5 to 6 roles, plus platform and training. Economically, running your own SOC only pays off with a large environment and a dedicated team, when regulation, data sovereignty or OT proximity demand it.
What a SOC costs: cost drivers, pricing models, in-house or service
SOC costs arise from the response scope first, not the platform licence. What counts are endpoint and identity counts, log sources and data volume, the response scope you choose, onboarding and licences. Swiss providers rarely publish prices; offers differ widely by scope. Your own calculation starts by holding the cost drivers against your organisation.
What is a SOC? Definition, tasks and structure
A Security Operations Center (SOC) is a team of people, processes and technology. It monitors an organisation's IT and OT environment around the clock, detects attacks and coordinates the response. A SOC is not a piece of software; it is an operating unit.