Plano de continuidade de negócios

1) Propósito, área e princípios

O objetivo é garantir a continuidade de serviços críticos (depósitos, apostas/jogos, conclusões, KYC/AML, safort) em casos de falhas e recuperação rápida sem violação de licenças e contratos.
Área: plataforma online, circuito de pagamentos, antifrod/CUS, DWH/BI, safort, funções operacionais e legais, vendedores-chave (PSP/KYC/nuvem/CDN/estúdios/agregadores).
Princípios: safety first, o jogador primeiro, correção regulatória, minimização de RTO/RPO, simples regimes de degradação, comprovação e exercícios regulares.

2) BIA - análise do impacto no negócio

Defina processos críticos, entradas/saídas, dependências, alternativas manuais e 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) Cenários/ameaças (Risk → Impact → Response)

Aquelas: queda da região da nuvem, falha do banco de dados, perda do cluster, ataques de DDoS, falha do CDN.
Vendedores: PSP/KYC degradação, rompimento com o agregador de jogos, indisponibilidade de antifrod/screening de sanções.
Ciber: comprometimento de cadastro/chaves, ransomware, fuga de PII.
Processos/pessoas: greves/doenças, cuidados de profissionais-chave, erro de lançamento.
Geo/força maior: cortes de comunicação/energia, riscos militares/sanções, bloqueios de domínios/tráfego.

Para cada um: desencadeadores, limite de escalação, medidas de controle, degradação do serviço e modelos de comunicação.

4) Arquitetura de sustentabilidade e estratégia

Ativo-ativo/ativo-padrão por região; infraestrutura as códigos para elevação rápida.
Modos de degradação: vitrines read-only, desativação de provedores de jogos não críticos, limites de pagamento, «apenas depósitos» com cassautas atrasados (se legalmente permitido), redução da frequência de analistas/ETL.
Traffic Management: CDN Anycast, balanceamento geo, health-checks, canary-rotation.
Dados: PITR bacaps, registros de alterações, replicação interregional, integridade criptográfica (hashi/WORM).
Chaves/segredos: independentes KMS per-region, «break-glass».
PSP/KYC multi-homing: feelover automático, roteirizado por SLA/latência.

5) Estrutura de comando (Invident Command System)

O Incident Team (IC) é um único ponto de decisão.
Ops Lead (SRE/Plataforma) - Tecnologia, feedback, métricas.
Business Continuity Lead - coordenação de processos/procedimentos manuais.
Comms Lead - notificações externas/internas (jogadores, parceiros, reguladores).
Segurança/DPO - ciberidentes/privacidade, janelas regulatórias.
Payments/KYC Lids - PSP/KYC Script.
Liaisons: Legal, Support, VIP/CRM, Data/BI.

Regra: um IC para incidente, canais claros e logs de soluções.

6) Plano de comunicação

Canais: war-room (bate-papo/ponte), ligações de reserva (telefone/rádio/alto-serviço de mensagens), contatos pré-verificados PSP/KYC/bancos.
Modelos de mensagens externas: página de status, redes sociais, email/push; o tom são os factos, os prazos, os próximos passos.
Reguladores e parceiros: endereços pré-instalados, SLA notificações; formulações acordadas.
Jogadores: transparente ETA, compensação/bónus (se aplicável), FAQ por período de degradação.

7) Planos operacionais (Runbooks)

7. 1 Feelover para outra região

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 PSP degradação

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 fornecedores KYC não estão disponíveis

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) Recuperação de TI e dados (DR)

Categorias de sistemas: Tier-1 (plataforma/pagamentos/CUS), Tier-2 (jogos/analistas), Tier-3 (interna).
Ordem de elevação: set→sekrety/KMS→BD→kesh→API→front/CDN→integratsii→analitika.
Verificações de integridade: valores de verificação, verificação de registros/replicação, verificação de transações (recordation).
Testes DR.: anualmente completo (switch-over), trimestralmente parcial; fixação de RTO/RPO real.

9) Pessoas, escritórios e logística

Remote-ready: laptops de reserva/modems, acesso SSO/MFA, acesso «vermelho» para IC.
Locais alternativos, escritórios de reserva/coworkings, listas de passagens, planos de evacuação.
Rotação de turnos: matriz de competência, duplicação de papéis-chave, plano de substituição.
Provedores críticos de comunicação/energia: contatos, SLA, geradores/UPS (se relevante).

10) Vendedores e cadeia de fornecimento

Requisitos BCP/DR. em contratos: RTO/RPO, testes obrigatórios, direito de auditoria e exercícios conjuntos.
Registro de subprocessadores: contatos, planos de outage, confirmação de remoção/exportação de dados no offboarding.
Rábulo trimestral Tier-1, incidentes, protocolos DR, status de certificados, SLA.

11) Treinamento, treinamento e testes

Tabletop uma vez por trimestre: PSP/KYC/nuvem/cenário cibernético.
Os ensinamentos são DR parciais/completos; DDoS/mudança de CDN; «kill-switch» dos provedores SDK.
Exercícios de comunicação: comunicado de imprensa/status de atualização/e-mails regulatórios.
Retrospectivas: timeline, RCA, CAPA, atualização de runbooks e BIA.

12) Métricas (KPI/KRI)

Fato RTO/RPO (Tier-1): correspondem aos objetivos ≥ 95%.
MTTD/MTTR: tendência de redução; MTTR incidentes críticos ≤ alvo.
Sem perda de dados/pedidos/taxas, ≤ X min de degradação.
Exercícios de Coverage: ≥ 2 testes de DR. completos/ano + 4 tabletop.
Comunicações: até o primeiro update ≤ 15 min, frequência de atualização de acordo com a política.
Vendor resilience: proporção de Tier-1 com testes DR confirmados em 12 m - 100%.

13) RASI (acentuado)

14) Folhas de cheque

14. 1 Ready-to-Failover

• Contatos atuais IC/vendedores/reguladores
• Saúde de replicação, PITR-Bacap regular
• Verificados «kill-switch» para SDK/webhooks
• Gerente de tráfego (GSLB/CDN) com health-checks verificados
• Modelos de status/cartas e direitos de publicação
• Runbooks e acessibilidade (SSO/MFA) verificados mensalmente

14. 2 Durante o incidente

• Atribuído IC, war-room aberto, arranque logs de soluções
• Classificação (P1/P2), seleção de cenário e degradação
• Usabilidade (Fplover/limites/desligamento)
• Primeiro update público ≤ 15 minutos
• Notificações regulatórias/parcerias SLA
• Captura de artefatos para o pós-mortem

14. 3 Após o incidente

• Pós-mortem com RCA e CAPA
• Atualizados BIA/liminares/procedimentos rotineiros
• Treinamento/retoque de fixação, relatório bordão
• Acervo financeiro/este (reconciação)

15) Modelos (fatias)

15. 1 Cartão de cenário

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 Mensagem de Status de Página

[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) Gerenciamento de documentos e versões

Versionagem do BCP/Runbooks no repositório, mudança-jobs, dono do documento.
Prazo de revisão (trimestral para Tier-1), controle de disponibilidade de cópias offline.
Armazenamento de artefatos de exercícios/incidentes e métricas de eficiência.

17) Mapa de trânsito de implementação (6-8 semanas)

Semanas 1-2: BIA e processos críticos, objetivos RTO/RPO, lista de cenários e proprietários.
Semanas 3-4: arquitetura de estabilidade e regimes de degradação, runbooks, modelos de comunicação, contatos.
Semanas 5-6: integração com vendedores (PSP/KYC/nuvem), exercícios-piloto (tabletop + DR parcial), ajustes.
Semanas 7-8: Teste DR. completo (se possível), lançamento do ciclo trimestral de exercícios, relatório do bordão e pacote regulatório (se necessário).

18) Seções wiki associadas

Registro de risco, Incidentes e Fugas, DR/BCP Testes, TPRM e SLA, ISO 27001/27701, SOC 2, PCI DSS, IGA/RBAC/Least Privege, Política de Logs/WORM - para um único circuito de estabilidade e provabilidade

TL; DR

Efetivo BCP = BIA→RTO/RPO→stsenarii e degradatsii→multi/região multi + nítido Invident Command, comunicações e ensinamentos. Mantenha o documento vivo, teste regularmente - e mesmo uma grande falha não interromperá o negócio nem afetará as licenças.