La mayoría de los ataques que tienen éxito no usan una técnica nueva. Usan una falla que el fabricante ya había corregido meses antes. Según el informe más reciente de Verizon sobre violaciones de datos, la explotación de una vulnerabilidad de software ya representa el 31% de las violaciones registradas en el mundo — por primera vez, por delante del robo de contraseñas como la puerta de entrada más común.
La corrección casi siempre existe antes de que ocurra el ataque. Por eso, en Estados Unidos, el organismo de ciberseguridad del gobierno (CISA) empezó a exigir a las agencias federales un plazo de corrección que va de pocos días a algunos meses, según el riesgo de cada falla del catálogo de vulnerabilidades que ya fueron usadas en ataques reales. La norma más reciente del organismo, de junio de 2026, prioriza según el riesgo de cada falla — no según el orden en que llegó la actualización.
Esto le importa a quien decide en una empresa porque la cuenta siempre es más barata de un lado. Aplicar la actualización cuesta una ventana de mantenimiento acordada con anticipación. No aplicarla cuesta un ataque que usa una puerta que ya podía estar cerrada — y la diferencia casi nunca es técnica. Es que nadie marcó la fecha, nadie la probó antes, o nadie quiso ser quien autorizó tocar un sistema que "está funcionando".
La falla que ya tenía remedio
Una vulnerabilidad de software es una brecha en el programa que la empresa usa todos los días — una forma de burlar la seguridad que el propio fabricante no había previsto. Cuando se descubre, el fabricante publica una corrección. A partir de ese momento, la falla deja de ser un secreto: se vuelve pública, documentada, y cualquier atacante puede leer exactamente qué permite hacer.
Es ese intervalo — entre que la corrección existe y que la corrección está instalada — lo que decide el resultado. El relevamiento más reciente sobre ataques de secuestro de datos, hecho por la empresa de seguridad Sophos con 2.158 responsables de TI de empresas afectadas por este tipo de ataque en 17 países, muestra que la explotación de una vulnerabilidad fue la causa raíz del 18% de los casos en el último año — después de liderar ese ranking durante tres años seguidos, llegando al 32% en el relevamiento anterior.
La baja es una buena noticia. Pero el motivo más citado para que la empresa haya sido víctima sigue siendo el mismo desde hace dos años: el 62% de los encuestados señaló una brecha de seguridad conocida o desconocida como lo que abrió el camino al ataque. "Conocida" es la palabra que duele: significa que alguien, en algún momento, sabía de la falla — y siguió abierta de todos modos.
Esto no es exclusivo de empresas grandes ni de un sector específico. Es el efecto de tratar "está funcionando" como sinónimo de "está seguro". Los dos no tienen ninguna relación entre sí: un servidor puede funcionar sin fallar durante años y, al mismo tiempo, tener una puerta abierta que el propio fabricante ya avisó que había que cerrar.
Por qué la forma habitual no resuelve
La forma habitual es dejar la actualización de seguridad para después. A veces porque nadie quiere arriesgarse a detener un sistema que está funcionando; a veces porque la versión del programa de finanzas, de inventario o de producción "no está homologada" para la versión nueva, y cambiar de versión parece un proyecto demasiado grande para tratarlo como rutina.
El problema es que "después" no tiene fecha marcada. Sin alguien responsable de decidir cuándo y cómo aplicar cada actualización, esta entra en una cola que nunca avanza — y el servidor que funciona hace tres años sin reiniciarse carga, junto con esa estabilidad, tres años de correcciones que nunca llegaron a instalarse.
La otra versión del mismo problema es aplicar la actualización directo en el sistema en uso, sin probarla antes, y esperar que no salga mal. Cuando sale mal una vez — el sistema se cuelga, un informe deja de cerrar, una integración deja de funcionar —, la lección que queda es "actualizar es arriesgado", y la próxima vez se posterga con más razón todavía. Es un ciclo que se alimenta solo.
Lo que tiene que existir en la práctica
Una TI que trata esto como rutina, y no como emergencia, se apoya en mecanismos concretos.
Un inventario de todo lo que la empresa tiene funcionando. Sin saber qué sistemas, servidores y programas existen — y en qué versión —, no hay forma de saber cuáles tienen una corrección disponible esperando a ser aplicada.
Prioridad por riesgo, no por orden de llegada. Una falla que ya se está usando en ataques reales, en un sistema accesible desde fuera de la empresa, necesita corrección en días. Una falla teórica, en un sistema aislado, puede esperar el próximo mantenimiento programado. Tratar a las dos de la misma manera es lo que hace que la cola nunca avance.
Una ventana de mantenimiento acordada con anticipación. En vez de aplicar la actualización de sorpresa, la fecha se fija, se avisa y se planea para el horario de menor actividad — lo que quita el miedo de "va a parar el sistema sin avisar".
Prueba antes de aplicar en el sistema en uso. Un entorno separado, aunque sea simple, donde la actualización se prueba antes de llegar al sistema que la empresa usa todos los días, es lo que separa "actualizar con seguridad" de "esperar que no salga mal".
Registro de causa y solución en cada ticket. Cuando aparece un problema después de una actualización, la próxima persona no pierde tiempo reconstruyendo algo que ya se resolvió una vez.
Así es como trabaja Skills IT: con inventario de lo que tiene funcionando cada cliente, prioridad de corrección por riesgo y una ventana de mantenimiento acordada antes de que cualquier actualización entre al sistema en uso.
La ganancia para la empresa
La ganancia de tratar la actualización como rutina no es abstracta. Es menos horas de equipo apagando incendios después de que un sistema se detiene en medio de la jornada, y menos riesgo de un ataque que usa una puerta que ya podía estar cerrada desde hacía meses.
La escala del problema, cuando sale mal, aparece en los números del sector: el costo promedio para recuperar una empresa de un ataque de secuestro de datos — sin contar el valor del rescate, cuando llega a pagarse — llegó a US$ 1,7 millones por incidente en el relevamiento más reciente de Sophos, un aumento del 11% respecto al año anterior. El número no es sobre un caso aislado; es el promedio entre más de dos mil empresas afectadas en 17 países.
También hay una ganancia menos visible: previsibilidad. Una empresa que ya sabe cuándo y cómo aplica cada actualización no tiene que decidirlo a último momento, bajo presión, después de que algo ya salió mal. La decisión se vuelve calendario, no crisis.
Y está la ganancia de las personas: cuando la actualización se prueba antes y se avisa con anticipación, quien trabaja en el sistema no se ve sorprendido, y el área de TI deja de ser sinónimo de "los que frenan las cosas sin avisar".
Preguntas para llevar a la próxima reunión
Antes de volver a preguntar "cuándo vamos a actualizar", vale la pena preguntar qué existe para que la empresa decida esto sin depender de la suerte:
- ¿Alguien sabe, hoy, qué sistemas tienen una actualización de seguridad disponible y todavía no aplicada? Si la respuesta exige llamar a alguien y preguntar, el inventario no existe de verdad.
- ¿Existe un criterio para decidir qué se corrige primero? Sin prioridad por riesgo, la cola avanza por orden de llegada — y la falla más peligrosa puede quedar esperando detrás de una sin importancia.
- ¿La actualización se prueba antes de llegar al sistema que la empresa usa todos los días? Sin prueba, cada actualización es una apuesta.
- ¿Existe una ventana de mantenimiento acordada, o cada actualización es una sorpresa? La sorpresa es lo que convierte el mantenimiento de rutina en motivo de resistencia.
- Si hoy se descubriera una falla crítica en un sistema de la empresa, ¿quién decide cuándo se corrige? Si la respuesta es "nadie, todavía no lo pensamos", ese es el primer problema por resolver.
