DR/BCP: preparar y supervisar una prueba de recuperación en una sede financiera

Qué vas a conseguir

Una prueba de recuperación que demuestra algo: que los servicios que soportan las funciones críticas arrancan en el centro alternativo dentro del tiempo comprometido, con los datos que se esperaba, y que el negocio puede operar con ellos. Y un informe que lo cuenta con números, con lo que falló y con quién lo arregla y cuándo. En servicios financieros esa prueba no es opcional ni se hace "cuando haya tiempo": forma parte del programa de resiliencia que revisarán auditoría y, si llega el caso, el supervisor.

Antes de empezar

• El análisis de impacto (BIA) con las funciones críticas o importantes y sus objetivos de RTO y RPO, aprobados por el negocio.
• El plan de recuperación de cada servicio en alcance, actualizado: si el último cambio de arquitectura no está en el plan, la prueba probará un plan que ya no existe.
• La réplica al centro alternativo funcionando y vigilada (almacenamiento, bases de datos, copias), con su retraso medido.
• Contactos y compromisos de los proveedores que intervienen: operadoras, proveedores de datos de mercado, plataformas externas de contratación.

1. Alcance y escenario

Una prueba sin alcance claro acaba siendo una demostración de lo que ya funciona. Escribe en una página:

• Escenario: por ejemplo, "pérdida total del centro de datos principal un viernes a las 22:00". Un escenario concreto obliga a decidir qué cae y qué no.
• Servicios en alcance: plataforma de órdenes, conectividad con mercados y contrapartes, datos de mercado, base de datos de operaciones, directorio y DNS que necesitan todos los demás.
• Fuera de alcance, por escrito: lo que no se prueba esta vez y por qué. Lo que nunca se prueba es lo que fallará el día real.
• Objetivos:

2. Lo que espera la regulación

En la Unión Europea, el Reglamento DORA (Reglamento (UE) 2022/2554, aplicable desde enero de 2025) pide a las entidades financieras, entre otras cosas:

• Un programa de pruebas de resiliencia operativa digital, con pruebas al menos anuales de los sistemas que soportan funciones críticas o importantes.
• Planes de continuidad y de respuesta y recuperación de las TIC probados de forma periódica, también con escenarios de caída de proveedores.
• Resultados documentados, deficiencias identificadas y su corrección con seguimiento.
• Para algunas entidades, además, pruebas de penetración basadas en amenazas (TLPT) cada cierto tiempo.

Qué aplica exactamente a tu entidad lo determinan las áreas de riesgos y cumplimiento. Para IT, lo práctico es que la prueba deje evidencia: plan, horas, resultados, aceptación y acciones, todo fechado y localizable.

3. Roles y go/no-go

Un no-go no es un fracaso: es exactamente para lo que sirve la lista. Si una condición falla, se aplaza o se reduce el alcance, y se registra.

4. El calendario del fin de semana

La vuelta es parte de la prueba. Muchas pruebas salen bien hasta el regreso y el lunes la sede abre con una réplica a medias.

5. Medir RTO y RPO de verdad

• RTO: desde T0 hasta que el negocio confirma que el servicio sirve, no hasta que el servidor arranca. Cada técnico anota la hora real de cada paso en el registro; el coordinador las consolida.
• RPO: compara la última operación registrada en el centro principal antes de T0 con la última disponible en el centro alternativo.

›sqlcmd -S srv-oms-sql01 -d oms -E -Q "SELECT MAX(exec_time) AS ultima FROM dbo.executions"ultima-----------------------2026-11-13 21:59:47.310 (1 rows affected)›sqlcmd -S srv-oms-dr01 -d oms -E -Q "SELECT MAX(exec_time) AS ultima FROM dbo.executions"ultima-----------------------2026-11-13 21:58:12.904 (1 rows affected)

La primera consulta se lanza justo antes de T0 y se guarda; la segunda, en el centro alternativo tras el arranque. Aquí la diferencia es de 1 min 35 s, dentro del objetivo de 5 min. Si no hubiera operaciones en ese intervalo, el RPO no se puede medir con esta tabla: genera operaciones de prueba antes de T0.

6. El ticket: "la plataforma arranca en DR pero los traders no ven precios"

Sábado, 08:40. La plataforma de órdenes está arriba en el centro alternativo y el negocio entra, pero las pantallas de precios están vacías.

1. La plataforma está conectada a su base de datos y responde: el problema está en la entrada de datos de mercado.
2. El proveedor confirma que su feed está activo, pero que solo acepta conexiones desde las IP del centro principal. El cambio de IP del centro alternativo nunca se le pidió.
3. Durante la prueba: el proveedor da de alta la IP por su línea de guardia (por eso se le avisó antes) y a las 09:25 hay precios. En el informe, datos de mercado figura con la hora real en que hubo precios y como fuera de objetivo, no como "en objetivo, con un incidente".
4. En el registro: incidencia, causa (dependencia de proveedor no documentada en el plan), impacto en el RTO y acción con dueño y fecha: que la IP del centro alternativo quede autorizada de forma permanente y se pruebe cada trimestre.

7. Aceptación, informe y remediación

• Aceptación del negocio: cada probador firma qué ha probado y con qué resultado. Sin esa firma, el servicio no se da por recuperado.
• El informe, en pocos días: alcance, escenario, horas reales, RTO y RPO medidos contra objetivo, incidencias, desviaciones del plan, aceptación y acciones.
• Las acciones van a la herramienta de seguimiento con dueño y fecha, y se revisan en el comité correspondiente hasta cerrarse. La siguiente prueba empieza comprobando que las de la anterior están hechas.
• Actualiza los planes con lo aprendido: un paso que nadie supo hacer es un paso mal escrito.

Siguientes pasos

• La guía de Backup y DR/BCP del Nivel 4 cubre el diseño de copias, réplicas y planes de recuperación.
• La guía de ISO 27001/NIS2/RGPD en IT sitúa la continuidad dentro del marco de cumplimiento.
• La de Veeam Backup cubre la restauración de máquinas y la verificación de copias.
• La de PostgreSQL/MySQL/SQL Server ayuda con la réplica y la comprobación de las bases de datos.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.