Plan de continuidad del negocio

1) Objetivo, ámbito y principios

Objetivo: garantizar la continuidad de los servicios críticos (depósitos, apuestas/juegos, retiros, KYC/AML, sapport) en caso de interrupciones y recuperación rápida sin infracción de licencias y contratos.
Área: plataforma en línea, circuito de pago, antifraude/CUS, DWH/BI, sapport, funciones operativas y legales, proveedores clave (PSP/KYC/nube/CDN/estudios/agregadores).
Principios: seguridad primero, jugador primero, corrección regulatoria, minimización de RTO/RPO, modos de degradación simples, probabilidad y enseñanzas regulares.

2) BIA - Análisis de Impacto Empresarial

Identifique procesos críticos, entradas/salidas, dependencias, alternativas «manuales» y RTO/RPO de destino.

yaml process: payouts owner: head_of_payments criticality: tier1 dependencies: [psp1, psp2, bank_api, kyc_service, ledger_db]
rto: "4h"
rpo: "15m"
manual_workaround: "limited manual VIP payments when the PSP is completely unavailable"
max_tolerable_downtime: "8h"
legal_constraints: ["AML/KYC check before payout," "regulatory notification windows"]

3) Escenarios/amenazas (Risk → Impact → Response)

Ésos: caída de la región de la nube, fallo de la DB, pérdida de clúster, ataques DDoS, fallo de CDN.
Vendedores: Degradación PSP/KYC, ruptura con el agregador de juegos, inaccesibilidad de detección antifraude/sanción.
Cyber: compromiso de cuentas/claves, ransomware, fuga PII.
Procesos/personas: huelgas/enfermedades, atención de profesionales clave, error de liberación.
Geo/fuerza mayor: apagones de comunicación/energía, riesgos militares/sancionadores, bloqueos de dominios/tráfico.

Para cada uno: desencadenantes, umbral de escalamiento, medidas de control, degradación del servicio y plantillas de comunicación.

4) Arquitectura de sostenibilidad y estrategia

Active-active/active-standby por región; infraestructura como código para una elevación rápida.
Modos de degradación: vitrinas read-only, desactivación de proveedores de juegos no críticos, límites de pago, «solo depósitos» con cajeros diferidos (si es legalmente permitido), reducción de la frecuencia de análisis/ETL.
Gestión de tráfico: Anycast CDN, geo balanceo, health-checks, canary-routing.
Datos: bitups PITR, registros de cambios, replicación interregional, integridad criptográfica (hashes/WORM).
Claves/secretos: KMS por región independiente, «break-glass» con registro.
PSP/KYC multi-homing: failover automático, enrutamiento por SLA/latencia.

5) Estructura de comandos (Sistema de comandos incidentales)

Detectent Commander (IC) es un único punto de decisión.
Ops Lead (SRE/Plataforma) - Teestabilización, Feilover, métricas.
Business Continuity Lead - Coordinación de procesos/procedimientos manuales.
Comms Lead - notificaciones externas/internas (jugadores, socios, reguladores).
Security/DPO - ciberincidentes/privacidad, ventanas regulatorias.
Payments/KYC Leads - scripts PSP/KYC.
Liaisons: Legal, Support, VIP/CRM, Data/BI.

Regla: un IC por incidente, canales claros y registros de soluciones.

6) Plan de comunicaciones

Canales: war-room (chat/puente), enlaces de respaldo (teléfono/radio/alt-messenger), contactos PSP/KYC/bancos previamente verificados.
Plantillas de mensajes externos: página de estado, redes sociales, correo electrónico/inserción; tono - hechos, plazos, pasos siguientes.
Reguladores y socios: direcciones preestablecidas, notificaciones SLA; formulaciones convenidas.
Jugadores: ETA transparente, compensaciones/bonificaciones (si corresponde), preguntas frecuentes durante el período de degradación.

7) Planes operativos (Runbooks)

7. 1 Feilover a otra región

yaml trigger: "loss of primary availability> = 5m, p95_latency>threshold"
steps:
- IC approves region_failover
- SRE: flip traffic via GSLB to secondary
- Data: verify replication lag < RPO
- Apps: switch env vars/secrets; warm caches
- QA: smoke tests; Business: announce status rollback: "switch-back on 60m stability"

7. 2 Degradación PSP

yaml trigger: "auth_rate_psp1 < baseline-3σ 15m"
steps:
- Payments: route X%→psp2, include limits
- Comms: banner at the checkout, status page
- Finance: reconciliation plan for T + 0
- Legal: notification log and SLA letter

7. 3 KYC proveedor no está disponible

yaml trigger: "kyc_sla_breach 30m"
steps:
- Risk: time limits of deposits/rates
- Ops: VIP/High-risk manual check
- Comms: KYC Time Increase Notice
- Vendor: escalation, protection switch

8) Recuperación de TI y datos (DR)

Categorías de sistemas: Tier-1 (plataforma/pagos/CUS), Tier-2 (juegos/análisis), Tier-3 (interno).
Orden de elevación: set→sekrety/KMS→BD→kesh→API→front/CDN→integratsii→analitika.
Comprobaciones de integridad: sumas de comprobación, verificación de registros/replicación, conciliación de transacciones (reconciliation).
Pruebas de RD: anual completo (switch-over), trimestralmente parcial; fijación de RTO/RPO reales.

9) Personas, oficinas y logística

Remote-ready: laptops/módems redundantes, acceso a través de SSO/MFA, acceso «rojo» para IC.
Ubicaciones alternativas: oficinas de repuesto/espacios de coworking, listas de pases, plan de evacuación.
Rotación de turnos: matriz de competencias, duplicación de roles clave, plan de sustitución.
Proveedores críticos de comunicación/energía: contactos, SLA, generadores/UPS (si es relevante).

10) Vendedores y cadena de suministro

Requisitos BCP/DR en los contratos: RTO/RPO, pruebas obligatorias, derecho de auditoría y ejercicios conjuntos.
Registro de subprocesadores: contactos, planes de outage, confirmaciones de eliminación/exportación de datos en offboarding.
Rugido trimestral Tier-1: incidentes, protocolos DR, estado de certificados, SLA.

11) Formación, ejercicios y pruebas

Tabletop una vez al trimestre: PSP/KYC/cloud/cyber-scripts.
T-enseñanzas: DR parcial/completo; DDoS/conmutación CDN; «kill-switch» de los proveedores de SDK.
Ejercicios de comunicación: comunicado de prensa/actualizaciones de estado/cartas regulatorias.
Retrospectivas: timeline, RCA, CAPA, actualización de runbooks y BIA.

12) Métricas (KPI/KRI)

RTO/RPO hecho (por Tier-1): cumple con los objetivos ≥ 95%.
MTTD/MTTR: tendencia a la baja; MTTR de incidentes críticos ≤ objetivo.
Éxito del Fairlover: sin pérdida de datos/pedidos/apuestas, ≤ X min de degradación.
Ejercicio Coverage: ≥ 2 pruebas DR completas/año + 4 tabletop.
Comunicaciones: tiempo hasta el primer apdate ≤ 15 min, frecuencia de actualización según la política.
Vendor resiliencia: proporción de Tier-1 con pruebas de RD confirmadas para 12 meses - 100%.

13) RACI (ampliado)

14) Hojas de cheques

14. 1 Ready-to-Failover

• Contactos actuales de IC/vendedores/reguladores
• Salud de la replicación, refuerzo regular de PITR
• Comprobado «kill-switch» para SDK/webhooks
• Gestor de tráfico (GSLB/CDN) con cheques de salud verificados
• Plantillas de estado/correos electrónicos y derechos de publicación
• Runbooks y accesos (SSO/MFA) verificados mensualmente

14. 2 Durante el incidente

• Asignado IC, abierto war-room, inicio de los registros de soluciones
• Clasificación (P1/P2), selección de escenarios y degradación
• Techdactions (Feilover/Límites/Desactivaciones)
• Primer apdate público ≤ 15 minutos
• Notificaciones regulatorias/de asociación sobre SLA
• Captura de artefactos para post-mortem

14. 3 Después del incidente

• Post mortem con RCA y CAPA
• Se han actualizado los procedimientos BIA/umbrales/rutina
• Entrenamiento/retest de fixes, informe de bordu
• Conciliación financiera/dada (reconciliation)

15) Plantillas (fragmentos)

15. 1 Tarjeta de script

yaml scenario: "Region outage: cloud-eu1"
triggers: ["error_rate>5%", "loss of quorum", "cdn health fail"]
degradation: ["disable live-casino", "payments=psp2 only", "payouts=VIP manual"]
rto_target: "30m"
rpo_target: "15m"
contacts: {cloud: "...", isp: "...", regulator: "..."}
comms_templates: ["status_page_v1", "partner_notice_v2"]

15. 2 Mensaje a la página de estado

[UTC + 02] We are seeing the degradation of payments through PSP # 1. Transactions are automatically routed through an alternative provider. Player funds are safe. The next update is in 15 minutes.

16) Gestión de documentos y versiones

Versionar BCP/Runbooks en el repositorio, change-log, propietario del documento.
Plazos de revisión (trimestral para Tier-1), control de disponibilidad de copias offline.
Almacenamiento de artefactos de ejercicios/incidentes y métricas de rendimiento.

17) Hoja de ruta para la implementación (6-8 semanas)

Semanas 1-2: BIA y procesos críticos, objetivos de RTO/RPO, lista de escenarios y propietarios.
Semanas 3-4: arquitectura de sostenibilidad y modos de degradación, runbooks, patrones de comunicación, contactos.
Semanas 5-6: integración con vendedores (PSP/KYC/nube), ejercicios piloto (tabletop + DR parcial), ajustes.
Semanas 7-8: prueba completa de RD (si es posible), inicio del ciclo trimestral de ejercicios, informe de bordes y paquete regulatorio (si es necesario).

18) Secciones relacionadas wiki

Registro de riesgos, Incidentes y fugas, pruebas DR/BCP, TPRM y SLA, ISO 27001/27701, SOC 2, PCI DSS, IGA/RBAC/Least Privilege, Política logs/WORM - para un circuito único de sostenibilidad y probabilidad.

TL; DR

Eficaz BCP = BIA→RTO/RPO→stsenarii y degradatsii→multi -vendedor/multi-región + claro Comando Incidente, Comunicación y Enseñanza. Mantenga el documento vivo, pruebe regularmente, e incluso un gran fallo no detendrá el negocio ni golpeará las licencias.