Respuesta corta: la política de gestión de vulnerabilidades es un documento corto que fija cuántos días puede existir una vulnerabilidad según su severidad, quién la corrige, quién autoriza una prórroga y cómo se documenta. Sin esos plazos, cada hallazgo se negocia desde cero y los incómodos quedan para después. Con plazos escritos y firmados por la dirección, el equipo de IT tiene respaldo para pedir cambios.
La regla ancla: un plazo sin consecuencia ni dueño no es un plazo.
Plan y política no son lo mismo
La guía de DHS/CISA (CRR Resource Guide — Vulnerability Management) separa estrategia, plan y operación. La estrategia dice qué se va a cubrir. El plan baja eso a especificaciones. La política es la parte del plan que se firma y se hace cumplir.
| Documento | Responde a | Cambia |
|---|---|---|
| Estrategia | Qué activos y qué métodos entran | Una vez al año o menos |
| Plan | Cómo, con qué herramientas y con qué frecuencia | Cuando cambia el entorno |
| Política | Plazos, responsables y excepciones | Con aprobación de la dirección |
En una PyME conviene un solo documento de dos páginas que cubra los tres niveles de forma resumida.
Qué tiene que decir la política
Los elementos que la guía pide definir en el plan, traducidos a una PyME:
- El equipo. Quién detecta, quién corrige y quién autoriza. Una persona puede tener los tres roles en una empresa chica, pero el documento tiene que nombrarlos.
- La coordinación con riesgo. Cuando una vulnerabilidad no se puede corregir en plazo, se registra como riesgo y alguien con autoridad lo acepta.
- Los plazos por severidad. Una escala (crítica, alta, media, baja) y, para cada nivel, la cantidad de días que el hallazgo puede seguir abierto.
- El registro. Todos los hallazgos, vengan de la herramienta que vengan (la comparativa de herramientas para PyMEs ayuda a elegir), van a un repositorio central.
- Las excepciones. Cómo se pide una prórroga y a qué nivel de la gerencia se aprueba.
- Las actividades periódicas. Cada cuánto se escanea y se revisan las fuentes de información.
Plazos por severidad
La severidad base sale de CVSS, la escala de 0 a 10. Los rangos cualitativos estándar son: baja (0,1 a 3,9), media (4,0 a 6,9), alta (7,0 a 8,9) y crítica (9,0 a 10,0).
Estos plazos son una propuesta de Bootable como punto de partida para una PyME; no surgen de una norma ni de la guía de DHS/CISA. Ajustalos a tu capacidad real de corregir, medida como indica el artículo sobre recursos del programa:
| Severidad | Plazo propuesto para corregir o mitigar | Ejemplo de acción |
|---|---|---|
| Crítica | 7 días | Parche de emergencia o aislamiento del equipo |
| Alta | 30 días | Parche en la próxima ventana de mantenimiento |
| Media | 90 días | Parche dentro del ciclo regular de actualizaciones |
| Baja | 180 días | Se resuelve con el ciclo normal o se acepta con registro |
Si el plazo no es alcanzable, no lo escribas. Un plazo que nadie cumple le quita valor a todos los demás.
Cuándo se ajusta la severidad
El puntaje base no sabe nada de tu empresa. La política tiene que prever reglas de ajuste explícitas:
- Sube un nivel si el equipo está expuesto a internet, o si la vulnerabilidad figura en el catálogo KEV de CISA (vulnerabilidades explotadas conocidas).
- Sube un nivel si el activo es crítico para la operación o maneja datos sensibles.
- Baja un nivel si existe un control compensatorio verificado, por ejemplo el servicio no es accesible desde ninguna red de usuarios.
Cada ajuste se anota en el registro con la razón. Cómo combinar CVSS, EPSS y KEV con la criticidad del activo se desarrolla en el post sobre priorización.
Excepciones: la parte que decide si la política funciona
A veces una vulnerabilidad no se puede corregir en plazo. Un sistema heredado sin parche del fabricante, una aplicación que se rompe con la actualización, una ventana de mantenimiento que cae después del vencimiento. La política tiene que tener un camino formal para eso.
Una excepción válida tiene:
| Campo | Qué exige |
|---|---|
| Justificación | Por qué no se puede corregir en plazo |
| Control compensatorio | Qué reduce el riesgo mientras tanto |
| Fecha de vencimiento | Toda excepción expira; no existen las permanentes |
| Aprobador | Alguien con autoridad sobre el activo y sobre el riesgo |
| Revisión | Quién la vuelve a mirar antes de que venza |
La regla de aprobación escala con la severidad: una excepción sobre un hallazgo bajo puede aprobarla el responsable de IT; una sobre uno crítico requiere a la dirección. La guía lo plantea igual: el plan define qué nivel de gerencia interviene cuando se excede el plazo estándar.
Errores típicos
- Plazos copiados de otra organización. Un plazo de siete días para críticas sin capacidad de parchear en siete días solamente produce incumplimientos.
- Excepciones sin fecha. Se acumulan y a los seis meses nadie recuerda por qué existen.
- Aprobar el que pide. Quien corrige no debería ser quien acepta el riesgo de no corregir.
- Política sin firma. Un documento sin respaldo de la dirección no obliga a los dueños de los sistemas.
Preguntas frecuentes
¿Los plazos son los mismos para servidores y equipos de usuario?
Pueden serlo, y lo simple es mejor. Lo habitual es que el ajuste por exposición y criticidad ya diferencie los casos, sin multiplicar las tablas.
¿Desde cuándo corre el plazo?
Desde que el hallazgo se registra y se confirma, no desde que el parche está disponible ni desde el escaneo. Definilo en el documento para que no haya discusión.
¿Qué pasa si vence un plazo?
Se escala. La política tiene que decir a quién y en cuántos días. El vencimiento se registra y se informa en las métricas del programa como vulnerabilidad vencida.
¿Cuánto tiene que durar el documento?
Dos páginas alcanzan. Si pasa de eso, nadie lo lee en el momento en que lo necesita.
En resumen
La política fija cuatro plazos, tres reglas de ajuste y un procedimiento de excepciones con vencimiento y aprobador. Armala en dos páginas, ajustá los días a tu capacidad real de corregir y hacela firmar por la dirección. Descargá la plantilla editable y reemplazá los valores sugeridos por los tuyos.
4 páginas · el procedimiento paso a paso, en PDF. Gratis, por dejar tu email.