Building a SOC: Build, Buy or Co-Manage?

What a SOC actually has to do

A security operations centre is not a room full of screens. It is a capability that continuously collects security telemetry, detects threats, investigates alerts, responds to incidents and improves detection over time. Whether that capability sits in-house, with a provider or somewhere between is a business decision — and it should be made on facts, not assumptions.

The staffing maths of 24x7

A year has 8,760 hours. A full-time analyst, after annual leave, public holidays, training and sickness, is typically available for around 1,600 to 1,800 hours. Covering a single seat around the clock therefore needs five to six analysts — before you add a team lead, a detection engineer, threat hunting or incident response specialists.

Most in-house SOC business cases underestimate this. A realistic minimum for a credible 24x7 in-house SOC is a team of eight to twelve people, plus the cost of recruiting and retaining them in a competitive market.

The three models compared

What a SOC needs beyond a SIEM

• Log sources that matter — identity, endpoint, email, cloud control planes and critical applications, not simply every firewall log.
• Detection engineering — use cases mapped to real threats, typically using the MITRE ATT&CK framework, tuned to your environment and reviewed regularly.
• Response playbooks — agreed steps and authority for containment, including who may isolate a device or disable an account at 3 a.m.
• Automation — SOAR or built-in automation to enrich alerts and handle repetitive steps.
• Threat intelligence — relevant to your sector and region, not a generic feed.
• Metrics — mean time to detect and respond, detection coverage, false-positive rate and escalations handled.

How to choose

• If you have no security team and need coverage quickly, a managed service is usually the right first step.
• If you have a capable small team, co-managed lets them keep context and control while a provider covers nights, weekends and surge.
• If you have the scale, budget and regulatory drivers to justify it, an in-house SOC gives maximum control — often still supported by a partner for specialist skills.
• Whatever the model, insist on transparency: access to your own data, clear escalation, and the ability to change provider without losing your detection content.

Questions to ask a provider

• Which log sources and use cases are included, and how are new ones added?
• What are the contractual response times by severity?
• Who is authorised to take containment actions, and how is that recorded?
• Where is our data stored, and who can access it?
• Do we own the detection rules and playbooks if we leave?
• How is performance reported, and how often?

Metrics that prove a SOC is working

Alert counts and dashboards full of green tiles say little about protection. These measures tell leadership whether the investment is working:

• Mean time to detect (MTTD) — how long threats go unnoticed, measured from first malicious activity to alert.
• Mean time to respond (MTTR) — from alert to containment, split by severity.
• Detection coverage — the proportion of relevant attack techniques your use cases can detect, typically mapped to MITRE ATT&CK.
• True-positive rate — the share of escalated alerts that were genuine, a direct measure of tuning quality.
• Log source health — critical sources that stopped sending data, and how quickly that was noticed.
• Improvement actions closed — lessons from incidents and exercises turned into new or better detections.

Report these monthly and review them quarterly with the provider or team. A SOC whose metrics never change is not improving.

Frequently asked questions

NAZZTEC Editorial TeamWritten and reviewed by NAZZTEC practitioners. This briefing is general guidance, not legal advice.