Security operations centre (SOC)

Also known as: SOC, security operations center

A team that watches an organisation's systems around the clock and acts when an alarm points to a real attack.

Draft - this entry has not been reviewed yet.

How to put it into practice

The usual steps, in order. Adapt them to your organisation.

Start from the threats you face and the systems you must protect, and decide what the SOC must cover - which environments, which hours and how fast an alarm must be looked at.
Choose the sourcing model - an in-house team, an MSSP that forwards alerts, an MDR service that also investigates and contains, or a hybrid with your own staff by day and a provider at night - keeping in mind that one seat staffed around the clock takes about five to six analysts.
If you buy the service, write into the contract what the provider may do on its own, such as isolating a production server at night, and who owns the logs, how long they are kept and how you get them back when the contract ends.
Give the SOC the tools and data it needs, typically a SIEM, EDR on endpoints, a case or ticket system and threat intelligence, and connect the systems that matter most first.
Write a runbook for each common alert type, such as phishing, a compromised account and ransomware precursors, and an escalation matrix that says when the business is called in.
Have analysts record their triage actions in the case, and sample closed alerts regularly to check that none were dismissed without good reason.
Set up shift handover, training time and career paths, and move repetitive triage to automation so analysts spend their time on judgement.
Measure time to detect, time to respond and detection coverage every month, and assess the SOC's maturity once a year, for example with SOC-CMM.

Common pitfalls

Buying a managed service without agreeing what the provider may do at night, so an alarm is forwarded but nobody acts until morning.
Chasing speed metrics until analysts close alerts too early to hit the target.
Treating the SOC as a room or a product rather than people, process and technology that must all be maintained.
Putting all the repetitive work on junior analysts until they burn out and leave.

Good guides

Technical deep dive

A SOC is an organisational capability - people, process and technology - rather than a room or a product. Its core loop is detect, triage, investigate, respond and improve. Many SOCs are organised in tiers: tier 1 analysts triage incoming alerts against runbooks and close false positives or escalate; tier 2 performs deeper investigation, scoping and containment; tier 3 covers threat hunting, malware analysis, forensics and detection engineering. The tier model is increasingly criticised because it concentrates repetitive, burnout-prone work at the bottom and slows escalation, and many teams are replacing tier-1 triage with SOAR playbooks and automated enrichment so that humans handle judgement rather than copy-paste.

The technology stack usually centres on a SIEM for log correlation, EDR for endpoint telemetry and response, network detection (IDS/NDR), a case-management or ticketing system, threat intelligence feeds and a SOAR platform. The process layer consists of use cases mapped to MITRE ATT&CK, playbooks for common incident types (phishing, account compromise, ransomware precursor activity), escalation matrices with the business, and shift handover. The SOC-CMM model is a widely used self-assessment for SOC maturity across business, people, process, technology and services domains.

Sourcing is a strategic decision. Staffing one 24/7 seat in-house takes, by a common rule of thumb, around five to six analysts once shifts, leave and training are covered, which is beyond most small and mid-sized organisations. Alternatives are managed security service providers (MSSP) that monitor devices and forward alerts, managed detection and response (MDR) services that also investigate and take containment actions using their own or the customer's EDR, and hybrid models with an internal team during business hours and a provider at night. The contract must specify response authority - may the provider isolate a production server at 3 a.m.? - as well as log ownership, retention and exit terms.

A SOC is distinct from a CSIRT or CERT, which coordinates incident response, communication and recovery once an incident is declared, although small organisations merge the roles. NIST SP 800-61 Rev. 3 (2025) repositions incident response within the NIST CSF 2.0 functions rather than as a standalone lifecycle. Under NIS2, essential and important entities must submit an early warning to the CSIRT or competent authority within 24 hours of becoming aware of a significant incident and an incident notification within 72 hours (Art. 23); in practice the SOC is where awareness starts the clock. Common metrics are mean time to detect, mean time to respond, alert-to-incident ratio and detection coverage, although chasing speed metrics alone can encourage premature alert closure.

What to learn first

Everything this builds on, foundations first.

Threat
→Incident response
→Security operations centre (SOC)

Relationships

Requires: Incident response
Don't confuse with: IT operations
Used with: Threat intelligence Runbook Alert triage Endpoint detection and response (EDR)Escalation procedure False positive Security metrics (KPIs)Security monitoring SIEM SOAR

Sources & further reading

Standards & official texts

NIST SP 800-61 Rev. 3 - Incident Response Recommendations and Considerations · NIST
CIS Controls v8 - Control 17 (Incident Response Management) · Center for Internet Security

Where this data comes from

This entry was drafted by an AI from the sources above and has not yet been checked by a person. Treat it as a starting point, and check anything important against the sources.

See the review queue Suggest a correction on GitHub This term as JSON

Mentioned in

IP address Anomaly detection Detection rule Indicator of compromise (IoC)MITRE ATT&CK

Check yourself

Loading…