What Is a SOC (Security Operations Center): How It Works

A SOC (Security Operations Center) is the team and the platform that watch an organisation's systems every day, every hour, to detect and stop cybersecurity incidents before they cause meaningful damage. It is not a single tool: it is the combination of people (analysts working in shifts), technology (SIEM, EDR, SOAR, threat intelligence) and processes (runbooks, escalation paths, communication with the business) that turns thousands of daily alerts into a handful of operational decisions that stop attacks in progress.

This guide explains what a SOC actually is, how the operational workflow runs, the L1, L2 and L3 tiers, the metrics that matter and when an organisation needs to bring one in (internal or managed).

What a SOC is: technical definition

A SOC is the organisational function responsible for detection, analysis and response to security events across the company's entire technology footprint: endpoints, servers, network, identities, applications, cloud and SaaS. Its work is measured against three main metrics:

• MTTD (Mean Time To Detect). Average time between when an attacker takes action and when the SOC notices.
• MTTR (Mean Time To Respond). Average time between detection and containment.
• Coverage over the inventory and over the relevant techniques (typically mapped to MITRE ATT&CK).

A mature SOC does not produce alerts; it produces decisions. The difference between a SOC that adds value and one that just counts logs is exactly that.

How a SOC works: operational workflow

The standard SOC workflow has five well-defined blocks:

1. Ingestion. Logs and telemetry from endpoints (EDR), network (firewall, NDR, proxy), identities (Active Directory, IdP), applications, cloud (CloudTrail, Azure Activity, GCP Audit) and critical SaaS land on the central platform.
2. Normalisation and correlation. The SIEM puts events into a common format and applies rules that correlate individually innocent actions (a login from a new location, a mass download, the creation of a forwarding rule) into a prioritised alert.
3. Human analysis. L1 analysts cross the alert with the context of the asset, the identity and threat intelligence. If real, they escalate to L2 or L3 for deeper work.
4. Response. Isolate the endpoint, disable the compromised account, block the attacker IP, trigger the DFIR procedure if the incident is significant. Automation (SOAR) executes repetitive actions without human intervention.
5. Continuous improvement. Every incident closes with lessons learned: new rules, better runbooks, adjustments in EDR or in the cloud platform configuration.

SOC tiers: L1, L2, L3

A professional SOC distributes work across three tiers so the expensive profile does not do the cheap work and vice versa:

• L1, triage. Filters noise, validates alerts and escalates what matters. It is the first human pair of eyes on the automatic alert.
• L2, investigation. Correlates the alert with the asset context, contains the incident and decides the tactical response.
• L3, advanced hunting. Proactive threat hunting, forensic analysis, detection engineering for cases that L1 and L2 cannot resolve.

Above L3 there are detection engineering roles (writing the rules and queries that fire alerts) and incident response (DFIR), which in large SOCs become separate teams.

Real example: how a SOC stops a phishing compromise

Imagine the scenario: a user clicks on a phishing email and hands over credentials on a fraudulent page. This is what happens in a properly configured SOC:

• 00:00. The attacker uses the credentials and signs in from an unusual IP. The SIEM correlates "login from new country + off-pattern hours + no successful MFA" and fires an alert.
• 00:03. L1 validates the alert and calls the user on the phone to confirm.
• 00:08. L2 disables the account, forces a credential reset and revokes active tokens at the IdP. The EDR isolates the user's endpoint.
• 00:25. L3 reviews the scope: the attacker created an automatic forwarding rule on the mailbox but did not exfiltrate anything meaningful. The rule is removed and the incident is documented.
• +24 h. A new detection rule is written for the pattern "creation of forwarding rule + login from new country within 15 minutes". The next attempt will be stopped earlier.

Without a SOC, the attacker keeps access for weeks, until a diverted invoice is noticed, an important client receives a strange email from the company's legitimate domain or internal credentials show up on a forum.

In-house SOC vs managed SOC (MSSP, MDR)

Not every organisation needs its own SOC. Three models coexist:

• In-house SOC. Own team, own platform. Justified in large companies with very sensitive data (banking, defence, critical infrastructure) and enough volume to sustain 24/7 shifts.
• MSSP (Managed Security Service Provider) or managed SOC. The provider runs the platform and the analysts. It is the dominant model in the Spanish mid-market.
• MDR (Managed Detection and Response). A variant of MSSP focused on advanced detection and active response, not just monitoring. Usually includes an explicit commitment to human containment under short SLAs.

For most mid-sized organisations, a managed service (MSSP or MDR) is much more efficient than building an in-house SOC. The provider's economies of scale (analysts shared across clients, proprietary threat intel, amortised platform) are difficult to replicate internally.

SOC, SIEM, NOC, CSIRT and CTI: how they differ

These five terms get mixed up all the time and the distinction is operational, not semantic:

• SOC. The team and platform for security detection and response.
• SIEM. The log aggregation and correlation tool the SOC uses as its operational base.
• NOC (Network Operations Center). Focused on availability and performance, not on security.
• CSIRT or CERT. Incident response team (DFIR), which kicks in when the SOC detects a serious incident.
• CTI (Cyber Threat Intelligence). Threat intelligence that feeds SOC detections with external context (active campaigns, IoCs, actor TTPs, CVE feeds applicable to the client stack).

In short: the SIEM is the tool, the SOC is the operation, the CSIRT enters when the SOC detects something serious, the CTI feeds SOC detections and the NOC takes care of the network running, not of it being secure.

When a company needs a SOC

Three clear signals indicate that the time has come to contract (or build) a SOC:

1. A regulatory framework that requires or presupposes it. NIS2 (article 21) requires detection and response capabilities; ENS high category presumes them; DORA and PCI DSS push in the same direction.
2. A meaningful attack surface. More than 100 employees, non-trivial cloud presence, public exposure (e-commerce, SaaS) or regulated data (health, financial).
3. Estimated incident cost higher than several months of managed service. If a Spanish SME estimates an average impact of tens to low-hundreds of thousands of euros per incident, an MSSP costing a fraction of that per year pays for itself by preventing a single incident over several years.

If your organisation has a CISO, an IT team and EDR but nobody looking at alerts at 3 a.m., you already have the problem a SOC is meant to solve.

Frequently asked questions

What is the difference between a SOC and a SIEM?

The SIEM is the tool (the log correlation platform); the SOC is the team and processes that operate it. A SIEM without a SOC is an event repository with nobody acting on it. A modern SOC also uses EDR, SOAR, threat intelligence and identity platforms, not just SIEM.

Does a SOC run 24/7?

Ideally yes. Attackers do not respect business hours, and many compromises run on holidays or overnight precisely to buy time. For the mid-market, the realistic move is contracting an MSSP or MDR with 24/7 coverage rather than building internal shifts.

Which KPIs measure the effectiveness of a SOC?

The main ones are MTTD, MTTR, number of contained incidents, MITRE ATT&CK coverage and false positive rate. A SOC that detects late or drowns its team in false positives is not working, no matter how many pretty reports it produces.

What is SOC as a Service?

It is the MSSP/MDR model applied to the SOC: the provider delivers the full operation (analysts, platform and processes) under a contract with SLAs, instead of building it internally. Most mid-sized organisations in Spain contract it this way.

How does the SOC fit with NIS2 and ENS?

NIS2 requires detection, monitoring and response capabilities as part of the mandatory measures in article 21; ENS high category presumes continuous monitoring. An operational SOC (internal or managed) is the usual technical evidence to meet those controls. For more on NIS2 see NIS2 in Spain: a compliance guide for 2026.

Related resources

• NIS2 in Spain: compliance guide for 2026: how detection and response capability becomes evidence for the regulator.
• DORA compliance guide for financial entities in 2026: the framework that pushes SOC capability in finance.
• What is a penetration test: how pentesting feeds the SOC detection rules.
• Penetration testing pricing in Spain: cost drivers when commissioning the audits that feed SOC detections.

The SOC at Secra

At Secra we run the SOC inside our managed cybersecurity service: full SIEM and EDR coverage, threat intelligence feeds, 24/7 human response and SLA tiers adapted to the client's risk profile (essential entity under NIS2, financial entity under DORA, high-category ENS, PCI scope). Identifiable analysts, documented runbooks, MITRE ATT&CK coverage tracked per quarter and quarterly review of MTTD/MTTR against the baseline. If you want a proposal with the actual detection coverage and SLA tiers for your real attack surface, get in touch through contact or check the managed cybersecurity catalogue.