Cómo definir SLA de remediación de vulnerabilidades según riesgo
Un SLA útil no empieza preguntando cuántos días merece un CVSS 9.8. Empieza definiendo qué riesgo necesita tratar primero, quién responde, cuándo vence y qué evidencia demuestra que la exposición realmente cambió.
Una política de remediación debe convertir riesgo en una expectativa operativa verificable.
NIST trata la gestión de parches como un proceso que incluye identificar, priorizar, instalar y verificar correcciones, dentro de una estrategia orientada a reducir riesgo. Ese enfoque es más útil que asignar ventanas únicamente por severidad técnica.
El SLA define una expectativa de tiempo, pero el proceso necesita algo más: criterio de prioridad, responsable, mecanismo de excepción y condición de cierre. Sin esos elementos, una fecha objetivo puede convertirse en un dato administrativo que no demuestra reducción de exposición.
Seis señales que deberían influir en la ventana de remediación.
La política puede formalizar estas señales con pesos, reglas o decisiones. Lo importante es que la urgencia sea explicable y repetible.
Explotación conocida. Una vulnerabilidad incluida en CISA KEV o con evidencia confiable de explotación activa debe acelerar la decisión de tratamiento.
Probabilidad de explotación. Señales como EPSS ayudan a distinguir vulnerabilidades con mayor probabilidad de ser explotadas en el corto plazo.
Exposición. No es igual un servicio público accesible desde Internet que un activo aislado detrás de controles efectivos y segmentación.
Criticidad del activo. Considere impacto sobre procesos, datos, privilegios, disponibilidad y dependencias del negocio.
Controles y mitigaciones. EDR, WAF, segmentación, hardening o una mitigación temporal pueden reducir exposición, pero deben verificarse y tener owner.
Viabilidad operativa. Disponibilidad de parche, pruebas, ventanas de mantenimiento y riesgo de indisponibilidad afectan cómo se ejecuta la remediación.
Defina exactamente cuándo empieza y cuándo termina el SLA.
Dos equipos pueden reportar “95% de cumplimiento” y estar midiendo cosas distintas. Uno inicia el reloj cuando el escáner detecta la vulnerabilidad; otro cuando un analista la valida; otro cuando llega al equipo técnico.
Inicio. Defina el evento oficial: detección ingerida, validación técnica o creación del caso. Documente también cómo se tratan falsos positivos y duplicados.
Fin de remediación. Establezca qué significa “implementado”: parche, configuración, upgrade, aislamiento, retirada del activo o mitigación aceptada.
Fin de cierre. Determine cuándo se necesita rescan, retest, evidencia de cambio o aprobación de una excepción antes de cerrar el hallazgo.
Seis pasos para pasar de prioridad a SLA sin perder contexto.
Defina cuándo inicia el reloj. Aclare si el SLA comienza con la detección, la validación del hallazgo o su asignación. Sin una regla común, las métricas dejan de ser comparables.
Clasifique el riesgo con contexto. Use severidad, amenaza, exposición, criticidad e impacto para decidir prioridad. Evite convertir CVSS en un SLA automático.
Asigne una ventana de tratamiento. Cada prioridad debe tener una fecha objetivo explícita y un owner responsable de remediar, mitigar o escalar una excepción.
Diferencie remediación de cierre. Aplicar un parche no siempre significa cerrar el hallazgo. Defina cuándo necesita rescan, retest o evidencia adicional.
Gestione excepciones con vencimiento. Si la corrección no es viable dentro del SLA, documente la razón, controles compensatorios, aceptación del riesgo y fecha de revisión.
Mida y ajuste. Revise cumplimiento, tiempos reales, reincidencia y excepciones vencidas para saber si las ventanas son exigentes, alcanzables y efectivas.
Un punto de partida para diseñar ventanas, no una tabla universal.
Los tiempos siguientes son ejemplos para estructurar una conversación interna. Deben ajustarse a su perfil de riesgo, obligaciones contractuales o regulatorias, arquitectura, capacidad operativa y tolerancia a indisponibilidad.
P1 · Urgente. Explotación conocida, activo crítico expuesto o combinación equivalente de amenaza e impacto. Ejemplo: 24–72 horas. Contención o mitigación inmediata, owner ejecutivo/técnico, corrección prioritaria y validación posterior.
P2 · Alta. Alta probabilidad o severidad con exposición relevante y criticidad significativa. Ejemplo: 7–15 días. Plan de remediación confirmado, seguimiento frecuente y escalamiento si la fecha está en riesgo.
P3 · Media. Riesgo relevante sin señales de urgencia inmediata o con controles que reducen la exposición. Ejemplo: hasta 30 días. Remediación dentro del ciclo normal con seguimiento y evidencia de cierre.
P4 · Baja. Baja exposición, bajo impacto o condiciones que permiten tratamiento planificado. Ejemplo: 60–90 días. Corrección dentro de mantenimiento planificado o tratamiento formal del riesgo.
KEV debería modificar la urgencia, no convertirse en otra lista desconectada.
CISA mantiene el Known Exploited Vulnerabilities Catalog con vulnerabilidades para las que existe evidencia de explotación. Su directiva BOD 22-01 obliga a determinadas agencias federales de Estados Unidos a remediarlas dentro de fechas definidas y CISA recomienda a otras organizaciones priorizarlas de manera oportuna.
Para una empresa privada, la utilidad práctica no es copiar automáticamente la fecha federal, sino usar la explotación conocida como una señal fuerte dentro de su propio modelo: ¿el producto existe en su entorno?, ¿está expuesto?, ¿qué privilegios permite?, ¿qué impacto tendría y qué mitigación puede aplicar mientras corrige?
No cumplir el SLA puede ser una decisión de riesgo; dejarlo sin gobernanza no debería serlo.
Hay situaciones donde una corrección inmediata puede introducir indisponibilidad, incompatibilidad o un riesgo operativo mayor. La excepción debe ser controlada, no informal.
No mida solo cuántos tickets cerró. Mida dónde sigue concentrado el riesgo.
Seis formas de tener SLA en papel y vulnerabilidades críticas todavía abiertas.
Conecte prioridad, ventana y evidencia en el mismo backlog.
El SLA funciona mejor cuando nace de un criterio de priorización explícito y termina en una condición de cierre verificable.
Más allá del CVSS — cómo combinar severidad, explotación, exposición y criticidad antes de asignar prioridad.
Plantilla de priorización — una matriz editable para llevar hallazgos a P1–P4, owner, fecha y evidencia de cierre.
Gestionar el backlog — cómo gobernar pendientes, owners, vencimientos y excepciones.
Métricas del programa — cómo medir cumplimiento, deuda y reducción de riesgo.
Gestión de vulnerabilidades vs. pentesting — cuándo necesita continuidad de remediación y cuándo validación ofensiva.
Fuentes para diseñar su política de remediación.
Las ventanas ilustrativas de esta guía son una propuesta práctica y no corresponden a un SLA oficial de NIST, CISA o FIRST.
NIST SP 800-40 Rev. 4 — estrategia de enterprise patch management orientada a priorizar, implementar y verificar correcciones para reducir riesgo.
NIST Secure Software Development Framework — referencia para decisiones de remediación y priorización basadas en riesgo.
CISA — Known Exploited Vulnerabilities Catalog — vulnerabilidades con evidencia de explotación y fechas de remediación para el ámbito cubierto por BOD 22-01.
FIRST — CVSS v4.0 User Guide — aclara que CVSS Base mide severidad y no debe utilizarse por sí solo como riesgo.
FIRST — EPSS — probabilidad estimada de explotación para apoyar decisiones de priorización.
¿Sus SLA existen, pero el backlog vencido sigue creciendo?
Revisamos criterios de prioridad, ventanas, owners, excepciones y evidencia de cierre para convertir la política en un proceso de remediación medible y defendible.