What is a SOC? Security Operations Center.

Ask ten people what a SOC is and half will point at a dark room full of screens. That picture isn't wrong, but it's the least important part. A SOC (Security Operations Center) is not a room and it isn't a product you buy — it's a function: the standing team, process, and tooling an organization uses to watch its systems, decide what's a real attack, and act before it becomes a breach. Some SOCs sit in a war room, some are fully remote, some are three people sharing an on-call phone. The screens are set dressing. The job is what matters.

Cybersecurity is a team sport, and the SOC is the team that never goes home. Firewalls, endpoint agents, and identity providers generate signals every second of every day; someone has to read them, separate the noise from the one event that matters, and act while it still matters. That "someone," organized into shifts and workflows, is the SOC.

What a SOC actually is (and why it isn't a room)

Organizations stand up a SOC for a blunt reason: attacks don't wait for business hours, and detection without response is just expensive logging. A vulnerability scanner tells you where you're weak. A SOC tells you when someone is actively using that weakness — and gets you to contain it. The value is continuous: coverage across nights, weekends, and holidays, because that's exactly when adversaries prefer to move.

The other reason is consolidation. Modern estates sprawl across laptops, servers, cloud accounts, SaaS apps, and identity systems, each with its own logs and alerts. Left alone, those signals are a hundred disconnected fire alarms. The SOC pulls them into one place, correlates them, and turns "a login here, a file there, an odd process over there" into a single coherent story: this account was taken over, and here's how far it got.

What a SOC does on a Tuesday

Strip away the marketing and the day-to-day work falls into five recurring activities. They overlap, and the same analyst often does several in an hour, but it's worth naming them cleanly:

• Monitoring. Watching alert queues and dashboards fed by every log source in the environment. This is the baseline — eyes on glass, or increasingly, eyes on a well-tuned queue.
• Detection. Turning raw telemetry into meaningful alerts through rules, correlation, and behavioral analytics. Good detection is the difference between catching an intrusion and archiving evidence of one you missed.
• Triage. The core reflex of the job: for each alert, decide fast whether it's a false positive, a benign true positive (real but authorized), or something that needs to be escalated and worked.
• Investigation. Once an alert survives triage, pulling the threads — which host, which user, what ran, what talked to what — to establish scope and root cause.
• Incident response. When it's confirmed, containing the damage, eradicating the foothold, recovering, and writing down what happened so it doesn't happen the same way twice.

Everything else a SOC does — threat hunting, detection engineering, reporting to leadership — hangs off these five. If you understand how a single alert travels through them, you understand the SOC.

The life of an alert, start to finish

Abstract definitions don't stick, so let's walk one real alert all the way through. It's a common one: impossible travel — a sign-in from a location the same user physically couldn't have reached in the time since their last sign-in.

Ingestion and detection. The company's identity provider streams sign-in logs into the SIEM. A correlation rule notices that user j.martin authenticated from the corporate office at 09:04, then again from an IP geolocated two time zones away at 09:26 — and, critically, the second sign-in passed multi-factor authentication. The rule fires an alert into the queue.

[ALERT] rule: identity.impossible_travel   severity: HIGH
user:     j.martin@corp.example
event_1:  2026-07-14 09:04:11  IP 198.51.100.20  (office / expected)
event_2:  2026-07-14 09:26:47  IP 203.0.113.77   (datacenter ASN, foreign)
mfa:      SATISFIED on event_2
mapping:  ATT&CK T1078 Valid Accounts

Triage. A Tier 1 analyst picks it up. First question: is this just a VPN or a corporate proxy making the user look foreign? They check — the second IP belongs to a hosting provider's datacenter range, not a known corporate egress. MFA being satisfied is the detail that turns a shrug into a concern: a stolen password alone shouldn't clear MFA. This isn't a clean false positive. It gets escalated.

Investigation. A Tier 2 analyst takes over and widens the lens. They pull the identity logs and see the second session immediately created a new OAuth app consent and an inbox rule that auto-forwards finance emails to an external address — classic post-compromise behavior. They cross-reference the endpoint (EDR) telemetry for j.martin's laptop and find nothing malicious there, which points to a session token theft or MFA-fatigue-driven approval rather than malware on the device. Scope is now clear: the account is compromised, the attacker has valid session tokens, and they're already staging data theft.

Containment and response. The team moves. They disable the account, revoke all active sessions and refresh tokens (disabling the password isn't enough when the attacker holds live tokens), delete the malicious inbox rule and the rogue OAuth grant, force an out-of-band credential reset, and check the forwarded emails to gauge impact. Because the token — not the device — was the weak point, isolating the laptop would have accomplished nothing; revoking sessions is what actually cuts the attacker off.

Improvement and tuning. The last step is the one weak SOCs skip. The team writes a short post-incident note, then feeds it back into detection: add or sharpen a rule for new OAuth consent grants on privileged accounts, alert on auto-forwarding rules to external domains, and lower the noise on the impossible-travel rule so the next real one isn't buried. The alert that took an hour to work becomes a detection that fires in seconds next time. That loop — every incident makes the next detection better — is what separates a maturing SOC from one that keeps relearning the same lesson.

The detection pipeline: logs to SIEM to rules to SOAR

Behind every alert is a pipeline, and it's worth seeing the whole thing rather than just the tools. It has four stages.

1. Log sources — the raw material

Detection is only as good as its inputs. A capable SOC ingests telemetry from four broad domains, and gaps in any of them are blind spots an attacker can live in:

• Endpoint — EDR agents on laptops and servers: process launches, file writes, registry changes, script execution. This is where you see what actually ran.
• Network — firewalls, proxies, DNS, and NetFlow: who talked to whom, and the odd outbound connection that looks like command-and-control.
• Identity — the identity provider and directory: sign-ins, MFA events, privilege changes. In cloud-first estates, identity is the new perimeter and often the first place a compromise shows.
• Cloud and SaaS — control-plane and audit logs from cloud providers and business apps: new API keys, changed permissions, mass downloads.

2. SIEM — the central nervous system

All of that flows into a SIEM (Security Information and Event Management) platform — the aggregation and correlation layer that normalizes wildly different log formats into something searchable and lets one rule reason across sources. The impossible-travel alert above only exists because the SIEM could line up two identity events by user and time. The SIEM is where detections live and where analysts pivot during an investigation.

3. Detection rules — turning data into alerts

A pile of logs detects nothing on its own. Detection rules — from simple signatures to correlation logic to behavioral analytics — are what convert telemetry into an alert worth a human's attention. Writing and tuning them is a discipline in its own right (detection engineering), and it's a constant balancing act between catching real attacks and drowning analysts in noise.

4. SOAR — automating the boring parts

SOAR (Security Orchestration, Automation and Response) sits on top and handles the repetitive glue work: enriching an alert with threat-intel context, opening a case, pulling the related endpoint data, even auto-containing in clear-cut situations. SOAR doesn't replace analysts; it removes the twenty minutes of copy-paste around each alert so they can spend their judgment where judgment is actually needed. We go deep on all of these in the SOC toolstack: SIEM, SOAR and EDR — here they're just the stations on the pipeline.

Tiers: T1, T2, T3

Larger SOCs organize analysts into tiers so that the right problem reaches the right skill level without wasting anyone's time.

• Tier 1 (triage). Front line. Works the alert queue, dispositions the obvious false positives, escalates the rest. High volume, fast decisions.
• Tier 2 (investigation). Takes escalations, runs deeper analysis, handles real incidents, and starts to shape detections.
• Tier 3 (hunting and engineering). Senior work: proactive threat hunting, detection engineering, forensics, and the hard incidents. Often overlaps with the blue team's build side.

Smaller SOCs collapse these into one or two people wearing all the hats. For a full breakdown of who does what, how the shifts run, and how the roles pay, see inside a SOC: team roles and tiers.

Build, buy, or blend: sourcing models

Not every organization runs its own SOC, and "having a SOC" can mean very different things. There are four common models, and the right one is a function of budget, in-house talent, and how much control you need to keep.

The metrics that actually matter

A SOC that can't measure itself can't improve. A handful of metrics do most of the useful work, and each one answers a specific question about how the team is performing.

• MTTD (Mean Time to Detect). How long from the start of malicious activity until the SOC notices. Lower is better; it's the headline measure of detection quality.
• MTTR (Mean Time to Respond). How long from detection to containment or resolution. (Watch the definition — some teams read the "R" as respond, remediate, or resolve, so agree on which before you compare numbers.)
• Dwell time. The total window an attacker was inside before being evicted — from initial compromise to full containment. It's the metric that best captures real-world exposure. Industry reports have tracked dwell times trending downward over the years as detection matures, but they still vary enormously by organization, so treat any single figure with caution.
• False positive rate. The share of alerts that turn out to be nothing. High rates aren't just wasted effort — they cause the alert fatigue that makes teams miss the real thing.
• Coverage. How much of the relevant attacker playbook you can actually detect. The standard way to express this is by mapping your detections onto MITRE ATT&CK techniques and looking at the resulting heatmap — the gaps are the techniques you'd currently miss.

Why running a SOC is genuinely hard

None of this is easy, and the failure modes are consistent enough to name:

• Alert fatigue. When the queue never empties and most alerts are noise, analysts start rubber-stamping. The dangerous alert is the one that arrives on hour six of a shift full of false positives.
• Tuning debt. Detection rules rot. Environments change, new apps appear, and yesterday's precise rule becomes today's noise generator. Tuning is never finished.
• Coverage gaps. You can only detect what you have logs for. A missing log source — an unmonitored cloud account, a forgotten server — is a room with the lights off, and attackers look for exactly those.
• Talent retention. SOC work, especially Tier 1, burns people out. Shift work, high alert volume, and repetitive triage drive turnover, and every departure takes environment-specific knowledge with it. Automation and a real career ladder from T1 upward are the usual defenses.

The SOC maturity curve

SOCs aren't all at the same level, and the honest way to think about progress is a curve from reactive to proactive. You can place almost any team on it.

The jump that matters most is from reactive to proactive: the shift from only answering alarms to actively looking for the attacker who hasn't tripped one yet. That's threat hunting, and it's the clearest sign a SOC has grown up.

Where the SOC sits: blue team, IR, and threat intel

The SOC doesn't operate alone — it's the operational heart of a wider defensive effort. The blue team is the broader defensive discipline; the SOC is its always-on operational arm, though the two terms get used interchangeably (see red, blue and purple teams explained). Incident response is the sharp end the SOC escalates into when something is confirmed serious — sometimes a dedicated CSIRT, sometimes the SOC's own Tier 3. And threat intelligence feeds it from the outside: knowledge of which adversaries and techniques are active right now, so detections and hunts target what attackers are actually doing rather than what they did last year. Understanding the threats themselves is upstream work — our guide to threat modeling with STRIDE is a good on-ramp. A healthy SOC is a hub these three plug into, not a silo.

Tools and frameworks worth knowing

Two frameworks and one deeper article will take you a long way past this overview:

• MITRE ATT&CK — a free, curated knowledge base of real adversary tactics and techniques. It's the common language SOCs use to describe attacks, measure detection coverage, and plan hunts. If you learn one framework, learn this one.
• NIST SP 800-61 — the Computer Security Incident Handling Guide, which lays out the incident lifecycle every SOC's response process is built on: preparation; detection and analysis; containment, eradication, and recovery; and post-incident activity. The SANS six-step handling model (often remembered as PICERL) covers the same ground with a slightly different breakdown.
• The toolstack. We deliberately kept tools to a walk-on part here. For the real comparison of SIEM, SOAR, and EDR platforms and how they fit together, read the SOC toolstack: SIEM, SOAR and EDR.

Strip it all back and a SOC is a simple promise made continuously: someone is watching, someone will notice, and someone will act. Everything above — the tiers, the pipeline, the metrics, the maturity curve — is just the machinery that keeps that promise at three in the morning.

Frequently asked questions