Continuidad de negocio: demuestre la ruta de recuperación

Un plan de recuperación resulta creíble cuando el equipo puede mostrar cómo volverá a funcionar un servicio crítico, en qué orden y con qué recursos. Una copia de seguridad es un elemento de ese plan; no acredita toda la capacidad de recuperación.

Para un CTO, la pregunta práctica es si la recuperación sigue funcionando cuando fallan los supuestos operativos habituales. ¿Puede otro ingeniero ejecutar el procedimiento? ¿Puede el equipo obtener las credenciales sin el servicio de identidad de producción? ¿Pueden los usuarios de negocio completar una transacción una vez restaurada la infraestructura?

Trate la continuidad como una capacidad diseñada: defina resultados aceptables, identifique dependencias, construya procedimientos de recuperación, póngalos a prueba en ejercicios y conserve evidencias de lo ocurrido. El entregable es una ruta de recuperación demostrada, con sus limitaciones comprendidas y sus debilidades asignadas para su corrección.

Establezca la obligación y el perímetro operativo

El artículo 21 de NIS2 incluye la continuidad de las actividades, como la gestión de copias de seguridad y la recuperación en caso de catástrofe, y la gestión de crisis entre las medidas para la gestión de riesgos de ciberseguridad. También aborda las políticas y los procedimientos para evaluar la eficacia de esas medidas. El artículo 20 trata la aprobación y la supervisión por parte de los órganos de dirección.

NIS2 es una directiva que se aplica a través de la legislación nacional. La aplicabilidad depende del sector, el tamaño, el servicio y las reglas de inclusión; los requisitos nacionales y sectoriales aplicables determinan las obligaciones concretas. No trate una plantilla genérica de continuidad como una evaluación jurídica completa.

Desde el punto de vista operativo, distinga cuatro actividades conectadas:

• Continuidad de negocio: mantener en funcionamiento las funciones de negocio importantes, posiblemente con capacidad reducida.
• Gestión de copias de seguridad: mantener copias protegidas y recuperables de los datos y de la configuración necesaria.
• Recuperación ante desastres: restaurar los sistemas técnicos y validar el servicio al que dan soporte.
• Gestión de crisis: coordinar decisiones, recursos, comunicaciones y escalado.

Un servicio puede continuar mediante trabajo manual mientras sus sistemas siguen sin estar disponibles. A la inversa, los servidores pueden estar en marcha mientras la función de negocio sigue siendo inutilizable. Defina criterios de aceptación tanto técnicos como de negocio.

Empiece con un servicio crítico y un perímetro de escenario explícito. Recuperarse de un borrado accidental es distinto de recuperarse después de que se hayan comprometido credenciales administrativas. Registre qué situaciones cubre el plan, cuáles necesitan procedimientos separados y quién acepta cualquier carencia restante.

Trabaje hacia atrás desde el servicio de negocio

Un análisis de impacto en el negocio, o BIA, establece qué significa una interrupción antes de que ingeniería elija un diseño de recuperación. Entreviste al responsable del servicio y a las personas que realmente hacen el trabajo. Pregunte qué ocurre tras una hora, una jornada laboral y una interrupción más prolongada: transacciones perdidas, operaciones inseguras, incumplimientos contractuales, perjuicios a clientes o trabajo pendiente acumulado.

Documente el nivel operativo mínimo aceptable. Un portal de clientes podría necesitar el envío de pedidos y la consulta de su estado antes de que vuelvan las funciones de informes. Una operación de producción puede necesitar la planificación y la información de seguridad antes que las funciones administrativas.

Tres medidas orientan el diseño:

Están relacionadas, pero son distintas. El RTO debe dejar margen, dentro de la interrupción tolerable, para la validación de negocio y la recuperación operativa. El RPO describe la pérdida de datos aceptable; no es otro objetivo de tiempo de inactividad.

Acuerde de forma explícita cuándo empieza a contar el tiempo. Si un equipo mide el RTO desde la declaración del incidente y otro desde la interrupción del servicio, los resultados notificados serán engañosos. Registre por separado el momento de la detección y el de la activación, aunque la métrica de recuperación acordada empiece más tarde.

Los responsables de negocio aprueban el resultado exigido; ingeniería demuestra si el diseño puede alcanzarlo. Cuando las limitaciones de coste, personal o proveedores hagan que un objetivo no sea realista, presente las opciones: invertir en una recuperación más rápida, introducir operaciones reducidas, cambiar el objetivo con una aprobación responsable o aceptar el riesgo. No sustituya en silencio un requisito de negocio por lo que el sistema de copias de seguridad actual logra por casualidad.

Trace las dependencias que pueden impedir la recuperación

En un portal de clientes, restaurar la base de datos puede seguir dejando el servicio inutilizable si la identidad, el DNS o las credenciales de despliegue no están disponibles. Construya un mapa de dependencias desde la transacción de negocio hacia fuera, no desde el inventario de servidores hacia dentro.

Incluya aplicaciones y bases de datos, pero también redes, proveedores de identidad, servicios de certificados, secretos, claves de cifrado, artefactos de despliegue, monitorización, integraciones externas, personas y soporte de proveedores. Registre dónde se opera cada dependencia, quién puede recuperarla y qué debe existir antes de que empiece la recuperación.

Busque en particular las dependencias circulares. El gestor de contraseñas puede requerir la plataforma de identidad, mientras que restaurar esa plataforma requiere credenciales guardadas en el gestor. La guía de recuperación puede estar en el servicio de colaboración que, a su vez, no está disponible. Resuelva estos bucles mediante un acceso de emergencia controlado e instrucciones accesibles de forma independiente; pruebe ambos en lugar de suponer que funcionan.

El orden de recuperación es un grafo de dependencias, no necesariamente una secuencia universal de red, base de datos y aplicación. Algunas tareas pueden ejecutarse en paralelo. Otras tienen puntos de control, como confirmar que existe un entorno administrativo limpio antes de exponer a él las cargas de trabajo restauradas.

En el caso de los proveedores, distinga las promesas de los acuerdos operativos. Establezca los contactos de soporte, las vías de escalado, las responsabilidades del lado del cliente, las opciones de exportación, los compromisos de recuperación y cómo recibirá actualizaciones durante la interrupción. El objetivo de recuperación de un proveedor no establece automáticamente su objetivo de servicio de extremo a extremo. Modele qué ocurre si el proveedor no está disponible durante más tiempo del previsto.

Diseñe las copias de seguridad pensando en la recuperación, no en que la tarea termine

Una tarea de copia de seguridad correcta muestra que un proceso ha finalizado. No demuestra que se hayan capturado los datos adecuados, que las claves sigan disponibles ni que la aplicación pueda utilizar el estado restaurado.

Cree una especificación de copias de seguridad para cada sistema crítico:

• Conjuntos de datos, configuración y artefactos incluidos, y exclusiones explícitas.
• Método, calendario, antigüedad prevista del punto de recuperación y conservación de las copias.
• Ubicaciones de almacenamiento y dependencias de cuentas, regiones o instalaciones.
• Acceso administrativo, cifrado, recuperación de claves y controles de borrado.
• Responsabilidades de monitorización, escalado de fallos e instrucciones de restauración.
• Alcance de las pruebas de restauración, criterios de aceptación y resultados conservados.

El enfoque 3-2-1 de uso habitual, ampliado a veces con una copia fuera de línea o inmutable y con verificación, es una heurística de diseño práctica, no una fórmula universal de NIS2. Evalúe si las copias tienen modos de fallo realmente distintos. Varias copias gestionadas a través de una única cuenta de administrador comprometida pueden ofrecer poca protección frente a un borrado deliberado.

Las copias fuera de línea y las inmutables también son distintas. El almacenamiento fuera de línea está desconectado; el almacenamiento inmutable restringe la modificación o el borrado conforme a controles definidos. Examine quién puede alterar la conservación, destruir las claves, cerrar la cuenta o cambiar las políticas de acceso. Evite tratar la etiqueta por sí sola como prueba de protección.

Adecue el mecanismo a los datos

En una base de datos transaccional, la frecuencia de las instantáneas puede no bastar por sí sola para cumplir el RPO. Pueden ser necesarias la captura de registros de transacciones, las copias de seguridad coherentes con la aplicación y la recuperación a un momento dado. Valide si las transacciones repartidas entre varios sistemas pueden recuperarse a un estado coherente.

La replicación puede reducir la interrupción, pero también puede replicar daños o cambios maliciosos. No sustituye a los puntos de recuperación conservados. Del mismo modo, un compromiso de disponibilidad de un SaaS puede no cubrir la recuperación tras un borrado por parte del cliente o un compromiso de la cuenta; compruebe los acuerdos reales de recuperación y exportación.

Incluya las claves de cifrado y la configuración necesarias para interpretar los datos restaurados. Proteja el material de recuperación por separado cuando proceda, con un acceso controlado y una vía de obtención probada. El cifrado y la gestión de claves deben cubrir tanto la recuperación como el funcionamiento normal.

La conservación debe tener en cuenta el descubrimiento tardío: la copia más reciente puede contener ya el problema. Elegir un punto limpio más antiguo puede aumentar la pérdida de datos por encima del RPO. Documente esa disyuntiva y el trabajo de conciliación necesario en lugar de calificar de éxito cualquier restauración completada.

Redacte manuales de recuperación que otro ingeniero pueda ejecutar

Un manual de recuperación útil identifica los requisitos previos, las acciones, los resultados esperados, las ramas de fallo y las comprobaciones de aceptación. Debe ser lo bastante concreto para que un sustituto autorizado pueda seguirlo sin reconstruir la arquitectura bajo presión.

Empiece por las condiciones de activación y los límites de seguridad. ¿Quién autoriza la recuperación? ¿Dónde se ejecutará? ¿Qué redes deben permanecer aisladas? ¿Qué cambios en producción están prohibidos durante el ejercicio? Si se sospecha de actividad maliciosa, conserve las evidencias pertinentes y coordine la contención antes de volver a conectar los sistemas recuperados.

Cada paso debe contener:

Haga referencia a procedimientos controlados para los comandos específicos de cada entorno. Mantenga los secretos fuera del propio manual, pero explique cómo los obtienen los intervinientes autorizados durante una interrupción.

Mida por separado la preparación, la transferencia, la restauración, la configuración, la validación y el traspaso. Una restauración de datos rápida puede seguir incumpliendo el RTO porque el aprovisionamiento de la infraestructura o las comprobaciones de negocio tardan más de lo previsto.

En la recuperación tras un ciberataque, reconstruir a partir de artefactos de confianza puede ser más seguro que restaurar máquinas completas. Valide las cuentas privilegiadas, rote las credenciales expuestas cuando proceda y compruebe que no haya mecanismos de persistencia antes de la puesta en servicio. Estas decisiones deben ser ramas explícitas del procedimiento.

Termine con comprobaciones a nivel de servicio: autenticación, una transacción representativa, comportamiento de las integraciones, monitorización y conciliación. El responsable técnico registra la finalización; el responsable de negocio acepta el nivel operativo acordado. Incluya un retorno controlado desde las soluciones provisionales, con la responsabilidad de resolver el trabajo en cola y los registros duplicados.

Mantenga el negocio en funcionamiento mientras avanza la recuperación

Las operaciones alternativas necesitan sus propios límites de capacidad y de seguridad. «Usar una hoja de cálculo» no es un plan a menos que alguien haya establecido el acceso, los campos, la autorización, la protección del almacenamiento y la conciliación posterior.

Para un servicio de pedidos interrumpido, un proceso temporal podría aceptar una clase limitada de pedidos a través de un canal aprobado, emitir referencias únicas y aplazar el procesamiento de los pagos. Registre quién autoriza los pedidos, cómo se evitan los duplicados, cómo se protege la información de los clientes y cuándo debe terminar la solución provisional.

Evalúe si las operaciones reducidas permiten realmente ganar suficiente tiempo. El procesamiento manual puede sostener un volumen pequeño, pero desbordarse con la carga de trabajo normal. Pruebe una demanda representativa e identifique los clientes o transacciones prioritarios con criterios de negocio acordados.

Planifique también las personas y los lugares de trabajo. La recuperación puede fracasar porque el único operador cualificado no está disponible, el emplazamiento alternativo carece de conectividad o los intervinientes no pueden trabajar de forma segura durante un incidente prolongado. Asigne sustitutos, requisitos de traspaso y turnos de personal en lugar de confiar en la resistencia individual.

Otorgue al equipo de crisis derechos de decisión claros

Separe la coordinación del incidente de la recuperación práctica para que el responsable técnico no esté a la vez restaurando sistemas, aprobando gastos y respondiendo a todas las partes interesadas.

Asigne roles principales y suplentes para la coordinación de la crisis, la recuperación técnica, las operaciones de negocio, las decisiones de la dirección, las comunicaciones y la evaluación jurídica o de cumplimiento. Registre los umbrales de activación, los medios de contacto, la autoridad de decisión y las condiciones de escalado. Las autorizaciones previas prácticas pueden cubrir compras de soporte de emergencia, infraestructura alternativa y la suspensión de servicios inseguros, dentro de los límites aprobados por la dirección.

Prepare plantillas de comunicación para empleados, clientes, proveedores y autoridades. Cada una debe distinguir los hechos conocidos de las estimaciones, describir los servicios afectados, dar las instrucciones vigentes e indicar la hora de la próxima actualización. Pruebe un canal alternativo para cuando el correo electrónico y el chat corporativos no estén disponibles. Asegúrese de que los intervinientes puedan acceder a la información de contacto de forma segura fuera de los sistemas habituales.

La evaluación de las obligaciones de notificación debe avanzar a la par que la recuperación. En el caso de los incidentes significativos dentro del ámbito de aplicación, el artículo 23 de NIS2 establece una alerta temprana en 24 horas, una notificación del incidente en 72 horas y, por lo general, un informe final en el plazo de un mes desde la notificación. Compruebe las normas, umbrales, destinatarios y procedimientos nacionales y sectoriales aplicables. No toda interrupción es automáticamente notificable.

Asigne a alguien el seguimiento del momento del conocimiento y de las decisiones de notificación; no espere a la restauración completa para evaluar las obligaciones. Cuando haya datos personales implicados, evalúe por separado los requisitos de notificación de violaciones del RGPD según el rol de la organización y el riesgo para las personas.

Ponga a prueba afirmaciones distintas con pruebas distintas

Elija el tipo de ejercicio en función de lo que necesite demostrar:

Fije la frecuencia como una decisión práctica basada en el riesgo, teniendo en cuenta los requisitos aplicables, la criticidad del servicio, el ritmo de cambio y los hallazgos anteriores. No suponga que un intervalo universal trimestral o anual satisface todas las obligaciones. Desencadene pruebas adicionales después de cambios significativos en la arquitectura, los proveedores, los accesos o el personal.

Antes de la prueba, apruebe el escenario, los objetivos, los controles de seguridad, los participantes, las condiciones de parada y los criterios de éxito. Dé preferencia a entornos aislados cuando sea posible. Evite que mensajes, pagos o notificaciones a clientes de prueba se filtren a las operaciones reales.

Utilice restricciones realistas: un especialista ausente, servicios de identidad no disponibles, una copia de seguridad limpia más antigua o un soporte del proveedor que se retrasa. Evite proporcionar discretamente credenciales e infraestructura que no existirían durante el incidente.

Recoja el escenario, los participantes, las horas de inicio y fin, los tiempos de cada paso, los resultados reales y las desviaciones. Registre la ayuda recibida y los atajos. Si la prueba omitió cambios de DNS, datos con volúmenes de producción o integraciones externas, indíquelo. Un resultado acotado es más útil que un aprobado exagerado.

Ejemplo práctico: demostrar la ruta de recuperación de un portal de clientes

Consideremos un portal ilustrativo que da soporte al envío de pedidos. Los objetivos y tiempos que siguen son supuestos, no referencias del sector ni promesas de producto.

El negocio acuerda un RTO de cuatro horas y un RPO de 15 minutos. Recuperar significa que los clientes pueden autenticarse, enviar un pedido y ver su estado; los informes pueden volver más tarde. El escenario supone que la infraestructura de producción y las credenciales de administrador habituales no están disponibles, pero que sigue siendo accesible una copia de seguridad controlada por separado.

El equipo presupuesta la ruta de la siguiente manera:

Esto deja solo 20 minutos de margen frente al objetivo de cuatro horas. Como varias tareas comparten un mismo ingeniero de recuperación, el equipo no supone que puedan ejecutarse en paralelo.

Durante el ejercicio, obtener las credenciales de despliegue lleva 55 minutos adicionales: la vía de acceso documentada depende del proveedor de identidad que no está disponible. El servicio supera sus comprobaciones funcionales a los 275 minutos e incumple el RTO. Su última transacción recuperable es de 12 minutos antes de la interrupción, lo que cumple el RPO supuesto para este escenario.

El resultado no es un aprobado general. El responsable de los accesos establece una vía de obtención independiente y controlada, se actualiza el manual y un ingeniero sustituto lo vuelve a probar. El siguiente ejercicio integrado debe verificar de nuevo el tiempo total transcurrido. El responsable de negocio revisa además si el margen de tiempo restante es suficiente en condiciones menos favorables.

Conserve las evidencias y corrija las debilidades

Mantenga un conjunto de evidencias coherente: el BIA aprobado, el perímetro y las dependencias del servicio, la especificación de copias de seguridad, los manuales de recuperación, los roles y contactos de crisis, los procedimientos de operación alternativa y los registros de los ejercicios. Conserve las versiones para que los revisores puedan ver qué plan se probó realmente.

Para cada debilidad significativa, registre el servicio afectado, el resultado observado, la consecuencia para el negocio, el responsable, la fecha límite, la corrección y el método de verificación. Completar una tarea no es lo mismo que demostrar la corrección. Vuelva a probar el paso afectado y, si han cambiado las dependencias, la ruta de recuperación más amplia. Escale las acciones vencidas y las carencias frente a los objetivos al responsable de la decisión.

En Secani, modele el servicio crítico y los sistemas y proveedores que le dan soporte, vincule las evidencias de los ejercicios con los requisitos o controles que respaldan y convierta las carencias en tareas con responsable. Mantenga los comentarios de los revisores y las aprobaciones humanas vinculados a las decisiones. El flujo de trabajo documentado respalda ese contexto de evidencias; la recuperación técnica sigue teniendo que ejecutarla y validarla el equipo responsable.

Empiece con un servicio crítico. Acuerde qué significa recuperarlo, recorra su ruta de dependencias con un operador sustituto y programe un ejercicio de restauración acotado. Utilice el resultado medido para actualizar el plan, no solo para marcar el ejercicio como completado.