Continuidade & Resiliência • Artigo

Resiliência é disciplina diária, não um dossier na gaveta

⏱️ Leitura estimada: 8 minutos

Incidentes tecnológicos e falhas de terceiros continuam a provar que a continuidade se constrói na prática, todos os dias.

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”?

  1. 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.
  2. 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
  3. 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).
  4. 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 1 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

 

Tem uma dúvida de formação relacionada com este tema?

Se procura perceber em que curso, área ou percurso Behaviour este conteúdo pode ser trabalhado, consulte a página Formação por Necessidades.

Ver Formação por Necessidades

Autor: Behaviour
Publicado em: 13 outubro de 2025
Não é autorizada a cópia ou reprodução deste artigo.