La mayoría de las organizaciones en México tiene alguna forma de respaldo o plan de recuperación. Pocas tienen un programa de continuidad de negocio que funcione cuando realmente se necesita. La diferencia entre los dos no es tecnológica — es metodológica: un BCP sin análisis de impacto documentado, sin objetivos de recuperación definidos por el negocio y sin pruebas periódicas es un documento que da falsa seguridad.
Este artículo explica la diferencia real entre BCP y DR, cómo se calculan RTO y RPO, qué es un tabletop exercise y por qué importa, y cómo ISO 22301 convierte la continuidad en un sistema de gestión auditable en lugar de un proyecto puntual.
BCP vs DR: no son lo mismo y confundirlos tiene consecuencias
El error más frecuente en programas de continuidad es tratar BCP y DR como sinónimos. Son conceptos complementarios pero con alcances distintos. Entender la diferencia determina qué se necesita implementar y en qué orden.
Business Continuity Plan (BCP)
El BCP cubre cómo la organización continúa operando durante y después de una disrupción. Su alcance es el negocio completo: personas, procesos, instalaciones, comunicaciones, proveedores y tecnología.
Responde preguntas como: ¿qué procesos son críticos y cuánto tiempo pueden estar caídos? ¿Quién toma decisiones si los responsables habituales no están disponibles? ¿Dónde trabaja el equipo si las instalaciones principales no son accesibles? ¿Cómo se comunica con clientes y proveedores durante el incidente?
Marco de referencia: ISO 22301 — Sistemas de Gestión de Continuidad de Negocio.
Disaster Recovery Plan (DR)
El DR cubre cómo se recuperan los sistemas de TI y datos después de un incidente que los afecta. Es un subconjunto técnico del BCP, enfocado en infraestructura, aplicaciones, bases de datos y redes.
Responde preguntas como: ¿en cuánto tiempo se recupera cada sistema crítico? ¿Cuántos datos se pueden perder sin impacto inaceptable para el negocio? ¿Cuál es el orden de recuperación de sistemas cuando no todos se pueden restaurar a la vez? ¿Dónde está el sitio alterno y cómo se activa?
El DR sin BCP es técnicamente posible pero incompleto: recuperas los sistemas pero no sabes cómo opera el negocio mientras tanto.
Una organización puede tener un DR robusto — backups automatizados, sitio de recuperación, procedimientos de failover — y carecer de un BCP. El resultado es que cuando ocurre un ransomware o una caída de datacenter, TI sabe qué hacer con los sistemas pero nadie sabe cómo gestionar las operaciones del negocio durante las horas o días que tarda la recuperación. Ese vacío tiene un costo directo en contratos, clientes y reputación.
RTO y RPO: los dos parámetros que definen qué tecnología de recuperación necesita
RTO y RPO son los indicadores que conectan las necesidades del negocio con las decisiones tecnológicas de recuperación. Se definen primero desde el negocio — no desde TI — y luego determinan qué arquitectura, qué herramientas y qué inversión son necesarias para cumplirlos.
RTO — Recovery Time Objective
El tiempo máximo aceptable que un proceso o sistema puede estar no disponible antes de que el impacto para el negocio sea inaceptable. Es una decisión de negocio, no de TI: el área responsable del proceso define cuánto tiempo puede tolerar la interrupción.
Ejemplo: El sistema de procesamiento de pagos tiene un RTO de 2 horas. El portal de autoservicio al cliente tiene un RTO de 24 horas. El sistema de archivo histórico tiene un RTO de 72 horas. Cada uno requiere una arquitectura de recuperación diferente.
Error frecuente: Definir el mismo RTO para todos los sistemas. Esto sobredimensiona la infraestructura de recuperación para sistemas no críticos e infla el costo total del programa.
RPO — Recovery Point Objective
La cantidad máxima de datos que la organización puede perder sin impacto inaceptable, expresada en tiempo. Define con qué frecuencia deben tomarse respaldos y qué tecnología de replicación es necesaria.
Ejemplo: Un sistema de transacciones financieras tiene un RPO de 0 horas (cero pérdida de datos, requiere replicación síncrona). Un sistema de gestión documental tiene un RPO de 4 horas (requiere backups cada 4 horas). Un sistema de reportes tiene un RPO de 24 horas (backup diario es suficiente).
Error frecuente: Asumir que el RPO es igual a la frecuencia del backup. Si el backup tarda 6 horas en ejecutarse y ocurre un fallo a mitad del proceso, el RPO real puede ser mayor que el esperado.
Cómo se definen RTO y RPO en la práctica
La herramienta para definir RTO y RPO es el Análisis de Impacto al Negocio (BIA). El BIA identifica los procesos críticos de la organización, cuantifica el impacto de su interrupción en función del tiempo (financiero, operativo, regulatorio, reputacional) y establece los umbrales de tolerancia que determinan RTO y RPO para cada proceso.
| Proceso de negocio | Impacto por hora de interrupción | RTO definido | RPO definido | Implicación técnica |
|---|---|---|---|---|
| Procesamiento de pagos | Alto — pérdida directa de ingresos + penalidades contractuales | 2 horas | 0 horas | Replicación síncrona, failover automático, sitio activo-activo |
| Plataforma de ventas / e-commerce | Alto — pérdida de ventas e impacto en reputación | 4 horas | 1 hora | Replicación asíncrona, failover semi-automático, cloud activo-pasivo |
| ERP / sistemas de gestión interna | Medio — operaciones internas se degradan pero no se detienen | 24 horas | 4 horas | Backups frecuentes, procedimientos manuales de contingencia documentados |
| Email corporativo | Medio — comunicación reducida, workarounds disponibles | 8 horas | 4 horas | Servicio cloud con redundancia del proveedor, backup de buzones |
| Sistemas de archivo histórico | Bajo — impacto diferido, no inmediato | 72 horas | 24 horas | Backup diario, restauración desde almacenamiento frío |
El BIA transforma la conversación de “necesitamos buenos backups” a “necesitamos cumplir estos objetivos de negocio con esta inversión tecnológica”. Sin BIA, el programa de DR se diseña según las preferencias del equipo de TI en lugar de según las prioridades del negocio.
ISO 22301: el estándar que convierte el BCP en un sistema de gestión
ISO 22301 es el estándar internacional para Sistemas de Gestión de Continuidad de Negocio (SGCN). Define los requisitos para planificar, establecer, implementar, operar, monitorear, revisar, mantener y mejorar un programa de continuidad — usando la misma estructura de cláusulas que ISO 27001, lo que facilita la integración de ambos sistemas de gestión.
Por qué ISO 22301 y no solo un plan documentado
Un plan de continuidad documentado es un punto de partida. ISO 22301 exige que ese plan sea probado, revisado periódicamente, aprobado por la dirección y mejorado con base en los resultados de las pruebas y los incidentes reales. Sin ese ciclo, el plan se desactualiza y no funciona cuando se necesita.
Conexión con ISO 27001:2022
Los controles 5.29 (Seguridad de la información durante una disrupción) y 5.30 (Preparación de TIC para continuidad) de ISO 27001:2022 exigen exactamente lo que ISO 22301 cubre en profundidad. Una organización certificada en ISO 22301 satisface automáticamente esos dos controles del Anexo A de ISO 27001.
Relevancia regulatoria en México
CNBV, Banxico y contratos con gobierno federal exigen cada vez más evidencia de planes de continuidad probados. ISO 22301 proporciona la estructura y el lenguaje que los reguladores y auditores externos reconocen y aceptan como demostración de madurez en gestión de continuidad.
Las fases del SGCN bajo ISO 22301
Análisis del contexto y alcance
Identificación de las partes interesadas, requisitos legales y contractuales de continuidad, y definición del alcance del SGCN: qué procesos, unidades de negocio y ubicaciones están incluidos. El alcance puede ser toda la organización o un subconjunto crítico.
Análisis de Impacto al Negocio (BIA)
Identificación de procesos críticos, cuantificación del impacto de su interrupción en función del tiempo y definición de RTO y RPO para cada proceso. El BIA es el insumo principal para el diseño del plan de recuperación.
Evaluación de riesgos de continuidad
Identificación de amenazas que pueden interrumpir los procesos críticos: desastres naturales, fallas de infraestructura, ciberataques, pandemias, fallas de proveedores clave. Evaluación de probabilidad e impacto para priorizar los escenarios de planificación.
Diseño de estrategias y planes
Definición de estrategias de recuperación para cada proceso crítico y elaboración de los planes: BCP general, planes por área de negocio, Plan de Recuperación de Desastres (DR), Plan de Gestión de Crisis y Plan de Comunicación en Emergencias.
Implementación de controles y recursos
Configuración de la arquitectura de recuperación técnica (backups, replicación, sitio alterno), capacitación del personal con roles en los planes, acuerdos con proveedores alternativos y establecimiento de las comunicaciones de crisis.
Pruebas, mantenimiento y mejora continua
Ejecución periódica de ejercicios de prueba (tabletop, simulacros, pruebas técnicas), revisión de los planes con base en resultados de pruebas e incidentes reales, y auditorías internas del SGCN. ISO 22301 requiere evidencia documentada de este ciclo.
Tabletop exercises: la prueba más efectiva que pocas organizaciones hacen bien
Un tabletop exercise es una discusión estructurada donde el equipo de liderazgo y los responsables de proceso analizan cómo responderían ante un escenario de disrupción específico, sin interrumpir las operaciones reales. Es la prueba más accesible, más efectiva para identificar brechas organizacionales y la que más se subestima.
Qué es y qué no es un tabletop
Lo que sí es
- Una sesión facilitada de 2 a 4 horas con los responsables de decisión
- Un escenario específico (ransomware, caída de datacenter, falla de proveedor crítico, incidente físico)
- Preguntas estructuradas que revelan si los planes están claros, si los roles están asignados y si las comunicaciones funcionan
- Un reporte de hallazgos con brechas identificadas y plan de remediación
- Evidencia auditable para ISO 22301 e ISO 27001 controles 5.29–5.30
Lo que no es
- Una prueba técnica de recuperación de sistemas (eso es una prueba de DR)
- Un simulacro con interrupción real de operaciones
- Una revisión de documentación (el tabletop prueba personas y decisiones, no papeles)
- Un ejercicio que se puede hacer sin preparación previa
- Algo que se hace una vez y se archiva — debe ejecutarse al menos anualmente
Escenarios de tabletop más utilizados en México
Ransomware con cifrado masivo
El escenario más relevante en 2025-2026. El ejercicio revela si el equipo sabe cuándo y cómo aislar sistemas, quién autoriza el apagado de infraestructura, si se paga o no el rescate y cómo se comunica con clientes durante la interrupción.
Brechas más frecuentes: falta de árbol de decisión para escalamiento, ausencia de criterio documentado sobre pago de rescate, comunicación externa no coordinada.
Caída de proveedor crítico de nube
Con la adopción de Azure y AWS en México, la dependencia en un solo proveedor cloud es un riesgo real. El ejercicio revela si existe plan de contingencia para servicios críticos alojados en cloud y si el equipo sabe cómo activarlo.
Brechas más frecuentes: ausencia de arquitectura multi-región o multi-cloud, procedimientos de contingencia no probados, SLAs de proveedor no revisados.
Indisponibilidad de instalaciones
Incendio, inundación, corte prolongado de energía o acceso restringido al edificio. El ejercicio revela si el personal puede trabajar de forma distribuida, si los accesos remotos a sistemas críticos funcionan y si hay coordinación con RR.HH. y seguridad física.
Brechas más frecuentes: credenciales de acceso remoto sin MFA, equipos críticos sin posibilidad de trabajo remoto, ausencia de árbol de comunicación de emergencia.
Tipos de pruebas de continuidad: de menor a mayor complejidad
| Tipo de prueba | Qué se prueba | Impacto operativo | Frecuencia recomendada |
|---|---|---|---|
| Revisión documental | Vigencia y consistencia de los planes | Ninguno | Semestral |
| Tabletop exercise | Decisiones, roles, comunicación y brechas organizacionales | Ninguno (sesión de discusión) | Anual como mínimo |
| Prueba técnica de DR | Recuperación real de sistemas en entorno de prueba | Bajo (entorno separado) | Anual como mínimo |
| Simulacro parcial | Activación de parte del plan con equipos reales | Medio — puede afectar operaciones no críticas | Cada 2 años |
| Simulacro completo | Activación completa del BCP incluyendo sitio alterno | Alto — interrumpe operaciones reales temporalmente | Cada 2-3 años |
BCP y ransomware: el escenario que más expone los planes sin probar
El ransomware es hoy el escenario de disrupción más frecuente en México para empresas medianas y grandes. A diferencia de una falla de hardware o un desastre natural, el ransomware combina la pérdida de disponibilidad de sistemas con la presión de un actor adversario activo que tiene plazos, demandas y, frecuentemente, capacidad de filtrar información sensible.
Los BCP que no han sido probados contra este escenario específico tienden a colapsar en tres puntos críticos:
1. Decisión de contención vs. continuidad
Aislar los sistemas afectados detiene la propagación pero interrumpe operaciones. Seguir operando mientras se investiga arriesga cifrado adicional. Esta decisión requiere un árbol de autorización documentado — no puede tomarse en el momento por quien esté disponible.
2. Backups contaminados o no probados
Si el ransomware llevaba semanas en la red antes de activarse (dwell time promedio: más de 20 días), los backups recientes pueden estar comprometidos. El RTO real puede ser mucho mayor que el planificado si se debe ir a un punto de restauración antiguo para garantizar integridad.
3. Comunicación con clientes y reguladores
LFPDPPP exige notificación al INAI ante vulneraciones de datos personales. CNBV tiene requisitos de reporte de incidentes para instituciones financieras. Sin un plan de comunicación de crisis preaprobado, la respuesta se improvisa y el riesgo reputacional y regulatorio se amplifica.
Operación de seguridad 24/7
Detección temprana como primer componente de continuidad
Un plan de continuidad frente a ransomware empieza antes del incidente: detección temprana con MTTD bajo, contención automatizada y evidencia operativa continua. El servicio MDR de QMA reduce el dwell time y proporciona el contexto forense que el plan de respuesta necesita.
Ver servicio MDR de QMAMétricas de madurez de un programa BCP/DR
La madurez de un programa de continuidad no se mide por el grosor del documento — se mide por la capacidad real de la organización para recuperarse dentro de los objetivos definidos. Estas son las métricas que permiten evaluar el estado real del programa.
Métricas de diseño
- Cobertura de BIA: % de procesos críticos con RTO y RPO definidos y aprobados por el negocio.
- Completitud del plan: % de procesos críticos con procedimientos de contingencia documentados y vigentes.
- Asignación de roles: % de roles críticos en el plan con titular y suplente designados.
- Vigencia de planes: Antigüedad máxima de los planes — más de 12 meses sin revisión es señal de alerta.
Métricas de operación y prueba
- RTO real vs. objetivo: Tiempo medido de recuperación en la última prueba técnica de DR vs. el RTO definido.
- RPO real vs. objetivo: Pérdida de datos medida en la última prueba vs. el RPO definido.
- Frecuencia de pruebas: Meses desde el último tabletop y desde la última prueba técnica de DR.
- Brechas cerradas: % de hallazgos de pruebas anteriores con acción correctiva implementada.
- Tiempo de activación del plan: Cuánto tarda el equipo en activar el BCP desde que se declara el incidente.
Preguntas frecuentes sobre BCP, DR, RTO y RPO
¿Cuál es la diferencia entre RTO y MTTR?
El RTO es el objetivo definido por el negocio: el tiempo máximo aceptable de interrupción. El MTTR (Mean Time to Recovery) es el tiempo promedio real que tarda la organización en recuperarse, medido en incidentes o pruebas. El MTTR debe ser consistentemente menor que el RTO. Si el MTTR histórico supera el RTO definido, el plan de recuperación no es realista y necesita revisión.
¿ISO 22301 y ISO 27001 se pueden implementar juntos?
Sí, y es la combinación recomendada. Ambas normas usan la misma estructura de cláusulas (High Level Structure) de ISO, lo que permite integrar los sistemas de gestión. Los controles 5.29 y 5.30 de ISO 27001:2022 son los puntos de intersección formales: una organización certificada en ISO 22301 los satisface automáticamente con evidencia de su SGCN. La integración reduce el trabajo duplicado en auditorías internas, revisiones por la dirección y gestión de documentación.
¿Con qué frecuencia deben probarse los planes de continuidad?
ISO 22301 exige que los planes sean probados periódicamente sin especificar frecuencia mínima. La práctica estándar es: tabletop exercise anual, prueba técnica de DR anual y revisión documental semestral. Para organizaciones en sectores regulados (financiero, salud, gobierno), los reguladores pueden exigir frecuencias específicas. En cualquier caso, un plan que no se prueba en más de 12 meses no puede considerarse vigente.
¿Qué es un sitio de recuperación y qué tipos existen?
Un sitio de recuperación es una ubicación alternativa donde se pueden operar los sistemas críticos si el sitio principal no está disponible. Los tipos principales son: sitio frío (infraestructura disponible pero sin datos ni sistemas activos — tiempo de activación de días a semanas), sitio tibio (infraestructura lista con datos actualizados periódicamente — activación en horas), y sitio caliente (réplica activa del sitio principal — activación en minutos). Con cloud, el concepto de sitio caliente se ha transformado en arquitecturas activo-activo multi-región que eliminan la necesidad de un sitio físico alterno.
¿Qué debe incluir un Plan de Comunicación de Crisis?
Un Plan de Comunicación de Crisis debe definir: árbol de notificación interna (quién avisa a quién y en qué orden), portavoces autorizados para comunicaciones externas, mensajes preaprobados para distintos escenarios (interrupción de servicio, brecha de datos, incidente físico), canales de comunicación alternativos si los habituales no están disponibles, y requisitos de notificación regulatoria (INAI, CNBV, Banxico según aplique) con plazos documentados.
¿Cuánto tiempo tarda implementar ISO 22301?
Para una organización de tamaño mediano sin programa de continuidad previo, el proceso de implementación hasta certificación toma entre 6 y 10 meses. La fase más larga es el BIA (2 a 4 semanas por la necesidad de involucrar a los responsables de cada proceso crítico) y la implementación de controles técnicos de recuperación. Las organizaciones que ya tienen ISO 27001 reducen el tiempo porque el análisis de contexto, la gestión de documentos y las estructuras de auditoría interna ya existen.
Un programa de continuidad que funciona cuando se necesita
La diferencia entre un plan de continuidad que se archiva y uno que funciona bajo presión no es el documento — es el proceso que lo respalda: BIA realizado con los responsables reales del negocio, RTO y RPO validados técnicamente con pruebas, y tabletop exercises que revelan las brechas organizacionales antes de que lo haga un incidente real.
En QMA ejecutamos ese proceso con un equipo con experiencia en continuidad operativa, gestión de incidentes y cumplimiento regulatorio en México.
