Medir la eficacia de un SOC no consiste en contar cuántas alertas cierra un equipo cada día. Un centro de operaciones puede cerrar miles de tickets y, al mismo tiempo, tardar demasiado en detectar una intrusión importante. En 2026, con más automatización e inteligencia artificial, la medición tiene que centrarse cada vez más en resultados: qué ataques se detectan, cuánto se tarda en responder, cuántos falsos positivos generan los sistemas y si las acciones del SOC reducen realmente el riesgo.
La cuestión es especialmente importante porque los equipos de seguridad están incorporando IA y automatización a gran velocidad. El informe anual de SANS sobre SOC muestra que la adopción de IA/ML es ya muy elevada, pero también que el recuento de incidentes continúa siendo una métrica habitual. Eso demuestra que muchas organizaciones siguen midiendo actividad operativa cuando deberían medir eficacia. citeturn1search6
El error de medir un SOC por volumen
El número de alertas procesadas, tickets cerrados o investigaciones completadas es fácil de obtener. Precisamente por eso puede resultar engañoso. Si un sistema genera demasiadas alertas de baja calidad, el SOC puede mostrar una productividad espectacular simplemente porque sus analistas están ocupados apagando incendios.
Una buena métrica debe responder a una pregunta de negocio o de seguridad. ¿Detectamos antes las amenazas? ¿Reducimos el tiempo de exposición? ¿Contenemos los incidentes antes de que alcancen sistemas críticos? ¿La automatización libera horas para investigaciones complejas? ¿Las detecciones cubren las técnicas que realmente afectan a la organización?
1. MTTD: tiempo medio de detección
El Mean Time to Detect, o MTTD, mide cuánto tiempo transcurre entre el inicio de una actividad maliciosa y su detección por el SOC. Es una de las métricas básicas para evaluar la capacidad de visibilidad.
Conviene medirlo por tipo de incidente. Un phishing sencillo y una intrusión que utiliza credenciales válidas no deberían mezclarse en una única cifra. También es útil observar percentiles, porque una media puede esconder unos pocos incidentes extremadamente lentos.
2. MTTR: tiempo medio de respuesta o recuperación
El MTTR debe definirse con cuidado porque puede significar cosas distintas según la organización. En un SOC conviene especificar qué evento marca el inicio y qué evento marca el final. Puede ser desde la detección hasta la contención, o desde la apertura del incidente hasta su cierre.
Lo importante es no utilizar una única cifra para todo. Medir el tiempo hasta la primera acción de contención puede ser mucho más útil para un incidente activo que medir cuánto tarda el equipo en completar toda la documentación posterior.
3. Tasa de falsos positivos
Una detección que genera demasiados falsos positivos consume tiempo y termina dañando la capacidad del SOC para reconocer señales realmente importantes. Por eso conviene calcular el porcentaje de alertas que resultan benignas después de la investigación.
La cifra debe analizarse por regla, fuente y tipo de alerta. Una regla con una tasa de falsos positivos muy superior a la media puede necesitar ajuste, contexto adicional o sustitución.
4. Tasa de verdaderos positivos y calidad de las detecciones
No basta con reducir falsos positivos. También hay que comprobar que el SOC no está eliminando ruido a costa de perder ataques. Una regla demasiado restrictiva puede presentar una tasa de precisión excelente y, sin embargo, no detectar la actividad que interesa.
Una buena práctica consiste en combinar métricas de precisión con ejercicios controlados, threat hunting y simulaciones. Las detecciones deben probarse contra técnicas conocidas y contra escenarios relevantes para el entorno concreto.
5. Cobertura frente a técnicas de ataque
Un SOC eficaz debe conocer qué partes del ciclo de ataque puede detectar. El mapeo de detecciones a marcos como MITRE ATT&CK permite identificar huecos de cobertura y priorizar ingeniería de detecciones.
Esta métrica es más útil que decir simplemente que una organización tiene cientos de reglas. Una colección enorme de detecciones redundantes puede cubrir peor el riesgo real que un conjunto más pequeño pero bien diseñado.
6. Porcentaje de incidentes automatizados
Con la llegada de los SOC agénticos, esta métrica gana importancia. Hay que saber qué porcentaje del trabajo puede ejecutarse automáticamente y, sobre todo, qué resultado produce esa automatización.
Automatizar el 80 % de las tareas no es necesariamente mejor que automatizar el 40 %. Si el primer 80 % incluye acciones de alto riesgo sin supervisión, el resultado puede ser negativo. La métrica debe acompañarse de tasas de error, rollback y aprobación humana.
7. Tiempo dedicado por analista a tareas repetitivas
Una de las funciones más interesantes de la IA en un SOC es eliminar trabajo administrativo: recopilar evidencias, enriquecer indicadores, consultar múltiples sistemas, preparar líneas temporales o redactar informes iniciales.
Por ello, conviene medir cuántas horas semanales dedica un analista a estas tareas antes y después de introducir automatización. Si la tecnología funciona, una parte de ese tiempo debería trasladarse hacia threat hunting, ingeniería de detecciones, análisis de campañas y mejora de controles.
8. Tasa de escalado correcto
No todos los incidentes deben llegar al mismo nivel de respuesta. Un SOC maduro necesita medir si los casos se escalan correctamente. Demasiados escalados innecesarios saturan a los especialistas; pocos escalados pueden ocultar incidentes importantes.
9. Tiempo hasta la contención
En incidentes críticos, el tiempo hasta contener la amenaza puede ser más relevante que el tiempo hasta cerrar el ticket. Una organización puede tardar horas en completar el informe final y seguir teniendo un buen resultado si consiguió aislar rápidamente la cuenta o dispositivo comprometido.
10. Incidentes repetidos y reducción del riesgo
Esta es una de las métricas más importantes y menos utilizadas. Si el SOC detecta diez incidentes provocados por la misma debilidad y ninguno provoca una corrección estructural, el sistema está respondiendo pero no está aprendiendo.
Conviene medir cuántos incidentes reaparecen por la misma causa, cuánto tardan en corregirse las debilidades encontradas y qué porcentaje de recomendaciones del SOC termina implementándose.
Un cuadro de mando práctico para 2026
Una organización puede comenzar con un panel reducido:
- MTTD por severidad.
- Tiempo hasta la contención.
- MTTR.
- Tasa de falsos positivos.
- Cobertura de técnicas prioritarias.
- Porcentaje de investigaciones automatizadas.
- Errores o acciones revertidas por automatización.
- Horas de analista ahorradas.
- Incidentes repetidos.
- Tiempo de corrección de las causas raíz.
El objetivo no es crear un panel con cien indicadores. Es seleccionar un grupo pequeño de métricas que permitan detectar degradación, comparar periodos y demostrar si el SOC está reduciendo el riesgo.
La métrica definitiva: resultados de seguridad
La madurez de un SOC se aprecia cuando las métricas operativas empiezan a relacionarse con resultados. Menor MTTD es positivo si permite contener ataques antes de que alcancen sistemas críticos. Menos falsos positivos es positivo si no reduce la cobertura. Más automatización es positiva si disminuye el tiempo de respuesta sin elevar los errores.
La llegada de la IA hace esta disciplina todavía más importante. Un SOC puede parecer muy eficiente porque los agentes procesan miles de eventos, pero la organización necesita saber si esos agentes están tomando buenas decisiones y si el riesgo final está disminuyendo.
Conclusión
La pregunta correcta no es cuántas alertas procesa un SOC, sino cuánto riesgo consigue eliminar y con qué coste. En 2026, los mejores cuadros de mando combinan velocidad, calidad, cobertura, automatización y resultados. MTTD y MTTR siguen siendo esenciales, pero deben acompañarse de falsos positivos, cobertura de detecciones, tiempo hasta la contención y métricas que demuestren que el SOC aprende de cada incidente.
Deja una respuesta