How we profile SOC vendors and models

Why no scores?

The question on this site is which operating model fits a team, and the answer depends on the team. A single score would hide that. So we record facts, mark what is not published, and let the fit finder order the models from your answers.

Where do the facts come from?

• Vendor homepages, product pages, pricing pages, security pages, documentation and press releases, read in September 2026 and updated on 13 October 2026.
• Most vendor facts were read on 27 September 2026; facts read from 11 to 13 October 2026 carry their own date on their source line. MDR provider and SIEM copilot profiles are lighter: they carry facts, a work strip, strengths and limits, but no capability flags.
• Each fact on a profile carries a source line with the read date; press releases also show their own publication date.
• Vendor figures, such as savings or customer counts, appear only in boxes labelled The vendor says, and are never our findings.
• Where a vendor does not publish a fact we write Not published or Not described. Compliance lines we did not check say Not reviewed, which does not mean the vendor lacks a certification.

How is the work strip drawn?

The work strip shows who carries each of five stages of the alert queue, always in this order:

• Triage: sorting alerts: real, noise, or needs a look.
• Investigate: gathering evidence across tools to reach a verdict.
• Respond: containment and fix actions.
• Tune: improving detections, playbooks or instructions after the fact.
• Nights and weekends: who keeps working the queue when the day shift is gone.

Each stage has one of six holders, drawn with a pattern and always labelled in text:

• Your analysts: your own analysts do the stage by hand.
• Rules you write: logic written in advance, such as playbooks, carries the stage.
• AI agent: software agents carry the stage at run time.
• Provider's analysts: a provider's analysts carry the stage under contract.
• Shared: people and software split the stage.
• Not described: the vendor's public pages do not describe who carries it.

The SOAR model as an example:

Why these points?

The points encode four plain ideas. Software that acts needs someone to own its decisions, so teams with no analysts score MDR highest. Unread alerts need something that reads every alert, so high volume favors the AI SOC analyst and works against the copilot. Working playbooks are an asset, so a large SOAR estate favors SOAR. Outsourcing is a choice about people, so it favors MDR alone. The points are editorial judgments; the table is published so you can disagree with it.

What do we leave out?

eSentire and SentinelOne Purple AI: their pages did not render for us, so we have no first-hand facts to profile. Radiant Security: its pages did not load on either read. Any vendor we cannot read does not appear. We also leave out customer logos, analyst-firm badges and review-site ratings.

What are the limitations?

Public sources only. No hands-on testing, no vendor interviews, no access to private documentation or contracts. Vendors change pages often; facts can change after the read date shown next to each source. Our reading of a vendor's position on SOAR and of its work strip is editorial.

How do we handle corrections?

Send a correction through the contact page with the topic Correction and a link to the source. We check it against the vendor's page and update the data and the read date.