SOC (Security Operations Center)

What is a SOC?

A SOC is the function in an organisation that watches for attacks and acts when one happens. It has three parts. People: analysts who triage alerts and investigate, engineers who maintain the detection rules and integrations, and incident responders who contain and recover. Tooling: a platform that collects telemetry from endpoints (EDR), networks, identity systems, cloud services and applications, correlates it and raises alerts, plus case management and threat intelligence feeds. Processes: runbooks for common alert types, escalation paths, reporting duties and the loop that turns every incident into better detection.

SOCs are often described in tiers: tier 1 triages, tier 2 investigates, tier 3 hunts for threats proactively and builds detections. Smaller operations collapse these roles into a handful of people.

Where is it defined?

There is no standard that defines “a SOC”. The functions it performs are: NIST SP 800-61 Rev. 3 (2025) describes incident response as part of cybersecurity risk management and maps it to the functions of the NIST Cybersecurity Framework 2.0, in particular Detect and Respond. MITRE ATT&CK is the common vocabulary for adversary behaviour that detection rules and SOC reports refer to. In the EU, NIS2 Article 21(2)(b) requires incident handling and Article 23 the reporting of significant incidents to the CSIRT or competent authority within fixed time frames; the German implementation is in the BSIG. ISO/IEC 27001 Annex A includes controls for logging, monitoring and incident management.

What it means in practice

The value of a SOC is decided by two numbers: how fast an intrusion is detected and how fast it is contained. An attacker who gains a foothold on Friday evening and is found Monday morning has had the weekend to move laterally and stage ransomware. Coverage outside office hours is the hard part and the main reason the question “own SOC or managed SOC” exists.

From our managed SOC we see what detection is worth in mid-sized companies: most real incidents start with a phished account or an exposed remote access, and the first signs are unremarkable on their own: a login from a new country, a new inbox rule, a service account running a PowerShell script. A SOC that correlates these and calls you within the hour prevents the incident; a weekly log review does not. Equally important is what the SOC does not drown you in: alert tuning so that your IT team only sees what needs a decision.

For device makers and OT operators a SOC has an extra dimension: the monitoring of products and plants in the field. UN R155 paragraph 7.2.2.2 (g) requires vehicle manufacturers to detect and respond to cyber attacks on their vehicles, which has created vehicle SOCs at OEMs.

Common misunderstandings

A SOC does not prevent attacks; firewalls, patching, hardening and awareness do. It detects what gets through and limits the damage. A SOC also does not replace incident response planning on your side: the SOC can tell you that a server is compromised and isolate it, but who decides to shut down production, who informs customers and who files the NIS2 report are your roles, and they should be written down before the first call.