← Volver al blog
Publicado 27 de abril de 20264 min de lectura

ISO 27001: gestión de vulnerabilidades y parches, riesgo y evidencias de auditoría

ISO 27001Patch ManagementComplianceRisk

ISO/IEC 27001 espera que las organizaciones gestionen las vulnerabilidades técnicas de forma sistemática, documentada y auditable. Para muchos equipos de seguridad, la parte más difícil no es el parcheo en sí — es demostrarle al auditor que las vulnerabilidades se identifican, evalúan, tratan y registran de forma consistente. Esta guía cubre el proceso, las decisiones de riesgo y las evidencias que necesitas.

Qué exige ISO 27001

En ISO/IEC 27001:2022, el control relevante del Anexo A es A.8.8 — Gestión de las vulnerabilidades técnicas (antes A.12.6.1 en la versión de 2013). En esencia, exige que la organización:

  • obtenga información oportuna sobre las vulnerabilidades técnicas de sus sistemas,
  • evalúe su exposición a ellas, y
  • tome medidas apropiadas para tratar el riesgo asociado.

Se conecta estrechamente con la gestión de cambios, la configuración segura y el proceso global de tratamiento del riesgo de tu SGSI.

La gestión de vulnerabilidades y parches como proceso documentado

Para satisfacer A.8.8, formaliza un proceso repetible — y déjalo por escrito:

  1. Inventario de activos — saber qué tienes.
  2. Identificación de vulnerabilidades — escaneo programado en red, endpoints, cloud y contenedores.
  3. Evaluación y priorización — ordenar por riesgo real (ver nuestro marco de priorización).
  4. Tratamiento — parchear, mitigar con controles compensatorios o aceptar formalmente el riesgo.
  5. Verificación — confirmar el cierre.
  6. Registros y revisión — conservar evidencias y revisar a nivel de dirección.

La gestión de parches es el paso de tratamiento más común, pero es solo una de las respuestas al riesgo disponibles — y ese es el punto que más interesa a los auditores.

Analizar cada vulnerabilidad: la decisión de riesgo

ISO 27001 se basa en riesgo, así que cada vulnerabilidad significativa (o grupo) merece una decisión, no solo un ticket de parche. Evalúala en contexto — explotabilidad (EPSS), explotación activa (CISA KEV), exposición del activo y criticidad de negocio — y luego elige uno de tres tratamientos:

  • Remediar — aplicar el parche o la corrección.
  • Mitigar — reducir el riesgo con controles compensatorios (segmentación de red, reglas de WAF, configuración endurecida, monitorización reforzada) cuando un parche inmediato no es viable.
  • Aceptar — aceptar formalmente el riesgo residual cuando el tratamiento es desproporcionado respecto al riesgo.

Es el enfoque disciplinado y basado en riesgo que la norma espera.

Aceptar vs mitigar — y hacerlo bien

Los auditores no esperan que lo hayas parcheado todo. Esperan que cada vulnerabilidad relevante sin parchear tenga detrás una decisión consciente y documentada. Una aceptación de riesgo válida:

  • está aprobada por un propietario del riesgo apropiado (no el analista que la encontró),
  • está justificada (por qué el riesgo es aceptable, con los controles compensatorios en marcha),
  • tiene fecha límite, con caducidad o fecha de revisión — nunca "aceptada para siempre".

Las evidencias que pedirá un auditor de ISO 27001

Aquí es donde fallan la mayoría de los programas. Mantén estos registros actualizados y con fecha:

  • El procedimiento documentado en sí.
  • Un inventario de activos.
  • Registros de escaneo — fechas, alcance y resultados a lo largo del tiempo.
  • Un registro de evaluación/tratamiento de riesgo por vulnerabilidad significativa o grupo.
  • Aprobaciones de aceptación de riesgo — propietario, justificación, fecha de caducidad/revisión.
  • Tickets de remediación que muestren el cierre (p. ej. de Jira o ServiceNow).
  • Métricas y revisión por la dirección — SLAs, MTTR, tendencia en el tiempo.

Si puedes presentar esto cuando te lo pidan, la parte de A.8.8 de tu auditoría está prácticamente resuelta.

Cómo priorIQ.ai apoya ISO 27001

priorIQ.ai mantiene un inventario reconciliado de activos y vulnerabilidades, puntúa el riesgo por grupo, te permite registrar decisiones de mitigación y aceptación de riesgo con propietarios y fechas, sigue la remediación a través de Jira/ServiceNow y exporta informes ejecutivos — justo el rastro de evidencias que espera un auditor de ISO 27001. Solicita una demo.

Preguntas frecuentes

¿Qué control de ISO 27001 cubre la gestión de vulnerabilidades? A.8.8 (Gestión de las vulnerabilidades técnicas) en la versión de 2022; A.12.6.1 en la de 2013.

¿Tengo que parchear cada vulnerabilidad para ISO 27001? No. Debes evaluar cada una y aplicar un tratamiento apropiado — parchear, mitigar o aceptar formalmente — con justificación documentada.

¿Qué evidencias quieren los auditores? Un procedimiento documentado, registros de escaneo, decisiones de riesgo por vulnerabilidad, aprobaciones de aceptación de riesgo, tickets de remediación y métricas de revisión por la dirección.