1. Âmbito e Objetivos

1.1 Âmbito de Aplicação

Esta Política de Continuidade de Negócio (BCP) aplica-se a [NOME DA ORGANIZAÇÃO], abrangendo todas as operações críticas, sistemas de informação, processos de negócio e infraestruturas essenciais localizadas em [LOCALIZAÇÕES].

A política cobre os seguintes domínios operacionais:

• Sistemas de TI e infraestrutura tecnológica crítica
• Processos de negócio essenciais identificados na Business Impact Analysis (BIA)
• Instalações físicas e locais de trabalho alternativos
• Recursos humanos e equipas críticas
• Fornecedores e parceiros de cadeia de abastecimento críticos
• Dados e informações sensíveis ou regulamentadas

1.2 Objetivos Estratégicos

Os objetivos fundamentais desta política incluem:

• Resiliência Operacional: Garantir a continuidade de operações críticas durante e após incidentes disruptivos
• Proteção de Ativos: Salvaguardar pessoas, dados, sistemas e reputação organizacional
• Recuperação Rápida: Estabelecer objetivos de RTO (Recovery Time Objective) e RPO (Recovery Point Objective) para sistemas críticos
• Conformidade Regulamentar: Cumprir requisitos Diretiva NIS2, art. 21.º, n.º 2, alínea c) (DL 125/2025, art. 27.º, n.º 1, alínea b)), ISO 22301, e orientações ENISA 2024/2025
• Gestão de Crise: Implementar estruturas de governança e comunicação eficazes durante crises

2. Definições e Terminologia

3. Governança e Estrutura de Gestão

3.1 Crisis Management Team (CMT)

A equipa de gestão de crise é responsável pela coordenação estratégica durante incidentes disruptivos. Composição:

• Crisis Manager: [NOME] - Autoridade máxima de decisão durante crise
• Technical Recovery Lead: [NOME] - Coordena recuperação de sistemas TI
• Business Continuity Coordinator: [NOME] - Gere processos de negócio alternativos
• Communications Officer: [NOME] - Gere comunicação interna e externa
• Legal/Compliance Advisor: [NOME] - Assegura conformidade regulamentar (NIS2, GDPR)

3.2 RACI Matrix - Responsabilidades

R = Responsible (Executa), A = Accountable (Aprova), C = Consulted (Consultado), I = Informed (Informado)

3.3 Autoridade e Escalamento

Níveis de autoridade durante crise:

• Nível 1 (Minor): Technical Recovery Lead pode ativar procedimentos técnicos sem aprovação executiva
• Nível 2 (Major): BC Coordinator ativa BCP completo após consulta com Crisis Manager
• Nível 3 (Critical): Crisis Manager assume controlo total, Board of Directors informado imediatamente

4. Business Impact Analysis (BIA)

4.1 Metodologia de Avaliação

A criticidade de processos e sistemas é avaliada com base em:

• Impacto Financeiro: Perda de receita, multas, custos de recuperação
• Impacto Reputacional: Danos à marca, confiança de clientes
• Impacto Regulamentar: Violações NIS2, GDPR, sanções
• Impacto Operacional: Incapacidade de entregar serviços essenciais
• Dependências: Sistemas interdependentes, fornecedores críticos

4.2 Classificação de Criticidade

4.3 Dependências Críticas

Mapeamento de dependências entre processos e sistemas:

• Infraestrutura TI: [Servidores, redes, datacenters]
• Aplicações: [ERP, CRM, sistemas de produção]
• Fornecedores Críticos: [Cloud providers, ISPs, fornecedores de energia]
• Recursos Humanos: [Especialistas técnicos, equipas operacionais]
• Instalações Físicas: [Escritórios, datacenters, armazéns]

5. RTO/RPO por Sistema Crítico

5.1 Tabela RTO/RPO de Sistemas Existentes

6. Procedimentos de Disaster Recovery

6.1 Playbook: Falha Crítica de Datacenter

Cenário: Indisponibilidade total do datacenter primário (falha de energia, incêndio, desastre natural)

Fase 1: Deteção e Ativação (0-30 minutos)

1. Sistema de monitorização 24/7 deteta falha e alerta equipa de plantão
2. [NOME] (Technical Recovery Lead) valida severidade do incidente
3. Se RTO de sistemas Tier 1 em risco, ativa protocolo de failover imediato
4. Notifica Crisis Manager e BC Coordinator via [CANAL DE EMERGÊNCIA]
5. Ativa War Room virtual em [PLATAFORMA]

Fase 2: Failover para Site Secundário (30 min - 2 horas)

1. Executa script de failover automatizado para sistemas Tier 1:
   • Redireciona DNS para datacenter secundário em [LOCALIZAÇÃO]
   • Ativa instâncias standby na cloud ([AWS/Azure/GCP])
   • Valida integridade de backups mais recentes (RPO check)
2. Inicia recuperação manual de sistemas Tier 2 a partir de backups
3. Testa conectividade e funcionalidade de sistemas críticos no site secundário
4. Valida que perda de dados está dentro dos limites de RPO estabelecidos

Fase 3: Comunicação e Estabilização (2-4 horas)

1. Communications Officer notifica stakeholders internos e externos:
   • Colaboradores via [EMAIL/SMS/TEAMS]
   • Clientes afetados via [STATUS PAGE/EMAIL]
   • CSIRT/CNCS se aplicável (NIS2 notificação 24h/72h)
2. Monitoriza performance de sistemas recuperados
3. Documenta timeline, ações tomadas, sistemas afetados
4. Crisis Manager atualiza Board of Directors

Fase 4: Operação em Modo Contingência (4 horas - semanas)

1. Mantém operações em datacenter secundário até primário restaurado
2. Escala sistemas conforme necessário para manter SLAs
3. Reuniões diárias de status da CMT
4. Planeia e executa failback quando primário estiver operacional

6.2 Playbook: Ataque Ransomware

Cenário: Deteção de ransomware a encriptar ficheiros críticos

1. Contenção Imediata (0-15 min):
   • Isola segmentos de rede afetados (VLAN quarantine)
   • Desliga sistemas infetados para prevenir propagação
   • Preserva evidências forenses (logs, memory dumps)
2. Avaliação (15-60 min):
   • Identifica variante de ransomware e IoCs (Indicators of Compromise)
   • Determina extensão da infeção (sistemas, dados afetados)
   • Verifica integridade de backups offline (tape, air-gapped)
3. Recuperação (1-48 horas):
   • Reconstrói sistemas a partir de imagens limpas
   • Restaura dados de backups verificados como não comprometidos
   • Implementa patches e hardening adicional
   • Aplica regras de firewall/IDS para bloquear C2 servers
4. Notificação Regulamentar:
   • NIS2: Early warning a CSIRT/CNCS dentro de 24h se critérios preenchidos
   • Incident notification completa dentro de 72h
   • GDPR: Notificação a CNPD dentro de 72h se violação de dados pessoais

6.3 Playbook: Falha de Fornecedor Crítico

Cenário: Cloud provider ou ISP principal indisponível

1. Ativa fornecedor secundário conforme acordos pré-estabelecidos
2. Redireciona tráfego via BGP anycast ou DNS failover
3. Contacta Account Manager do fornecedor primário para ETA de recuperação
4. Se indisponibilidade > [X horas], invoca SLA penalties e considera mudança permanente

7. Operações Alternativas e Workarounds

7.1 Instalações de Recuperação

Hot Site (Tier 1 Systems)

• Localização: [ENDEREÇO DATACENTER SECUNDÁRIO]
• Capacidade: 100% dos sistemas críticos Tier 1 em standby ativo
• Tempo de Ativação: < 2 horas (maioritariamente automático)
• Custo Mensal: [€ VALOR]
• Contrato: [FORNECEDOR] - renovação anual

Warm Site (Tier 2 Systems)

• Localização: Cloud híbrido ([AWS/Azure region])
• Capacidade: Infraestrutura pré-configurada, dados replicados diariamente
• Tempo de Ativação: 4-12 horas (requer configuração manual)
• Custo Mensal: [€ VALOR] standby + pay-as-you-go quando ativo

Cold Site (Tier 3 Systems)

• Localização: [ESCRITÓRIO REGIONAL]
• Capacidade: Espaço físico, energia, conectividade básica
• Tempo de Ativação: 48-72 horas (requer instalação completa)
• Custo: Incluído em contrato de arrendamento do escritório

7.2 Trabalho Remoto em Massa

Cenário: Escritório principal inacessível (pandemia, desastre natural, falha de infraestrutura)

• VPN Capacity Scaling: Expandir de [X] para [Y] ligações simultâneas via [SOLUÇÃO VPN]
• Laptops de Emergência: Pool de [N] laptops pré-configurados em [LOCALIZAÇÃO]
• Cloud Desktops: Ativar VDI (Virtual Desktop Infrastructure) em [Azure Virtual Desktop/AWS WorkSpaces]
• Colaboração: Microsoft Teams/Zoom escalado para [X] utilizadores
• Suporte 24/7: Helpdesk externo via [FORNECEDOR]

7.3 Processos Manuais Temporários

Para sistemas Tier 2/3 com RTO > 24h, procedimentos manuais aprovados:

8. Testes, Simulações e Exercícios

8.1 Programa Anual de Testes BCP

Em conformidade com Diretiva NIS2, art. 21.º, n.º 2, alínea c) (DL 125/2025, art. 27.º, n.º 1, alínea b)) e ENISA 2024/2025 guidance, a organização executa o seguinte programa de testes:

8.2 Critérios de Sucesso para Testes

• Tabletop Exercises: 100% da CMT participa, decisões documentadas, timeline respeitada
• DR Site Tests: RTO atingido, RPO validado, zero perda de dados críticos
• Backup Restores: Dados restaurados com integridade verificada, dentro do RPO
• Communication Tests: Todos stakeholders contactados dentro de [X minutos]

8.3 Documentação de Testes

Cada teste deve gerar:

• Data e hora de execução
• Participantes e observadores
• Cenário testado e objetivos
• Resultados (sucesso/falha de cada objetivo)
• Gaps identificados e ações corretivas
• Timeline de execução vs. RTO/RPO targets
• Lições aprendidas

9. Manutenção e Atualizações

9.1 Ciclo de Revisão

Este documento e os planos associados são revistos nas seguintes frequências:

9.2 Triggers para Atualização Ad-Hoc

Revisão extraordinária obrigatória quando ocorrer:

• Mudança significativa na infraestrutura TI (migração cloud, novo datacenter)
• Aquisição/fusão ou venda de unidades de negócio
• Lançamento de novos produtos/serviços críticos
• Incidente real que ativou o BCP (post-incident review)
• Mudanças regulamentares (ex: atualizações NIS2, novas ENISA guidelines)
• Falha em testes BCP que revele gaps críticos
• Mudança de fornecedor crítico (ISP, cloud provider)

9.3 Controlo de Versões

Histórico de versões deste documento:

9.4 Distribuição e Acesso

Este documento é classificado como CONFIDENCIAL - INTERNAL USE ONLY

• Acesso Completo: Crisis Management Team, Board of Directors, Auditoria Interna
• Acesso Parcial (secções relevantes): Equipas técnicas, gestores departamentais
• Repositório: [SharePoint/Confluence/Sistema de Gestão Documental]
• Backup Offline: Cópias impressas em [LOCALIZAÇÃO SEGURA] (acessível mesmo com sistemas offline)

10. Diretório de Contactos de Emergência

10.1 Entidades Externas Críticas

11. Gestão de Dependências de Fornecedores

11.1 Fornecedores Críticos Identificados

Fornecedores cuja indisponibilidade impacta diretamente RTO/RPO de sistemas Tier 1/2:

11.2 Cláusulas Contratuais BCP

Todos contratos com fornecedores críticos devem incluir:

• SLA Penalities: Créditos/compensação por violação de uptime garantido
• RTO Commitment: Tempo máximo de restauro de serviço em caso de falha
• Disaster Recovery: Fornecedor deve ter seu próprio BCP auditado
• Notificação: Alerta imediato (< 15 min) em caso de incidente que afete serviço
• Data Portability: Garantia de extração de dados em formatos standard se mudar de fornecedor
• Audit Rights: Direito de auditar medidas de BC/DR do fornecedor anualmente

11.3 Revisão Anual de Fornecedores

Avaliação anual de performance BCP de fornecedores críticos:

• Análise de histórico de indisponibilidade (vs. SLA)
• Validação de que fornecedor mantém certificação ISO 22301 ou equivalente
• Teste de failover para fornecedor alternativo (pelo menos uma vez por ano)
• Revisão de contact points 24/7 e procedimentos de escalamento
• Verificação de cláusulas de saída (exit clauses) e prazos de migração

12. Aprovação e Conformidade

12.1 Aprovações

12.2 Conformidade Regulamentar

12.3 Próxima Revisão Agendada

Data: [DATA PRÓXIMA REVISÃO - 12 meses]

Responsável: [Business Continuity Coordinator]