SOC as a Service: guía para externalizar tu SOC en 2026

Montar y mantener un centro de operaciones de seguridad (SOC) propio es uno de los proyectos más caros y difíciles dentro de un programa de ciberseguridad. Requiere analistas en tres turnos, herramientas que cuestan cinco o seis cifras anuales, runbooks que se afinan durante meses, conexión con inteligencia de amenazas y un proceso de mejora continua que no se compra hecho. Por eso, en 2026, la mayoría de empresas medianas en España optan por SOC as a Service: contratar a un proveedor especializado que ya tiene todo eso montado y lo aplica a sus sistemas.

Esta guía explica qué es exactamente un SOC as a Service, qué componentes técnicos incluye, los tres modelos de externalización que existen, los SLA que un proveedor serio se compromete a cumplir, qué cuesta de media en el mercado español y qué señales separan a un SOC profesional de un servicio cosmético.

Qué es un SOC as a Service

Un SOC as a Service (también conocido como SOC gestionado, SOC externalizado, managed SOC o, según el alcance, MDR) es un servicio donde un proveedor especializado pone a disposición de tu empresa tecnología, procesos y personas dedicadas a detectar, analizar y responder a incidentes de seguridad de forma continuada, normalmente 24x7. No es solo monitorización: incluye triaje de alertas, contención inicial, escalado, comunicación con tu equipo y mejora iterativa de las detecciones.

La pregunta que responde un SOC as a Service es directa: si entra alguien o pasa algo raro en mi infraestructura, ¿lo detectamos a tiempo y reaccionamos antes de que haga daño?. La respuesta interna depende de tener tres cosas a la vez: tecnología que vea lo que pasa, personas que sepan interpretar lo que ve, y procesos que conviertan una alerta en una acción.

En la práctica, un SOC as a Service profesional incluye:

• Recolección y normalización de logs desde servidores, endpoints, firewalls, identidad (AD, Entra ID), aplicaciones, cloud (AWS, Azure, GCP) y red.
• Plataforma de detección (SIEM, XDR o ambos) con reglas de correlación afinadas para tu entorno, no recetas genéricas.
• Analistas L1/L2/L3 que reciben las alertas, las triajan, descartan los falsos positivos y escalan los reales.
• Threat intelligence integrada con feeds comerciales y open source, contextualizando alertas con TTPs conocidos de actores reales.
• Automatización de respuesta (SOAR) para acciones repetitivas: aislar un equipo, bloquear una IP, deshabilitar una cuenta, lanzar un playbook.
• Procedimientos de comunicación con tu equipo en plazos definidos por SLA.
• Reporting periódico ejecutivo y técnico, además de informes post-incidente.
• Mejora continua de reglas y detecciones según lo que se ve en tu entorno y en otros entornos del mismo sector.

Si lo que te ofrecen es "te enviamos alertas del SIEM" sin analistas que las interpreten, eso no es un SOC, es un servicio de monitorización. La diferencia se nota cuando llega una alerta a las 03:14 de un domingo.

Componentes técnicos de un SOC

Un SOC moderno se construye sobre cinco capas que tienen que funcionar coordinadas. Cada una respondiendo a una función concreta:

La pieza que más diferencia entre un SOC sólido y uno mediocre no es la tecnología, son los analistas y los runbooks. Hay SOCs caros con tecnologías excelentes que generan miles de alertas al día y nadie las mira en serio. Y hay SOCs eficaces con stack moderado que detectan amenazas reales porque los analistas conocen el entorno y los runbooks están afinados.

Cada una de estas capas tiene su propia guía técnica en el blog: el concepto general en qué es un SOC, la capa de detección en qué es un SIEM (con Wazuh como alternativa open source), la telemetría de endpoint en qué es un EDR, la búsqueda proactiva de amenazas en qué es threat hunting y el modelo gestionado de respuesta en qué es MDR.

SOC propio vs SOC as a Service

La decisión entre montar un SOC interno o contratar uno gestionado no es solo financiera. Hay variables operativas que pesan tanto como el coste:

El punto de inflexión típico en España: por debajo de 300 a 500 empleados, un SOC propio rara vez compensa salvo en sectores muy regulados (financiero, defensa, infraestructura crítica). Entre 500 y 2.000 empleados, el modelo híbrido (SOC interno de horario laboral + SOC as a Service para 24x7) es habitual. Por encima de 2.000, las empresas suelen tener SOC propio con servicios especializados externalizados (threat intel avanzada, hunting bajo demanda).

Si estás en la franja donde la cuenta sale, el servicio de ciberseguridad gestionada de Secra cubre los tres modelos (totalmente externalizado, híbrido y co-managed) con SOC 24x7 sobre SIEM propio o del cliente.

Modelos de externalización: completamente gestionado, híbrido y co-managed

No todas las externalizaciones son iguales. Hay tres modelos principales con implicaciones operativas y contractuales distintas:

Modelo 1: SOC totalmente externalizado

El proveedor opera 100% del SOC. Tu empresa entrega telemetría, recibe alertas escaladas, ejecuta acciones de mitigación en sus sistemas cuando se lo indican. El proveedor tiene SIEM/XDR propio, analistas, threat intel, SOAR y reporting. Es el modelo más simple de gestionar pero requiere confianza alta en el proveedor y un proceso de comunicación bien aceitado.

Ideal para empresas que no quieren (o no pueden) tener equipo SOC propio. Habitual en pymes y medianas empresas hasta 500 empleados.

Modelo 2: SOC híbrido

Tu empresa tiene un equipo interno que cubre horario laboral, y el proveedor cubre noches, fines de semana y festivos. Habitualmente el SIEM se comparte (es del proveedor o del cliente, según contrato) y la lógica de detección la afinan conjuntamente. Los runbooks de respuesta son compartidos.

Ideal para empresas medianas y grandes que quieren control sobre el horario crítico pero no quieren la complejidad operativa del 24x7.

Modelo 3: Co-managed SOC

El SIEM, las herramientas y la infraestructura las tiene la empresa cliente. El proveedor aporta solo personal especializado (analistas L2/L3, threat hunters) que trabajan dentro de las herramientas del cliente. Permite mantener control técnico y cumplir requisitos de soberanía del dato, externalizando solo el talento difícil de contratar.

Ideal para empresas grandes con SOC propio que necesitan reforzar áreas específicas (hunting, forense, threat intel) sin contratar.

SLA típicos en un SOC as a Service

Los acuerdos de nivel de servicio son la diferencia entre un SOC con compromiso real y un servicio de buzón de quejas. Los SLA que un proveedor profesional asume:

Pide siempre el reporting mensual de cumplimiento de SLA por escrito. Sin métricas medibles, "tenemos un SOC 24x7" no significa mucho.

Coste de mercado en España 2026

Los rangos que se ven en el mercado español varían mucho según el tamaño del entorno (eventos por segundo, endpoints, usuarios, cloud accounts) y el modelo elegido. Cifras orientativas industry-wide, no propuesta de Secra:

El coste de un SOC propio 24x7 con plantilla mínima viable en España (8 analistas en turnos, supervisor, ingeniero SIEM, plataforma) ronda los 400.000 a 800.000 € anuales solo en costes operativos, sin contar licencias ni inversión inicial.

Cuándo conviene externalizar tu SOC

Escenarios donde el SOC as a Service tiene sentido económico y operativo claro:

1. No tienes SOC y necesitas uno por NIS2, DORA o ENS. Montar uno desde cero tarda más de un año, y NIS2 obliga a notificar incidentes significativos en plazos de 24 horas (alerta temprana) y 72 horas (notificación de incidente). La externalización te pone en funcionamiento en semanas y cubre esos plazos desde el día 1.
2. Tienes SIEM pero las alertas no las mira nadie en serio. Síndrome muy común: licencia cara, alertas que se acumulan, falsos positivos sin filtrar. Un proveedor SOC limpia el ruido y convierte el SIEM en algo útil.
3. Tu equipo de seguridad está saturado con la operación y no llega a la mejora. Externalizando la operación del día a día, tu equipo interno puede dedicarse a estrategia, arquitectura y proyectos.
4. No consigues retener analistas SOC. El talento de SOC rota mucho. Si has perdido tres analistas en dos años, la economía cambia.
5. Necesitas cobertura 24x7 sin contratar 8 personas. Geométricamente más barato y operativamente más estable.

Y dos donde no conviene:

1. Tu negocio exige soberanía completa del dato y no aceptas que telemetría salga de tu infraestructura. Aquí encaja co-managed o SOC propio.
2. Operas sistemas tan específicos que ningún proveedor los entiende. Algunos entornos industriales OT o ICS muy específicos requieren equipo interno o consultoría muy especializada.

Si tu caso está claramente en el primer grupo, la decisión siguiente es elegir modelo y proveedor. En ciberseguridad gestionada de Secra cubrimos los tres modelos descritos arriba con SLA medibles y cobertura 24x7 desde el onboarding.

Cómo elegir un proveedor de SOC as a Service

Hay cinco criterios que separan a un proveedor profesional de uno que vende un dashboard bonito:

1. Métricas SLA por escrito y por contrato. MTTD, MTTA, MTTR, falsos positivos. Si no se comprometen con números, no se comprometen con nada.
2. Equipo técnico identificable. Analistas con experiencia documentable, certificaciones (GCIH, GCFA, GCIA, OSCP, OSDA), perfiles públicos en LinkedIn. Si no puedes ver al equipo, no hay equipo.
3. Onboarding estructurado con fases claras: inventario de activos, integración de fuentes, calibración de reglas, simulacro de incidente, paso a producción. No "lo activamos y ya está".
4. Soberanía del dato y cumplimiento normativo. Dónde se almacenan tus logs, cuánto tiempo se retienen, quién accede, si cumple ENS, ISO 27001 o el esquema que tu sector exija. Pide la documentación.
5. Demo realista, no marketing. Pide ver el portal de cliente con un caso real sanitizado. Ver una alerta escalada, un informe post-incidente, un dashboard de reporting. Si solo te enseñan slides, falta producto.

SOC, MDR, MSSP: aclarando términos

Estos tres conceptos se solapan y se usan con criterios distintos según el proveedor. La diferencia rápida:

• SOC as a Service. Servicio gestionado de detección y respuesta sobre la infraestructura del cliente con SIEM/XDR, analistas y procesos de respuesta. Énfasis en la operación del centro.
• MDR (Managed Detection and Response). Foco específico en detección y respuesta sobre endpoints con tecnología EDR/XDR propia del proveedor. Suele ser un subset del SOC as a Service centrado en threats avanzadas y respuesta automatizada.
• MSSP (Managed Security Service Provider). Término más amplio que incluye SOC pero también gestión de firewalls, VPN, parcheo, antimalware, identidad. Es un paraguas comercial, no una categoría técnica.

Para una organización española en 2026, SOC as a Service y MDR son los dos productos clave. MSSP es relevante si quieres externalizar también la operación de seguridad básica.

Preguntas frecuentes

¿Cuánto tarda en estar operativo un SOC as a Service?

Entre 4 y 12 semanas según el tamaño del entorno y el número de fuentes a integrar. Un onboarding rápido en una pyme con cloud nativo y endpoints estándar puede cerrarse en un mes. En un entorno híbrido con sistemas legacy y aplicaciones a medida, llega a las 12 semanas.

¿Necesito tener SIEM propio antes de contratar?

No necesariamente. Hay proveedores que aportan su propio SIEM/XDR (modelo totalmente gestionado), y otros que trabajan sobre el SIEM del cliente (co-managed). En el primer modelo no necesitas tener nada; en el segundo, sí.

¿Quién mantiene la responsabilidad legal en caso de incidente?

La responsabilidad última de la seguridad de los datos es siempre del responsable del tratamiento (tu empresa). El proveedor del SOC tiene responsabilidad contractual definida en el SLA y el contrato. Es importante que el contrato cubra escenarios de fallo del proveedor, incidente con dolo o negligencia, y obligaciones de notificación.

¿Es compatible con NIS2 y DORA?

Sí, y es de hecho la opción más habitual para cumplir los requisitos de monitorización continua y gestión de incidentes de estas normas. El proveedor debe poder demostrar cumplimiento normativo propio (ISO 27001, ENS, certificaciones específicas del sector).

¿Es mejor contratar SOC as a Service o MDR?

Depende de qué activos sean más críticos. Un MDR se centra en detección y respuesta sobre endpoints con tecnología EDR/XDR del proveedor, y es muy eficaz contra ransomware y amenazas avanzadas dirigidas a estaciones de trabajo y servidores. Un SOC as a Service es más amplio: cubre endpoints, red, cloud, identidad y aplicaciones de forma coordinada. Para empresas que solo necesitan reforzar el endpoint con respuesta rápida, MDR cumple. Para empresas con superficie distribuida (cloud, identidad, aplicaciones a medida), SOC as a Service es la opción más completa. Muchos proveedores combinan ambos productos en el mismo contrato.

¿Cómo afecta a la respuesta a incidentes con autoridades (INCIBE-CERT, AEPD)?

El proveedor SOC participa en la detección, contención e investigación inicial. La notificación a autoridades sigue siendo responsabilidad del cliente, aunque muchos proveedores asisten en la redacción del comunicado y aportan los registros técnicos necesarios. Confirma en el contrato que el proveedor se compromete a colaborar en la respuesta forense.

¿Qué pasa con los datos sensibles que ven los analistas?

Los analistas del SOC tienen acceso a la telemetría de seguridad, no al contenido de negocio. En contratos serios se firma confidencialidad reforzada y, cuando aplica, acuerdos de protección de datos personales (DPA) con cláusulas específicas. Los proveedores cumplen ENS o ISO 27001 sobre su propia infraestructura.

¿Puedo cambiar de proveedor sin perder el histórico?

Depende del modelo. En co-managed los datos son tuyos y no migras nada. En totalmente externalizado, el contrato debe incluir cláusula de devolución de datos al cliente al finalizar, normalmente en formatos estándar (CSV, JSON, OCSF) para que puedan reimportarse en otra plataforma.

Por dónde empezar

Si tu empresa está evaluando externalizar el SOC, el orden razonable es:

1. Inventario de fuentes de telemetría. Qué hay que monitorizar (servidores, endpoints, cloud, identidad, aplicaciones, red).
2. Definición del alcance del servicio. Detección, respuesta, threat hunting, forense, reporting normativo.
3. Cobertura horaria. 8x5, 16x5 o 24x7 según criticidad del negocio.
4. Modelo de externalización. Totalmente gestionado, híbrido o co-managed.
5. Tres propuestas comparables. Mismo alcance, mismos SLA, misma cobertura. Sin igualar el alcance no hay comparativa útil.
6. Prueba piloto de 4 a 8 semanas antes de firmar el contrato largo. Permite validar la operativa real, no solo la propuesta comercial.

En Secra prestamos servicios de ciberseguridad gestionada integrando SOC, SIEM y monitorización continua, con casos de uso adaptados al perfil regulatorio de la empresa (NIS2, DORA, ENS, ISO 27001). Si quieres revisar qué modelo encaja con tu entorno, puedes contactarnos y lo evaluamos antes de hablar de propuesta.