SOC Guide: Building and Running a Security Operations Centre

Many security operations centres are built around tools and headcount rather than the threats and assets they exist to protect, and end up as expensive alert queues that miss the intrusions that matter. A SOC is an operating capability: people, processes, data and authority organised to detect attacks that get past preventive controls and to start the response quickly. This guide covers SOC functions, structural and team models (tiers versus pods), staffing and shift arithmetic, use-case and playbook management, threat-informed defence, metrics that do not reward the wrong behaviour, maturity assessment, and when to insource, outsource or run a hybrid. It is written for CISOs and SOC managers building or fixing a SOC, and draws on MITRE's 11 Strategies of a World-Class Cybersecurity Operations Center and the NCSC's Building a SOC collection.

Key takeaways

• Size the SOC to the threat, not to a template. The NCSC says SOC capabilities "should be proportionate to the threat faced by your organisation", and that it is "OK to start with a lower capability and then improve as the SOC matures".
• Coverage hours are the biggest cost decision. A continuously staffed seat needs roughly five to six people once leave and training are counted; business hours plus on-call, or a provider for nights, is a legitimate design.
• Use cases are the unit of work. Every detection needs an owner, a data requirement, a runbook and a review date, and the rule set must not "stagnate".
• Measure outcomes, not activity. MITRE warns that the "wrong" measures can lead to "wasted time or worse, a focus on harmful practices"; alert counts and closure speed alone reward closing alerts, not finding attackers.
• The SOC is a high-value identity target. Analysts and their automation hold standing rights to disable accounts, isolate hosts and read every log; protect those identities as privileged access.

What a SOC does

The NCSC describes SOCs as varying widely in scope, with most responsible for detecting and responding to attacks, and lists services "such as threat intelligence, content development, threat hunting and incident response". MITRE notes that "it is very rare for a single SOC to fulfill every single one" of the possible functions, and that SOCs range "from small operations with just a few people, each working part time, to national coordination centers employing hundreds of analysts and responders". Decide which functions are core, shared or bought in.

Watch scope creep: the NCSC warns that "diverting resources away from detecting security events might have a detrimental effect". Scanning, compliance checks and change requests drift into a 24x7 team; give them their own owners.

Operating models and structure

Insourced, outsourced or hybrid

The NCSC observes that "Most SOCs will outsource some of their operations, even if it is just the signatures that your tools will use for detection." In-house teams bring "better contextual awareness of the business", while outsourcing suits functions that are seldom used.

Whatever the model, contract for access to raw data, detection logic and case history, so knowledge stays with you if the provider changes. See the Third-Party Access Guide for controlling provider access to your environment.

Organisational structure

MITRE's structural models run from ad hoc response and "security as additional duty" through distributed, centralised, federated, coordinating and hierarchical SOCs to national SOCs and managed service providers, and it notes that "The size of the constituency is a key driver". A single business usually runs a centralised SOC; groups with autonomous subsidiaries tend towards federated or hierarchical models, with a central SOC setting standards and coordinating major incidents.

Team design: tiers, pods and roles

The classic tiered SOC splits work by depth: tier 1 triages alerts and escalates, tier 2 investigates and contains, tier 3 handles major incidents, hunting and complex analysis. MITRE also describes "tierless SOC models", where small pods or squads own a set of use cases or a business area end to end.

The NCSC favours rotating analysts because enabling them "to be part of and understand the SOC lifecycle often leads to better security". A practical middle path is tiered shifts with rotation into detection engineering, hunting and automation weeks.

• SOC manager: owns scope, budget, metrics, staffing and the link to incident management.
• Shift lead: runs the queue and handover, and decides when to call the incident lead.
• Analysts: triage, investigate and contain within agreed authority.
• Detection engineers: manage use cases as code, test and tune them. See the Detection Engineering Guide.
• Threat intelligence analyst and threat hunter: set detection priorities and search for what rules miss.
• SOC and automation engineers: run the SIEM, pipeline and automation, and their credentials.

Staffing, shifts and handover

The NCSC states plainly that "maintaining a 24/7 SOC will require significantly more staff than a 9-5 operation with out-of-hours on-call", and that "The effectiveness of a 24/7 SOC would be greatly reduced if other IT functions are only covered 9-5". Check that the identity, cloud and application owners who must act on a 3am alert can be reached.

Seat arithmetic

One continuously staffed seat covers 8,760 hours a year. An analyst on a 37.5-hour week works about 1,950 hours; after 25 days' leave, 8 public holidays, 10 training days and 5 days' sickness (48 days of 7.5 hours, 360 hours), roughly 1,590 productive hours remain. 8,760 divided by 1,590 is about 5.5 people per seat, before cover for vacancies. Two seats around the clock need around 11 analysts plus shift leads. Use your own absence data, but do the calculation before agreeing a budget.

• Shift patterns: three 8-hour shifts give shorter days but more handovers; 12-hour rotations reduce handovers but increase fatigue on long nights. Avoid permanent night teams; rotate so everyone gets day work, training and project time.
• Follow the sun: teams in two or three time zones each cover their daytime. It removes night shifts but needs one case system, common runbooks and consistent authority, and may raise data residency questions.
• Night cover options: the NCSC suggests "routing high priority out-of-hours security alerts" to an existing 24/7 team such as IT operations for initial triage; a provider for nights and weekends is the common hybrid alternative.
• Handover: a written handover at every shift change listing open incidents with owner and next action, alerts awaiting escalation, containment actions in place (and when they expire), degraded log sources or tools, and expected changes or maintenance. Handover is verbal plus written, never written only.
• Retention and onboarding: MITRE advises SOCs to "Pre-plan for departures by formally capturing institutional knowledge" and notes that "passion for the role is a key indicator of success" when hiring. Onboard in stages (shadowing, runbook sign-off, supervised triage, solo shifts) and publish career paths into engineering, hunting, intelligence and incident response.

Use cases, runbooks and playbooks

The NCSC is direct: "You should not allow the rulesets which drive your detection process to stagnate." It recommends a use-case lifecycle, being "(cautiously) open to simply removing alerts that have high false positive rates", and remembering that "just because a use-case has not fired, does not mean it is invalid". Run use-case management as a register the SOC manager reviews, not a folder of rules.

1. Request: a threat, incident lesson, intelligence report or audit finding creates a use-case request with a business justification.
2. Design: data required, logic, expected false positives, severity, ATT&CK mapping and the runbook that analysts will follow.
3. Build and test: the NCSC says "testing your use-cases is vital"; prove the rule fires on simulated activity and measure noise on production data before it pages anyone.
4. Operate: collect analyst dispositions as feedback; allow-listing must be "strongly object/time bounded".
5. Review: on a fixed cycle, and after any data source change; retire, tune or keep with evidence.

Runbooks are step-by-step analyst procedures for one alert type; playbooks coordinate a response to an incident type across teams. The NCSC notes runbooks "allow analysts to react promptly to an alert" but warns that scripted work "might limit the level of genuine investigation", so each runbook should end with questions to answer, not only steps to tick. CISA's federal incident and vulnerability response playbooks show the form and, CISA says, "may be useful for organizations outside of the FCEB to standardize incident response practices". Declaration, severity and the incident lifecycle are covered in the Incident Response Guide; use-case design and tuning in the SIEM Guide.

Threat-informed defence

MITRE's Center for Threat-Informed Defense defines threat-informed defence as "the systematic application of a deep understanding of adversary tradecraft" to improve defences, across three dimensions: cyber threat intelligence ("knowing the adversary and their tactics, techniques, & procedures"), defensive measures ("prevention, detection, and mitigation tailored to known threats") and testing and evaluation ("emulating realistic adversary behaviors and TTPs").

• Know which adversaries matter: MITRE's 11 Strategies states that "SOCs cannot predict attacks without adversary association". Keep a short list of relevant threat groups and techniques. See the Threat Intelligence Guide.
• Map coverage to ATT&CK: which techniques have tested detections with healthy data, and which do not.
• Prioritise endpoint and identity telemetry: MITRE notes endpoint data is "generally considered more informative" than network traffic data.
• Hunt: "Threat hunting is one of the best ways for a SOC to find adversaries that elude ordinary, routine detections and alerting." Every successful hunt should leave a new or improved detection behind.
• Test: purple team exercises and adversary emulation turn coverage claims into evidence; the NCSC warns there are "risks associated with running tests on production environments", so agree scope and stop conditions first.

Where identity fits

• Identity telemetry first: directory, IdP, privileged access and cloud role activity, including service principals and workload identities, should be among the first sources onboarded and the first use cases built. See the ITDR Guide.
• Response actions on non-human identities: runbooks must cover rotating a leaked API key, revoking OAuth grants and disabling a compromised service account without breaking production, not only resetting user passwords. See the Leaked Credential Response Playbook.
• The SOC's own privileged access: analysts often hold standing rights to isolate hosts, disable accounts and read every mailbox log. Use role-based access, just-in-time elevation for containment rights where response times allow, phishing-resistant MFA and quarterly membership reviews. See the Privileged Access Management Guide.
• Integration credentials: SIEM connectors, EDR APIs and automation hold keys that can read all telemetry and act across the estate. Vault, scope and rotate them, and alert on use from unexpected hosts. The NCSC also advises: "Make sure you adequately protect your catalogue of detections."

SOC metrics

MITRE groups SOC measures into those for internal SOC use, those that report value and status to stakeholders, and those that give insight into the wider organisation's security, and warns that "Choosing and monitoring the "wrong" measures can lead to wasted time or worse, a focus on harmful practices." Define each metric precisely, measure from event time where possible, and report medians and 90th percentiles by severity, not averages.

Report four to six to leadership with trend and narrative. A falling MTTR alongside a falling true positive rate deserves investigation, not congratulation; re-check a sample of closed alerts monthly.

Maturity assessment

• SOC-CMM: "a capability maturity model and self-assessment tool for Security Operations Centers", founded in 2016, offering a full assessment and a quick screening. It assesses five domains (Business, People, Process, Technology and Services), rating maturity on a 0 to 5 scale for all of them and capability on a 0 to 3 scale for Technology and Services. Use it to baseline and to show change year on year, not as a score to chase.
• MITRE INFORM: the Center for Threat-Informed Defense's assessment that lets you "evaluate your level of threat-informed defense", useful alongside SOC-CMM because it focuses on intelligence, detection and testing rather than organisation.
• NIST SP 800-61 Rev. 3: the April 2025 CSF 2.0 Community Profile for incident response; use it to check SOC outcomes connect to governance, recovery and improvement.

Building or rebuilding a SOC step by step

1. Mission and authority: write a charter with scope, constituency, hours and the actions the SOC may take without asking (MITRE's second strategy is "Give the SOC the Authority to Do Its Job").
2. Know what you protect: critical assets, business services and threat profile; the NCSC notes "a SOC must understand what the organisation's most critical assets are".
3. Choose the model: in-house, hybrid or outsourced; coverage hours; tiered or pod structure; budget from seat arithmetic.
4. Onboard data by priority: identity, EDR, email, cloud control plane and internet-facing systems first, with source health monitoring.
5. Launch a minimum use-case set: 20 to 40 high-confidence use cases with runbooks, tested before go-live; expand monthly.
6. Pilot: run business-hours operation, or shadow an existing provider, for one to three months; compare detections and escalations side by side.
7. Go live by function: extend hours, take over tiers or domains from the provider in stages, and keep the previous arrangement contracted until each stage meets agreed criteria. Rolling back a stage is then a contractual switch, not a rebuild.
8. Improve: quarterly metric reviews, annual maturity assessment, purple team exercises and post-incident lessons feeding the use-case register.

Decision guidance

• Small organisations: a full in-house SOC is rarely viable. Buy managed detection and response, keep an internal owner for scope, response authority and lessons learned, and make sure identity and email are in scope.
• Mid-sized organisations: a small in-house team for business-hours detection engineering, investigation and context, with a provider covering nights and weekends on shared case management.
• Large or regulated organisations: in-house 24x7 or follow-the-sun, a detection engineering team, intelligence and hunting functions, and a provider for surge, specialist forensics or subsidiaries.
• Tiered or pods: start tiered when alert volume is high and staff are junior; move towards pods as automation removes routine triage and the team matures.

Framework mapping

Common failure patterns

• Tool-first SOC: a SIEM bought before use cases and data priorities exist; the queue fills with vendor default alerts and analysts learn to ignore them.
• Missing the log that mattered: the Microsoft Storm-0558 Key Breach was first spotted by a US government customer whose own detection on mailbox access audit events fired; organisations without that data or that use case had nothing to triage.
• 24x7 on paper: a night shift of one analyst with no authority to contain and nobody to call in identity or cloud teams.
• Metrics that reward closure: time-to-close targets drive analysts to close ambiguous alerts as false positives.
• No feedback loop: tier 1 dispositions never reach detection engineering, so the same noisy rules fire for years.
• Outsourced and forgotten: provider scope is never updated for new cloud and SaaS estates, and nobody internal reviews escalations.

Practitioner checklist

• Write a SOC charter with scope, hours, constituency and pre-approved response actions.
• Choose the sourcing model and coverage hours explicitly, and budget them with seat arithmetic.
• Define roles, escalation paths and a written shift handover template.
• Run a use-case register with owners, runbooks, tests and review dates.
• Map detection coverage to prioritised ATT&CK techniques and test it with purple team exercises.
• Include non-human identity compromise runbooks (key rotation, grant revocation, service account containment).
• Protect analyst and integration privileges with role-based access, MFA, JIT where feasible and logging.
• Report four to six defined metrics with trends, and sample closed alerts monthly.
• Assess maturity annually with SOC-CMM or an equivalent and track the change.
• Give analysts a career path, rotation and structured onboarding.

Standards and references

• NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NCSC: Building a Security Operations Centre (SOC)
• NCSC: Designing an Operating Model
• NCSC: Detection practices
• MITRE: 11 Strategies of a World-Class Cybersecurity Operations Center
• MITRE Center for Threat-Informed Defense: Our Mission
• CISA: Federal Government Cybersecurity Incident and Vulnerability Response Playbooks
• SOC-CMM: SOC Capability Maturity Model

Related NHI Mgmt Group resources: Incident Response Guide · SIEM Guide · Detection Engineering Guide · Threat Intelligence Guide · Log Management and Retention Guide