By Uniqcli Team
A security operations center (SOC) is the organizational function responsible for continuously monitoring an environment for security threats, triaging what it finds, investigating what survives triage, and coordinating the response. It is a combination of people, defined process and tooling rather than a room or a product, and it exists because detection is a continuous activity: an attacker does not wait for business hours, and the window between an intrusion and its discovery is the variable that decides how much damage the intrusion does.
Two other things share the acronym and neither is this. A system on a chip (SoC) is a processor design that integrates CPU, memory controller and peripherals onto one die. SOC 2 is an audit and attestation report on a service organization's controls, produced under AICPA standards. Both are legitimate uses of the letters and neither has anything to do with security monitoring; the rest of this page is about the security operations center.
The practical reason a buyer meets the term is that a SOC is where several separate purchases become one operating capability. Logging, endpoint telemetry, network detection and identity signals are individually useful and collectively useless without somebody watching them against a defined process. Deciding what that watching looks like — in-house, outsourced, or somewhere between — is usually a harder question than choosing any of the underlying tools, and it is the question this page is organized around.
What does a SOC actually do?
The core loop is monitor, triage, investigate, respond. Telemetry arrives from across the estate — endpoints, servers, network devices, identity providers, cloud services and applications — and detection logic raises alerts against it. An analyst triages each alert into one of three outcomes: benign and closeable, worth deeper investigation, or an incident requiring response. Investigation reconstructs what happened across systems and timeframes; response contains and eradicates it and hands the environment back in a known state. NIST's incident-response guidance, revised as SP 800-61r3 in April 2025 and restructured as a Cybersecurity Framework 2.0 community profile, is the reference most public-sector programs map that loop onto.
Around that loop sit functions that are easy to cut and expensive to lose. Detection engineering writes and maintains the rules the loop depends on. Threat hunting looks for activity no rule fired on, working from a hypothesis rather than an alert. Threat intelligence supplies the indicators and adversary context that make triage faster. Vulnerability and exposure management feeds the SOC a picture of what is actually reachable. Reporting turns all of it into something an executive, an auditor or a regulator can read.
What a SOC does not do is worth stating as plainly. It is not a help desk, and giving it password resets and printer tickets is the most reliable way to destroy its response capacity. It is also not a substitute for the engineering work that closes the gaps it finds — a SOC that reports the same misconfiguration every quarter is functioning correctly and being ignored.
Who staffs a SOC, and what does 24/7 really cost?
The traditional structure is tiered. Tier 1 triages the alert queue and escalates; Tier 2 investigates escalations and runs containment; Tier 3 handles the hardest incidents, hunts, and builds detections. Around them sit a SOC manager, detection engineers who maintain the tooling, and — in mature programs — a dedicated incident-response function. Many teams have flattened this model deliberately, because a queue-only Tier 1 role has poor retention and automated triage has absorbed much of what it used to do, but the underlying division between triage, investigation and engineering persists whatever the job titles say.
The staffing arithmetic is the part that surprises people, and it is arithmetic rather than opinion. Covering a single seat continuously means three shifts a day, seven days a week, every week of the year — and once weekends, leave, training, sickness and attrition are accounted for, a genuinely continuous single seat needs roughly five people rather than three. Two-person shifts double that. This is why the build-versus-buy conversation almost always begins with headcount rather than with tooling: the platform is a line item, and the rota is a permanent operating cost with a hiring market attached to it.
Analyst workload is the other constraint, and the published research is consistent about its direction. The 2025 SANS Detection and Response Survey found false positives to be the single most-cited detection challenge among security teams, and alert fatigue appears in survey after survey as a primary cause of both missed detections and analyst attrition. Any SOC design that does not include continuous rule tuning and automated closure of known-benign patterns is designing in the failure mode.
The four delivery models
An in-house SOC gives the most control and the deepest environmental knowledge, and costs the most to staff. It suits organizations with regulatory obligations that make outsourced monitoring awkward, with environments unusual enough that generic detections do not fit, or with enough scale that the rota is affordable. MITRE's freely available handbook 11 Strategies of a World-Class Cybersecurity Operations Center, the second edition of its earlier SOC textbook, is the standard reference for organizations designing one and is worth reading before committing to the model.
A fully managed service — an MSSP or an MDR provider — buys the rota rather than building it. The provider supplies analysts, tooling and process, and the organization supplies telemetry access and an escalation contact. It is the fastest route to continuous coverage and the usual answer below a certain size. The trade is contextual: an external analyst does not know that the odd-looking transfer at 2 a.m. is the finance system's normal batch job, so contract quality depends on how much environmental knowledge the provider can absorb and how tightly escalation is defined.
The hybrid model — internal analysts during business hours, a provider covering nights and weekends — is the most common shape in mid-size organizations, because it puts the people who understand the environment on the alerts most likely to matter while buying the hours nobody wants to staff. The fourth model, sometimes called a virtual or distributed SOC, has no dedicated facility at all: staff work remotely against shared tooling and a shared process. That model became ordinary after 2020, and it is worth noting that a physical SOC room is a choice about collaboration and access control, not a requirement of the function.
What technology sits behind a SOC?
The detection stack is usually a SIEM for aggregation, correlation and retention; endpoint detection and response for host-level telemetry and containment; network detection for traffic the endpoints cannot see; and identity monitoring, which has become the highest-value stream in cloud-heavy estates. A threat-intelligence platform supplies context, a case-management system holds the investigation record, and an automation layer — SOAR, or automation built into the SIEM — executes the repetitive steps of a response.
The infrastructure underneath is a genuine hardware line and frequently gets forgotten in the budget. Log retention is the largest single component: audit obligations are measured in months or years, and the storage sized against them is bought once and grown continuously. Analyst positions need multi-display workstations and, where analysts work across separated networks or classification boundaries, secure KVM switching so one desk can reach several systems without cross-connecting them. Then there is the ordinary data-center bill of materials — rack space, structured cabling, conditioned power and out-of-band management for the platform itself.
One design rule is worth carrying into any procurement: the monitoring stack should not depend on the environment it monitors. If the SIEM authenticates against the same directory an attacker has just compromised, or the analyst workstations sit on the network segment under investigation, the SOC loses visibility exactly when it is needed. Separate credentials, separate management paths and out-of-band access are cheap to specify at build time and very expensive to retrofit during an incident.
Why regulated buyers end up with one
For a great many organizations the SOC is not a security preference; it is how several control requirements get implemented at once. Federal control catalogs express the obligations separately — the Incident Response family covers preparation, handling, reporting and testing; Audit and Accountability covers what is logged, how long it is kept and how it is reviewed; and continuous-monitoring expectations cover the ongoing assessment of controls in operation. Nothing in those families names a security operations center, and in any environment of real size a SOC is what satisfying them simultaneously looks like.
The same shape recurs in the frameworks that sit on top. CMMC's incident-response and audit-and-accountability domains ask defense-industrial organizations to detect and report incidents and to review audit records; authorization programs expect continuous monitoring rather than a point-in-time assessment; and sector rules in healthcare, justice and payments each carry log-review and reporting duties of their own. The obligations arrive from different directions and land on the same function, which is why a compliance-driven SOC business case is often stronger than a threat-driven one even when the threat argument is the honest motivation.
Two practical consequences follow. First, reporting deadlines are a design input rather than an afterthought: obligations that require notification within a fixed number of hours of determining an incident put a hard floor under the escalation path and the on-call rota, and a monitoring arrangement that cannot meet the clock is not compliant regardless of how good its detections are. Second, the obligations flow downhill through contracts — organizations working with government, defense or regulated customers routinely inherit monitoring and reporting requirements from the entity above them, and cyber-insurance underwriting has begun asking the same questions. Read the actual clauses before sizing the capability, because the required coverage hours are usually written down somewhere.
How is a SOC measured?
The headline metrics are mean time to detect and mean time to respond, usually paired with dwell time — how long an intruder was present before discovery. They are the right things to care about and they are also the easiest numbers in security to make look good by accident: a SOC that only detects noisy commodity malware will post excellent averages, because the incidents it never sees never enter the calculation. Read them alongside a coverage measure, most commonly detection coverage mapped against the MITRE ATT&CK framework, which describes what the SOC is capable of seeing rather than how quickly it handled what it saw.
Operational health needs its own numbers. Alert volume per analyst per shift, false-positive rate by detection rule, escalation rate from triage, and the proportion of alerts closed automatically together describe whether the queue is survivable. A rising false-positive rate on a specific rule is a maintenance signal, not a staffing one, and separating those two is most of what good SOC management consists of.
Finally, test rather than assume. Purple-team exercises, detection validation and tabletop incident rehearsals answer a question no dashboard can: whether the alerts that should fire actually do, and whether the people on the rota know what to do when they fire at 3 a.m. on a holiday weekend. A detection that silently stopped working after a log-source change is indistinguishable from a quiet week until somebody deliberately triggers it.
Key takeaways
- A security operations center (SOC) is a function — people, process and tooling that continuously monitor, triage, investigate and respond — rather than a room or a product.
- The acronym is shared: a system on a chip (SoC) is a processor design and SOC 2 is a controls attestation report; neither relates to security monitoring.
- Continuous coverage of one seat needs roughly five people once shifts, leave, training and attrition are counted, which is why staffing usually decides build-versus-buy before tooling does.
- Four delivery models exist — in-house, fully managed (MSSP or MDR), hybrid with a provider covering nights and weekends, and a distributed team with no dedicated facility.
- The stack is SIEM plus endpoint, network and identity telemetry, with automation for repetitive response; log retention storage and analyst workstation infrastructure are real hardware lines.
- Measure detection coverage alongside mean time to detect and respond — speed metrics only describe the incidents the SOC saw, and testing is what proves the detections still fire.
Shop it at Uniqcli
Frequently asked
- Is a SOC the same thing as SOC 2?
- No, and the overlap is purely in the letters. A security operations center is an operational function that monitors an environment for threats. SOC 2 is a reporting standard under AICPA auditing guidance, in which an independent auditor examines a service organization's controls over security, availability, processing integrity, confidentiality or privacy and issues a report. An organization can hold a SOC 2 report without running a SOC, and can run a SOC without ever undergoing a SOC 2 audit — though in practice a SOC 2 examination frequently looks for evidence of the monitoring and log review a SOC provides.
- What is the difference between a SOC and a NOC?
- A network operations center watches availability and performance: uptime, capacity, latency, link failures, and the health of the infrastructure itself. A security operations center watches for adversary activity. The distinction matters because the two roles pull in opposite directions during an incident — a NOC's instinct is to restore service as quickly as possible, and a SOC may need a compromised system left running and untouched to preserve evidence. Some organizations combine them into one team; where they do, the escalation path has to state explicitly who decides between restoration and preservation.
- Should we build a SOC or buy a managed service?
- Start from the rota rather than the tooling. Continuous coverage of a single seat requires roughly five people once shifts, leave, training and attrition are accounted for, so the honest first question is whether that headcount is fundable and hirable in your market. Below that threshold, a managed service or a hybrid arrangement — internal analysts in business hours, a provider overnight and at weekends — usually delivers better coverage for the money. Above it, in-house buys environmental knowledge that an external analyst cannot easily acquire, which is what makes the difference on the alerts that matter.
- What is the difference between a SOC and a SIEM?
- A SIEM is a platform; a SOC is the function that uses it. The SIEM aggregates and correlates log data and raises alerts, and it will keep doing that whether or not anyone reads the output. The SOC is the analysts, the triage process, the investigation and escalation procedures, and the response capability that turn those alerts into decisions. Buying a SIEM without staffing a SOC produces a very well-instrumented environment that nobody is watching, which is one of the more common and more expensive failure patterns in security procurement.
- Does a SOC need a dedicated room with video walls?
- No. A physical operations room is a choice about collaboration, supervision and physical access control, not a requirement of the function, and distributed teams working against shared tooling and shared process are now ordinary. Where a dedicated facility does make sense — high-security programs, environments with classification or access-control boundaries, or teams that need constant face-to-face escalation — the room is a real construction project with power, cabling, display, workstation and secure switching requirements that belong in the budget from the start rather than as an afterthought.
- How do you tell whether a SOC is working?
- Look at coverage before speed. Mean time to detect and mean time to respond only describe incidents the SOC actually saw, so a team that detects nothing sophisticated can post excellent averages. Pair those figures with a detection-coverage assessment — commonly mapped against the MITRE ATT&CK framework — plus false-positive rate by rule, alert volume per analyst, and the results of purple-team or detection-validation exercises. Testing is what distinguishes a detection that still fires from one that silently broke after a log-source change.
Keep reading