Un servidor inaccesible, un ransomware que cifra los ficheros compartidos o un fallo eléctrico prolongado pueden detener ventas, atención al cliente, facturación y logística en cuestión de minutos. El problema no es únicamente que ocurra un incidente, sino no saber quién decide, qué sistemas se recuperan primero y cuánto tiempo puede operar la empresa sin ellos. Un plan de recuperación ante desastres convierte esa incertidumbre en un procedimiento medible para proteger la continuidad operativa.
Tener copias de seguridad no equivale a estar preparado. Una copia puede existir y, aun así, ser incompleta, estar cifrada por un atacante, no restaurarse correctamente o tardar días en recuperarse. La recuperación ante desastres plantea una cuestión más exigente: ¿cómo reanuda la empresa sus procesos críticos dentro de un plazo aceptable y con la menor pérdida de información posible?
Qué debe resolver un plan de recuperación ante desastres
Un plan útil parte del negocio, no de una lista de herramientas. Dirección y TI deben identificar qué procesos generan ingresos, sostienen el servicio al cliente, cumplen obligaciones legales o afectan directamente a la reputación de la organización. No todos los activos tienen la misma prioridad: una caída de la web corporativa puede ser asumible durante unas horas, mientras que la indisponibilidad del ERP, del correo, de las máquinas virtuales o de una plataforma de pedidos puede detener la operación completa.
El documento debe establecer el orden de recuperación, las personas responsables, los canales de comunicación y los recursos técnicos necesarios. También debe definir qué ocurre si el incidente afecta a la sede, a la conectividad, a los equipos de usuario, al proveedor cloud o a las credenciales de administración. Un desastre no siempre es un incendio o una inundación. Hoy es igual de probable que sea una cuenta comprometida, un ataque de ransomware, una configuración errónea o un borrado accidental.
Dos indicadores ayudan a tomar decisiones sin ambigüedad. El RTO, o tiempo objetivo de recuperación, define cuánto puede tardar un sistema en volver a estar disponible. El RPO, o punto objetivo de recuperación, fija cuánta información puede perderse desde la última copia válida. Por ejemplo, una empresa puede aceptar recuperar el portal corporativo en 24 horas, pero exigir que su sistema de facturación se restablezca en cuatro horas y pierda como máximo 15 minutos de datos.
Estos objetivos tienen un coste. Reducir el RTO y el RPO exige más automatización, replicación, capacidad disponible y supervisión. Por eso conviene decidirlos con criterios operativos y financieros, no asignar el mismo nivel de exigencia a todos los sistemas.
Empiece por un inventario que refleje la operación real
Muchos planes fallan antes de producirse un incidente porque se basan en inventarios incompletos. TI puede tener controlados los servidores, pero desconocer una aplicación SaaS contratada por un departamento, una hoja de cálculo crítica alojada en una cuenta personal o una integración que alimenta los pedidos desde la web.
El inventario debe incluir activos, dependencias y propietarios. No basta con registrar que existe una máquina virtual: hay que saber qué aplicación aloja, qué base de datos necesita, qué usuarios dependen de ella, dónde se guardan sus copias y quién puede autorizar su restauración. También hay que documentar proveedores, licencias, dominios, accesos privilegiados, configuraciones de red y procedimientos de contacto fuera de los sistemas afectados.
Una forma práctica de priorizar consiste en clasificar los servicios según su impacto. Los sistemas críticos son los que impiden vender, producir, facturar o atender. Los esenciales degradan seriamente la operación, aunque permitan continuar de forma temporal. Los secundarios pueden recuperarse después. Esta clasificación evita que el equipo técnico dedique las primeras horas a restaurar elementos visibles pero no decisivos.
Respaldo, ciberseguridad y recuperación son capas distintas
El respaldo es la base, pero no es toda la estrategia. Las copias deben estar cifradas, monitorizadas y separadas del entorno de producción para que un atacante no pueda eliminarlas o cifrarlas con las mismas credenciales. El cifrado AES-256 protege la confidencialidad de los datos almacenados, pero no garantiza por sí solo que la restauración vaya a funcionar ni que se cumplan los tiempos acordados.
Una política madura combina copias locales para recuperaciones rápidas con copias externas o inmutables para responder a incidentes graves. La regla 3-2-1 sigue siendo una referencia razonable: tres copias de los datos, en dos soportes distintos y una fuera de la ubicación principal. En entornos expuestos a ransomware, conviene añadir controles de inmutabilidad, acceso con privilegios mínimos y autenticación multifactor para las consolas de respaldo.
La recuperación también depende de prevenir la propagación del incidente. Si se restaura un servidor sin investigar cómo entró el atacante, la empresa puede volver a poner en producción una vulnerabilidad activa. La protección de correo frente a phishing, la defensa de endpoints con EDR o MDR, la seguridad perimetral y la gestión de parches reducen la probabilidad de activar el plan y ayudan a contener el alcance cuando ocurre algo.
Microsoft 365 merece atención específica. Que el correo, OneDrive, SharePoint o Teams estén en la nube no significa que la organización disponga automáticamente de una estrategia de retención y recuperación ajustada a sus necesidades. El borrado accidental, la eliminación maliciosa o una política de retención insuficiente pueden afectar a información crítica. El respaldo de Microsoft 365 debe formar parte del mismo mapa de prioridades, con responsables y pruebas de restauración definidos.
Cómo construir el procedimiento de respuesta
El plan debe ser claro incluso para quien lo consulta bajo presión. No es un documento pensado para archivarse, sino una guía de actuación durante las primeras horas de un incidente. Conviene que esté disponible de forma segura fuera de los sistemas que podrían quedar inaccesibles.
La respuesta inicial debe contemplar cuatro frentes: contener el daño, evaluar el impacto, comunicar decisiones y recuperar servicios. El equipo necesita saber quién puede aislar un equipo o desconectar una red, quién coordina con proveedores, quién informa a Dirección y quién comunica a clientes si el servicio se ve afectado. La ausencia de esta asignación suele provocar retrasos, mensajes contradictorios y acciones que complican la investigación.
Cada procedimiento de recuperación debe indicar el sistema afectado, sus dependencias, el RTO y RPO acordados, las credenciales o llaves necesarias, el origen de la copia, el orden de restauración y los criterios de validación. Restaurar no significa únicamente encender un servidor. Hay que comprobar integridad de datos, conectividad, acceso de usuarios, integraciones, rendimiento y seguridad antes de declarar el servicio operativo.
En empresas con varias sedes o equipos remotos, también es necesario prever alternativas de conectividad y trabajo. Puede ser suficiente con acceso seguro a escritorios virtuales, una ubicación de contingencia o procedimientos manuales temporales. La solución correcta depende del proceso: mantener la atención comercial puede requerir acceso prioritario al CRM y al correo, mientras que una planta necesita garantizar la disponibilidad de sistemas industriales y comunicaciones locales.
Las pruebas distinguen un plan real de un documento optimista
No hay forma responsable de asegurar que una recuperación funcionará si no se prueba. Las pruebas deben ejecutarse con una frecuencia acorde al nivel de riesgo y siempre que haya cambios relevantes en infraestructura, aplicaciones, proveedores o procesos de negocio.
Una primera prueba puede validar la recuperación de ficheros y máquinas virtuales en un entorno aislado. Después conviene realizar ejercicios más completos: recuperar una aplicación crítica, verificar sus dependencias y medir el tiempo real hasta que los usuarios puedan trabajar. Los resultados deben compararse con el RTO y RPO definidos, documentar desviaciones y generar acciones con responsable y fecha.
Los simulacros también deben incluir a Dirección y responsables de negocio. Un incidente de ransomware, por ejemplo, obliga a decidir si se detiene una operación, cómo se comunica la indisponibilidad y cuándo se autoriza la vuelta a producción. La tecnología proporciona evidencias, pero esas decisiones afectan a ingresos, contratos y reputación.
Gobierno continuo, no revisión anual simbólica
Un plan de recuperación pierde valor cuando deja de reflejar la empresa. Nuevas aplicaciones, cambios de personal, crecimiento de sedes y migraciones a cloud modifican las dependencias y los riesgos. Por eso debe revisarse de forma periódica, con informes que permitan a Dirección entender qué activos están protegidos, qué objetivos se cumplen y qué brechas requieren inversión.
Un proveedor administrado puede aportar monitorización, verificación de copias, defensa ante amenazas y acompañamiento técnico durante una contingencia. La clave es que conozca el entorno y los procesos prioritarios de la empresa. En RealNet, ese acompañamiento se plantea desde el diagnóstico hasta las pruebas y revisiones, porque una recuperación efectiva requiere personas que comprendan qué está en juego, no solo una herramienta instalada.
La pregunta que conviene plantear en el próximo comité no es si la empresa tiene backups. Es si, ante una interrupción mañana, cada responsable sabría qué hacer, en qué orden y con qué evidencia para devolver la operación a la normalidad.
