Una empresa SaaS sin BCP es una empresa esperando su próximo incidente sin un plan. Un BCP sin testing es ficción. Esta guía describe cómo construir un Plan de Continuidad del Negocio y un Disaster Recovery Plan para una SaaS, con plantillas, métricas y un calendario de pruebas que sí se ejecuta.
Los tres conceptos esenciales: BIA, BCP y DRP
BIA — Business Impact Analysis
Es el análisis previo que identifica:
- Procesos críticos del negocio (los que, si paran, dañan el ingreso, la reputación o la operación).
- Impacto financiero y operacional de cada hora de interrupción.
- Dependencias técnicas y de personas para cada proceso.
- RTO y RPO objetivo por proceso.
Sin BIA, el BCP y el DRP se construyen sobre supuestos. Es la fase más importante y la que las empresas suelen saltarse.
BCP — Business Continuity Plan
El plan integral que cubre cómo la empresa sigue operando ante eventos disruptivos. Incluye:
- Estrategias de continuidad por proceso crítico.
- Roles y responsabilidades durante la crisis (Comité de Crisis, jefes de área).
- Planes de comunicación (interna, clientes, prensa, reguladores).
- Procedimientos para activar respuesta y para retornar a la normalidad.
- Recursos alternativos (personas, instalaciones, infraestructura).
DRP — Disaster Recovery Plan
La parte técnica del BCP, enfocada en recuperar infraestructura TIC tras un incidente. Incluye:
- Procedimientos de fail-over a infra secundaria.
- Procedimientos de restauración desde backups.
- Configuraciones de redundancia (multi-AZ, multi-region, multi-cloud).
- Runbooks paso a paso por escenario.
- Personal técnico de turno y escalamiento.
El BIA es el insumo. El BCP es el plan general. El DRP es la pieza técnica del BCP. Una empresa seria tiene los tres documentos vivos y probados.
Las métricas críticas: RTO y RPO
RTO — Recovery Time Objective
Tiempo máximo aceptable entre la ocurrencia del incidente y la restauración del servicio. Define qué tan rápido tu DRP debe operar.
RPO — Recovery Point Objective
Cantidad máxima aceptable de datos a perder, medida en tiempo. Si tu RPO es 15 minutos, necesitas backups o replicación continua que no esté más de 15 minutos atrasada.
| Tipo de servicio | RTO típico | RPO típico |
|---|---|---|
| Sitio web corporativo | 4–24 h | 4–24 h |
| SaaS B2B no transaccional | 2–4 h | 15–60 min |
| SaaS transaccional (fintech, e-commerce) | 15 min–2 h | 0–15 min |
| Sistemas de pago en tiempo real | < 15 min | 0 (cero pérdida) |
| Datos analíticos / BI | 24–48 h | 4–24 h |
Costo vs RTO: la curva exponencial
Reducir el RTO de 24 horas a 4 horas suele duplicar el costo de infraestructura. Reducirlo de 4 horas a 15 minutos puede multiplicarlo por 10. La pregunta no es "¿cuánto rápido podemos recuperar?", sino "¿cuánto rápido necesitamos recuperar para no perder dinero?".
Escenarios típicos de disrupción en SaaS
1. Caída del proveedor cloud principal
AWS, Azure o GCP tienen incidentes regionales más frecuentes de lo que la gente cree (1–3 por año por región). Si tu SaaS opera en una sola región, eres tan resiliente como tu proveedor.
- Mitigación: arquitectura multi-AZ obligatoria (incluida por defecto en la mayoría), multi-region para servicios con RTO < 4 h.
- Costo extra: 30–80 % sobre infraestructura monoregión.
2. Ransomware o compromiso interno
Un atacante con acceso a credenciales privilegiadas puede cifrar producción y backups si están en la misma cuenta cloud. Es el escenario más letal para SaaS modernas.
- Mitigación: backups inmutables, separación de cuentas (producción ≠ backups), MFA obligatorio, segmentación de red, monitoreo de actividad anómala.
3. Pérdida de personal clave (key person risk)
Especialmente crítico en SaaS pequeñas. Si la única persona que sabe cómo desplegar a producción renuncia o sufre un accidente, el RTO se vuelve indefinido.
- Mitigación: documentación de runbooks accesible, rotación de roles, no menos de dos personas con cada conocimiento crítico, IaC (Infrastructure as Code) para evitar configuración manual.
4. Brecha de datos personales
No es solo técnica: la Ley 21.719 obliga a notificar a la Agencia y a titulares. Sin un plan, el plazo se incumple.
- Mitigación: integrar el procedimiento de brechas (Ley 21.719) dentro del BCP.
5. Disrupción no técnica: huelga, pandemia, regulación
Eventos que no son ciberincidentes pero que afectan la operación. El BCP debe contemplar trabajo remoto extendido, proveedores alternativos y comunicación con clientes.
Cómo construir el BCP: metodología paso a paso
Paso 1 — Patrocinio y alcance (semanas 1–2)
- Sponsor ejecutivo (típicamente COO o CFO).
- Definición de unidades de negocio incluidas.
- Cronograma y presupuesto.
Paso 2 — BIA (semanas 3–5)
- Entrevistas con líderes de cada área.
- Identificación de procesos críticos.
- Estimación de impacto financiero y operacional por hora de interrupción.
- Mapeo de dependencias técnicas y humanas.
- Definición de RTO/RPO objetivo por proceso.
Entregable: reporte BIA con matriz de criticidad.
Paso 3 — Análisis de riesgos de continuidad (semanas 5–6)
- Identificación de amenazas relevantes (técnicas, físicas, humanas, regulatorias).
- Evaluación de probabilidad × impacto.
- Estrategias de tratamiento.
Paso 4 — Diseño del BCP (semanas 6–9)
- Estrategias por proceso crítico.
- Estructura del Comité de Crisis.
- Planes de comunicación.
- Procedimientos de activación y retorno.
Paso 5 — Diseño del DRP (semanas 7–10)
- Arquitectura técnica de recuperación.
- Runbooks por escenario.
- Configuración de redundancia y backups.
- Listas de contactos técnicos.
Paso 6 — Testing y aprobación (semanas 10–12)
- Tabletop con Comité de Crisis.
- Walkthrough técnico del DRP.
- Ajustes y aprobación final.
Estructura del documento BCP — plantilla recomendada
- Propósito, alcance y objetivos.
- Definiciones y referencias normativas (ISO 22301, ISO 27001).
- Política de continuidad del negocio.
- Resultados del BIA (resumen).
- Resultados del análisis de riesgos.
- Estructura del Comité de Crisis y roles.
- Criterios de activación del BCP.
- Estrategias de continuidad por proceso crítico.
- Plan de comunicación interna y externa.
- Procedimientos de gestión de crisis.
- Procedimientos de retorno a operación normal.
- Programa de mantenimiento y pruebas.
- Anexos: contactos, plantillas de comunicación, mapa de procesos.
Estructura del DRP — plantilla recomendada
- Propósito y alcance técnico.
- Inventario de activos críticos y sus RTO/RPO.
- Arquitectura técnica de recuperación (diagramas).
- Procedimientos de backup y restauración.
- Procedimientos de fail-over y fail-back.
- Runbooks por escenario.
- Lista de contactos técnicos y escalamiento.
- Plan de pruebas técnicas.
- Anexos: configuraciones, scripts, credenciales en bóveda segura.
Testing: el corazón del BCP/DRP
El plan no probado no existe. Tres niveles ascendentes de prueba:
Tabletop (anual mínimo)
Simulación en sala. El facilitador presenta un escenario; el Comité de Crisis discute decisiones, activación, comunicación. Sin tocar sistemas. Sirve para validar comprensión y descubrir lagunas documentales.
Walkthrough (semestral o anual)
Simulación técnica en ambiente aislado. El equipo TIC ejecuta los procedimientos del DRP en ambiente staging. No afecta producción. Verifica que los runbooks funcionan tal como están documentados.
Test funcional (anual o bianual)
Ejecución real con fail-over parcial controlado. Se prueba la restauración de un servicio en infra secundaria. Riesgo controlado, beneficio enorme: solo aquí se ve si los tiempos reales coinciden con los RTO/RPO declarados.
Integración con ISO 27001 y NCh-ISO 22301
El Anexo A 2022 de ISO 27001 contiene los controles relevantes:
- A.5.29 — Seguridad de la información durante una disrupción.
- A.5.30 — Preparación TIC para la continuidad del negocio.
- A.8.13 — Respaldo de información.
- A.8.14 — Redundancia de instalaciones de procesamiento.
NCh-ISO 22301:2019 es la norma chilena de Sistema de Gestión de Continuidad del Negocio. Es certificable independientemente y muchas empresas reguladas (bancos, isapres, OIVs) la integran con ISO 27001. La estructura común permite reutilizar política, comité, gestión de riesgos y auditorías internas.
Errores típicos en BCP/DRP de SaaS
- Plan en PDF estático que nadie lee. Debe estar disponible 24/7, idealmente en wiki interna accesible desde fuera de la VPN principal.
- Single Point of Failure humano. Un solo SRE que sabe cómo restaurar.
- Backups que no se restauran nunca. Backup que no se prueba no existe.
- RTO/RPO sin sustento BIA. Números aspiracionales sin análisis de impacto real.
- Falta de testing. El plan que se testea una vez al año descubre problemas graves; el que nunca se testea descubre los problemas en plena crisis.
- No incluir aspectos no técnicos. Comunicación a clientes, manejo de prensa, notificación a reguladores (Ley 21.719) suelen quedar fuera.
¿Necesitas implementar BCP y DRP en tu SaaS?
Confiden360 acompaña empresas SaaS chilenas en la construcción de BCP y DRP integrados con ISO 27001 y NCh-ISO 22301, con plantillas operativas, testing facilitado y mantenimiento anual.
Conversar sobre BCP/DRP → Ver servicio →Preguntas frecuentes
¿Cuál es la diferencia entre BCP, BIA y DRP?
BIA es el análisis previo que identifica procesos críticos e impacto. BCP es el plan integral que cubre cómo seguir operando. DRP es la parte técnica del BCP, enfocada en recuperar infraestructura TIC.
¿Qué son RTO y RPO?
RTO: tiempo máximo aceptable para restaurar un servicio. RPO: cantidad máxima aceptable de datos a perder, medida en tiempo. Por ejemplo: RTO=4h significa estar operativo en máximo 4 horas; RPO=15min significa no perder más de 15 minutos de datos.
¿ISO 27001 exige BCP y DRP?
Sí. El Anexo A 2022 incluye los controles A.5.29 (continuidad de la información), A.5.30 (preparación TIC), A.8.13 (respaldo) y A.8.14 (redundancia). En conjunto exigen tener BCP y DRP funcionales.
¿Cuál es la norma específica para continuidad?
ISO 22301:2019 (NCh-ISO 22301 en Chile) es la norma certificable de Sistema de Gestión de Continuidad del Negocio. Complementaria a ISO 27001.
¿Cómo testear un BCP/DRP sin afectar producción?
Tres niveles ascendentes: (1) Tabletop: simulación en sala. (2) Walkthrough: simulación técnica en ambiente aislado. (3) Test funcional: ejecución real con fail-over parcial controlado.
¿Qué tan común es activar el DRP en una SaaS?
Los DRPs completos se activan rara vez (1 vez cada 3–5 años). Las activaciones parciales ocurren con más frecuencia: 2–4 veces al año en operaciones reales.
¿Cuánto cuesta implementar BCP/DRP en una SaaS?
Para SaaS chilenas medianas: CLP 12–35 millones para implementación, sin contar inversión técnica en redundancia. El BIA inicial puede hacerse en 2–3 semanas con CLP 4–8 millones.
¿El DRP debe estar fuera de mi cloud principal?
Para escenarios serios sí: la replicación debe estar en una región distinta o en un proveedor distinto. Para SaaS con RTO < 4h, multi-region es práctica estándar.