Incidentes tecnológicos e falhas de terceiros mostram que resiliência é disciplina diária, não um dossiê guardado na gaveta.
Casos recentes que provaram este facto são:
- Outage global do CrowdStrike (jul/2024): atualização defeituosa provocou BSOD (Blue Screen of Death) em milhões de sistemas Windows e parou operações em múltiplos setores — um “mega‑incidente” sem intrusão maliciosa Reuters
- Apagão ibérico (28/abr/2025): falha elétrica massiva imobilizou Portugal e Espanha durante horas (transportes, semáforos, redes móveis), com reposição gradual do serviço. Relatórios nacionais indicam como origem técnica a rede ibérica (não existindo indícios de ciberataque) RTP
- Google Cloud (12/jun/2025): interrupção com impacto em plataformas populares (ex.: Spotify, Fitbit), expondo dependência de hyperscalers. Google Cloud Status
- Microsoft 365/Outlook (jul/2025): perturbação prolongada (~19h) com paralisação de e‑mail/calendários — erros de configuração, não existindo indícios de ciberataque. Computerworld
- Ataques via fornecedores: aumento significativo de incidentes na e através da supply chain em 2024/25. Financial Times
- Custos de indisponibilidade: estudos de 2025 demonstram perdas por hora significativas e uma tendência de subestimação pelas empresas. IT Pro
O que é continuidade “moderna”?
- Do cenário técnico ao impacto no cliente: comece pelo BIA (serviços críticos, RTO/RPO), não por uma simples lista de servidores.
- Cenários obrigatórios de teste (5)
- Falha de update (tipo CrowdStrike) — indisponibilidade massiva sem violação de segurança. Reuters
- Falha de hyperscaler (GCP/Azure/M365) — perda temporária de serviços partilhados. Google Cloud Status
- Terceiro crítico indisponível — SaaS/outsourcer falha além do seu RTO. Financial Times
- Ransomware/compromisso de dados — decisão entre recuperação e reconstrução.
- Falha de infraestrutura (energia/telecom) — blackout regional com operação em modo degradado (UPS/geradores, comunicações alternativas) e plano de comunicação pública RTP
- Arquitetura resiliente para suportar falhas com segurança: segmentação, break‑glass accounts, backups imutáveis, multirregião e planos de degradação funcional (serviços mínimos viáveis).
- Governança e reporte: para as entidades financeiras, o DORA exige testes de resiliência, gestão de terceiros e demonstração de evidências para os supervisores; os setores NIS 2 devem alertar em 24h, notificar em 72h e emitir relatório final em e mês. Digital Strategy
7 métricas que importam (e que o Board percebe)
- RTO / RPO por serviço crítico (alvo vs. conseguido em teste)
- MTTR por tipo de incidente (média e p95)
- Cobertura de backups restaurados (últimos 90 dias)
- Cobertura EDR/SIEM em endpoints e servidores
- % de runbooks testados com sucesso (e com owners)
- Dependências de terceiros mapeadas por serviço
- Tempo para comunicação a clientes/reguladores
Programa em 100 dias
- 0–30 dias: BIA rápido; mapa de serviços e dependências (inclui energia/telecom); priorização por impacto.
- 31–60 dias: exercícios executivos (table‑top NIS 2 — 24h/72h/1 mês), teste de restore, plano de comunicação.
- 61–100 dias: teste técnico (falha de update ou perda de cloud), ensaio de blackout (UPS/geradores, comunicações alternativas), revisão de contratos de terceiros (RTO/RPO, reporte de incidentes, right to audit), e after‑action review com melhorias. Google Cloud Status
Cursos Behaviour recomendados
- ISO 22301 Lead Implementer
- ISO 22301 Lead Auditor
- NIS 2 Compliance Lead Manager
- Certified DORA Compliance Lead Manager
Autor: Behaviour
Não é autorizada a cópia ou reprodução deste artigo.