Métricas SOC 2026: las que importan a un CISO y las que no

El hallazgo primero: la mayoría de los dashboards SOC que revisamos en assessments de madurez miden esfuerzo, no resultado. Alertas procesadas por día, tickets cerrados, eventos ingestados por segundo. Son cifras grandes, crecen cada trimestre y no responden a la única pregunta que el consejo hace: ¿estamos mejor protegidos que hace un año?

Las métricas de actividad tienen dos defectos estructurales. Primero, premian el volumen: un SOC que genera más alertas de baja calidad parece más productivo que uno que afina sus detecciones y genera menos. Segundo, son manipulables sin mejorar nada: basta cerrar tickets en bloque antes del corte mensual o reclasificar severidades para que la curva mejore.

• Alertas procesadas: mide carga del SIEM, no capacidad de detección. Un actor que evade sus reglas no genera ninguna alerta.
• Tickets cerrados dentro de SLA: incentiva cierres rápidos y superficiales, no investigaciones completas.
• Volumen de logs ingestados: mide coste de almacenamiento, no visibilidad útil. Ingestar más fuentes irrelevantes empeora la señal.

Una métrica de resultado mide si el SOC detecta antes, contiene antes y cubre las técnicas que le afectan. Son más difíciles de calcular y más difíciles de manipular. Esa dificultad es precisamente su valor ante un consejo o un regulador.

MTTD y MTTR siguen siendo válidos, pero están saturados de gaming. La corrección es metodológica, no abandonarlos. Desagregue siempre por severidad y por vector: un MTTR agregado de 4 horas no dice nada si los incidentes de ransomware tardan días y el promedio lo bajan los falsos positivos cerrados en minutos.

El dwell time es la métrica más honesta de las tres porque mide al adversario, no al analista. Su limitación es estadística: solo existe cuando hay un incidente confirmado, así que la muestra trimestral suele ser pequeña. Repórtelo como rango y tendencia anual, no como promedio trimestral, y complételo con resultados de ejercicios: detecciones en purple team o en un TLPT estilo TIBER-EU generan datos de dwell time controlados sin esperar a un incidente real.

La métrica que mejora sola es sospechosa. Si MTTD o MTTR mejoran trimestre tras trimestre sin cambios en detecciones, plantilla o automatización, lo más probable es que haya cambiado la forma de medir, no la capacidad. Un assessment independiente de madurez verifica la integridad de la medición, no solo el número.

La cobertura de detección frente a MITRE ATT&CK es la métrica de calidad central, con dos condiciones. Primera: cobertura relevante, no absoluta. Cubrir el framework completo es ruido; cubrir las técnicas de los actores que atacan su sector es la cifra defendible. Segunda: cobertura validada. Una técnica solo cuenta como cubierta si la detección se ha probado con un ataque simulado, no porque exista una regla con ese nombre.

La salud del ciclo de vida de use cases es el indicador que separa un SOC que opera de uno que mejora. Cada use case debe tener dueño, fecha de última validación, ratio de falsos positivos y criterio de retirada. El informe SOC-CMM 2026 sitúa la cobertura media de ATT&CK en torno al 60%; la diferencia entre un 60% sano y un 60% decorativo está justamente en ese ciclo de vida.

• % de use cases validados con simulación en los últimos 12 meses.
• % de use cases con falsos positivos por encima del umbral pactado (candidatos a ajuste o retirada).
• Tasa de automatización: % de acciones de respuesta de nivel 1 ejecutadas por playbook sin intervención humana, con tasa de error de la automatización al lado.

Una métrica aislada no tiene contexto. ¿Un MTTD de 6 horas es bueno? Depende de la madurez del proceso que lo produce. Aquí es donde la puntuación SOC-CMM (escala continua 0-5 en cinco dominios: Business, People, Process, Technology y Services) convierte métricas operativas en evidencia de gobierno: dice si el número sale de un proceso repetible o de un esfuerzo heroico irrepetible.

Los datos del informe SOC-CMM 2026 dan referencias útiles para el consejo: medias por dominio de 2,5 en Business, 2,3 en People, 2,3 en Process, 2,7 en Technology y 2,2 en Services. Un SOC con Technology en 3,5 pero Process en 2,0 produce métricas bonitas y frágiles. Y un dato más incómodo: las autoevaluaciones sobreestiman la madurez en torno a 0,6 puntos. Si sus métricas y su madurez las puntúa el propio equipo que las produce, el consejo está mirando un espejo, no una medición. Un assessment de madurez independiente elimina ese sesgo.

El consejo no necesita el dashboard del SOC; necesita una página que pueda leer en cinco minutos y defender ante un regulador. Estructura probada, de arriba abajo:

1. 1.Cabecera de madurez: puntuación SOC-CMM por dominio frente al objetivo y frente a la media del sector, con fecha del último assessment independiente.
2. 2.Tres métricas operativas: MTTD y MTTR por severidad (tendencia 4 trimestres) y dwell time como rango anual.
3. 3.Tres métricas de calidad: cobertura ATT&CK relevante y validada, % de use cases validados en 12 meses, tasa de automatización con su tasa de error.
4. 4.Dos métricas de riesgo: gaps SOC-CMM materiales abiertos y % de avance del roadmap de remediación.
5. 5.Una narrativa: los 2-3 incidentes o ejercicios del trimestre, qué se detectó, qué falló y qué cambió como consecuencia.

Total: entre 6 y 9 cifras más una narrativa. Cada cifra con tendencia, objetivo y fuente. Si una métrica no cambia ninguna decisión del consejo, no pertenece a esta página.