Hard2bit
← Back to glossary Security operations

SOC (Security Operations Center)

What is a SOC

A SOC (Security Operations Center) is the team —with its processes and technology— that watches over an organisation's security continuously: it monitors signals from across the environment, detects suspicious activity, triages alerts, responds to incidents, hunts for threats proactively and reports the security posture to the business. It relies on a SIEM that centralises and correlates logs, on EDR or XDR at the endpoints, and on SOAR to automate repetitive responses. It can be an in-house team, a managed service (MDR) or a hybrid model; what defines it is not the room full of screens, but the ability to detect and respond before an incident escalates.

Why it matters

Buying security tools with nobody to operate them is the most expensive mistake in the industry: the SIEM piles up logs nobody reads, the EDR raises alerts nobody closes, and the attacker enjoys days or weeks of headroom. The two numbers that summarise a SOC's value are MTTD (mean time to detect) and MTTR (mean time to respond): the difference between spotting an anomalous login in twenty minutes or in three weeks is the difference between resetting an account and managing ransomware with exfiltration. Attackers operate in the small hours and on public holidays precisely because they know most companies have nobody watching; 24/7 coverage is not a luxury, it is the minimum condition for detection to mean anything. Frameworks such as NIS2 and DORA also demand demonstrable detection and incident-management capability, which is very hard to evidence without a structured operation. For most SMBs and mid-market companies, building that capability in-house is unrealistic —a continuous shift rota needs at least five analysts—, which is why the managed model (MDR) has become the practical route in.

Key points

Core functions: continuous 24/7 monitoring, threat detection, alert triage and prioritisation, incident response, proactive threat hunting, handling of detected vulnerabilities, and periodic reporting to leadership with metrics the business understands.

Technology stack: the SIEM centralises and correlates logs from across the organisation; EDR and XDR provide telemetry and the ability to act on endpoints and beyond; SOAR automates repetitive playbooks (enrich, block, notify) so analysts can focus on what requires judgement.

Tiered organisation: Tier 1 performs initial alert triage, Tier 2 investigates escalated cases, and Tier 3 handles hunting, forensics and detection engineering. In modern SOCs automation blurs the boundaries, but structured escalation remains.

Sourcing models: in-house SOC (full control, high cost, hard to staff 24/7), managed SOC or MDR (immediate access to continuous coverage and accumulated expertise), and hybrid (own team during business hours, provider for nights, holidays and surges).

Metrics that matter: MTTD and MTTR as the central indicators, false positive rate, coverage of log sources and of MITRE ATT&CK techniques, and the number of incidents contained before causing impact. A SOC that only reports 'alerts processed' is not measuring what counts.

Threat hunting separates a mature SOC from a reactive one: instead of waiting for an alert to fire, analysts form hypotheses (what if someone is using stolen valid credentials?) and test them against historical telemetry.

Example: A 3 a.m. intrusion at a company without and with a SOC

On a Tuesday at 3:47 a.m., an attacker logs into a 120-employee engineering firm using VPN credentials bought on a dark web market. Without a SOC: the login from an unusual country lands in a log nobody looks at, the attacker spends the following week moving laterally, locates the backup server and launches the encryption on a Friday night. The company discovers the incident on Monday, with production down and the online backups encrypted.

With a managed SOC: the SIEM's correlation flags the login as anomalous (new country, atypical hour, no registered travel) and raises a high-priority alert at 3:49. The on-call analyst validates the lead within minutes, disables the account, kills the VPN session and uses the EDR to isolate the one machine the attacker had managed to reach. By 4:30 the incident is contained: one compromised account and one machine to review, instead of a production outage. The follow-up report identifies the origin (credentials stolen by an infostealer on a personal device) and the company hardens MFA on the VPN. The difference was not the technology —the logs existed in both scenarios— but having someone watching at 3:47.

Common mistakes

  • Buying a SIEM and calling it a SOC. The platform without analysts, playbooks and an on-call rota merely accumulates logs; the SOC is the operational capability, not the tool.
  • Staffing the SOC only during office hours. Attackers deliberately operate at night and on holidays; an 8x5 SOC leaves uncovered exactly the hours when serious incidents happen.
  • Measuring performance by the volume of alerts processed instead of MTTD/MTTR and incidents contained. A SOC can close thousands of alerts a month and still miss the one intrusion that matters.
  • Not tuning detection rules to the company's context. Out-of-the-box rules generate an avalanche of false positives that burns out analysts and buries the real alerts (alert fatigue).
  • Contracting an MDR without defining the escalation playbook: who decides to isolate a production server at 4 a.m., with what authority and through which channel. Without that agreement, detection arrives on time but the response sits waiting for approvals.

Related terms

Related services

This concept may be related to services such as:

Frequently asked questions

What is the difference between a SOC and a SIEM?

The SIEM is the technology platform: it centralises logs, correlates them and generates alerts. The SOC is the complete operational capability: the analysts who investigate those alerts, the triage and escalation processes, incident response and reporting. A SIEM without a SOC is a log warehouse with alarms nobody answers; a SOC uses the SIEM as one of its central tools.

When does a managed SOC (MDR) make more sense than an in-house one?

An in-house 24/7 SOC needs at least five analysts just to cover the rota, plus the platform, detection engineering and continuous training: few organisations below several thousand employees can justify it. The managed model provides immediate access to continuous coverage and accumulated expertise at a fraction of the cost. Hybrid —own team by day, provider out of hours— is a common middle ground for mid-sized companies.

What are MTTD and MTTR and why do they matter so much?

MTTD is the mean time from when malicious activity occurs until it is detected; MTTR, from detection to containment or resolution. They are the metrics that best predict an incident's impact: almost all the damage in a modern attack —lateral movement, exfiltration, encryption— happens in the window between intrusion and containment. Shrinking that window is, in essence, the SOC's job.

Does an SMB really need a SOC?

It needs the function, not the department. No SMB is going to build a room with analyst shifts, but it can buy that capability as a managed service on top of its EDR and log sources. The practical test: if an incident causing several days of downtime would threaten the business, or if NIS2 or similar frameworks apply, continuous detection and response stop being optional.