La continuidad del negocio pregunta cómo mantener las operaciones importantes cuando las condiciones normales se interrumpen. La recuperación ante desastres pregunta cómo restaurar los sistemas, datos y dependencias técnicas necesarios. Estas tareas están relacionadas, pero tienen diferentes alcances. Un servidor en funcionamiento no ayudará a enviar un pedido si el personal o un proveedor no están disponibles. Aceptar pedidos a través de un proceso temporal no elimina la necesidad de restaurar el sistema y reconciliar los datos.
Por lo tanto, elegir entre BCP y DRP suele ser una cuestión de títulos de documentos, más que de responsabilidad por el resultado. Puede documentar un plan de continuidad y un plan de recuperación por separado o como un conjunto. Lo importante es llegar a un acuerdo sobre las prioridades, los responsables y la transferencia de decisiones.
Qué cubre cada tarea
BCP mantiene los procesos de negocio importantes
Un plan de continuidad del negocio considera a las personas, las instalaciones, el equipo, las comunicaciones, los proveedores y los procedimientos operativos. Define qué operaciones deben continuar, a qué capacidad aceptable y a través de qué métodos temporales. Estos podrían incluir un lugar de trabajo alternativo, otro canal de comunicación o un proceso manual acordado. Verifique que la alternativa funcione antes de que la necesite.
La continuidad no promete trabajo sin interrupciones ni pérdidas. Algunas operaciones pueden funcionar en un modo limitado, mientras que otras pueden no ser compatibles. La dirección y el responsable del proceso deben comprender los límites, los recursos disponibles y las consecuencias de una solución temporal.
DRP restaura la capacidad técnica para trabajar
Un plan de recuperación ante desastres de la informática describe cómo restaurar o cambiar las aplicaciones, los datos, los componentes de la red y las dependencias necesarias. Necesita una secuencia, acceso a copias de seguridad y claves, un entorno disponible, roles asignados y verificación del resultado. Una copia de seguridad es un recurso, no todo el plan.
La recuperación técnica debe coincidir con la tarea de negocio. Restaurar un sistema que no soporte el proceso de prioridad primero puede consumir recursos sin el beneficio requerido. Por el contrario, un proceso crítico puede depender de un servicio de inicio de sesión fácilmente pasado por alto, integración o participante externo. Ambos equipos deben conocer estas dependencias.
Las directrices de AWS consideran la recuperación de TI como parte de la continuidad del negocio. Las prioridades y objetivos de recuperación deben tener en cuenta la tarea, el riesgo y el coste del negocio. La disponibilidad técnica por sí sola no aborda las consecuencias más allá de la aplicación.
Comparar el alcance, los responsables y los criterios de preparación
Diferentes límites dentro de un esfuerzo coordinado
|
Criterio |
Continuidad del negocio |
Recuperación de TI ante desastres |
|---|---|---|
|
Pregunta principal |
Cómo mantener una operación importante cuando las condiciones normales se interrumpen |
Cómo restaurar los recursos técnicos que requiere esa operación |
|
Alcance |
Personas, instalaciones, proveedores, comunicaciones, procedimientos y dependencias del sistema de TI |
Aplicaciones, datos, infraestructura, acceso y dependencias técnicas |
|
Responsabilidad |
Equipos de gestión y propietarios de procesos trabajando con los departamentos correspondientes |
Equipos técnicos trabajando con los propietarios de los resultados empresariales |
|
Solución temporal |
Un modo de funcionamiento o proceso alternativo acordado y limitado |
Recuperación, conmutación o cualquier otra procedimiento técnico planificado |
|
Condiciones iniciales |
Prioridades, impacto aceptable, recursos y restricciones |
Requisitos del proceso, RPO y RTO acordados, y un entorno y procedimiento disponibles |
|
Confirmación del resultado |
La operación importante se ejecuta según el modo acordado. |
El resultado técnico y la operación empresarial pasan la verificación. |
|
Actualizaciones |
Se modifican procesos, personas, ubicaciones o proveedores. |
Se modifican sistemas, datos, dependencias o la ruta de recuperación. |
Prepare ambos ámbitos antes de una interrupción. Durante una interrupción, el trabajo puede continuar en paralelo: la empresa organiza un modo de funcionamiento temporal aceptable mientras que el departamento de TI restaura su base técnica. No asuma que el plan de continuidad del negocio (BCP) solo se aplica antes de un desastre o que la recuperación (DR) solo comienza después de que la crisis haya terminado por completo. Defina las condiciones de activación y coordinación en los planes.
Dónde encaja la respuesta a incidentes cibernéticos
Un plan de respuesta a incidentes cibernéticos ayuda a detectar y evaluar un evento, a limitar sus consecuencias y a acordar las siguientes acciones. Se conecta con la recuperación y la continuidad, pero no las reemplaza. Por ejemplo, antes de restaurar una aplicación, establezca si el entorno y los datos seleccionados son seguros para su uso. Iniciar la tecnología sin este acuerdo podría traer el problema de vuelta.
Un fallo de equipo sin signos de un ataque puede requerir procedimientos diferentes. No trate un plan de respuesta cibernética como el documento principal universal para cada interrupción empresarial. La actual tercera revisión de las directrices de NIST conecta la respuesta con la gestión más amplia de los riesgos cibernéticos, que incluye la preparación, la detección, la respuesta y la recuperación.
Conecte los planes a través de una tarea empresarial compartida
Acuerde sobre prioridades y un modo de funcionamiento aceptable
Utilice los resultados del análisis del impacto empresarial: qué operaciones son importantes, quién se ve afectado por la interrupción y cómo cambian las consecuencias con el tiempo. Estos hallazgos apoyan la comparación y la coordinación de los planes. Un análisis de riesgos y un cálculo de impacto completos requieren un trabajo separado. Aquí, verifique que ambos equipos utilicen las mismas prioridades.
Para cada proceso importante, se debe identificar a su responsable, las dependencias técnicas y la forma temporal aceptable de trabajar. Los objetivos de RTO y RPO deben estar alineados con estas condiciones y la viabilidad técnica. Este artículo no prescribe límites de tiempo universales ni reemplaza una decisión separada sobre los objetivos.
Registrar quién activa cada conjunto de acciones, quién aprueba los cambios de prioridad y quién recibe la confirmación de disponibilidad. Incluir participantes de respaldo, equipos externos y un canal de comunicación para utilizarse cuando las herramientas normales fallen. Si el contacto solo está disponible dentro del sistema caído, la coordinación puede detenerse junto con él.
Analizar un escenario hipotético
Supongamos que el sitio principal está inactivo y los empleados no pueden utilizar el sistema de procesamiento de pedidos. El siguiente escenario hipotético verifica los límites de responsabilidad. No es un procedimiento predefinido para su empresa. Confirme la viabilidad de la recepción temporal de pedidos y el método de recuperación para su propio entorno.
Escenario hipotético coordinado para la indisponibilidad del sitio
|
Etapa |
Acciones de continuidad |
Acciones de recuperación de TI |
Punto de coordinación |
|---|---|---|---|
|
Evaluación del impacto |
El responsable del proceso identifica las operaciones afectadas y la capacidad de trabajo aceptable |
El equipo identifica los componentes no disponibles y las dependencias requeridas |
La dirección confirma las prioridades y la activación de las acciones planificadas |
|
Operaciones temporales |
El equipo utiliza un canal alternativo aprobado y registra las solicitudes recibidas |
El departamento de TI prepara el entorno acordado y recupera los datos utilizables |
Los participantes conocen los límites, los propietarios y el próximo momento de actualización |
|
Restauración técnica |
El propietario prepara una prueba de la operación empresarial requerida |
El departamento de TI restaura el sistema y verifica los datos, el acceso y las conexiones |
La aceptación depende de la funcionalidad, y no solo del inicio de un servidor |
|
Conciliación de registros acumulados |
Los propietarios asignados comparan las solicitudes y los cambios del período temporal |
El departamento de TI ayuda a aplicar el proceso acordado de transferencia y verificación |
No se pierden registros, no aparecen duplicados, y los datos en disputa se entregan al propietario |
|
Regresar a las operaciones normales |
El propietario confirma el fin de las operaciones temporales e informa a los participantes |
El equipo completa la transición acordada y verifica la protección normal |
Se confirman los resultados del negocio, los límites restantes y las acciones posteriores |
Si el mismo escenario incluye signos de un ataque, coordine con las personas responsables de la respuesta cibernética. No restaure la confianza en un sistema simplemente porque comienza. Si el trabajo manual temporal es inaceptable, también lo registre. En ese caso, no puede garantizarlo como un sustituto universal para la TI.
Verifique las lagunas en los límites de responsabilidad
- El negocio espera que la operación esté disponible, pero la verificación técnica se detiene al iniciar la infraestructura.
- Existe una forma de trabajar temporal, pero los permisos, los límites y un propietario permanecen sin definir.
- Las prioridades del proceso y la secuencia de recuperación del sistema no coinciden.
- Se ha omitido un servicio externo, proveedor, canal de comunicación o participante de respaldo.
- Nadie posee la responsabilidad de la conciliación de los nuevos datos temporales con el sistema restaurado.
- El equipo no sabe quién acepta el resultado y autoriza la devolución.
- Los contactos, las instrucciones y las pruebas solo existen en el entorno no disponible.
La infraestructura en la nube, la redundancia y la automatización pueden apoyar la recuperación, pero no resuelven todos los problemas relacionados con las personas, los suministros y las decisiones empresariales. Elija los recursos para el escenario acordado. Comprar un producto etiquetado como BCDR no establece límites de responsabilidad ni criterios de aceptación empresarial.
Coordinación de pruebas y decisiones de actualización
Comience una revisión conjunta con una operación seleccionada: quién decide, cómo funciona el trabajo temporal, qué IT restaura y quién confirma la finalización. Trabajar a través del escenario ayuda a identificar los puntos poco claros. Realice la recuperación real por separado dentro del alcance acordado. Una simple discusión alrededor de una mesa no prueba la preparación técnica.
Después de la revisión, conserve las brechas identificadas, los responsables de la remediación y las condiciones para volver a probar. Revise la conexión entre los planes después de un cambio en el proceso, el equipo, el sistema, el proveedor o la ubicación. La frecuencia depende del riesgo y de los requisitos aplicables, no de una afirmación general de que una revisión anual es suficiente para cada negocio.
Como siguiente paso, cree un mapa breve de una operación: propietario, modo de funcionamiento aceptable, dependencias de IT, objetivos, datos temporales, aceptación y devolución. Esto muestra lo que necesita acuerdo. Desarrolle plantillas completas de BCP y DRP, instrucciones de recuperación y registros de ejercicios para las condiciones específicas.
¿Necesita verificar si la recuperación de IT se alinea con las prioridades empresariales? Póngase en contacto con DKs Enterprises sobre respaldo y recuperación ante desastres. Prepare una lista de las operaciones importantes, las dependencias técnicas y las brechas conocidas para discutir el alcance del trabajo.
