En una reunión de quince minutos, la dirección de una aseguradora de tamaño mediano aprueba postergar la actualización del sistema de emisión de pólizas. El proveedor homologó únicamente la versión anterior, la integración con el motor de cálculo de primas se rompe con cada corrección aplicada, y el área comercial tiene metas de emisión para la semana siguiente. La decisión es razonable, queda registrada en un correo electrónico y nadie vuelve al tema durante los dieciocho meses siguientes.
La escena se repite en empresas de todos los tamaños, con otros nombres en lugar del sistema de pólizas: el ERP (Enterprise Resource Planning, sistema integrado de gestión) trabado en una versión homologada, el servidor que sostiene un proceso crítico y no admite paradas, el equipo de operación con un sistema fuera de soporte del fabricante. Cada excepción nace de un buen motivo operativo, y es justamente por eso que sobrevive tanto tiempo sin revisión.
Para quien responde por el resultado, el punto relevante es que el conjunto de esas decisiones aisladas, y no la ausencia de una herramienta de corrección automática, define la superficie de riesgo real de la empresa. La pregunta de gestión deja de ser si la empresa está actualizada y pasa a ser cuánto riesgo carga a propósito, por cuánto tiempo y a cambio de qué retorno.
La deuda que nadie registró en el balance
El NIST (National Institute of Standards and Technology, instituto estadounidense de estándares y tecnología) abordó el asunto de forma directa en la guía SP 800-40 Revisión 4, publicada en 2022: la gestión de correcciones es un problema de negocio antes de ser un problema técnico, y toda excepción debería nacer con plazo definido, responsable designado y control compensatorio asociado. La misma guía observa que las organizaciones suelen ver la aplicación de correcciones como un costo operativo puro, cuando funciona como una prima pagada en pequeñas cuotas para evitar un siniestro grande.
La cuenta de no pagar esa prima aparece en los datos de incidentes. El Microsoft Digital Defense Report de 2024 registra que más de ocho de cada diez compromisos por ransomware, el secuestro de datos mediante cifrado y pedido de rescate, alcanzaron la red por medio de dispositivos que no estaban bajo gestión formal de la empresa. Son exactamente los activos que viven en régimen de excepción: fuera del inventario, fuera del ciclo de corrección, dentro del perímetro de confianza y conectados a los sistemas que sostienen los ingresos.
El volumen también trabaja en contra del gestor. Gartner, en el Market Guide for Vulnerability Assessment de 2024, señala que las empresas logran remediar apenas una fracción pequeña de las vulnerabilidades detectadas en cada ciclo, lo que convierte la priorización en la variable decisiva del programa. Cuando la fila es prácticamente infinita y la capacidad es finita, la calidad de la elección sobre qué queda para después pasa a valer más que la velocidad con la que se aplica la corrección de turno.
Cómo transformar la excepción en decisión
El primer movimiento es documental, cuesta poco y puede comenzar en dos semanas: escribir la lista. Un inventario explícito de excepciones contiene cinco columnas, a saber: el activo afectado, el motivo técnico o contractual, el responsable designado de la decisión, la fecha de vencimiento de la excepción y el control compensatorio que reduce el riesgo mientras ella exista. La simple existencia de ese registro cambia el comportamiento de la organización, porque convierte una memoria informal en un objeto de gestión que puede ser revisado, exigido y valorizado.
El segundo movimiento es elevar la aceptación de riesgo al nivel decisorio correcto. Cuando la excepción compromete un sistema que sostiene ingresos, datos de clientes u obligaciones regulatorias, quien firma no debería ser el coordinador de infraestructura, sino el ejecutivo que responde por ese proceso ante el consejo. Estructuras maduras de gobernanza y cumplimiento tratan la aceptación de riesgo como un acto formal, con fecha, firma y revisión periódica, lo que evita descubrir después del incidente que la decisión nunca tuvo dueño.
El tercer movimiento es traducir la severidad técnica en exposición de negocio. Una vulnerabilidad clasificada como crítica por el CVSS (Common Vulnerability Scoring System, estándar abierto de puntuación de vulnerabilidades) en un servidor aislado de laboratorio importa menos que una falla de gravedad media en un sistema expuesto a internet y conectado a la base de asegurados. Los programas de gestión continua de vulnerabilidades combinan escaneo recurrente, monitoreo continuo y contexto de negocio para producir una fila ordenada por daño potencial, colocando en el tope aquello que realmente puede detener la operación.
Cinco preguntas que todo gestor debería hacer
¿Cuántos activos están en régimen de excepción permanente, y alguien logra listarlos sin consultar la memoria de un técnico?
La respuesta honesta, en la mayoría de las empresas, es que la lista existe solo en la cabeza de dos o tres personas. Esto crea una dependencia peligrosa, porque el conocimiento sobre los puntos más frágiles del entorno se va por la puerta cuando el profesional cambia de empleo, y el sucesor hereda un mapa incompleto que solo será actualizado en el próximo incidente.
Una prueba simple mide la madurez de la organización en este punto: pida la lista de excepciones por escrito y observe cuánto tiempo tarda en llegar. Si demora más de dos días hábiles o llega en formatos distintos de fuentes distintas, la brecha está en el proceso, que deja de registrar la decisión en el momento exacto en que se toma.
¿Quién firma formalmente la aceptación del riesgo cuando un sistema central no puede actualizarse?
En muchas organizaciones, la respuesta práctica es nadie, por tiempo indeterminado. El correo que autorizó la excepción no traía plazo, el gerente que lo escribió cambió de área y la decisión sigue produciendo efecto años después, con el agravante de que el contexto técnico que la justificaba quizás ya haya desaparecido.
La práctica recomendada por el NIST en la guía de 2022 es dar a toda excepción un vencimiento explícito, con revisión obligatoria en intervalos de noventa o ciento ochenta días. En una aseguradora, esto significa que la imposibilidad de actualizar el sistema de emisión se convierte en un tema recurrente en la agenda del comité ejecutivo, con costo estimado y alternativa evaluada, en lugar de convertirse en una característica permanente de la arquitectura que nadie cuestiona.
¿Cuál es el costo real de una ventana planificada comparado con el de una interrupción no planificada?
Esa comparación rara vez se hace, y es la que suele destrabar el presupuesto. Una ventana planificada de cuatro horas en período de baja demanda tiene un costo conocido, con equipo preparado, plan de retorno probado y comunicación previa a las áreas afectadas, mientras que una interrupción no planificada en el mismo sistema acumula pérdida de producción, horas de recuperación, desgaste con clientes y, en sectores regulados, obligación de notificar a autoridades y titulares de datos.
Para una aseguradora, cuatro horas sin emitir pólizas en período de baja demanda representan un número de propuestas medible y recuperable, mientras que tres días fuera de servicio en pico de renovación significan corredores migrando cartera hacia la competencia. Cuantificar los dos escenarios en dinero, incluso con margen de error, tiende a ser el argumento más eficaz para aprobar el mantenimiento que se venía postergando.
¿Su empresa prioriza por severidad técnica o por exposición efectiva al negocio?
La mayoría prioriza por severidad técnica, porque es el número que la herramienta entrega listo. El límite de esa elección es que el índice describe la gravedad teórica de la falla, sin saber si ese activo está expuesto a internet, si guarda datos sensibles de clientes o si sostiene el proceso que genera caja a fin de mes.
La traducción entre los dos lenguajes es una función de gestión y necesita a alguien formalmente encargado de ella. Ese rol combina conocimiento del entorno técnico con entendimiento de qué procesos detienen el negocio, y es donde un socio de retaguardia agrega valor con rapidez, al aportar método, historial comparativo y capacidad analítica que un equipo interno reducido difícilmente sostiene mientras atiende la demanda del día.
Si un cliente o una renovación de póliza cibernética exigiera evidencia de cadencia de corrección en quince días, ¿lograría presentarla?
La pregunta es una prueba de preparación, y el plazo corto es intencional. Evidencia de cadencia significa demostrar, con registros, cuánto tiempo tarda la empresa en promedio entre la publicación de una corrección crítica y su aplicación, qué porcentaje del parque está dentro de la política vigente y qué excepciones siguen activas, con justificación y fecha de vencimiento.
Las empresas capaces de producir ese material en quince días suelen obtener mejores condiciones en la renovación del seguro cibernético y avanzar más rápido en homologaciones con clientes corporativos. Las demás descubren, en el peor momento posible, que la brecha documental tiene precio, en forma de prima más alta, deducible mayor, cláusula de exclusión o pérdida del contrato ante un competidor que respondió mejor al mismo cuestionario.
Preguntas frecuentes
¿Qué es una excepción de corrección y por qué representa un riesgo para el negocio?
Una excepción de corrección es la decisión de no aplicar una actualización de seguridad en determinado sistema, generalmente por dependencia de proveedor, riesgo de romper una integración o imposibilidad de detener la operación. El riesgo surge cuando esa decisión no recibe plazo, responsable nombrado ni control compensatorio, porque la medida temporal se vuelve permanente sin una nueva evaluación. La acumulación de esas decisiones define la superficie de riesgo real de la empresa.
¿Con qué frecuencia debería revisarse la lista de excepciones?
La guía SP 800-40 Revisión 4 del NIST, publicada en 2022, recomienda que toda excepción tenga vencimiento explícito y revisión periódica, con ciclos usuales de noventa a ciento ochenta días. En la revisión, se verifica si el motivo original aún existe, si el control compensatorio sigue siendo eficaz y cuál es el costo estimado de mantener la excepción activa. Las revisiones más frecuentes corresponden a sistemas expuestos a internet o que tratan datos sensibles.
¿Quién debe firmar la aceptación de riesgo de un sistema que no puede actualizarse?
La firma debe venir del ejecutivo que responde por el proceso de negocio sostenido por ese sistema, y no solo del responsable técnico. Cuando la excepción afecta ingresos, datos de clientes u obligación regulatoria, la aceptación necesita ser un acto formal, con fecha, plazo de validez y registro auditable. Ese diseño evita que la organización descubra, después de un incidente, que la decisión nunca tuvo dueño.
Si la lista de excepciones de su empresa nunca fue escrita, un Diagnóstico Estratégico de TI sin compromiso es un buen lugar para empezar.