Qué es un SOC: definición, cómo funciona y ejemplos

Un SOC (Security Operations Center, en español Centro de Operaciones de Seguridad) es el equipo y la plataforma que vigilan los sistemas de una empresa todos los días, todas las horas, para detectar y parar incidentes de ciberseguridad antes de que causen daño relevante. No es una herramienta sola: es la combinación de personas (analistas en turnos), tecnología (SIEM, EDR, SOAR, threat intelligence) y procesos (runbooks, escalado, comunicación con negocio) que convierte miles de alertas diarias en un puñado de decisiones operativas que paran ataques en marcha.

Esta entrada explica qué es exactamente un SOC, cómo funciona el flujo operativo, los niveles L1, L2 y L3, las métricas que importan y cuándo una organización necesita contratarlo (interno o gestionado).

Qué es un SOC: definición técnica

Un SOC es la función organizativa responsable de la detección, análisis y respuesta a eventos de seguridad sobre toda la superficie tecnológica de la empresa: endpoints, servidores, red, identidades, aplicaciones, cloud y SaaS. Su trabajo se mide con tres métricas principales:

• MTTD (Mean Time To Detect). Tiempo medio entre que un atacante actúa y el SOC se da cuenta.
• MTTR (Mean Time To Respond). Tiempo medio entre la detección y la contención.
• Cobertura sobre el inventario y sobre las técnicas relevantes (típicamente mapeada a MITRE ATT&CK).

Un SOC maduro no genera alertas; genera decisiones. La diferencia entre un SOC que aporta valor y uno que solo cuenta logs es exactamente esa.

Cómo funciona un SOC: flujo operativo

El flujo de trabajo estándar de un SOC tiene cinco bloques bien definidos:

1. Ingesta. Logs y telemetría de endpoints (EDR), red (firewall, NDR, proxy), identidades (Active Directory, IdP), aplicaciones, cloud (CloudTrail, Azure Activity, GCP Audit) y SaaS críticos llegan a la plataforma central.
2. Normalización y correlación. El SIEM ordena los eventos en un formato común y aplica reglas que correlacionan acciones individualmente inocuas (un login desde una ubicación nueva, una descarga masiva, la creación de una regla de reenvío) en una alerta priorizada.
3. Análisis humano. Los analistas L1 contrastan la alerta con el contexto del activo, la identidad y la threat intelligence. Si es real, escalan a L2 o L3 para profundizar.
4. Respuesta. Aislar el endpoint, deshabilitar la cuenta comprometida, bloquear la IP atacante, lanzar el procedimiento DFIR si el incidente es relevante. La automatización (SOAR) ejecuta acciones repetitivas sin intervención humana.
5. Mejora continua. Cada incidente se cierra con lessons learned: nuevas reglas, mejores runbooks, ajustes en EDR o configuración de la plataforma cloud.

Niveles de un SOC: L1, L2, L3

Un SOC profesional reparte el trabajo entre tres niveles para que el caro no haga lo barato y al revés:

• L1, triaje. Filtra el ruido, valida alertas y escala lo relevante. Es la primera línea de mirada humana sobre la alerta automática.
• L2, investigación. Correlaciona la alerta con el contexto del activo, contiene el incidente y decide la respuesta táctica.
• L3, caza avanzada. Threat hunting proactivo, análisis forense, ingeniería de detecciones para los casos que el L1 y L2 no resuelven.

Por encima del L3 hay roles de detection engineering (escribir las reglas y queries que disparan las alertas) e incident response (DFIR), que en SOCs grandes son equipos separados.

Ejemplo real: cómo un SOC detiene un compromiso por phishing

Imagina la situación: un usuario hace clic en un correo de phishing y entrega sus credenciales en una página fraudulenta. Esto es lo que ocurre en un SOC bien configurado:

• 00:00. El atacante usa las credenciales y firma desde una IP no habitual. El SIEM correlaciona "login desde país nuevo + horario fuera de patrón + sin MFA satisfactorio" y dispara una alerta.
• 00:03. L1 valida la alerta y contacta al usuario por teléfono para confirmar.
• 00:08. L2 deshabilita la cuenta, fuerza el reset de credenciales y revoca los tokens activos en el IdP. El EDR aísla el endpoint del usuario.
• 00:25. L3 revisa el alcance: el atacante creó una regla de reenvío automático en el buzón pero no llegó a exfiltrar nada relevante. Se elimina la regla y se documenta el incidente.
• +24 h. Nueva regla de detección para el patrón "creación de regla de reenvío + login desde país nuevo en menos de 15 minutos". El siguiente intento se detendrá antes.

Sin SOC, el atacante mantiene acceso durante semanas hasta que se nota una factura desviada, un cliente importante recibe un correo extraño desde el dominio legítimo de la empresa o aparecen credenciales internas en un foro.

SOC interno vs SOC gestionado (MSSP, MDR)

No todas las organizaciones necesitan un SOC propio. Conviven tres modelos:

• SOC interno. Equipo propio, plataforma propia. Justificado en empresas grandes con datos muy sensibles (banca, defensa, infraestructura crítica) y volumen suficiente para sostener turnos 24/7.
• MSSP (Managed Security Service Provider) o SOC gestionado. El proveedor opera la plataforma y los analistas. Es el modelo dominante en el mid-market español.
• MDR (Managed Detection and Response). Variante del MSSP centrada en detección avanzada y respuesta activa, no solo monitorización. Suele incluir compromiso explícito de contención humana en SLA cortos.

Para la mayoría de organizaciones medianas, un servicio gestionado (MSSP o MDR) es mucho más eficiente que montar un SOC propio. La economía de escala del proveedor (analistas compartidos entre clientes, threat intel propia, plataforma amortizada) es difícil de replicar internamente.

SOC, SIEM, NOC, CSIRT y CTI: en qué se diferencian

Estos cinco términos se mezclan continuamente y la distinción es operativa, no semántica:

• SOC. Equipo y plataforma de detección y respuesta a incidentes de seguridad.
• SIEM. Herramienta de correlación y agregación de logs que usa el SOC como base operativa.
• NOC (Network Operations Center). Centro de operaciones de red, con foco en disponibilidad y rendimiento, no en seguridad.
• CSIRT o CERT. Equipo de respuesta a incidentes (DFIR), que entra en juego cuando el SOC detecta un incidente serio.
• CTI (Cyber Threat Intelligence). Inteligencia de amenazas que alimenta las detecciones del SOC con contexto externo (campañas activas, IoC, TTP de actores).

Dicho corto: el SIEM es la herramienta, el SOC es la operación, el CSIRT entra cuando el SOC detecta algo serio, la CTI nutre las detecciones del SOC y el NOC se ocupa de que la red funcione, no de que sea segura.

Cuándo una empresa necesita un SOC

Tres señales claras indican que ha llegado el momento de contratar (o construir) un SOC:

1. Marco regulatorio que lo exige o lo presupone. NIS2 (artículo 21) exige capacidades de detección y respuesta; ENS categoría alta lo presume; DORA y PCI DSS también empujan en esa dirección.
2. Superficie de ataque relevante. Más de 100 empleados, presencia cloud no trivial, exposición pública (e-commerce, SaaS) o datos regulados (sanitarios, financieros).
3. Coste estimado del incidente superior a varios meses de servicio gestionado. Si una pyme española calcula entre 50.000 y 150.000 € de impacto medio por incidente, un MSSP que cuesta una fracción de eso al año amortiza con prevenir uno solo en varios años.

Si tu organización tiene CISO, equipo de IT y EDR pero nadie mira las alertas a las 3 de la madrugada, ya tienes el problema que un SOC resuelve.

Preguntas frecuentes

¿Qué diferencia hay entre un SOC y un SIEM?

El SIEM es la herramienta (la plataforma de correlación de logs); el SOC es el equipo y los procesos que la operan. Un SIEM sin SOC es un repositorio de eventos sin nadie que actúe sobre ellos. Un SOC moderno usa además EDR, SOAR, threat intelligence y plataformas de identidad, no solo SIEM.

¿Un SOC opera 24/7?

Idealmente sí. Los atacantes no respetan horarios y muchos compromisos se ejecutan en festivos o de madrugada precisamente para ganar tiempo. Para mid-market, lo realista es contratar un MSSP o MDR con cobertura 24/7 en lugar de montar turnos propios.

¿Qué KPIs miden la eficacia de un SOC?

Los principales son MTTD, MTTR, número de incidentes contenidos, cobertura sobre MITRE ATT&CK y tasa de falsos positivos. Un SOC que detecta tarde o que ahoga a su equipo en falsos positivos no funciona, aunque genere muchos informes bonitos.

¿Qué es un SOC as a Service?

Es la modalidad MSSP / MDR aplicada al SOC: el proveedor entrega la operación completa (analistas, plataforma y procesos) bajo un contrato con SLAs, en lugar de montarlo internamente. La mayoría de organizaciones medianas en España lo contratan así.

¿Cómo encaja el SOC con NIS2 y ENS?

NIS2 exige capacidades de detección, monitorización y respuesta como parte de las medidas obligatorias del artículo 21; el ENS categoría alta presupone monitorización continua. Un SOC operativo (interno o gestionado) es la evidencia técnica habitual para cumplir esos controles. Para detalle de NIS2 puedes leer NIS2 en España: cómo cumplir la normativa en 2026.

Recursos relacionados

• Qué es un SIEM: la plataforma que el SOC usa para correlacionar logs.
• Auditoría NIS2 paso a paso: cómo se evidencia la capacidad de detección y respuesta.
• Qué es un pentesting: cómo el pentesting alimenta las reglas de detección del SOC.
• TIBER-EU y TLPT en banca: pruebas avanzadas que activan el SOC bajo presión.
• Servicio de ciberseguridad gestionada: cómo integramos SOC, SIEM, EDR y respuesta humana 24/7.

El SOC en Secra

En Secra integramos el SOC dentro del servicio de ciberseguridad gestionada, combinando SIEM, EDR, threat intelligence y respuesta humana 24/7 con SLAs adaptados al perfil de riesgo del cliente. Si quieres una propuesta concreta para tu organización, escríbenos a través de contacto.