Operaciones y Administración → Continuidad de los procesos del negocio

Continuidad de procesos empresariales (BCP)

1) Qué es BCP y por qué lo necesita

BCP (Business Continuity Planning) es un enfoque sistémico para garantizar la sostenibilidad de los procesos del negocio en cualquier falla: desde el fallo del datacenter hasta la crisis del proveedor, la fuga de datos o el aumento repentino de la carga.
En los productos altamente cargados (iGaming, fintech, marketplace), no se trata solo de infraestructura: se trata de mantener la confianza, cumplir con las obligaciones regulatorias y proteger los ingresos.

• Mantener la disponibilidad de servicios y datos críticos.
• Minimizar el tiempo de recuperación (RTO) y la pérdida de datos (RPO).
• Garantizar que los equipos, las comunicaciones y los socios externos en una crisis funcionen.
• Estandarizar la respuesta y la formación del personal.

2) Componentes principales de BCP

1. BIA (Business Impact Analysis): evalúa el impacto de las fallas en los procesos y el negocio.
2. Los riesgos y escenarios son una matriz de amenazas (infraestructuras, externas, humanas).
3. Objetivos RTO/RPO - Valores objetivo de recuperación y pérdidas admisibles.
4. Plan de recuperación (DRP): pasos detallados para reiniciar sistemas y procesos.
5. Comunicaciones - canales internos y externos, plantillas de notificación.
6. Pruebas y revisiones - revisiones periódicas, ejercicios, post-análisis.
7. Documentación y control de versiones: acceso y actualización centralizados.

3) Análisis de impacto (BIA)

La BIA determina qué procesos son críticos y la rapidez con la que deben recuperarse.

1. Lista de todos los procesos de negocio (Pagos, Apuestas, Juegos, KYC, Soporte).

2. Definición de dependencias (servicios, datos, proveedores, empleados).

3. Evaluación del impacto de la renuncia: financiera, legal, reputacional, operativa.

4. Instalación de RTO/RPO para cada proceso.

5. Priorización: «Must Have», «Should Have», «Nice to Have».

4) Matriz de riesgo

5) RTO, RPO y niveles de criticidad

RTO (Recovery Time Objective): cuánto tiempo es permisible antes de la recuperación.
RPO (Recovery Point Objective): qué cantidad de datos se puede perder.

6) DRP (Disaster Recovery Plan)

Objetivo: garantizar una recuperación rápida y coherente de los sistemas.

1. Identificar escenarios (desastre de centro de datos, fallo de PSP, compromiso de clave, pérdida de red).

2. Para cada escenario, un playbook paso a paso listo.

3. Soporte de infraestructura de DR: clústeres de respaldo, réplicas de DB, CDN/edge.

4. Pruebe rutinariamente los procedimientos de RTO/RPO y failover.

5. Almacenar todas las instrucciones en un solo almacén con control de versiones.

Scenario: EU region falls
RTO: 30 min    RPO: 5 min
Actions:
1. Activate plan DR # EU
2. Switch DNS → AP Region
3. Verify database consistency (replication lag ≤ 60s)
4. Update Status on StatusPage
5. Perform API benchmarking

7) Organización de equipos y roles

Coordinador de BCP: propietario del programa, organiza revisiones y pruebas.
DR lead: responsable de la implementación técnica de los planes de DR.
Domain Owners: aseguran la continuidad de sus procesos (Pagos, Juegos, KYC).
Equipo de comunicaciones: responsable de las notificaciones internas/externas y las plataformas de estado.
HR/Admin: BCP para personal (remota, comunicaciones, accesos).
Cumplimiento legal: notificaciones regulatorias y medidas legales.

8) Comunicaciones en crisis

• Canales claros y contactos de respaldo.
• El primer apdate es a los 15 minutos del incidente.
• Tono único de las comunicaciones, los hechos y ETA.
• Actualizaciones cada N minutos antes del cierre del incidente.
• Después de la recuperación - informe y post mortem.

[HH: MM] PSP-X failed. Impact: Deposits in EU region.
Measures: feilover on PSP-Y. ETA stabilization: 30 min.
The next update is at 15:00.

9) Pruebas y ejercicios

Pruebas técnicas: failover, recuperación de DB, simulaciones DDoS.
Quirófanos: cambio de comandos handover/role.
Enseñanzas BCP completas: script «blackout» o inaccesibilidad del proveedor.

• Pruebas DR - trimestrales;
• BCP-ejercicio completo - 1-2 veces al año.
• Documentación: resultados, desviaciones de RTO/RPO, acciones de mejora.

10) Métricas y KPI

RTO compliance:% de los procesos recuperados ≤ el objetivo.
RPO compliance:% de los procesos sin pérdida de datos> destino.
DR test success rate: validación exitosa de los procedimientos de recuperación.
Cobertura BCP: proporción de procesos con planes actualizados (> 90%).
Comms SLA: primer resumen ≤ 15 min, actualizaciones sobre ETA.
Postmortem SLA: 100% de eventos críticos con análisis ≤ 72 h.

11) Documentación y gestión de los conocimientos

Almacenamiento único BCP (versiones, propietarios, fechas de revisión).
Control de versiones: revisión al menos una vez cada 6 meses.
Disponibilidad: copias fuera de línea y canales de comunicación de respaldo (incluyendo teleco/mensajeros).
Integraciones: referencia a BCP en SOP, procesos de incidentes y dashboards operativos.
Sincronización con Risk Register y Security Policies.

12) 30/60/90 - Plan de implementación

• Identificar el propietario de BCP y los procesos críticos.
• Realizar la BIA básica y la clasificación (RTO/RPO).
• Crear una matriz de riesgo y un catálogo de incidentes-secuencias de comandos.
• Desarrollar la plantilla DRP y la primera versión para los servicios prioritarios.

• Realizar pruebas piloto de DR (failover, recuperación de DB).
• Preparar plantillas de comunicación y distribución de roles.
• Cree un solo almacén de documentos BCP e integración SOP.
• Comenzar a entrenar a los equipos y al personal on-call.

• Llevar a cabo un ejercicio BCP entre equipos.
• Auditar el cumplimiento de RTO/RPO y las métricas de KPI.
• Finalice el plan de revisión y automatización de los procesos BCP.
• Incluya BCP en las verificaciones trimestrales de OKR y de seguridad interna.

13) Anti-patrones

«BCP sólo para marcar»: no hay pruebas reales y propietarios.
Instrucciones de DR obsoletas que no coinciden con las arquitecturas actuales.
Canales de comunicación y contactos no verificados.
Dependencias no contabilizadas (PSP, CDN, proveedores KYC).
Falta de post mortems después de los fallos.
No hay acceso sin conexión a BCP cuando la red se cae.

14) Ejemplo de la estructura del documento BCP

1. Objectives and Scope
2. Critical Processes (BIA)
3. Risk Matrix
4. Target RTO/RPO
5. DRP (by scenario)
6. Contacts and Roles
7. Communication templates
8. Schedule of tests and exercises
9. Reporting and auditing
10. Version and update history

15) Integración con otras secciones

Análisis operativo: métricas de headroom y degradación a incidentes.
Sistema de notificaciones y alertas: señales tempranas para iniciar procedimientos BCP.
Ética de la gestión: informes transparentes y pruebas honestas.
Asistentes AI: preparación automática de resúmenes BCP y hojas de verificación DR.
Cultura de la responsabilidad: entrenamientos, «días de juego», retrospectivas.

16) FAQ

P: ¿En qué se diferencia BCP de DRP?
R: BCP - más amplio: abarca personas, procesos, comunicaciones, socios e infraestructura. DRP es un plan técnico de recuperación de sistemas de TI.

P: ¿Con qué frecuencia actualizar BCP?
R: Después de cada cambio importante en la arquitectura, incidente o al menos 1 vez cada 6 meses.

P: ¿Es necesario incluir socios?
R: Sí. PSP, KYC y los estudios son parte de la cadena de continuidad, deben tener sus acuerdos de OLA y BCP.