SLA y MTTR en remediación: cómo medir una gestión de vulnerabilidades que funciona

Si no puedes responder "¿cómo de rápido corregimos lo que importa?", no estás gestionando un programa de vulnerabilidades — solo estás generando informes. Dos métricas convierten la gestión de vulnerabilidades de actividad en responsabilidad: el SLA de remediación y el MTTR. Aquí tienes cómo definirlos, medirlos con honestidad y evitar las trampas.

Por qué importan las métricas de resultado

La métrica de vulnerabilidades más común —"número de vulnerabilidades abiertas"— es una métrica de vanidad. Sube y baja con el alcance del escaneo y no dice nada sobre si de verdad te estás volviendo más seguro. Lo que la dirección y los auditores quieren saber es más simple: cuando aparece algo peligroso, ¿con qué rapidez lo corregimos y cumplimos nuestros propios objetivos?

¿Qué es el MTTR?

El MTTR (tiempo medio de remediación) es el tiempo medio desde que se detecta una vulnerabilidad hasta que se remedia. Es el pulso de un programa de remediación. El detalle clave es la segmentación: un MTTR único y mezclado para todos los hallazgos es casi inútil, porque corregir un problema de bajo riesgo en 90 días y uno explotado activamente en 90 días son resultados radicalmente distintos. Reporta siempre el MTTR por nivel de riesgo.

¿Qué es un SLA de remediación?

Un SLA de remediación es una política documentada que fija el tiempo máximo aceptable de remediación, por nivel de riesgo. Es el objetivo; el MTTR es la medición contra él. Un buen SLA está atado al riesgo, no a la severidad bruta de CVSS — una vulnerabilidad explotada activamente merece un plazo más estricto que una teóricamente grave que nadie está tocando.

Definir SLAs basados en riesgo

Evita un plazo único para todo. Una segmentación práctica:

• Explotada activamente (en CISA KEV) o combinación tóxica confirmada → 24-72 horas.
• EPSS alto (EPSS) o activo crítico expuesto a Internet → ~7 días.
• Severidad alta, baja probabilidad → ~30 días.
• Riesgo medio / bajo → próximo ciclo de mantenimiento.

Reflejan la lógica de la gestión de vulnerabilidades basada en riesgo: el plazo sigue al riesgo.

Medir el MTTR correctamente

• Elige el punto de inicio correcto —fecha de detección o de divulgación— y aplícalo de forma consistente.
• Segmenta por nivel. El MTTR de los ítems en KEV / explotados activamente es el número que más importa.
• Mide el cumplimiento del SLA (el porcentaje de ítems corregidos dentro del plazo), no solo el promedio.
• Vigila el backlog que envejece — los ítems que incumplen el SLA son tu exposición real.

Métricas que de verdad importan (más allá del MTTR)

• Reducción de riesgo en el tiempo, no el conteo bruto de cierres.
• % de cumplimiento del SLA por nivel.
• Cobertura de los ítems en KEV y de EPSS alto.
• Tasa de reapertura / recurrencia — correcciones que no aguantaron.

Errores comunes

• Promedios mezclados que ocultan la remediación lenta de los ítems más arriesgados.
• Medir actividad, no resultados (tickets cerrados vs riesgo eliminado).
• Manipular la métrica cerrando hallazgos fáciles y de bajo riesgo para maquillar el promedio.

Cómo ayuda priorIQ.ai

priorIQ.ai sigue el cierre en tu inventario reconciliado, calcula el MTTR y el cumplimiento del SLA por nivel de riesgo, y exporta los informes que satisfacen las revisiones por la dirección y las auditorías de ISO 27001. Solicita una demo.

Preguntas frecuentes

¿Cuál es un buen objetivo de MTTR? Depende por completo del nivel. Horas para los problemas explotados activamente; semanas para los de bajo riesgo. Un objetivo único para todo es una señal de alarma.

¿MTTR vs MTTD? El MTTD (tiempo medio de detección) mide cómo de rápido encuentras los problemas; el MTTR, cómo de rápido los corriges. Ambos importan.

¿SLA o MTTR — cuál reporto? Ambos: el SLA es la promesa; el MTTR y el cumplimiento del SLA son cómo demuestras que la cumples.