Una caída del ERP a primera hora, un correo de phishing que roba credenciales o un servidor inaccesible pueden detener facturación, logística, atención al cliente y ventas en cuestión de minutos. Una guía de continuidad operativa empresarial no consiste en tener un documento archivado para auditorías: define cómo seguirá funcionando la organización cuando un incidente afecte a sus sistemas, sus datos o a las personas que los gestionan.
La pregunta para Dirección no es si habrá una interrupción, sino qué impacto económico, comercial y reputacional tendría y cuánto tiempo puede asumir el negocio sin cada servicio. La continuidad operativa convierte esa incertidumbre en decisiones medibles: qué se protege primero, quién actúa, cómo se recupera y cómo se comprueba que la recuperación funciona.
Qué debe resolver un plan de continuidad operativa
Un plan útil parte de los procesos de negocio, no de una lista de herramientas. Es habitual comenzar por servidores, licencias o firewalls, pero el punto de partida correcto es identificar qué actividad no puede detenerse: emitir pedidos, cobrar, acceder a expedientes, coordinar rutas, atender incidencias o trabajar con información confidencial.
A partir de ahí, se relacionan los procesos con las aplicaciones, los datos, los equipos, las conexiones y los proveedores que necesitan. Un CRM puede parecer secundario desde un punto de vista técnico, pero si el equipo comercial deja de recibir y asignar leads durante dos días, el coste se traduce en oportunidades perdidas y una experiencia deficiente para el cliente.
La continuidad también debe diferenciar dos conceptos que se confunden con frecuencia. La continuidad de negocio establece cómo mantener o reanudar los procesos prioritarios. La recuperación ante desastres define cómo restaurar la infraestructura y los datos después de una caída grave, un ransomware, una avería física o un error humano. Ambos planes deben estar coordinados, pero no son lo mismo.
Paso 1: identificar los activos y procesos críticos
El inventario es la base del plan. No basta con saber cuántos equipos tiene la empresa. Hay que registrar qué sistemas soportan cada proceso, dónde residen los datos, quién tiene permisos de administración, qué integraciones existen y qué dependencia hay de terceros.
Conviene clasificar cada activo según su criticidad. Por ejemplo, el correo electrónico, Microsoft 365, el ERP, las bases de datos, las máquinas virtuales, el acceso remoto, la telefonía IP y el CRM pueden tener prioridades distintas según la actividad de la empresa. También hay que incluir activos menos visibles: certificados digitales, dominios, configuraciones de red, claves de acceso, documentación técnica y contactos de proveedores.
En esta fase, las conversaciones con Finanzas, Operaciones, Comercial, Recursos Humanos y TI suelen revelar riesgos que no aparecen en un inventario técnico. Si solo una persona sabe recuperar una aplicación crítica o si un proveedor concentra toda la conectividad, existe una dependencia que debe quedar documentada y tratada.
Paso 2: definir el impacto y los objetivos de recuperación
Cada proceso crítico necesita dos métricas sencillas, pero decisivas. El RTO, Recovery Time Objective, indica el tiempo máximo aceptable para recuperar un servicio. El RPO, Recovery Point Objective, establece cuánta información puede perderse como máximo desde la última copia válida.
No todos los sistemas requieren el mismo nivel de inversión. Una plataforma de pedidos puede necesitar un RTO de dos horas y un RPO de quince minutos. En cambio, un repositorio histórico de documentos quizá admita recuperación al día siguiente y una copia diaria. Definir estos objetivos evita dos errores costosos: sobredimensionar la protección de sistemas no esenciales o descubrir, tras un incidente, que la copia disponible tiene varios días de antigüedad.
El análisis de impacto debe considerar más que el coste de parar un servidor. Hay que valorar penalizaciones contractuales, obligaciones regulatorias, pérdida de confianza, interrupción de la cadena de suministro, horas improductivas y posibles daños a la reputación. Para una empresa con atención al cliente continua, una interrupción de la telefonía y el correo puede ser tan perjudicial como la caída de su aplicación principal.
Paso 3: proteger las vías de interrupción más probables
La continuidad no se resuelve solo cuando se produce el desastre. Reducir la probabilidad de que ocurra es parte del plan. El phishing, el fraude por suplantación de identidad, el ransomware y el robo de credenciales siguen siendo puertas de entrada frecuentes, especialmente cuando el correo electrónico concentra conversaciones comerciales, facturas y accesos a plataformas.
La protección debe combinar filtros avanzados de correo, autenticación multifactor, gestión de privilegios, actualizaciones, segmentación de red y vigilancia de endpoints. Las soluciones EDR detectan comportamientos anómalos en los equipos, mientras que un servicio MDR añade supervisión y respuesta especializada ante amenazas que un antivirus convencional puede no identificar a tiempo.
Las copias de seguridad merecen un criterio propio. Deben estar cifradas, automatizadas, separadas del entorno de producción y protegidas frente a borrados o manipulaciones. AES-256 ayuda a preservar la confidencialidad, pero el cifrado no sustituye a una estrategia de recuperación. Una copia que no se puede restaurar dentro del RTO comprometido no protege la continuidad del negocio.
También conviene respaldar los entornos Microsoft 365. Que una plataforma esté en la nube no significa que la empresa pueda recuperar con precisión archivos eliminados, buzones afectados por un ataque o datos alterados por usuarios con permisos legítimos. La responsabilidad de proteger la información crítica sigue siendo compartida.
Paso 4: documentar la respuesta sin convertirla en burocracia
Un buen plan debe poder utilizarse bajo presión. Eso exige instrucciones concretas, breves y actualizadas. Debe indicar quién declara el incidente, quién coordina la respuesta, a qué proveedor se llama, cómo se comunica la situación a empleados y clientes, y qué pasos se siguen para aislar, recuperar y validar los servicios.
La comunicación es un punto sensible. Informar demasiado tarde genera rumores; comunicar sin confirmar datos puede agravar el incidente. Defina mensajes por escenario y un responsable autorizado para emitirlos. Si existe una sospecha de ransomware, por ejemplo, el equipo debe saber que no debe reiniciar equipos afectados ni conectar discos externos sin indicación técnica.
Es recomendable preparar procedimientos para incidentes realistas: pérdida de acceso a Microsoft 365, caída de internet, indisponibilidad de una máquina virtual, ataque de ransomware, fallo del proveedor cloud y ausencia de personal clave. No todos requieren la misma respuesta. El objetivo es dar a cada equipo una secuencia clara de actuación, con contactos alternativos y criterios de escalado.
Paso 5: probar la recuperación antes de necesitarla
El error más habitual es asumir que las copias funcionan porque el panel indica que se han completado correctamente. La única prueba fiable es restaurar archivos, bases de datos, máquinas virtuales o servicios en un entorno controlado y medir el tiempo real empleado.
Las pruebas deben escalar con la madurez de la empresa. Puede empezar por una restauración mensual de archivos críticos y evolucionar hacia simulacros de recuperación de servidores, ejercicios de respuesta a phishing y revisiones semestrales del plan con responsables de negocio. No se trata de crear alarmismo, sino de detectar dependencias, permisos caducados, documentación incompleta o recursos insuficientes cuando todavía hay margen para corregirlos.
Cada prueba debe generar un registro: qué se recuperó, cuánto tardó, qué incidencias aparecieron y qué acción se asignó para resolverlas. Las métricas permiten a Dirección comprobar si los RTO y RPO acordados son realistas y si la inversión tecnológica responde al riesgo asumido.
La continuidad operativa es una responsabilidad de negocio
TI lidera gran parte de la ejecución, pero no puede decidir sola cuánto tiempo puede estar parada la empresa ni qué impacto tiene perder determinados datos. Dirección debe aprobar prioridades, responsables y presupuesto. Las áreas operativas deben validar que el plan les permite seguir trabajando. Y los proveedores tecnológicos deben conocer el entorno, responder con rapidez y revisar el modelo de forma continua.
Para organizaciones que no disponen de un equipo interno especializado, contar con un aliado tecnológico puede acortar de forma relevante el tiempo de respuesta. RealNet trabaja este enfoque desde el diagnóstico de riesgos hasta la implementación, monitorización y revisión de medidas de ciberseguridad, copias de seguridad y recuperación ante desastres.
La continuidad no se demuestra con una política firmada, sino con la capacidad de recuperar la actividad cuando más falta hace. Empiece por una pregunta concreta: si mañana fallara el sistema que sostiene sus ingresos, ¿quién sabría exactamente qué hacer durante la primera hora? La respuesta marcará la prioridad real de su siguiente decisión tecnológica.
