La caída pasó de madrugada. Por la mañana, el técnico ya tenía el servidor de vuelta: archivos, sistema de gestión, todo restaurado. Y aun así la empresa siguió parada un día más, porque nadie sabía por dónde continuar: qué sistema encender primero, quién avisaba a los clientes del retraso, quién tenía autoridad para decir "deja de intentar arreglarlo, vamos al plan alternativo".
El NIST —el instituto de normas técnicas del gobierno de Estados Unidos— describe ese momento, en su guía de planificación de contingencia, como un proceso por fases: primero alguien tiene que ser avisado y decidir activar el plan; luego viene la recuperación propiamente dicha, sistema por sistema, en un orden definido de antemano; solo al final llega el regreso a la operación normal. La misma guía llama la atención sobre un detalle que la mayoría de las empresas ignora: las copias de ese plan, con la lista de a quién avisar y en qué orden, tienen que estar guardadas en un lugar que sobreviva a la propia caída, porque el sistema que guarda ese archivo puede ser justamente el que cayó.
Para quien decide en una empresa pequeña o mediana, el dinero que se pierde entre que el servidor vuelve y la empresa vuelve a facturar rara vez está en el backup en sí. Está en el tiempo que alguien pasa buscando un teléfono, decidiendo solo algo que ya debería estar decidido, y explicándole al cliente un retraso que ya debería tener un aviso preparado.
Que vuelva el servidor no es que vuelva la empresa
Una caída grave —un ataque que revuelve los archivos, una falla de hardware, una inundación en la sala de servidores— deja el sistema fuera de servicio por más de unas horas. El backup, cuando existe y funciona, resuelve la parte técnica. No resuelve cuatro preguntas que siguen abiertas: qué vuelve primero, quién habla con el banco y con los proveedores, a qué hora se desiste de arreglarlo, y dónde está la lista de contactos si el sistema que la guardaba es el que cayó.
Una encuesta de Veeam de 2025, entre empresas de todo el mundo que habían sido atacadas por ransomware —el secuestro de datos en el que un programa revuelve los archivos y piden un rescate para devolverlos— en el año anterior, midió exactamente esa brecha. Solo el 30% tenía definida, antes del ataque, una cadena de mando para manejar la crisis. Y solo el 26% tenía un proceso ya listo para orientar las decisiones más críticas bajo presión. La mayoría decide en el momento, en el peor instante posible para decidir bien.
La misma investigación encontró un dato que ayuda a entender por qué: el 69% de esas empresas creía estar preparada antes de ser atacada. Después del ataque, esa confianza cayó más de 20 puntos porcentuales. Lo que existía en el papel no resistió la prueba real, muchas veces porque el "plan" era solo una rutina de copia de seguridad, sin la parte de decisión.
Hay una señal de mejora, y apunta en la misma dirección. El informe 2025 de Sophos, con 3.400 líderes de TI y seguridad en 17 países cuyas empresas habían sido atacadas por ransomware el año anterior, encontró que el 53% de ellas volvió a operar dentro de una semana, más del doble del índice registrado en 2024. La mejora no vino solo de un backup más rápido: vino de empresas que ya habían ensayado la respuesta, no solo guardado la copia de los datos.
La forma habitual no es un plan
La forma habitual de manejar el día de la caída sigue más o menos el mismo guion en toda empresa que no se detuvo a pensarlo antes. La empresa confía en que, si el backup existe, el resto se resuelve solo. Se decide en el momento quién llama a quién, generalmente la persona más tranquila que está cerca en ese instante. Y la coordinación de la respuesta ocurre por el mismo correo corporativo o la misma aplicación de mensajería de la empresa, que, si el servidor cayó, también puede estar fuera de servicio.
La lista de contactos importantes —el teléfono del gerente del banco, del proveedor crítico, del cliente que hay que avisar primero— suele vivir dentro de la misma computadora que cayó, o solo en la cabeza de quien siempre resuelve eso. Cuando esa persona está de vacaciones, dormida o también afectada por la caída, la lista no existe para nadie más.
La guía de la CISA —la agencia de seguridad de infraestructura de Estados Unidos— sobre planes de respuesta a incidentes es directa al respecto: imprima el documento y la lista de contactos asociada, y entregue una copia a cada persona que vaya a tener un papel en la crisis, porque el correo, el chat y el almacenamiento de documentos de la empresa pueden estar fuera de servicio justo cuando más se necesitan. La misma guía describe dos roles que suelen faltar en una empresa pequeña: alguien responsable solo de conducir la respuesta y tomar la decisión, sin acumular la parte técnica, y alguien responsable solo de hablar con quienes están afuera, como clientes y proveedores. Sin esa división, la misma persona que intenta arreglar el servidor también intenta recordar el teléfono del banco, y hace mal las dos cosas.
Lo que tiene que existir en la práctica
Un plan de recuperación que funciona en el día malo se define por decisiones tomadas de antemano, no por el tamaño del backup guardado en algún lugar.
El orden de reactivación escrito, sistema por sistema. Decidido con anticipación qué vuelve primero —el sistema financiero, el correo, el que atiende al cliente— en vez de descubierto en el momento, entre quien grita más fuerte en la sala.
Una persona con autoridad para decidir, no una reunión. Alguien puede decir "deja de intentar arreglarlo, cambia al plan alternativo" sin necesidad de reunir a todos para votar, y esa persona está definida de antemano, con un suplente claro para cuando no esté disponible.
Una hora acordada para cambiar de estrategia. Un límite fijado con anticipación —"si a tal hora no está resuelto, activamos el plan alternativo"— para que la decisión no dependa del optimismo de quien está intentando arreglarlo.
La lista de contactos guardada fuera del sistema que puede caer. Nombre, teléfono y orden de prioridad de quién avisa al banco, quién habla con el cliente y quién contacta al proveedor, en papel o en un lugar que no dependa del servidor que cayó.
Un aviso listo para el cliente, faltando solo la fecha y la hora. Un texto ya escrito de antemano, para avisar del retraso sin tener que redactar una frase durante la crisis y sin parecer improvisado.
Así es como trabaja Skills IT: con el orden de reactivación definido antes de la caída, un responsable claro de la decisión de cambiar de plan, y la lista de contactos guardada fuera del entorno que puede caer.
Lo que se gana al decidir antes
La ganancia de haber decidido esto antes es operativa y financiera a la vez. Menos tiempo perdido en indecisión significa menos tiempo parado, y el tiempo parado es pedido no facturado, empleados esperando instrucciones y retrabajo después. Un cliente avisado a tiempo, con un texto que ya existía, tiende a aceptar el retraso; un cliente que se entera por el silencio tiende a buscar otro proveedor.
También hay una ganancia en quién decide bajo presión. La misma encuesta de Veeam citada arriba encontró que las empresas con mejores resultados después de un ataque tenían, con más frecuencia, justamente los elementos de decisión —cadena de mando definida, proceso listo para las decisiones más difíciles— dentro del propio plan, y no solo la parte técnica de copia y restauración. Tener esto escrito no evita la caída. Evita que la caída se convierta en dos crisis: la técnica, que el equipo resuelve, y la de decisión, que sigue sin dueño.
Cinco preguntas para llevar a la próxima reunión
Antes de escribir otro documento, vale la pena comprobar si las respuestas ya existen, y si dos personas distintas, preguntadas por separado, dan la misma respuesta.
- Si el servidor cae hoy, ¿qué sistema vuelve primero? Si la respuesta varía de una persona a otra, el orden no está definido: está en la cabeza de cada uno.
- ¿Quién tiene autoridad para decidir cambiar de plan, y quién es el suplente de esa persona? Si la respuesta es "nos reunimos y decidimos", todavía no existe un plan: existe una reunión prometida.
- ¿Dónde está la lista de contactos si el sistema que la guarda también cae? Papel, un servicio separado del servidor, el celular personal de alguien: cualquier lugar que no dependa de lo que cayó.
- ¿Existe una hora acordada para desistir del arreglo y cambiar de estrategia? Sin ese límite, la decisión queda rehén del optimismo de quien está intentando resolverlo.
- ¿Existe un aviso listo para el cliente, faltando solo la fecha y la hora? Si la respuesta es "lo escribimos en el momento", el cliente va a notar la improvisación, y lo va a recordar en la próxima negociación.
