A SOC (Security Operations Center) is the combination of people, processes, and technology that continuously monitors, detects, analyzes, and responds to cyber threats. It ingests events from logs, networks, and endpoints, correlates them in a SIEM, and contains incidents before they disrupt the business — typically operating around the clock, every day of the year.
What a SOC does
A SOC is the central cybersecurity function responsible for continuous monitoring of the IT environment and for coordinating incident response. Under the NIST methodology (Special Publication SP 800-61, the Computer Security Incident Handling Guide), the response lifecycle covers preparation, detection and analysis, containment, eradication and recovery, and post-incident learning. The SOC orchestrates all of these phases on a 24/7/365 basis, turning a chaotic stream of signals into a managed process.
The day-to-day work of a security operations center revolves around a flow of security events. Analysts receive signals from dozens of sources, filter out noise, and convert scattered records into clear, prioritized incidents. The core functions of a SOC can be summarized as follows:
- Monitoring and detection — collecting and correlating logs, network traffic, and endpoint telemetry on a single platform.
- Triage and prioritization — assessing alert severity, discarding false positives, and assigning criticality.
- Incident response — containing attacks, eradicating malicious activity, and recovering services.
- Threat hunting — proactively searching for hidden threats that evaded automated detection rules.
- Vulnerability management — tracking patches and configurations to shrink the attack surface.
- Reporting and metrics — computing MTTD and MTTR, and preparing evidence for audits and regulators.
A SOC also maintains an incident knowledge base, keeps response playbooks current, and continuously refines detection logic. A key reference is MITRE ATT&CK — a public catalog of the tactics and techniques used by real adversaries, which serves as a shared language between analysts and lets teams measure detection coverage. Many SOC decisions rely on threat intelligence: context about indicators of compromise, infrastructure, and adversary motivation turns raw alerts into well-founded verdicts.
SOC roles and tiers (L1/L2/L3)
A classic SOC is organized around a tiered escalation model. This division of labor, described in materials from the SANS Institute, allows large alert volumes to be processed without burdening the most expensive specialists with routine work. Each tier has its own scope of responsibility, skill set, and target metrics.
| Tier | Role | Primary tasks | Key metrics |
|---|---|---|---|
| L1 | Monitoring analyst (triage) | Initial alert sorting, false-positive filtering, escalation of confirmed events | MTTA, false-positive rate |
| L2 | Incident responder | Deep investigation, containment, hunting for related artifacts and attack scope | MTTR, containment completeness |
| L3 | Threat hunter and forensics specialist | Proactive threat hunting, malware reverse engineering, digital forensics, detection engineering | New detections, MITRE ATT&CK coverage |
Beyond analysts, a mature SOC includes detection engineers (who write and tune SIEM rules), SOAR engineers (who automate playbooks), a SOC manager, and often a dedicated incident response function. The role model directly affects reaction speed: the clearer the responsibilities and escalation paths, the less time is lost handing incidents between people.
SOC vs NOC
A SOC is often confused with a NOC (Network Operations Center). Both run around the clock and monitor infrastructure, but their goals are opposite in nature. A NOC is responsible for availability and performance: its job is to keep services running and SLAs met. A SOC is responsible for security: its job is to detect and stop an adversary, even when everything technically appears to be working.
| Criterion | SOC | NOC |
|---|---|---|
| Primary focus | Security threats and incidents | Service availability and performance |
| Responds to | Attacks, compromises, behavioral anomalies | Outages, degradation, overloads |
| Key metrics | MTTD, MTTR, number of incidents | Uptime, latency, SLA compliance |
| Typical tooling | SIEM, SOAR, EDR | Network monitoring systems, APM |
| Mental model | An adversary actively fights back | Failures are random |
The critical difference is mindset: a NOC assumes problems are random (a disk fails, a link drops), while a SOC works against an intelligent opponent who deliberately hides their tracks. That is why a SOC cannot rely on threshold alerts alone — it needs correlation, behavioral analysis, and human expertise.
In-house SOC vs outsourcing (SOCaaS/MSSP)
An organization can build its own in-house SOC, outsource the function as a service (SOCaaS — Security Operations Center as a Service), or engage an MSSP (Managed Security Service Provider). The choice depends on budget, process maturity, regulatory requirements, and talent availability. According to Gartner, the acute shortage of skilled analysts is one of the main reasons small and mid-sized businesses adopt managed models.
| Parameter | In-house SOC | SOCaaS | MSSP |
|---|---|---|---|
| Control | Full | Medium | Limited |
| Time to launch | Months to years | Weeks | Weeks |
| Cost model | High CAPEX + ongoing OPEX | OPEX subscription | OPEX subscription |
| 24/7 expertise | Must hire and retain | Included in the service | Included in the service |
| Customization | Maximum | High | Medium |
The differences between providers are subtle but important. A classic MSSP historically focused on managing security controls (firewalls, IDS) and forwarding alerts, leaving response to the customer. Modern SOCaaS is closer to a full external SOC that investigates and responds. A separate category is MDR (Managed Detection and Response), which emphasizes active, provider-led response. A detailed breakdown of these formats is covered in MDR vs MSSP vs SOC; if speed of containment is your priority, start with the overview of what MDR is.
SOC technologies (SIEM/SOAR/EDR)
The technology foundation of a SOC is a stack of complementary platforms. No single tool covers every task, so a mature SOC builds a pipeline: data is collected, normalized, correlated, and then response is partially automated.
- SIEM (Security Information and Event Management) — the core of the SOC. It collects and normalizes logs from all sources, correlates events, and raises rule-based alerts. Learn more in what is SIEM.
- SOAR (Security Orchestration, Automation and Response) — orchestration and automation of playbooks: alert enrichment, indicator blocking, and ticket creation without human intervention.
- EDR (Endpoint Detection and Response) — deep endpoint telemetry and response: host isolation, change rollback, process analysis. See what is EDR.
- Threat Intelligence Platform — aggregation of indicator feeds and adversary context.
- UEBA (User and Entity Behavior Analytics) — detecting anomalies in the behavior of users and accounts.
- NDR (Network Detection and Response) — network traffic analysis to detect lateral movement and covert channels.
A recent trend is the consolidation of these components into unified XDR (Extended Detection and Response) platforms and cloud-native SIEM. This reduces blind spots between tools and speeds up correlation, but it does not change the core principle: technology amplifies the analyst rather than replacing them.
How to build a SOC
Building a SOC is a program, not a one-off project. A common mistake is to start by purchasing a SIEM and only then think about processes and people. The correct order is the reverse: goals and risks first, then processes, and only then technology. Below is a pragmatic sequence of steps.
- Define the goal and threat model. What you are protecting, from whom, and which assets are critical. MITRE ATT&CK helps describe the relevant adversary techniques.
- Document the processes. Response playbooks, an escalation matrix, on-call schedules, and reaction SLAs by incident criticality.
- Assemble the team. At minimum an L1/L2 rotation to cover 24/7, or a deliberate decision to outsource part of the function.
- Onboard log sources. Prioritize authentication, endpoints, network, and cloud services. Telemetry completeness matters more than the raw number of sources.
- Configure detection. SIEM rules, Sigma rules, and behavioral models mapped to ATT&CK techniques; keep driving the false-positive rate down.
- Automate the routine. SOAR for enrichment and standard responses frees analysts for investigations.
- Measure and improve. Track MTTD and MTTR, run incident reviews and tabletop exercises, and refine playbooks.
SOC maturity grows iteratively. Start with basic coverage of critical assets and the most likely attack techniques, then expand visibility and automation. Regularly checking your external perimeter — security headers, TLS configuration, exposed ports, and DNS — reduces the flow of incidents before they ever reach the SOC and complements internal monitoring well.
FAQ
How is a SOC different from a SIEM?
A SIEM is a tool (a platform for collecting and correlating logs), while a SOC is an organizational function that includes people, processes, and a whole set of technologies, one of which is the SIEM. A SIEM on its own, without a team and processes, does not manage incidents.
Does a SOC operate around the clock?
Ideally yes — a 24/7/365 model, because attacks are not tied to business hours and often launch at night or on weekends. Smaller organizations use on-call rotations or outsource night shifts through SOCaaS/MDR to ensure continuity without inflating headcount.
Which metrics measure SOC effectiveness?
Key indicators are MTTD (mean time to detect), MTTR (mean time to respond and recover), MTTA (time to acknowledge an alert), the false-positive rate, and MITRE ATT&CK technique coverage. Together they capture both the speed and the quality of the center's work.
Does a small business need a SOC?
An in-house SOC is usually too expensive for a small business. A reasonable alternative is a managed model such as SOCaaS or MDR, which provides access to expertise and 24/7 monitoring on a subscription basis without capital spending on tools or hiring a team.
Are a SOC and a CSIRT the same thing?
Not quite. A CSIRT (Computer Security Incident Response Team) is a team focused specifically on responding to and investigating incidents. A SOC is broader: it includes continuous monitoring, detection, threat hunting, and often houses the response function itself. In many organizations, the CSIRT is part of the SOC.