Equipo Consultto
Especialistas en sistemas de gestión · 13 sep 2026
El cuestionario de seguridad del cliente traía dos preguntas seguidas que parecían sencillas: cuántas vulnerabilidades críticas tiene abiertas en este momento y cuál es su plazo máximo de remediación para esa categoría. El responsable de sistemas tenía a la mano el reporte del escaneo del mes anterior, mil cuatrocientos hallazgos ordenados por puntaje, la mayoría en equipos de usuario final. No tenía la segunda respuesta porque no existía: nunca se había escrito un plazo. Lo que había era una práctica razonable, parchear cuando el proveedor liberaba algo y la ventana de mantenimiento lo permitía, sin criterio de prioridad y sin un registro que permitiera decir cuánto tardaba en promedio.
La gestión de vulnerabilidades técnicas es el control que obliga a obtener información oportuna sobre las debilidades técnicas de los sistemas de información en uso, evaluar la exposición de la organización a esas debilidades y tomar las medidas adecuadas. Son tres verbos y los tres se auditan por separado: obtener, evaluar y actuar. La mayoría de las organizaciones tiene el primero resuelto de forma parcial, con un escáner o con los avisos del fabricante, y falla en el segundo, que es donde el control se convierte en decisión.
El requisito previo, y el que con más frecuencia hace inútil todo lo demás, es el inventario de activos. Para saber si una vulnerabilidad publicada afecta a la organización hay que saber qué software y qué versiones están instalados, en qué equipos, quién es el responsable de cada uno, qué información procesa y qué tan expuesto está. Sin ese inventario, el aviso del fabricante es ruido y el reporte del escáner es una lista de la que no se puede decir qué importa. Por eso, cuando una auditoría encuentra que el proceso de vulnerabilidades no funciona, la causa suele estar un paso atrás, en un inventario incompleto o desactualizado.
El alcance también se define mal casi siempre. Se piensa en servidores y se dejan fuera los equipos de usuario final, que son la vía de entrada más común; los dispositivos de red y sus sistemas operativos; el firmware de equipos y periféricos; las aplicaciones desarrolladas en casa y las bibliotecas de terceros que incluyen, que hoy exigen mantener un listado de componentes del software; los servicios en la nube, donde la responsabilidad se reparte con el proveedor según el modelo contratado; y los equipos de planta con software del fabricante, que nadie se atreve a tocar y que suelen correr versiones sin soporte. Un programa que solo cubre el centro de datos deja fuera la mayor parte de la superficie real.
La priorización por el puntaje de severidad publicado es el punto de partida y no puede ser el único criterio, porque ese puntaje describe la debilidad en abstracto y no la situación de la organización. A él hay que sumarle cuatro factores propios: si el activo está expuesto a internet o vive en un segmento interno, si existe código de explotación público o explotación activa conocida, qué tan crítico es el activo para la operación y qué información procesa. Una vulnerabilidad de severidad media en un servicio publicado y con explotación activa es más urgente que una crítica en un equipo aislado que solo enciende dos veces al mes.
Con esa evaluación se fijan plazos por categoría en la política, y ese es el dato que piden los clientes y los auditores. El plazo se cuenta desde la detección y no desde la aprobación del cambio, porque de lo contrario el indicador mide la burocracia interna y no la exposición. Las acciones posibles son cuatro y conviene que estén nombradas: aplicar el parche o actualizar la versión, cambiar la configuración para eliminar la condición, aplicar un control compensatorio cuando no se puede parchear, como segmentar, restringir el acceso o deshabilitar el servicio, y aceptar formalmente el riesgo, con responsable, justificación y fecha de revisión. La aceptación es legítima; la aceptación tácita por olvido no lo es.
El proceso se conecta con otros dos que ya existen. Con la gestión de cambios, porque cada parche es un cambio que necesita pruebas, ventana y plan de retorno, y ahí es donde se resuelve la tensión real entre disponibilidad y seguridad, sobre todo en sistemas que sostienen producción. Y con la gestión de incidentes, porque una vulnerabilidad que ya fue explotada deja de ser un hallazgo pendiente y se convierte en un incidente con su propio circuito de contención, investigación y notificación. Conviene además distinguir el escaneo de la prueba de penetración: el primero es periódico o continuo y busca cobertura, la segunda es puntual y busca demostrar hasta dónde se puede llegar encadenando debilidades. Ninguna sustituye a la otra.
Los indicadores del proceso son pocos y dicen mucho: porcentaje de activos del inventario efectivamente cubiertos por el escaneo, tiempo medio de remediación por categoría de severidad, número de hallazgos que superaron el plazo definido y edad del hallazgo abierto más antiguo. Ese último número es el más incómodo y el más útil, porque desnuda la práctica de cerrar lo fácil y dejar lo difícil corriendo durante años. Los cuatro juntos permiten responder el cuestionario del cliente con datos y permiten a la dirección decidir si el problema es de recursos, de ventanas de mantenimiento o de sistemas que ya no tienen soporte y hay que reemplazar.
La seguridad de la información no es el objeto de la ISO 9001, pero la norma llegó a ese terreno por tres puertas. La infraestructura que hay que determinar, proporcionar y mantener incluye de forma explícita las tecnologías de la información y la comunicación, de modo que un sistema sin soporte del fabricante que sostiene un proceso del sistema de gestión es un problema de infraestructura. El control de la información documentada exige asegurar que esté disponible cuando se necesite y protegida adecuadamente, y la norma nombra la pérdida de confidencialidad, el uso inadecuado y la pérdida de integridad como las cosas de las que hay que protegerla.
La tercera puerta es el control de los procesos, productos y servicios suministrados externamente, que alcanza al proveedor de nube, al de soporte y al de desarrollo: hay que determinar los controles que se le aplican, comunicarle los requisitos y evaluar su desempeño. A eso se suma el pensamiento basado en riesgos, que obliga a considerar lo que puede impedir que el sistema logre los resultados previstos. Cuando el sistema de gestión vive en una plataforma, una indisponibilidad o una alteración de registros detiene liberaciones, rompe la trazabilidad y deja sin evidencia a la auditoría. Esa es la razón por la que un auditor de calidad puede, legítimamente, preguntar por el respaldo y por el estado de actualización de los sistemas donde viven sus registros.
En automotriz el mecanismo de exigencia es la evaluación de seguridad de la información que las armadoras piden a su cadena, con un cuestionario común y una verificación por tercera parte, y ahí la gestión de vulnerabilidades aparece con plazos y evidencia. En dispositivos médicos se cruza con la validación del software usado en el sistema de calidad y en la producción, porque actualizar una versión obliga a evaluar el impacto sobre el estado validado, y con los requisitos de ciberseguridad del producto cuando este tiene conectividad. En el sector financiero y en los servicios de tecnología, el requisito llega por regulación y por los contratos con clientes corporativos.
Para las empresas de software y de servicios administrados la exigencia es más directa todavía: el cuestionario de seguridad forma parte del proceso comercial, y la capacidad de responderlo con números define si se pasa a la siguiente etapa de la venta. En manufactura, el punto de dolor específico es la tecnología de operación, donde los equipos corren versiones antiguas porque el fabricante no libera actualizaciones, y la respuesta correcta no es parchear sino segmentar la red, restringir el acceso y documentar la aceptación del riesgo con revisión periódica. Declarar que no aplica porque es una máquina no resiste ninguna evaluación seria.
Este control se rompe en la ventana de mantenimiento. Quien administra los sistemas responde por la disponibilidad, y cada parche es un riesgo de que algo deje de funcionar durante la jornada; sin un plazo escrito y sin un criterio de prioridad acordado con la dirección, la decisión racional para esa persona siempre es esperar. Así se acumula una deuda que nadie mide, hasta que llega un cuestionario, una auditoría o un incidente. En Guadalajara, donde el ecosistema de software y servicios de tecnología convive con manufactura electrónica por contrato, dispositivos médicos y plantas cuyos registros de proceso viven en sistemas propios, el disparador casi siempre es comercial: el cliente corporativo pregunta por plazos de remediación antes de firmar. Dejar por escrito el inventario, los criterios de priorización, los plazos y el registro de lo que se acepta es parte de lo que se ordena en la Consultoría ISO 9001 en Guadalajara, donde la información del sistema de gestión se trata como un activo que hay que mantener disponible e íntegro.
La gestión de vulnerabilidades técnicas obliga a obtener información oportuna sobre las debilidades de los sistemas en uso, evaluar la exposición real y actuar. Su requisito previo es un inventario de activos con versiones, responsable y criticidad, sin el cual el escaneo no se puede interpretar. La priorización combina el puntaje publicado con exposición, existencia de explotación, criticidad del activo e información que procesa, y desemboca en plazos escritos por categoría que se cuentan desde la detección. Las salidas posibles son parchear, reconfigurar, aplicar un control compensatorio o aceptar el riesgo de forma formal y con revisión. El proceso se apoya en la gestión de cambios y desemboca en la de incidentes cuando la debilidad ya fue explotada, y se mide con cobertura, tiempo de remediación, hallazgos vencidos y edad del más antiguo.
Sin compromisos. Sin presentaciones genéricas. Te escuchamos, entendemos tu empresa y te decimos honestamente qué necesitas y cómo podemos ayudarte.
Hablemos