ES 
PT 
EN 
El plan está escrito. Fue aprobado, firmado y archivado en una carpeta compartida. Alguien pregunta cuándo se va a probar.
La respuesta es siempre la misma: no podemos detener la operación.
Así el plan queda ahí, intacto, dos o tres años. Hasta el día en que se ejecuta por primera vez, sin ensayo, con la operación realmente caída y el reloj corriendo.
Suena a pregunta razonable, pero parte de un error de definición. La mayor parte de lo que valida un plan de continuidad no es una prueba, y nunca toca producción.
“Probar” y “ejercitar” no son lo mismo
El NIST SP 800-84, publicada en septiembre de 2006 y escrita exactamente para este problema, separa tres actividades que suelen confundirse en una sola.
Prueba es una herramienta de evaluación que usa métricas cuantificables para validar si un sistema o componente funciona en el entorno que describe el plan. Cortar la energía de un equipo es una prueba. También lo es medir si el árbol de llamadas alcanza a todos dentro del plazo.
Capacitación es decirle a cada persona cuál es su papel en el plan.
Ejercicio es una emergencia simulada, hecha para descubrir si una o más partes del plan se sostienen.
El documento es claro sobre el límite: “prueba” queda reservado para sistemas y componentes, y no se usa para el ejercicio de planes.
Eso importa más de lo que parece. Cuando la dirección pregunta si el plan fue probado y TI responde que no se puede detener la operación, cada parte responde a una pregunta distinta. Una es sobre el plan. La otra es sobre el sistema.
El ejercicio de mesa nunca toca producción
Lo que el NIST llama tabletop funciona enteramente con discusión. Las personas que tienen un papel en el plan se sientan juntas, un facilitador presenta un escenario y hace preguntas, y el grupo responde como respondería en una crisis real.
La guía deja explícito lo que importa aquí: el ejercicio de mesa no moviliza equipamiento ni otros recursos.
Nada se apaga. Ningún servicio sale del aire. Y aun así el ejercicio encuentra lo que el documento esconde, porque obliga al plan a responder preguntas que nadie hizo al escribirlo:
- quién declara el desastre, y con qué evidencia
- a quién tiene que contactar esa persona, y por qué canal, si el sistema de tickets está caído
- dónde vive el plan, y si alguien puede llegar a él cuando el servidor de archivos es justamente el que falló
- quién decide por el negocio cuando el responsable del proceso está en un avión
- qué se le dice al cliente, y qué tan rápido
Son preguntas sobre cómo está organizada la empresa, no sobre tecnología. Y casi todas fallan la primera vez que alguien las hace en voz alta.
El ejercicio funcional corre en un entorno simulado
Un paso más arriba está lo que el NIST llama ejercicio funcional. Aquí las personas cumplen el papel que tendrían en una emergencia real, pero dentro de un entorno operativo simulado.
La escala la define usted. Puede cubrir una parte del plan, como la notificación de emergencia o la configuración de un solo equipo, o puede recorrer de punta a punta todos los elementos.
Aquí viven las verificaciones prácticas, las que dan trabajo pero no exigen caída: restaurar un backup en un entorno aislado y abrir la aplicación para confirmar que levanta, poner la réplica en línea en una red separada, confirmar que la licencia del software existe fuera del servidor original, cronometrar cuánto necesita realmente el equipo para un procedimiento que en el papel son tres líneas.
Tener backup y poder restaurarlo son dos afirmaciones distintas. La segunda solo se prueba cuando alguien restaura.
Lo que sí exige una caída real, y cómo achicar la ventana
Sería deshonesto decir que nada exige indisponibilidad.
Un failover real, donde la operación pasa al entorno de contingencia y vuelve, prueba cosas que ninguna simulación prueba: si el DNS propaga a tiempo, si las integraciones con terceros apuntan a la nueva dirección, si el entorno secundario aguanta la carga real en lugar de la estimada.
Lo que se negocia no es si habrá caída, sino de qué tamaño:
- un sistema por vez, en lugar del entorno entero, empezando por el que menos duele
- una ventana acordada, en un período de baja actividad, con la vuelta planificada antes de empezar
- un criterio de aborto definido, el punto en el que el ejercicio se detiene y la operación vuelve a la normalidad, acordado por escrito antes de empezar
- un failback ensayado, porque la vuelta suele ser la parte menos documentada y la que más sorprende
Dos horas de caída agendadas cuestan menos que dos días de caída que nadie agendó.
La norma pide un programa, no un evento
La ABNT NBR ISO 22301:2020, edición brasileña de la norma de gestión de continuidad de negocio, trata el tema en la cláusula 8.5, el programa de ejercicios.
El texto exige que la organización implemente y mantenga un programa de ejercicios y pruebas que valide, a lo largo del tiempo, qué tan bien funcionan sus estrategias y soluciones de continuidad. Los ejercicios deben ser coherentes con los objetivos de continuidad y, tomados en conjunto a lo largo del tiempo, deben validar las estrategias adoptadas.
Dos palabras cargan el peso de esa frase.
La primera es programa. La norma no pide un evento anual. Pide una secuencia de ejercicios que, sumados, cubran lo que hay que validar.
La segunda es a lo largo del tiempo. La norma no fija periodicidad. La organización decide, a partir de sus propios objetivos de continuidad y de la velocidad con que cambia su entorno.
Eso deja espacio para el diseño que funciona en la práctica: ejercicios de mesa más frecuentes y baratos, ejercicios funcionales en intervalos más amplios, y el failover completo en los sistemas donde el riesgo justifica la ventana.
Para instituciones financieras reguladas, no es opcional
En parte del mercado brasileño, probar la continuidad dejó de ser buena práctica y pasó a ser obligación legal.
A Resolución CMN 4.893, del 26 de febrero de 2021, que rige la política de seguridad cibernética de las instituciones autorizadas por el banco central de Brasil, exige en el artículo 3 que la política establezca cómo se construyen los escenarios de incidente usados en las pruebas de continuidad.
La misma resolución exige que el plan de respuesta a incidentes registre los resultados de esas pruebas, considerando escenarios de indisponibilidad causada por incidentes. Fue modificada por la Resolución CMN 5.274, del 18 de diciembre de 2025.
Para instituciones de pago, la regla equivalente es la Resolución BCB 85, del 8 de abril de 2021.
En la práctica, para quien está bajo esa regulación, el escenario de la prueba debe estar definido en política y el resultado debe existir como documento. Un plan que nunca fue ejercitado no produce ese documento.
Lo que el ejercicio encuentra y el documento nunca encuentra
Los planes de continuidad fallan en lugares predecibles, y por eso mismo el ejercicio funciona.
El NIST señala que los ejercicios ayudan a sacar a la luz lagunas e inconsistencias en los planes y procedimientos, y muestran dónde las personas necesitan más entrenamiento.
En la práctica, las fallas están en las juntas:
- el procedimiento asume que dos tareas corren en paralelo, y en la ejecución corren una tras otra, lo que revienta el RTO sin que nada haya salido mal
- la persona responsable de un paso dejó la empresa, y el plan sigue con su nombre
- la credencial que se necesita está guardada en el sistema que el escenario acaba de tumbar
- el tiempo de restauración se estimó con el volumen de datos de hace tres años
- el proveedor al que el plan recurre tiene un SLA de respuesta mayor que el RTO prometido al negocio
Ninguna de estas aparece en la revisión del documento, porque el documento es coherente consigo mismo. Aparecen cuando alguien intenta ejecutarlo.
Si el RTO y el RPO de su plan no pasaron por este tipo de verificación, el método para definirlos es el paso anterior a este.
Cómo conduce Integrity-UX este trabajo
El trabajo empieza por el escenario, no por el entorno. Definimos qué se va a ejercitar, quién participa y qué pregunta debe responder el ejercicio, y eso queda acordado antes de agendar nada.
El primer formato es el ejercicio de mesa, con las áreas de negocio que tienen un papel en el plan. Lo que sale de ahí es la lista de lo que nadie supo responder, y casi siempre es sobre decisiones y comunicación, no sobre tecnología.
Después viene el ejercicio funcional, en un entorno aislado: una restauración con la aplicación abierta, tiempos medidos contra el RTO y el RPO definidos, y una verificación de las dependencias que el papel asume y la ejecución desmiente. El failover completo va donde la criticidad justifica la ventana, con el criterio de aborto y el failback acordados por escrito antes de empezar.
Cada ronda termina en un registro: el escenario usado, quiénes participaron, los tiempos alcanzados frente a los objetivos, las fallas encontradas y los ajustes hechos en el plan. Ese registro es lo que la ABNT NBR ISO 22301 espera de un programa de ejercicios, y lo que el banco central de Brasil exige a las instituciones que regula.
Somos Microsoft Partner y trabajamos tanto sobre el entorno que el cliente ya tiene, sea nube pública, data center propio o híbrido, como sobre Azure cuando esa es la elección. Se puede contratar junto con la construcción del plan de continuidad y DRP o aplicarse sobre un plan que ya existe.
Próximos pasos
Si su plan está escrito y nunca fue ejercitado, hay una verificación que no necesita agenda ni ventana. Tome el procedimiento de recuperación de un sistema e intente responder tres preguntas: quién declara el desastre, dónde se puede alcanzar el plan si el servidor de archivos es el que falló, y si la persona nombrada en cada paso sigue trabajando ahí.
Si esas tres respuestas no llegan, el ejercicio de mesa es el próximo paso, y cabe en dos horas.
Para la capa anterior, de donde salen los números que el ejercicio va a cobrar, el artículo sobre cómo definir RTO y RPO cubre el método. Para la estructura del documento en sí, el artículo sobre DRP cubre lo que entra en el plan.
Si prefiere conversar sobre su caso, la página de plan de continuidad y DRP tiene el contacto directo.
Preguntas frecuentes
¿Probar el plan de continuidad exige detener la operación?
En la mayoría de los casos, no. El NIST SP 800-84 reserva la palabra prueba para sistemas y componentes, y usa ejercicio para los planes. El ejercicio de mesa funciona solo con discusión y no moviliza equipamiento. El ejercicio funcional corre en un entorno simulado. Solo el failover completo necesita una caída real, y aun así puede hacerse por sistema, en una ventana acordada.
¿Con qué frecuencia debe ejercitarse el plan?
La ABNT NBR ISO 22301:2020 no fija periodicidad. La cláusula 8.5 exige un programa de ejercicios y pruebas que valide las estrategias de continuidad a lo largo del tiempo. La frecuencia sale de los objetivos de continuidad de la propia empresa y de la velocidad con que cambia su entorno. Un entorno que cambia mucho pide un ciclo más corto.
¿Cuál es la diferencia entre ejercicio de mesa y ejercicio funcional?
El ejercicio de mesa es una discusión conducida por un facilitador sobre un escenario, sin movilizar equipamiento. Valida decisiones, roles y comunicación. El ejercicio funcional pone a las personas a cumplir sus roles en un entorno operativo simulado, y valida procedimiento, restauración y tiempo.
¿Qué debe quedar registrado después de un ejercicio?
El escenario usado, quiénes participaron, los tiempos alcanzados frente a los objetivos definidos, las fallas encontradas y los ajustes hechos en el plan. Para instituciones autorizadas por el banco central de Brasil, la Resolución CMN 4.893/2021 exige que los resultados de las pruebas de continuidad consten en el plan de respuesta a incidentes.
¿Restaurar un backup cuenta como prueba de continuidad?
Cuenta como una parte. La restauración prueba que la copia existe y que el dato vuelve. No dice nada sobre cuánto tarda el negocio en volver, si la aplicación levanta en el entorno alternativo, si las integraciones apuntan al lugar correcto, o si las personas saben qué hacer. Eso exige un ejercicio, no solo una restauración.
