Continuidad de Negocio y Recuperación de Desastres
Un incidente no avisa. Ransomware, caída de datacenter, falla de proveedor crítico, desastre físico. En cualquier escenario la pregunta no es si ocurrirá sino si su organización tiene la capacidad real de responder y recuperarse dentro de los tiempos que el negocio puede tolerar.
QMA estructura programas de BCP/DRP bajo el marco ISO 22301 con RTO y RPO definidos por el negocio, planes probados con tabletop exercises y arquitectura de recuperación validada técnicamente, no documentos que se archivan hasta el siguiente incidente.
Qué incluye el programa BCP/DRP de QMA
Un programa de continuidad efectivo cubre tres capas que deben funcionar juntas: la metodología de análisis y planificación, la arquitectura técnica de recuperación y el ciclo de prueba y mejora continua. Sin las tres, el programa tiene brechas que solo se descubren durante un incidente real.
Análisis de Impacto al Negocio (BIA)
Identificación de procesos críticos con los responsables reales de cada área. Cuantificación del impacto financiero, operativo y regulatorio de su interrupción en función del tiempo. Resultado: RTO y RPO definidos por el negocio, no por TI.
Evaluación de riesgos de continuidad
Identificación y priorización de amenazas que pueden interrumpir los procesos críticos: ciberataques, fallas de infraestructura, dependencia en proveedores críticos, desastres físicos y ambientales. Base para el diseño de estrategias de recuperación.
Diseño de planes BCP y DRP
Plan de Continuidad de Negocio con procedimientos por proceso crítico, árbol de decisiones de escalamiento y plan de comunicación de crisis. Plan de Recuperación de Desastres con secuencia de recuperación de sistemas, roles y tiempos objetivo.
Arquitectura de recuperación técnica
Diseño e implementación de la infraestructura: replicación de datos (síncrona o asíncrona según RPO), sitio de recuperación (frío, tibio, caliente o cloud multi-región), backup automatizado con pruebas de restauración periódicas.
Tabletop exercises y pruebas de DRP
Ejecución de ejercicios de continuidad: tabletop con el equipo directivo para validar decisiones y comunicación, y pruebas técnicas de DRP para medir RTO y RPO reales contra los objetivos definidos. Reporte de hallazgos y plan de remediación.
Alineación con ISO 22301 e ISO 27001
Implementación bajo el marco ISO 22301 (SGCN) con los documentos y evidencias que el estándar requiere. Integración con ISO 27001:2022 a través de los controles 5.29 y 5.30 del Anexo A, reduciendo el esfuerzo de certificación en ambas normas.
Qué es BCP, qué es DRP y en qué se diferencian
Los tres planes son complementarios. Un BCP sin DRP es un documento; un DRP sin BCP restaura sistemas sin saber cuáles importan primero.
| Concepto | Enfoque | Objetivo principal |
|---|---|---|
| BCP, Plan de Continuidad de Negocio | Negocio completo | Mantener funciones críticas durante una interrupción |
| DRP, Recuperación ante Desastres | TI e infraestructura | Restaurar sistemas y datos al estado operativo |
| IR, Respuesta a Incidentes | Seguridad | Contener y erradicar una amenaza activa |
La coordinación entre los tres se explica en detalle en Administración y Respuesta a Incidentes.
RTO y RPO: los parámetros que definen su arquitectura de recuperación
Cada decisión de arquitectura, desde el tipo de replicación hasta el sitio de recuperación y la frecuencia de los respaldos, debe derivarse de los RTO y RPO definidos para cada proceso crítico. Sin esa base, la inversión en infraestructura de recuperación puede estar sobredimensionada en sistemas no críticos y subdimensionada en los que realmente importan.
RTO: Recovery Time Objective
Tiempo máximo aceptable que un proceso puede estar interrumpido antes de que el impacto sea inaceptable para el negocio. Se define por área de negocio, no de forma homogénea para toda la organización.
Un RTO de 2 horas exige failover automático. Un RTO de 24 horas permite procedimientos manuales de contingencia. La diferencia en costo de infraestructura entre los dos es significativa.
RPO: Recovery Point Objective
Cantidad máxima de datos que la organización puede perder sin impacto inaceptable, expresada en tiempo. Determina la frecuencia de backups y el tipo de replicación necesario para cada sistema.
Un RPO de 0 horas exige replicación síncrona en tiempo real. Un RPO de 4 horas permite replicación asíncrona o backups frecuentes. Cada punto en el espectro tiene un costo y una complejidad diferentes.
Guía operativa
Cómo calcular RTO y RPO, qué es un tabletop y cómo estructurar su BCP
La guía completa de BCP/DRP cubre: diferencia entre BCP y DRP, cómo el BIA determina RTO y RPO, tipos de pruebas de continuidad, escenarios de tabletop más utilizados en México y métricas de madurez del programa.
Leer guía BCP/DRP completa →Del objetivo declarado al failover probado
Un RTO de dos horas no se sostiene con procedimientos manuales. Cuando el análisis de impacto arroja objetivos de recuperación agresivos para los procesos críticos, la única forma de cumplirlos es tener la infraestructura de recuperación levantada y probada antes del incidente.
QMA implementa esa capa con Acronis Cyber Protect Cloud, la plataforma que operamos como servicio gestionado. El sitio de recuperación se configura sin comprar hardware ni licencias adicionales, y los sistemas protegidos levantan como máquinas virtuales en la nube conservando su direccionamiento de red. El punto de recuperación desde el que se levanta el ambiente se verifica antes de activarlo: en un incidente de ransomware esa verificación es la diferencia entre recuperar y reinfectarse.
Especificaciones de la plataforma Acronis Cyber Protect Cloud. Los objetivos contractuales de cada cliente se fijan en el análisis de impacto y se validan en las pruebas periódicas.
Prioridad de recuperación: qué se levanta primero
El análisis de impacto no termina con un RTO por proceso. Termina con una secuencia. Sin ella, un incidente se convierte en una discusión sobre qué servidor arrancar mientras el reloj corre.
Esa secuencia se traduce en runbooks que ejecutan la recuperación en orden, con validaciones automáticas entre pasos que confirman que un sistema respondió antes de continuar con el siguiente. Un runbook puede invocar a otro, de modo que la recuperación de una organización con varias áreas se orquesta desde un solo procedimiento maestro sin perder el control por departamento.
ISO 22301: continuidad como sistema de gestión, no como proyecto puntual
ISO 22301 es el estándar internacional para Sistemas de Gestión de Continuidad de Negocio. Define los requisitos para que un programa de continuidad sea estructurado, probado, revisado por la dirección y mejorado continuamente, en lugar de ser un documento que se elabora una vez y se desactualiza.
Requisitos regulatorios en México
CNBV y Banxico exigen evidencia de planes de continuidad probados para instituciones del sector financiero. Contratos con gobierno federal incluyen cada vez más requisitos de continuidad operativa. ISO 22301 proporciona el marco que los reguladores y auditores externos reconocen.
Integración con ISO 27001:2022
Los controles 5.29 (Seguridad durante una disrupción) y 5.30 (Preparación de TIC para continuidad) del Anexo A de ISO 27001:2022 se satisfacen directamente con la implementación de ISO 22301. Para organizaciones que ya tienen o buscan ISO 27001, el esfuerzo incremental de ISO 22301 es significativamente menor.
Evidencia auditable continua
ISO 22301 exige no solo que los planes existan sino que se prueben y que los resultados de las pruebas se documenten con acciones correctivas. En QMA generamos esa evidencia como parte del programa, no como preparación para una auditoría.
Alineación regulatoria y normativa
La continuidad operativa no es opcional para organizaciones en sectores regulados en México. QMA documenta los controles de forma que sean auditables por terceros, reguladores y aseguradoras de ciberseguridad.
| Marco o regulación | Requisito de continuidad |
|---|---|
| ISO 27001:2022 | Cláusula 8.4 y controles 5.29 y 5.30 del Anexo A. Ver ISO 27001 |
| ISO 22301 | Estándar específico de continuidad de negocio, marco de referencia para el diseño del BCP |
| CNBV | Disposiciones de continuidad operativa para instituciones financieras, cuando aplican al sector |
| PCI DSS 4.0 | Requisito 12.3, plan de respuesta a incidentes con componentes de continuidad. Ver PCI DSS |
| LFPDPPP | Obligación de salvaguardar datos personales durante interrupciones operativas |
| Plan Nacional de Ciberseguridad | Continuidad y recuperación como capacidad exigible en la APF. Ver guía APF |
Cómo opera el programa BCP/DRP en QMA
1. Diagnóstico y BIA
Talleres con los responsables de cada área crítica para identificar procesos, cuantificar el impacto de su interrupción y definir RTO y RPO con el respaldo de la dirección. Sin este paso, todo lo demás es supuesto.
2. Diseño de planes y arquitectura
Elaboración de BCP, DRP, plan de gestión de crisis y plan de comunicación. Diseño de la arquitectura técnica de recuperación alineada con los RTO y RPO definidos, sin sobredimensionar ni subproteger.
3. Implementación y capacitación
Configuración de la infraestructura de recuperación, capacitación del equipo con roles en los planes y establecimiento de los procedimientos operativos. El plan existe en papel y en la memoria del equipo.
4. Pruebas, mejora y mantenimiento
Tabletop exercises anuales con el equipo directivo, pruebas técnicas de DRP con medición de RTO y RPO reales, y revisión periódica de planes para reflejar cambios en la organización, sistemas y amenazas.
Lo que recibe su organización
Cada entrega es un documento operativo firmado, no una presentación genérica. Los entregables son auditables por reguladores, aseguradoras de ciberseguridad y equipos de certificación ISO.
| Entregable | Detalle |
|---|---|
| Análisis de Impacto al Negocio | Matriz de RTO y RPO por proceso, validada con dirección y con TI |
| Plan de Continuidad | Procedimientos por escenario, árbol de notificación, roles y responsabilidades |
| Plan de Recuperación | Pasos técnicos de restauración y lista de verificación por sistema crítico |
| Arquitectura tecnológica de DRP | Diagramas de respaldo, failover y acceso remoto seguro |
| Reporte de prueba | Evidencia del tabletop o del failover ejecutado, brechas encontradas y plan de remediación |
| Revisión anual del plan | Actualización conforme cambia la infraestructura o la regulación aplicable |
La prueba que casi nadie ejecuta
El tabletop valida decisiones, comunicación y roles. Es indispensable y es la mitad del trabajo. La otra mitad es comprobar que la infraestructura responde, y ahí es donde la mayoría de los programas se queda corta, porque probar la recuperación suele implicar interrumpir la operación.
La prueba de failover se ejecuta en un ambiente aislado que no toca producción, y se puede programar para que corra sola con periodicidad mensual. El resultado no es una opinión sobre la capacidad de recuperación de la organización, es un registro con la fecha, el tiempo que tomó y el estado de cada sistema levantado. Esa es la evidencia que pide un auditor de ISO 22301 y la que pide una aseguradora cuando revisa una póliza de riesgo cibernético.
Cuando el resultado de la prueba se aleja del objetivo definido en el análisis de impacto, la brecha se corrige en la arquitectura, no en el documento.
Herramienta de dimensionamiento
Cuánto cuesta una hora de inactividad en su operación
La calculadora estima el costo de la interrupción con sus propios parámetros de nómina, ingreso y tiempo de recuperación, y contrasta ese número contra el de una arquitectura de recuperación gestionada. Tipo de cambio tomado del FIX de Banxico.
Abrir la calculadora de continuidad →Escenarios que el programa BCP/DRP cubre
Ransomware y ciberataques
El escenario más frecuente en México. El programa define cuándo aislar sistemas, quién autoriza el apagado de infraestructura, cómo operar durante la recuperación y qué notificar a reguladores (INAI, CNBV) y clientes.
Falla de infraestructura crítica
Caída de datacenter, falla de conectividad, pérdida de sistemas cloud. El plan define la secuencia de recuperación, el sitio alterno y los procedimientos manuales de contingencia mientras los sistemas se restablecen.
Falla de proveedor crítico
Interrupción de un proveedor SaaS, de servicios gestionados o de infraestructura cloud. El programa identifica dependencias críticas de proveedores y establece alternativas y tiempos de activación documentados.
Indisponibilidad de instalaciones
Incendio, inundación, corte de energía prolongado o acceso restringido. El plan garantiza que el equipo puede operar de forma distribuida y que los accesos remotos a sistemas críticos funcionan con los controles de seguridad activos.
Pérdida de personal clave
El BCP no es solo tecnología. Define suplentes para cada rol crítico en el plan de respuesta, árbol de comunicación de emergencia y procedimientos para que cualquier miembro del equipo pueda ejecutar las acciones críticas.
Crisis con impacto reputacional
Incidentes con exposición en medios, brecha de datos con impacto en clientes o interrupción de servicio con afectación pública. El plan de comunicación de crisis define portavoces, mensajes preaprobados y canales de notificación.
Operación de seguridad 24/7
La continuidad empieza con detección temprana
El tiempo entre el inicio de un incidente y su detección (dwell time) determina el alcance del daño y el tiempo de recuperación real. El servicio MDR de QMA reduce ese tiempo con monitoreo continuo, contención automatizada y el contexto forense que el plan de respuesta necesita para activarse correctamente.
Ver servicio MDR →Cuando la operación está distribuida
Una organización con sucursales, plantas o sitios remotos no tiene un único punto de falla sino varios, y cada uno con su propia conectividad. La red del sitio de recuperación se conecta de tres maneras según el caso, y la decisión no es técnica en primera instancia: sale del alcance que el plan de continuidad definió como crítico.
Solo nube
El ambiente de recuperación vive como una red independiente, sin equipo adicional en sitio. Es el arreglo más simple y aplica a operaciones concentradas en una sola ubicación.
Sitio a sitio
Extiende la red local hacia la nube conservando el mismo esquema de direccionamiento, de modo que el failover no obliga a reconfigurar aplicaciones. Admite hasta 23 redes.
Multisitio cifrado
Conecta varias ubicaciones físicas a la nube mediante túneles sobre los firewalls que la organización ya tiene. Es el arreglo para operaciones con sucursales o con terceros que también deben quedar cubiertos.
Tecnologías que respaldan el plan
El programa se implementa con tecnología validada, y cada plataforma está operada por nuestros especialistas, no solo recomendada. Puede ver el ecosistema completo en socios estratégicos.
Respaldo y recuperación con Acronis
Protección de servidores físicos, máquinas virtuales, endpoints y cargas en nube, con recuperación probada y failover a un punto verificado como limpio. Es la capa que ejecuta los objetivos definidos en el análisis de impacto.
Continuidad de red con iboss
Cuando la red corporativa falla, el acceso seguro de los usuarios remotos se mantiene sin depender de la VPN tradicional, con inspección en la nube y sin retorno de tráfico al sitio central.
Sitio alterno en Microsoft Azure
Replicación de cargas críticas hacia un ambiente alterno con automatización del failover y pruebas programadas, para organizaciones que ya operan sobre esa nube.
Integración con su programa de seguridad
El programa de continuidad no opera aislado. Se integra con los demás componentes para que los planes sean coherentes con la postura de riesgo real de la organización.
GRC e ISO 27001
Los controles 5.29 y 5.30 del Anexo A de la versión 2022 se mapean directamente a los entregables del programa, lo que reduce el esfuerzo en una auditoría de certificación o de renovación.
Respuesta a incidentes
El plan de respuesta define cómo se contiene la amenaza y el de continuidad define cómo opera la organización mientras tanto. Ambos deben estar coordinados y haberse probado juntos.
Monitoreo y detección
La detección temprana reduce el tiempo de activación del plan y, sobre todo, el alcance de lo que hay que recuperar después. Cada hora sin detectar es más superficie cifrada.
Zero Trust como base de resiliencia
Una arquitectura Zero Trust limita el radio de un incidente y con ello reduce los sistemas que el plan tiene que recuperar. Menor alcance del daño, recuperación más rápida.
Preguntas frecuentes sobre continuidad y recuperación
¿Qué es un Plan de Continuidad de Negocio?
Un BCP es el conjunto de procedimientos, recursos y responsabilidades que permiten a una organización mantener sus funciones críticas durante una interrupción o restaurarlas en el menor tiempo posible. Cubre comunicaciones de crisis, procedimientos técnicos de recuperación y roles de toma de decisiones bajo presión.
¿Cuál es la diferencia entre BCP y Plan de Recuperación ante Desastres?
El BCP abarca toda la organización, es decir personas, procesos, instalaciones y tecnología, y busca mantener operaciones durante la crisis. El DRP es un subcomponente técnico enfocado en restaurar sistemas de TI y datos al estado operativo. Ambos son necesarios y deben estar integrados.
¿Cuánto tiempo toma implementar un plan de continuidad?
Un proyecto completo, desde el Análisis de Impacto al Negocio hasta las primeras pruebas, toma entre 8 y 16 semanas dependiendo del tamaño de la organización y de la complejidad de la infraestructura.
¿ISO 22301 es obligatorio para empresas en México?
ISO 22301 no es de cumplimiento obligatorio por ley en México para la mayoría de los sectores, pero es el estándar de referencia internacional para continuidad. Para instituciones financieras, la CNBV sí establece requisitos específicos de continuidad operativa.
¿Qué métricas definen si el plan es suficientemente robusto?
Las dos métricas clave son el RTO, tiempo máximo para recuperar un sistema, y el RPO, máxima pérdida de datos tolerable. Se definen por proceso crítico en el análisis de impacto, y el plan debe demostrar en pruebas que se pueden cumplir.
¿Con qué frecuencia se debe probar un BCP?
ISO 22301 recomienda al menos una vez al año para ejercicios tabletop y pruebas técnicas de failover. Con una plataforma de recuperación gestionada la prueba de failover se puede automatizar con periodicidad mensual sin tocar producción. Cualquier cambio relevante en infraestructura, sistemas críticos o estructura organizacional debe disparar una revisión antes del ciclo anual.
¿El respaldo de datos es suficiente como plan de continuidad?
No. El respaldo resuelve la recuperación de datos, pero no indica en qué orden se restauran los sistemas, quién toma decisiones durante la crisis, cómo se comunica la organización con clientes y reguladores, ni cómo se opera manualmente mientras se recuperan los sistemas. El BCP responde todas esas preguntas.
¿Se puede integrar el plan con un programa ISO 27001 existente?
Sí. Los controles 5.29 y 5.30 del Anexo A de ISO 27001:2022 se mapean directamente a los entregables del plan. QMA integra la documentación de forma que el plan sea un insumo directo para auditorías de certificación o de renovación.
El siguiente paso: diagnóstico de su capacidad de recuperación actual
¿Cuánto tiempo tardaría su organización en recuperarse de un ransomware hoy? ¿Están sus RTO y RPO definidos y validados técnicamente? ¿Cuándo fue la última vez que se probó el plan?
En QMA comenzamos con un diagnóstico honesto del estado actual, sin asumir que lo que está documentado es lo que realmente funciona.