La continuidad del negocio mantiene en funcionamiento las actividades críticas de la organización durante una interrupción. La recuperación ante desastres restaura la tecnología de la que dependen dichas actividades. No son enfoques contrapuestos ni constituyen el mismo documento. La continuidad es una disciplina empresarial que decide qué debe seguir funcionando y cómo. La recuperación es una disciplina técnica que reconstruye los sistemas en un orden definido, para alcanzar los objetivos establecidos por la empresa.
- Diferentes propietarios: la continuidad suele recaer en las operaciones o el riesgo, la recuperación en el departamento de TI.
- Existen diferentes mecanismos de activación: la continuidad se activa ante un impacto en el negocio, la recuperación ante un fallo técnico.
- Diferentes definiciones de éxito: trabajo continuo versus sistemas restaurados.
- Un mismo conjunto de cifras, ambas extraídas del mismo análisis de impacto empresarial.
- Los fallos se producen en la unión entre ellos, no dentro de ninguno de ellos.
¿En qué se diferencian realmente la continuidad del negocio y la recuperación ante desastres?
Si se le pregunta a la mayoría de la gente sobre la continuidad del negocio frente a la recuperación ante desastres, la respuesta suele ser la misma: la continuidad es amplia, la recuperación es técnica. Esto es cierto, pero no resulta muy útil a la hora de decidir quién escribe qué. La distinción más útil reside en las responsabilidades de cada disciplina y en la procedencia de sus instrucciones.
Un plan de continuidad parte de las actividades. Se pregunta qué actividades de la organización no pueden interrumpirse, cuánto tiempo puede suspenderse cada una antes de que el daño sea grave y qué alternativa de trabajo se puede implementar mientras tanto. Su resultado es un conjunto de decisiones sobre prioridades y soluciones provisionales.
Un plan de recuperación parte de los sistemas. Se pregunta qué debe volver a funcionar, en qué orden, para cumplir con los plazos establecidos para la continuidad del negocio. Su resultado es un manual de procedimientos. La visión general de cómo ambos se integran en una única capacidad se describe en el apartado de continuidad del negocio.
| Continuidad del negocio | Recuperación de desastres | |
|---|---|---|
| ¿Quién es el dueño? | Responsable de operaciones, riesgos o continuidad del negocio, con el respaldo de la dirección ejecutiva. | El equipo de TI o de infraestructura suele ser el mismo que gestiona la plataforma a diario. |
| ¿Qué lo desencadena? | El impacto en el negocio alcanza un umbral, cualquiera que sea la causa, incluidas las causas sin componente técnico. | Un fallo técnico o la pérdida de un sistema, sitio web o conjunto de datos. |
| Lo que significa recuperado | Las actividades críticas se están prestando nuevamente a los clientes, por cualquier vía aceptable. | Los sistemas mencionados están en funcionamiento, son accesibles y se ha verificado la integridad de sus datos. |
| De dónde provienen los objetivos | El análisis del impacto en el negocio, aprobado por las personas responsables de cada actividad. | Heredado de la continuidad. La recuperación no establece sus propios objetivos. |
| Lo que piden los auditores | Existen pruebas de que se han realizado ejercicios en los que participa la empresa y de que las prioridades reflejan las operaciones actuales. | Existen pruebas de que las pruebas de restauración se han realizado con sus resultados, y de que las copias de seguridad son realmente recuperables. |
| Lo que cuesta equivocarse | El trabajo se detiene a pesar de que los sistemas funcionan correctamente, porque nadie acordó la ruta manual. | Los sistemas responden en un orden que hace que la actividad crítica tenga que esperar más tiempo. |
¿Quién es el propietario de cada plan y por qué eso causa problemas?
La propiedad dividida es sensata. Quienes conocen los compromisos de los clientes no son quienes conocen la secuencia de restauración de un clúster de bases de datos. El problema no radica en la división, sino en que ambas partes suelen escribir de forma aislada y solo descubren la discrepancia durante un incidente.
Se repiten tres patrones. El primero es un plan de recuperación con objetivos consensuados, generalmente definidos en función de lo que la infraestructura puede lograr sin problemas, en lugar de las necesidades de la actividad. El segundo es un plan de continuidad que contempla una solución manual que, en realidad, depende del mismo sistema que ha fallado. El tercero es el más común: ambos planes existen, ambos son técnicamente sólidos y ninguno especifica quién declara un incidente ni quién decide que el servicio se ha reanudado con normalidad.
La solución no es una fusión. Es una interfaz definida: objetivos compartidos derivados del análisis de impacto empresarial , una única autoridad para intervenir y suspender, y un ejercicio conjunto al menos una vez al año en el que ambas partes estén presentes.
Detrás de todo esto hay algo más importante.
Esta página abarca una parte de la resiliencia empresarial. Real Resilience, el marco de IO para conectar la seguridad, la privacidad y la gobernanza de la IA, es donde se obtiene la visión completa.
¿Dónde se hace el relevo entre uno y otro?
La mayoría de los análisis posteriores a incidentes que culpan a un plan en realidad describen una transición que nunca se definió. La continuidad y la recuperación se ejecutan en paralelo, no en secuencia, y se cruzan en cuatro puntos: la decisión de activar el plan, la elección de las acciones de la empresa mientras los sistemas están inactivos, el momento en que la tecnología se declara operativa nuevamente y la confirmación de que la empresa ha vuelto a funcionar de verdad, en lugar de estar simplemente conectada.
Observe dónde comienza la secuencia. La detección es casi siempre un proceso técnico, por lo que muchas organizaciones tratan todo el incidente como un asunto de TI e involucran al negocio demasiado tarde. Para cuando se necesita tomar una decisión sobre la continuidad del servicio, a menudo ya ha pasado el momento oportuno para encontrar una solución alternativa eficaz.
¿Qué ocurre en las primeras 24 horas?
Ambos planes están activos simultáneamente, realizando tareas diferentes. Dejar esto claramente establecido es la página más valiosa de cualquiera de los dos documentos, ya que elimina la pausa en la que todos esperan a ver quién actúa primero.
| Fase | La continuidad está haciendo | La recuperación está haciendo |
|---|---|---|
| Primera hora | Determinar qué actividades se ven afectadas y confirmar quién tiene autoridad para invocarlas. | Diagnosticar el alcance del problema, aislar la falla y confirmar si las copias de seguridad están intactas. |
| De dos a cuatro horas | Promover una forma alternativa de trabajar e informar al personal y a los clientes. | Decidir si reparar en el lugar o realizar una conmutación por error, e iniciar la restauración. |
| De cuatro a doce horas | Mantener la solución alternativa abastecida de personal y hacer un seguimiento de lo que se acumula sin hacer. | Restauración en orden de dependencia y verificación de datos a medida que se recupera cada capa. |
| De doce a veinticuatro horas | Gestionar la fatiga, los traspasos de tareas y la creciente acumulación de trabajo que la solución provisional no puede absorber. | Recuperar las aplicaciones restantes y probarlas con transacciones reales. |
| Más allá de las veinticuatro horas | Decidir cuándo suspender el servicio y luego eliminar el trabajo acumulado por orden de prioridad. | Confirmación del servicio completo, conciliación de los datos registrados durante la solución alternativa. |
La última fila es donde la mayoría de los planes se detienen, pero la mayoría de los incidentes reales no. El trabajo realizado manualmente debe integrarse posteriormente en los sistemas, y un retraso en la resolución de tareas en el orden incorrecto puede provocar una segunda interrupción.
¿Necesitas ambos documentos o uno solo sirve para ello?
Las organizaciones pequeñas suelen mantener un único documento, y para una operación realmente pequeña, esto puede funcionar. La clave no está en el tamaño, sino en si ambos públicos pueden encontrar lo que necesitan bajo presión. Un ingeniero que restaura una base de datos a las tres de la mañana no debería estar leyendo sobre comunicaciones con clientes, y un gerente de operaciones que implementa un proceso manual no debería estar revisando comandos de conmutación por error. El contenido del documento de continuidad y la procedencia del contenido de cada sección se especifican en el plan de continuidad del negocio.
Manténgalos separados cuando cualquiera de las audiencias necesite más de una o dos páginas, y mantenga referencias cruzadas entre ellos. Lo que nunca debe duplicarse son las cifras. Si el plazo de recuperación aparece en ambos documentos y no coinciden, los planes se contradecirán justo cuando más importa. Establezca los objetivos una sola vez, en el análisis de impacto, y haga referencia a ellos en todos los demás documentos. Los detalles del documento técnico se tratan en el plan de recuperación ante desastres , y el nivel de escenario subyacente a ambos se encuentra en sus planes de contingencia.
Si su interés se centra en un marco específico, la comparación con una auditoría SOC 2 se trata por separado en lo que SOC 2 exige en materia de continuidad y recuperación.
¿Qué normas cubren cada una de ellas?
La división se refleja en las propias normas, lo que permite una útil comprobación del alcance. La norma ISO 22301 especifica un sistema de gestión para la continuidad del negocio: es certificable y se centra en la capacidad organizativa. La norma ISO/IEC 27031 abarca la preparación de las tecnologías de la información y la comunicación para la continuidad del negocio, que constituye la capa de recuperación. La norma ISO 27001 las conecta mediante el Anexo A, donde el control 5.29 aborda la seguridad de la información durante las interrupciones y el control 5.30 aborda la preparación de las TIC.
Trabajar conforme a esos estándares no fusiona ambas disciplinas, pero sí obliga a que exista la interacción entre ellas. Un sistema de gestión debe demostrar que la preparación técnica está al servicio de las prioridades del negocio, y es precisamente ahí donde se produce el fallo cuando nadie exige que se demuestre.
ISO 27001 simplificado
Una ventaja del 81% desde el primer día
Hemos hecho el trabajo duro por ti y te damos una ventaja inicial del 81 % desde el momento en que inicias sesión. Todo lo que tienes que hacer es completar los espacios en blanco.
¿Cómo encaja este par en la resiliencia empresarial?
Tanto la continuidad como la recuperación responden a la misma pregunta: ¿qué sucede cuando algo falla? La resiliencia, en cambio, responde a una pregunta más amplia. Es la capacidad de absorber cambios de cualquier tipo, incluyendo interrupciones para las que no se elaboró un plan y obligaciones que no existían cuando se redactaron. Ambos planes son componentes de la resiliencia, no sustitutos de ella.
El ciclo de resiliencia gestiona la seguridad de la información según la norma ISO 27001 , la privacidad de los datos según la norma ISO 27701 y la gobernanza de la IA según la norma ISO 42001 como un sistema conectado. La continuidad y la recuperación se basan en los mismos controles, ofreciendo una perspectiva adicional. Esto es crucial: la gestión de accesos, las copias de seguridad y los controles de proveedores de los que depende un plan de recuperación son los mismos que los de la solución alternativa de continuidad, por lo que mantenerlos una sola vez beneficia a ambos. El marco de resiliencia empresarial describe cómo se integra todo el conjunto.
También explica por qué una interrupción del servicio puede convertirse en un problema de privacidad en cuestión de horas. Restaurar un sistema a partir de una copia de seguridad antigua puede recuperar datos que alguien solicitó borrar, y una solución alternativa que transfiere los registros de clientes a una hoja de cálculo crea una ruta de procesamiento que nadie evaluó. Tratar la recuperación como un asunto puramente técnico es la razón por la que se pasan por alto estas consecuencias.
¿Cómo se demuestra que ambos funcionan?
Nadie comprueba si usted posee dos documentos. Los clientes, auditores y entidades reguladas hacen una pregunta más difícil: demuéstrenme que ambos funcionan, que son coherentes entre sí y que reflejan su forma de operar actual.
Esto significa que se deben tener los objetivos actuales con evidencia de quién los aprobó, una prueba de restauración con resultados en lugar de una fecha programada, un ejercicio empresarial con participantes identificados, los hallazgos de ambos y las acciones correctivas finalizadas. El ejercicio conjunto es el que con mayor frecuencia falta, y es la única evidencia que demuestra la transferencia de responsabilidades. El enfoque se describe en cómo demostrar la resiliencia , y la puntuación de resiliencia proporciona una base de referencia.
¿Por qué elegir ISMS.online para la continuidad y la recuperación?
La discrepancia entre estos dos planes radica tanto en un problema de gestión de registros como en uno de planificación. ISMS.online permite que ambas partes trabajen desde la misma fuente.
- Un conjunto de objetivos: Los plazos de recuperación se encuentran en un mismo lugar y alimentan ambos planes, por lo que no pueden separarse.
- Planes vinculados a los controles en los que se basanLos controles de respaldo, acceso y proveedores que respaldan cada plan son visibles, por lo que una deficiencia en uno se refleja en el otro.
- Registros de ejercicios incorporados: programar conjuntamente las pruebas de restauración técnica y los ejercicios empresariales, registrar los resultados y realizar un seguimiento de las acciones en el mismo sistema.
- Un conjunto de controles, cada marcoMapear una sola vez y reutilizar en ISO 22301, ISO 27001, ISO 27701 e ISO 42001 en lugar de mantener conjuntos paralelos.
- Pruebas a demanda: mostrar un plan actual con un historial de pruebas, no un documento y una garantía.
- Propiedad que posee: propietarios designados, suplentes y fechas de revisión en ambos lados de la transferencia.
- Diseñado para el Reino Unido y los mercados regulados.Diseñado para organizaciones que deben demostrar resiliencia para ganar y conservar contratos.
Vea cómo se integra en la plataforma de resiliencia empresarial o solicite una demostración.
Preguntas Frecuentes
¿La recuperación ante desastres forma parte de la continuidad del negocio?
Sí, en el sentido de que la recuperación contribuye a los objetivos de la continuidad. La continuidad del negocio es la disciplina más amplia que abarca todas las actividades críticas y todas las causas de interrupción, incluso aquellas sin componente técnico. La recuperación ante desastres es el componente tecnológico dentro de ella. La recuperación hereda sus objetivos de la continuidad en lugar de establecer los suyos propios, razón por la cual un plan de recuperación redactado sin un análisis de impacto en el negocio tiende a proteger primero los sistemas equivocados.
¿Podemos tener un plan de recuperación ante desastres sin un plan de continuidad del negocio?
Es posible, y muchas organizaciones lo hacen, pero entonces se trata de adivinar las prioridades. Sin un consenso sobre qué actividades son importantes y cuánto tiempo puede interrumpirse cada una, el orden de restablecimiento se determina por conveniencia técnica. Además, no ofrece una solución para interrupciones que no son de índole técnica, como la pérdida de una sede, un proveedor clave o el personal que gestiona un proceso crítico.
¿Quién debería ser el propietario de cada plan?
La continuidad del negocio, generalmente en operaciones o gestión de riesgos, debe estar a cargo de un ejecutivo responsable que pueda comprometerse con las prioridades. La recuperación, en cambio, debe estar a cargo de TI o infraestructura. Lo importante no es la jerarquía, sino la interfaz: una autoridad designada para activar y desactivar las medidas de seguridad, un conjunto compartido de objetivos de recuperación y un ejercicio conjunto en el que participen ambas partes.
¿Ambos planes utilizan la misma RTO?
Deben utilizar las mismas cifras, procedentes de una misma fuente. El objetivo de tiempo de recuperación para una actividad se establece en el análisis de impacto empresarial, y el plan técnico se diseña para cumplirlo, teniendo en cuenta que el hecho de que un sistema vuelva a estar operativo no es lo mismo que la actividad esté plenamente operativa. Si ambos documentos presentan versiones distintas de la cifra, inevitablemente discreparán, y esta discrepancia saldrá a la luz durante un incidente.
¿Con qué frecuencia deberíamos ejercitarlos juntos?
Al menos una vez al año, y tras cualquier cambio que afecte a la transferencia: un nuevo sistema crítico, una configuración de alojamiento diferente, una reorganización que implique un cambio de titularidad o un incidente real. Se pueden realizar pruebas de restauración técnica independientes con mayor frecuencia, y de hecho se recomienda. El ejercicio conjunto es el que pone a prueba la interfaz, por lo que un programa de pruebas técnicas frecuentes sin un ejercicio conjunto deja sin examinar el punto de fallo más probable.
