Building a Lean SOC

Lean does not mean accepting worse outcomes. It means designing the SOC so that the work that scales poorly with headcount — alert triage, evidence collection, enrichment, ticket creation — is handled by software, and the work that doesn't scale well with software — threat modelling, detection engineering, stakeholder relationships, novel incident judgement — is where analysts spend their time.

A three-person lean SOC running ManySignal should be able to achieve: 90%+ autonomous triage, sub-4-minute MTTV, 100% alert verdict rate, and monthly ATT&CK coverage expansion. These are not aspirational — they are the baseline the platform is designed to deliver.

The lean SOC staffing model has three roles: SecOps lead (strategy, stakeholder management, escalation authority), detection engineer (detection-as-code, coverage gap analysis, tuning), and SOC analyst (case escalations, playbook improvement, tabletop facilitation). Each role is full-time in a team of three; in larger lean SOCs, these functions scale in parallel rather than adding headcount to the triage queue.

On-call coverage is the hardest lean SOC problem. The agentic model reduces but doesn't eliminate after-hours human need. For most organisations, a single on-call analyst with approve-gated authority for high-severity actions, backed by a full autonomous response capability, covers nights and weekends adequately.

Hire for detection engineering skills first. An analyst who can write, test, and tune detections compounds the SOC's capabilities every week. A pure-triage analyst does not.

ManySignal handles detection, triage, investigation, response, and reporting — collapsing five tool categories into one platform. The additional tooling a lean SOC needs: an EDR (CrowdStrike, SentinelOne, or Microsoft Defender for Endpoint) for host isolation and process telemetry, an IdP (Okta or Entra ID) for identity response, and a ticketing system (Jira or ServiceNow) for case escalations that require change management.

Avoid adding tools that duplicate ManySignal capabilities. A separate SOAR is redundant — ManySignal's respond agent is the SOAR. A separate threat intel platform that feeds raw feeds is redundant — ManySignal's enrichment resolvers consume threat intel inline.

A lean SOC needs three written procedures: the weekly metrics review (30 minutes, five metrics, tuning tickets created), the monthly detection review (coverage gap analysis, backtest review, deprecated rules archived), and the quarterly tabletop (one scenario per quarter, PIR-derived, response playbook updated afterward).

Everything else should be automated. Alert triage is the agent's job. Weekly report is the report agent's output. Compliance evidence is the case timeline export. The more the SOC relies on written procedures for things software can do, the less lean it is.

When to add headcount: when the detection engineering backlog exceeds three months of work, when the tabletop programme is running less than quarterly, or when compliance requirements demand dedicated personnel. Not when alert volume increases — that is an autonomy tuning problem, not a staffing problem.

The lean SOC scales its outcomes by expanding the autonomy ladder, not by hiring. Every new action class promoted to supervised-autonomous is equivalent to a part-time analyst in that domain. Measure the staffing equivalent of your autonomy expansions and report it to the CFO.