Cómo documentar que aplazas un parche sin perder el control del riesgo

Identificar con precisión qué queda pendiente

Anota CVE o identificador del aviso, producto, versión, equipos confirmados, servicio afectado, origen de la detección y fecha. Separa hechos comprobados de hipótesis; si desconoces la versión o el alcance, esa incertidumbre es parte del riesgo y genera una tarea para resolverla.

Explicar por qué no se aplica ahora

Describe la dependencia técnica u operativa concreta: incompatibilidad reproducida, proveedor que aún no certifica la versión, prueba fallida o ventana de mantenimiento no disponible. “Puede romper algo” no permite evaluar la excepción. Incluye evidencia y qué dato podría cambiar la decisión.

Describir el impacto que se acepta durante la espera

Identifica quién usa el activo, qué proceso depende de él y qué ocurriría si se explotara o si se interrumpiera. Anota exposición a internet, privilegios, datos y dependencias relevantes. No traduzcas una puntuación técnica directamente en impacto empresarial ni ocultes información desconocida.

Elegir una medida temporal comprobable

Según el caso, puede reducirse la exposición, limitar accesos, desactivar una función afectada, aumentar la vigilancia o aislar el componente. Escribe qué configuración se cambia, quién la mantiene y cómo probar que funciona. Una medida anotada pero no aplicada no reduce el riesgo residual.

Asignar decisión, propietario y vencimiento

Registra quién puede aprobar la excepción, quién ejecuta la mitigación y quién instala y valida el parche. Fija una fecha de revisión y una fecha objetivo acordes con el riesgo y la capacidad real, sin copiar plazos genéricos como si fueran universales. Una excepción no debe renovarse sola ni quedar abierta sin dueño.

Definir señales para reabrir antes de la fecha

Revisa de inmediato si aparece evidencia de explotación, cambia la exposición, falla el control temporal, el proveedor publica una corrección segura o el servicio deja de ser crítico. Configura alertas y un mecanismo de escalado que llegue a una persona disponible; no dependas de que alguien recuerde mirar una hoja.

Cerrar solo después de verificar el cambio

Al aplicar el parche, confirma versión y estado del servicio con una comprobación adecuada, retira los controles temporales cuando proceda y guarda evidencia. Si no se instaló, registra la nueva decisión y su aprobación. Los ejemplos de ENISA sirven para pensar el tratamiento documentado dentro de su alcance, no para declarar que una plantilla satisfaga por sí sola cualquier obligación.

Fuentes y documentación

• NIST SP 800-40 Rev. 4 — Guide to Enterprise Patch Management Planning — Describe la gestión de parches como un proceso de identificar, priorizar, adquirir, instalar y verificar; ayuda a tratar el aplazamiento dentro de un ciclo planificado.
• NIST — Risk Response — Glosario que incluye aceptar, evitar, mitigar, compartir y transferir riesgos como posibles respuestas.
• ENISA — Technical implementation guidance on cybersecurity risk management measures — Ofrece ejemplos de medidas y tratamiento documentado del riesgo en su ámbito europeo específico; se cita como referencia operativa, no como obligación universal para cualquier pyme.
• ENISA — Cybersecurity for SMEs: Challenges and Recommendations — Orientación general para que las pymes mejoren su gestión de ciberseguridad.