What Is a SOC in Cyber Security? (And Why It Is Not SOC 2)

SOC stands for Security Operations Centre: the team responsible for watching an organisation's systems for signs of attack, deciding which signs are real, and doing something about the ones that are.

First, the confusion worth clearing up

Two unrelated things share the letters, and people regularly end up in the wrong conversation.

• SOC (Security Operations Centre) — a team and a function. People, tooling and process that detect and respond to attacks. This is what the rest of this article is about.
• SOC 2 — an audit report, defined by the American Institute of CPAs, about whether an organisation's controls meet specified trust criteria. It is a compliance artefact produced by auditors, not a team.

You can have an excellent SOC and no SOC 2 report. You can hold a SOC 2 report and have nobody watching anything in real time. They are not related beyond the acronym, and if a vendor blurs them, that is worth noticing.

(There is also "system on chip" in hardware. Different field entirely.)

What a SOC actually does all day

The romantic picture is a dark room of screens. The real work is quieter and more procedural.

Monitoring. Logs and telemetry flow in from endpoints, servers, firewalls, identity providers and cloud platforms. Detection rules fire alerts when something matches a pattern worth a human look.

Triage. Most alerts are not incidents. An analyst establishes what happened, whether it is expected for that user or host, and whether anything corroborates it. This is the bulk of the job and the part that requires judgement rather than tooling.

Investigation. When something survives triage, the question becomes scope: what else did that account touch, when did it start, is it still happening, did anything leave the network.

Response. Containment — isolating a host, disabling an account, blocking an address — then eradication and recovery, usually alongside IT.

Detection engineering. The part that distinguishes a SOC that improves from one that drowns. Somebody writes new detections, tunes the ones producing noise, and closes the gaps the last incident revealed. A SOC with no engineering function slowly fills with alerts nobody reads.

Threat hunting. Deliberately looking for intrusions that produced no alert, starting from a hypothesis rather than from a queue.

Who works in one

The traditional description is three tiers: tier one triages, tier two investigates, tier three hunts and handles the hardest cases, with an incident manager coordinating and an engineer keeping the platform fed.

Many modern SOCs have moved away from strict tiering, because the model produces a tier-one role that is mostly queue-clearing with little learning, and those analysts leave. The functions still exist; the trend is toward analysts who own a case end to end, with specialists supporting.

What has not changed is that an entry-level analyst's value is in method rather than tool knowledge — asking what is normal for this host, what corroborates this, what would change my mind. That is what interviews for the role actually test.

The tooling, briefly

• SIEM — collects logs centrally, correlates them, raises alerts. Wazuh, Splunk and Elastic Security are the common choices; they differ more than the feature lists suggest.
• EDR/XDR — deep endpoint visibility and the ability to isolate a machine remotely.
• SOAR — automates the repetitive parts of response so analysts spend time on judgement.
• Threat intelligence — context on indicators and adversary behaviour.
• Case management — where the investigation is recorded, which matters more than it sounds. An investigation nobody can reconstruct later did not really happen.

None of this is the SOC. The tools are what the team uses; the team is the capability.

How you tell a good one from a busy one

Two numbers do most of the work. Mean time to detect — how long between an attacker acting and someone noticing. Mean time to respond — how long between noticing and containing. Everything else is secondary.

Alert volume is a vanity metric and often an inverse one: a SOC closing thousands of alerts a week is usually a SOC with untuned detections, not a vigilant one.

Do you need one?

Every organisation needs the function. Very few need to build the team.

Genuine round-the-clock coverage needs far more people than the arithmetic of hours suggests, once leave, sickness, training and attrition are allowed for — plus engineering, plus tooling, plus continuous recruitment, because entry-level analysts leave quickly from night rotas.

Most organisations below a certain size are better served by an outsourced service with a single internal owner, or by a hybrid where a provider covers nights and first-line triage while a small internal team owns decisions and detection engineering. The trade-offs are worked through here.

What a SOC is not

It is not a firewall, a product you buy, or a guarantee. A SOC does not prevent attacks — prevention is patching, hardening, identity and segmentation. A SOC exists for the attacks that get through anyway, which is all of the interesting ones.

And it is not a compliance checkbox. Standing up a SOC to satisfy a questionnaire, with no engineering behind it, produces an expensive alert queue and a true answer to the question that is still the wrong outcome.

Frequently asked questions