La gestión de vulnerabilidades técnicas es uno de los controles que ISO 27001 exige de forma explícita, y sin embargo suele tratarse como un asunto puramente técnico, ajeno al sistema de gestión de seguridad de la información. Un programa de pentesting continuo puede ser una fuente valiosa de evidencia para ese control, pero solo si su resultado queda documentado de una forma que un auditor pueda seguir sin reconstruir la historia desde cero.
Qué exige la norma sobre vulnerabilidades técnicas
ISO 27001 no exige un método específico de pentesting ni una frecuencia fija. Exige que la organización identifique, evalúe y trate las vulnerabilidades técnicas de forma oportuna, con un proceso definido y con evidencia de que ese proceso efectivamente opera. Un pentest anual puede satisfacer ese requisito en organizaciones de bajo cambio y riesgo acotado; una plataforma con despliegues frecuentes, datos personales o procesos de negocio críticos necesita, en la práctica, una validación más recurrente para sostener la misma afirmación ante una auditoría.
La decisión de frecuencia no es solo técnica: es una decisión de gestión de riesgo que el sistema de gestión debe poder justificar, con criterios explícitos —criticidad del activo, exposición, velocidad de cambio— y no solo con la disponibilidad de un proveedor externo.
La evidencia que interesa a una auditoría
Un hallazgo técnico sin trazabilidad documental no sirve como evidencia de control, por muy bien resuelto que haya quedado en la práctica. Para ISO 27001, lo que debe quedar registrado por cada hallazgo relevante es: el riesgo asociado, el control relacionado, la decisión de tratamiento —corregir, mitigar, aceptar o transferir—, el responsable, el plazo comprometido y la evidencia de que la corrección se validó sin introducir una regresión.
ISO 9001 añade una exigencia complementaria cuando el hallazgo revela algo más que un parche puntual: si una vulnerabilidad se repite por un problema de proceso —una plantilla de despliegue insegura, una revisión de código que no se está aplicando—, corresponde tratarla como una no conformidad, con análisis de causa y una acción correctiva propiamente registrada, no solo como un ticket cerrado.
Riesgo aceptado: una decisión que también debe documentarse
No todo hallazgo se corrige de inmediato, y eso puede ser una decisión razonable. Lo que un sistema de gestión no puede permitirse es que esa decisión quede solo en la memoria de quien la tomó. Cuando se acepta un riesgo residual —por ejemplo, porque el activo está aislado, sin datos reales o con un control compensatorio verificable—, la aceptación debe quedar registrada con su justificación, el responsable que la autoriza y una fecha de revisión. Esa pieza es, con frecuencia, la que más solicita un auditor y la que menos suele documentarse en la práctica.
Cómo se conecta con la matriz de riesgos del sistema de gestión
Un hallazgo de pentesting no debería vivir aislado en el informe de un proveedor externo. Su valor para el sistema de gestión aumenta cuando se conecta con la matriz de riesgos ya existente: el mismo activo, el mismo proceso de negocio y el mismo control pueden aparecer también en una evaluación de riesgo más amplia, una revisión de proveedores o un plan de continuidad. Mantener esa evidencia dispersa entre el informe técnico, un correo y una hoja de cálculo dificulta responder, meses después, una pregunta simple: ¿este riesgo sigue vigente y quién lo está siguiendo?
Plataformas como TCDX Compliance pueden apoyar esa trazabilidad, centralizando el hallazgo, el riesgo, el control y la acción correctiva en un mismo registro disponible para la revisión por la dirección. Eso no reemplaza el criterio técnico de quien ejecuta la prueba ni la decisión de riesgo de quien la autoriza: solo evita que la evidencia se pierda entre herramientas y quede sin poder demostrarse cuando corresponde.
Revisión periódica, no un evento aislado
El valor de este control para ISO 27001 no se agota en el momento del hallazgo. La revisión por la dirección debería poder ver, con datos y no solo con la impresión de que «se está trabajando en eso»: cuántos hallazgos críticos siguen abiertos, cuánto tiempo llevan abiertos, cuántos riesgos fueron aceptados formalmente y si las correcciones anteriores se sostienen tras los cambios más recientes en la aplicación. Sin esa revisión periódica, el pentesting continuo genera actividad, pero no necesariamente la evidencia de control que exige el sistema de gestión.
