Content
Services
Industries
Talk to an expert

What is a SOC (Security Operations Center)? Complete guide

· 7 min read · Network Secure

A SOC (Security Operations Center) is the combination of people, processes and technology that continuously watches a company's environment to detect attacks and respond to them in time. This guide explains what a SOC does, who works in it, which tools it uses, how it can be sourced and how to tell whether your company needs one.

What a SOC is, in one sentence

A SOC is the place, physical or not, where security events become decisions. Firewalls, servers, workstations, cloud and identity systems generate records all the time. The SOC collects those records, identifies what points to an attack and coordinates the response before the problem grows.

In the NIST Cybersecurity Framework 2.0, the SOC's work is concentrated in two of the six functions: Detect (finding and analyzing possible attacks and compromises) and Respond (taking action on a detected incident).

What a SOC does day to day

The routine follows a cycle that starts with data and ends with an action, then loops back with what was learned:

  1. Monitoring. Continuously receiving events from the environment's sources and making sure they keep sending data. A source that stopped sending logs is a blind spot.
  2. Detection. Applying rules and analytics that turn events into alerts: an impossible login, a strange process on a server, an abnormal volume of data leaving.
  3. Triage. Quickly deciding whether the alert is real, how severe it is and who needs to know.
  4. Investigation. Reconstructing what happened: how the attacker got in, which accounts and machines were touched, how far they went.
  5. Response. Containing (isolating a machine, blocking an account), engaging the people responsible and following through to closure, according to the incident response plan.
  6. Threat hunting. Actively searching for signs of compromise that have not yet triggered an alert, based on hypotheses about how an adversary would act.
  7. Threat intelligence. Bringing information about active campaigns, techniques and indicators into detection rules and hunting.

MITRE ATT&CK, a public knowledge base of tactics and techniques observed in real attacks, is the common language of this cycle: detections are mapped against it and gaps become visible. The difference between a SOC that merely forwards alerts and one that reduces risk is covered in Traditional vs. modern SOC.

People and roles

A SOC is usually organized in tiers, with names that vary between companies:

  • Tier 1 analyst. The front line. Works the alert queue, performs initial triage, discards noise and escalates what is real.
  • Tier 2 analyst. Takes escalated cases, investigates in more depth, correlates sources and drives containment.
  • Tier 3 analyst. The specialist for complex incidents: forensics, malware, attacks in progress. Usually leads the response in serious cases.
  • Detection engineering. Builds, tests and tunes detection rules and playbooks. This is who reduces false positives and closes coverage gaps.
  • Threat hunter. Runs proactive hunts and turns findings into new detections.
  • SOC manager. Owns processes, shift schedules, metrics and communication with executives and business units.

Since attacks do not keep business hours, these roles must be covered in 24×7 shifts, which is one of the main costs of a SOC. How the SOC (Blue Team) relates to the teams that simulate attacks is covered in Red Team, Blue Team and Purple Team.

Technologies and how they fit together

A SOC's tools form a chain, not a shopping list:

  • EDR/XDR. EDR monitors workstations and servers and allows action on them, such as isolating a machine. XDR extends that view to other layers (identity, email, cloud, network) in a single platform.
  • NDR. Analyzes network traffic to see what does not pass through a monitored endpoint, such as lateral movement and communication with command-and-control servers.
  • SIEM. Centralizes and correlates events from every source, keeps history for investigation and fires the alerts.
  • SOAR. Automates repetitive steps through playbooks: enriching the alert, checking reputation, opening a ticket, executing approved containment.

The typical flow is: EDR, NDR and other sources feed the SIEM; the SIEM correlates and alerts; SOAR enriches and executes; the analyst decides what has consequences. To choose the central platform, see how to choose a SIEM; to automate safely, the CISO's checklist for SOAR and playbooks; and for the role of artificial intelligence, AI in the SOC: what works.

Models: in-house, outsourced or hybrid

The UK NCSC guide on building a SOC covers all three options:

  • In-house. The company hires the team, buys the tools and runs everything. It offers full control and deep knowledge of the environment, but requires shift staffing, ongoing budget and time to mature.
  • Outsourced. A provider delivers the operation, either as MDR (focused on detecting and containing threats) or as SOC as a Service (the full operation, with metrics and governance).
  • Hybrid. Combinations such as an internal team during business hours and a provider outside them, or the provider on triage and the company on high-impact decisions.

In any model, outsourcing execution does not outsource accountability for risk. The detailed comparison, including what each model leaves in-house, is in SIEM as a service, MDR or SOC as a Service.

Metrics: how to measure a SOC

The two core metrics measure time, because time is what gives the attacker room to act:

  • MTTD (mean time to detect). From the start of malicious activity to detection.
  • MTTR (mean time to respond). From detection to containment or resolution.

Together, they show how long the intruder was free in the environment. They should come with the false positive rate and coverage of sources and ATT&CK techniques. To find out what stage your operation is at and what to prioritize, see SOC maturity: how to assess it.

Beware of averages. A low MTTR can hide a few serious incidents resolved slowly. Ask for metrics broken down by severity and follow the trend over months, not a single number.

Does your company need a SOC?

The most useful question is not "do I need a SOC?" but "who sees and responds to an attack at three in the morning on a Sunday?". Some signs that the current answer is not enough:

  • Nobody watches alerts after hours. Tools generate warnings that are only read the next business day.
  • There are logs, but no analysis. Events are stored and only looked at after something goes wrong.
  • There is no defined response process. It is unclear who may isolate a machine, who informs leadership and who talks to customers and regulators.
  • The company is regulated or holds sensitive data. Sectors such as finance, and any organization subject to Brazil's LGPD, must demonstrate the ability to detect and handle incidents.
  • IT also carries security. The people keeping systems running are also expected to investigate attacks.

If two or more of these signs apply, it is worth assessing which model closes the gap. For most mid-sized companies, building 24×7 shifts internally is expensive and slow, and an outsourced or hybrid 24×7 SOC with MDR is usually the most viable path.

Frequently asked questions

What is the difference between a SOC and a SIEM?

A SIEM is a tool that collects and correlates events. A SOC is the entire operation: the people who analyze alerts, the triage and response processes and the tools, the SIEM among them. Having a SIEM with nobody watching it is not having a SOC.

What is the difference between a SOC and MDR?

A SOC is the detection and response structure, whether in-house or contracted. MDR is a managed service model focused on detecting, investigating and containing threats, which can be one of the deliverables of an outsourced SOC.

Does a SOC replace the IT team?

No. The SOC detects, investigates and contains. Root remediation, such as patching the flaw or rebuilding a server, and business decisions during an incident remain with the company, with the SOC's support.

Sources consulted: NIST Cybersecurity Framework 2.0 (CSWP 29), Detect and Respond functions; NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management (2025); NCSC (UK), Building a Security Operations Centre; MITRE ATT&CK. Role and tier names vary between organizations. This article is educational and does not replace a technical assessment of your environment.

Official references

Read next