NIS2 Portugal

1. Âmbito e Objetivos

1.1 Âmbito de Aplicação

Este Plano de Resposta a Incidentes aplica-se a [nome da organização] e abrange todos os sistemas, redes, aplicações e dados que suportam as operações da organização, incluindo infraestrutura on-premises, cloud e serviços geridos por terceiros.

Entidades Abrangidas: [listar entidades, departamentos, filiais, subsidiárias]

Sistemas Críticos: [listar sistemas críticos para o negócio, e.g., ERP, CRM, sistemas de produção]

Exclusões: [listar exclusões, se aplicável, e.g., "sistemas legados em fase de desativação"]

1.2 Objetivos

Este plano visa estabelecer procedimentos claros e eficazes para:

• Deteção Rápida: [objetivo de deteção, e.g., "Detetar incidentes de segurança em menos de 15 minutos através de monitorização contínua"]
• Contenção Eficaz: [objetivo de contenção, e.g., "Isolar e conter incidentes críticos em menos de 30 minutos"]
• Erradicação Completa: [objetivo de erradicação, e.g., "Remover todas as ameaças e vulnerabilidades exploradas em menos de 4 horas"]
• Recuperação Rápida: [objetivo de recuperação, e.g., "Restaurar operações normais em menos de 24 horas para incidentes críticos"]
• Lições Aprendidas: [objetivo de melhoria contínua, e.g., "Realizar revisão pós-incidente em 100% dos casos para identificar melhorias"]
• Compliance Regulatório: [objetivo de compliance, e.g., "Cumprir 100% dos prazos de notificação obrigatória NIS2"]

1.3 Compliance e Alinhamento Regulatório

Este plano está alinhado com os seguintes requisitos e standards internacionais:

• NIS2 (EU) 2022/2555 - Artigo 21(2)(b): [descrever alinhamento, e.g., "Implementação de políticas e procedimentos para gestão de incidentes com notificação obrigatória a autoridades competentes"]
• ISO/IEC 27035-1:2023 (Incident Management): [descrever alinhamento, e.g., "Adoção do framework de 5 fases: Preparação, Deteção, Avaliação, Resposta e Lições Aprendidas"]
• ISO/IEC 27035-3:2020 (ICT Incident Response Testing): [descrever alinhamento, e.g., "Realização de testes trimestrais de resposta a incidentes"]
• NIST SP 800-61r2 (Computer Security Incident Handling): [descrever alinhamento, e.g., "Estruturação CSIRT conforme melhores práticas NIST"]
• GDPR (Regulamento Geral de Proteção de Dados): [descrever alinhamento, e.g., "Procedimentos de notificação de violações de dados pessoais em conformidade com Artigos 33 e 34"]

1.4 Revisão e Atualização

Frequência de Revisão: [frequência, e.g., "Anualmente ou após incidentes críticos"]

Responsável pela Revisão: [cargo/nome, e.g., "CISO"]

Aprovação Final: [órgão/cargo, e.g., "Administração"]

Data da Última Revisão: [data]

Próxima Revisão Agendada: [data]

2. Definições e Classificação de Incidentes

2.1 Definições Chave

• Evento de Segurança: [definição, e.g., "Qualquer ocorrência observável num sistema ou rede que pode indicar uma atividade anómala"]
• Incidente de Segurança: [definição, e.g., "Evento confirmado que viola políticas de segurança, resultando em comprometimento da confidencialidade, integridade ou disponibilidade"]
• Vulnerabilidade: [definição, e.g., "Fraqueza num sistema que pode ser explorada por ameaças"]
• Ameaça: [definição, e.g., "Potencial causa de um incidente indesejado que pode resultar em danos para sistemas ou organização"]
• CSIRT (Computer Security Incident Response Team): [definição, e.g., "Equipa especializada responsável por receber, analisar e responder a incidentes de segurança"]
• IOC (Indicator of Compromise): [definição, e.g., "Evidência forense que indica comprometimento de sistema, como hashes de malware, IPs maliciosos"]

2.2 Matriz de Severidade de Incidentes

Todos os incidentes são classificados segundo os seguintes níveis de severidade:

2.3 Critérios de Classificação

A severidade é determinada com base nos seguintes critérios (CIA Triad):

Confidencialidade

• Crítico: [critério, e.g., "Exposição de dados pessoais sensíveis (GDPR Artigo 9), segredos comerciais, propriedade intelectual"]
• Alto: [critério, e.g., "Exposição de dados pessoais não sensíveis, informação confidencial interna"]
• Médio: [critério, e.g., "Exposição de informação interna não confidencial"]
• Baixo: [critério, e.g., "Exposição de informação pública"]

Integridade

• Crítico: [critério, e.g., "Alteração ou destruição de dados críticos de produção, logs de auditoria, backups"]
• Alto: [critério, e.g., "Alteração de dados importantes não críticos, configurações de sistema"]
• Médio: [critério, e.g., "Alteração de dados não críticos com impacto limitado"]
• Baixo: [critério, e.g., "Alteração de dados de teste ou desenvolvimento"]

Disponibilidade

• Crítico: [critério, e.g., "Indisponibilidade total de sistemas críticos > 4 horas"]
• Alto: [critério, e.g., "Indisponibilidade de sistemas importantes ou sistemas críticos 1-4 horas"]
• Médio: [critério, e.g., "Degradação de performance, indisponibilidade parcial < 1 hora"]
• Baixo: [critério, e.g., "Impacto mínimo em disponibilidade, redundância ativa"]

3. Estrutura da Equipa CSIRT

3.1 Organograma e Papéis

A equipa CSIRT (Computer Security Incident Response Team) é a unidade responsável pela gestão de incidentes de segurança. A estrutura organizacional é:

3.2 Matriz de Escalation

Incidentes são escalados conforme a seguinte matriz hierárquica:

3.3 Contactos Externos Críticos

Em caso de incidente, os seguintes contactos externos podem ser necessários:

3.4 Ferramentas e Recursos CSIRT

A equipa CSIRT dispõe das seguintes ferramentas e recursos:

• SIEM (Security Information and Event Management): [ferramenta, e.g., "Splunk Enterprise", "Microsoft Sentinel"]
• EDR (Endpoint Detection and Response): [ferramenta, e.g., "CrowdStrike Falcon", "Microsoft Defender for Endpoint"]
• Network Security Monitoring: [ferramentas, e.g., "Palo Alto Networks NGFW, Zeek IDS"]
• Forensics Tools: [ferramentas, e.g., "EnCase, FTK, Volatility"]
• Threat Intelligence Platform: [ferramenta, e.g., "MISP, Recorded Future"]
• Ticketing System: [sistema, e.g., "JIRA Service Desk, ServiceNow"]
• Comunicação Segura: [ferramentas, e.g., "Signal, war room dedicado"]

4. Fases de Resposta a Incidentes (ISO 27035)

Este plano segue o framework de 5 fases da ISO/IEC 27035-1:2023:

4.1 Fase 1: Preparação

Atividades contínuas para garantir prontidão da organização para responder a incidentes:

4.1.1 Políticas e Procedimentos

• Políticas de Segurança Ativas: [listar políticas, e.g., "Política de Segurança da Informação, Política de Uso Aceitável, Política de Gestão de Acessos"]
• Procedimentos Operacionais: [listar SOPs, e.g., "SOP-IR-001: Triagem de Alertas SIEM, SOP-IR-002: Isolamento de Endpoints"]
• Playbooks Ativos: [listar playbooks, e.g., "Ransomware, Data Breach, DDoS, Phishing, Insider Threat"]

4.1.2 Ferramentas e Tecnologias

• Monitorização 24/7: [descrição, e.g., "SIEM com correlação de eventos, alertas em tempo real"]
• Deteção de Ameaças: [capacidades, e.g., "EDR em todos os endpoints, IDS/IPS na perímetro, threat hunting proativo"]
• Capacidade de Resposta: [capacidades, e.g., "Isolamento remoto de endpoints, bloqueio de IPs/domínios, quarentena automática"]
• Ferramentas Forenses: [ferramentas disponíveis]

4.1.3 Formação e Sensibilização

• Formação CSIRT: [programa, e.g., "Formação trimestral em análise de malware, forensics, threat hunting"]
• Exercícios Tabletop: [frequência e âmbito, e.g., "Exercícios semestrais simulando ransomware e data breach"]
• Sensibilização de Utilizadores: [programa, e.g., "Formação anual obrigatória em segurança, phishing simulations mensais"]
• Certificações da Equipa: [certificações, e.g., "CISSP, GCIH, GCFA, GCIA"]

4.1.4 Backup e Disaster Recovery

• Estratégia de Backup: [estratégia, e.g., "Regra 3-2-1: 3 cópias, 2 meios diferentes, 1 offsite"]
• Frequência de Backups: [frequência, e.g., "Backups incrementais diários, completos semanais"]
• RTO (Recovery Time Objective): [objetivo, e.g., "4 horas para sistemas críticos"]
• RPO (Recovery Point Objective): [objetivo, e.g., "1 hora de perda de dados máxima"]
• Testes de Restore: [frequência, e.g., "Testes trimestrais de restore de sistemas críticos"]

4.2 Fase 2: Deteção e Reporte

Identificação de potenciais incidentes e notificação à equipa CSIRT:

4.2.1 Fontes de Deteção

• Alertas SIEM: [descrição, e.g., "Correlação automática de eventos, alertas para anomalias comportamentais"]
• EDR Alerts: [descrição, e.g., "Deteção de malware, comportamento suspeito de processos"]
• IDS/IPS: [descrição, e.g., "Deteção de tráfego malicioso, tentativas de exploração"]
• Reportes de Utilizadores: [canal, e.g., "Email security@organization.pt, botão 'Report Phishing' no Outlook"]
• Threat Intelligence: [fontes, e.g., "Feeds de IOCs, alertas de fornecedores"]
• Auditorias e Logs: [descrição, e.g., "Análise de logs de acesso, auditorias de alterações"]

4.2.2 Canais de Reporte

Qualquer pessoa pode reportar um incidente através de:

• Email Dedicado: [email, e.g., "incidents@organization.pt"]
• Telefone 24/7: [número de emergência]
• Portal de Tickets: [URL e instruções]
• Chat Interno: [canal, e.g., "Canal #security-incidents no Slack/Teams"]

4.2.3 Triagem Inicial

Ao receber um reporte, o Security Analyst (Tier 1) executa:

1. Validação: [procedimento, e.g., "Confirmar se é evento de segurança ou incidente, descartar falsos positivos"]
2. Classificação Preliminar: [procedimento, e.g., "Atribuir severidade inicial (Baixo/Médio/Alto/Crítico)"]
3. Criação de Ticket: [procedimento, e.g., "Abrir ticket no sistema com todas as informações disponíveis"]
4. Notificação: [procedimento, e.g., "Alertar Incident Response Manager para incidentes Alto/Crítico"]

4.3 Fase 3: Avaliação e Decisão

Análise profunda do incidente e decisão sobre a resposta adequada:

4.3.1 Análise de Severidade

O Security Analyst (Tier 2) ou Incident Response Manager avalia:

• Escopo do Comprometimento: [fatores, e.g., "Número de sistemas afetados, dados expostos, propagação do incidente"]
• Impacto no Negócio: [fatores, e.g., "Serviços afetados, clientes impactados, perda financeira estimada"]
• Vector de Ataque: [análise, e.g., "Como o atacante entrou, TTPs utilizadas, persistência estabelecida"]
• Risco de Propagação: [avaliação, e.g., "Potencial de movimentação lateral, sistemas adjacentes vulneráveis"]

4.3.2 Classificação Final

Com base na análise, o incidente é classificado definitivamente usando a matriz de severidade (Secção 2.2).

4.3.3 Decisão de Ativação

• Incidentes Críticos: [decisão, e.g., "Ativação imediata do plano completo, convocação de todo o CSIRT, notificação ao CISO e administração"]
• Incidentes Alto: [decisão, e.g., "Ativação de equipa alargada, notificação ao Incident Response Manager"]
• Incidentes Médio/Baixo: [decisão, e.g., "Gestão por Security Analysts, escalation se necessário"]

4.4 Fase 4: Resposta

Execução de ações coordenadas para conter, erradicar e recuperar do incidente:

4.4.1 Contenção

Objetivo: Limitar o impacto e prevenir propagação do incidente.

Contenção Imediata (Short-term):

• Isolamento de Sistemas: [ações, e.g., "Desconectar sistemas comprometidos da rede, isolar VLANs afetadas"]
• Bloqueio de Acessos: [ações, e.g., "Revogar credenciais comprometidas, bloquear IPs maliciosos no firewall"]
• Desativação de Contas: [ações, e.g., "Suspender contas de utilizador suspeitas, desativar contas de serviço comprometidas"]
• Preservação de Evidências: [ações, e.g., "Captura de imagens de memória, snapshot de VMs, preservação de logs"]

Contenção Sustentada (Long-term):

• Segmentação de Rede: [ações, e.g., "Implementar micro-segmentação, restringir comunicação entre VLANs"]
• Hardening Temporário: [ações, e.g., "Aplicar configurações de segurança reforçadas, ativar autenticação multi-fator obrigatória"]
• Monitorização Reforçada: [ações, e.g., "Aumentar nível de logging, implementar alertas adicionais"]

4.4.2 Erradicação

Objetivo: Remover completamente a ameaça do ambiente.

• Remoção de Malware: [ações, e.g., "Executar scans antimalware em todos os sistemas, remover persistência de malware"]
• Patch de Vulnerabilidades: [ações, e.g., "Aplicar patches de segurança para vulnerabilidades exploradas"]
• Remoção de Backdoors: [ações, e.g., "Identificar e remover todas as formas de acesso persistente do atacante"]
• Correção de Configurações: [ações, e.g., "Corrigir misconfigurations que permitiram o incidente"]
• Reset de Credenciais: [ações, e.g., "Forçar reset de passwords de todas as contas potencialmente comprometidas"]

4.4.3 Recuperação

Objetivo: Restaurar sistemas e operações normais com confiança.

• Restore de Sistemas: [ações, e.g., "Restaurar sistemas a partir de backups verificados e limpos"]
• Validação de Integridade: [ações, e.g., "Verificar integridade de dados restaurados, executar scans de segurança completos"]
• Reconexão Gradual: [ações, e.g., "Reconectar sistemas à rede de forma faseada com monitorização intensiva"]
• Testes Funcionais: [ações, e.g., "Validar que sistemas restaurados funcionam corretamente"]
• Monitorização Pós-Recuperação: [ações, e.g., "Monitorização 24/7 durante X dias para detetar recorrência"]

4.5 Fase 5: Lições Aprendidas

Análise pós-incidente para melhoria contínua:

4.5.1 Post-Incident Review Meeting

Timing: [quando, e.g., "Até 5 dias úteis após encerramento do incidente"]

Participantes: [quem, e.g., "Todo o CSIRT, stakeholders afetados, gestão sénior para incidentes críticos"]

Agenda da Reunião:

1. Timeline do Incidente: [tópico, e.g., "Reconstrução detalhada do que aconteceu e quando"]
2. Root Cause Analysis: [tópico, e.g., "Identificação da causa raiz e fatores contribuintes"]
3. O Que Funcionou Bem: [tópico, e.g., "Aspetos da resposta que foram eficazes"]
4. O Que Pode Melhorar: [tópico, e.g., "Gaps identificados, atrasos, ferramentas em falta"]
5. Ações Corretivas: [tópico, e.g., "Lista de ações prioritizadas com responsáveis e prazos"]

4.5.2 Documentação

• Relatório de Incidente: [requisitos, e.g., "Documento completo com timeline, ações tomadas, impacto, custos"]
• Atualização de IOCs: [ação, e.g., "Adicionar novos IOCs ao threat intelligence platform"]
• Knowledge Base: [ação, e.g., "Criar artigo com lições aprendidas e procedimentos melhorados"]

4.5.3 Ações Corretivas e Preventivas

• Melhorias Técnicas: [exemplos, e.g., "Implementar novas regras de deteção, fortalecer controlos"]
• Melhorias de Processo: [exemplos, e.g., "Atualizar playbooks, reduzir tempos de resposta"]
• Formação Adicional: [exemplos, e.g., "Treinar equipa em técnicas específicas identificadas como gaps"]
• Atualização do Plano: [ação, e.g., "Incorporar lições aprendidas neste plano de resposta"]

4.5.4 Sharing e Colaboração

• Sharing com CERT.PT/CNCS: [quando, e.g., "Partilhar IOCs e TTPs anonimizadas para beneficiar comunidade"]
• Partilha Setorial: [quando, e.g., "Partilhar alertas com parceiros do setor através de ISACs"]

5. Playbook: Ransomware

5.1 Indicadores de Comprometimento (IOCs)

Sinais que podem indicar ataque de ransomware:

• Alterações em Ficheiros: [sinais, e.g., "Extensões de ficheiros alteradas (.locked, .encrypted, .crypted), ficheiros renomeados em massa"]
• Notas de Resgate: [sinais, e.g., "Ficheiros README.txt, HOW_TO_DECRYPT.html em múltiplos diretórios"]
• Processos Suspeitos: [sinais, e.g., "Processos de encriptação em execução, processos com nomes aleatórios consumindo CPU"]
• Conexões de Rede: [sinais, e.g., "Comunicação com C2 servers conhecidos, exfiltração de dados antes de encriptação"]
• Alterações no Sistema: [sinais, e.g., "Shadow copies deletadas, backups removidos, logs apagados"]
• Alertas EDR/AV: [sinais, e.g., "Múltiplos alertas de behavioral detection, tentativas de desativar antivírus"]

5.2 Contenção Imediata (Primeiros 15 Minutos)

PRIORIDADE MÁXIMA: Parar a propagação antes de mais danos.

5.3 Análise e Identificação (30-60 Minutos)

Identificar a variante de ransomware e avaliar opções de recuperação:

5.3.1 Identificação da Variante

• Análise da Nota de Resgate: [ação, e.g., "Recolher texto completo da nota, URLs de pagamento, contactos"]
• Identificação de Extensão: [ação, e.g., "Documentar extensão usada nos ficheiros encriptados"]
• Consulta de Bases de Dados: [ação, e.g., "Verificar ID Ransomware (https://id-ransomware.malwarehunterteam.com/), No More Ransom"]
• Análise de Amostras: [ação, e.g., "Enviar amostras para sandbox (Any.Run, Hybrid Analysis) e threat intelligence"]

5.3.2 Avaliação de Decryptor

• Verificar No More Ransom: [ação, e.g., "Procurar decryptor gratuito em https://www.nomoreransom.org/"]
• Consulta com Fornecedores: [ação, e.g., "Contactar fornecedores de segurança (Kaspersky, ESET, Avast) para decryptors"]
• Análise de Viabilidade: [ação, e.g., "Se não existe decryptor, avançar para análise de opções de recuperação"]

5.3.3 Scope do Impacto

• Sistemas Afetados: [inventariar, e.g., "Listar todos os sistemas encriptados, VMs, servidores, endpoints"]
• Dados Comprometidos: [avaliar, e.g., "Identificar que dados foram encriptados e criticidade de cada dataset"]
• Exfiltração: [investigar, e.g., "Verificar se houve exfiltração de dados antes da encriptação (double extortion)"]
• Impacto no Negócio: [quantificar, e.g., "Calcular downtime, perda de receita, custos de recuperação"]

5.4 Decisão sobre Pagamento de Resgate

5.4.1 Critérios de Avaliação

Considerar os seguintes fatores:

• Criticidade dos Dados: [fator, e.g., "Dados encriptados são críticos para continuidade do negócio? Existem alternativas?"]
• Disponibilidade de Backups: [fator, e.g., "Backups estão íntegros e permitem recuperação completa?"]
• Custo de Recuperação vs. Resgate: [fator, e.g., "Análise custo-benefício de rebuilding vs. pagamento"]
• Tempo de Recuperação: [fator, e.g., "Organização pode suportar downtime de X dias para rebuild?"]
• Reputação e Confiança: [fator, e.g., "Impacto reputacional de não recuperar vs. de pagar criminosos"]
• Garantias de Decryptor: [fator, e.g., "Existe garantia de que atacantes fornecerão decryptor funcional? Histórico desta gang?"]

5.4.2 Processo de Aprovação

Se considerado pagamento de resgate:

1. Aprovação da Administração: [requisito, e.g., "Decisão final pelo CEO/Board após apresentação de todas as opções"]
2. Consulta Jurídica: [requisito, e.g., "Validar legalidade do pagamento, considerações de sanctions compliance"]
3. Consulta com Seguradora: [requisito, e.g., "Verificar cobertura da apólice para ransom payment"]
4. Negociação: [ação, e.g., "Considerar envolver negociador profissional especializado em ransomware"]

5.4.3 Considerações Legais e Éticas

• Financiamento de Crime: [consideração, e.g., "Pagamento financia organizações criminosas e incentiva mais ataques"]
• Sanctions e AML: [consideração, e.g., "Verificar se gang está em lista de sanctions (OFAC, EU)"]
• Recomendação de Autoridades: [posição, e.g., "FBI, Europol, CNCS desencorajam pagamento de resgate"]

5.5 Recuperação

5.5.1 Recuperação via Backups (Opção Preferencial)

• Validação de Backups: [ação, e.g., "Verificar integridade e completude dos backups disponíveis"]
• Priorização de Sistemas: [ação, e.g., "Ordenar restauro: 1) Sistemas críticos, 2) Infraestrutura de suporte, 3) Sistemas secundários"]
• Ambiente de Staging: [ação, e.g., "Restaurar inicialmente em ambiente isolado para validação"]
• Scan de Segurança: [ação, e.g., "Executar scan completo de malware antes de colocar em produção"]
• Restauro Faseado: [ação, e.g., "Restaurar sistema por sistema com validação antes de avançar"]

5.5.2 Rebuild de Sistemas

Se backups não disponíveis ou comprometidos:

• Wipe Completo: [ação, e.g., "Formatar e reinstalar sistemas do zero"]
• Rebuild from Gold Images: [ação, e.g., "Usar imagens base verificadas e hardened"]
• Recriação de Dados: [ação, e.g., "Recuperar dados de fontes alternativas (mobile backups, cloud sync, etc.)"]

5.5.3 Hardening Pós-Recuperação

• Patch Management: [ação, e.g., "Garantir todos os sistemas recuperados têm patches atualizados"]
• Segmentação Reforçada: [ação, e.g., "Implementar micro-segmentação para limitar movimentação lateral"]
• Credenciais: [ação, e.g., "Reset de todas as passwords, implementar MFA obrigatória"]
• Monitorização Reforçada: [ação, e.g., "Aumentar logging e alerting durante 90 dias pós-incidente"]

5.6 Comunicação e Notificações

5.6.1 Notificações Regulatórias Obrigatórias (NIS2)

• CNCS - 24 Horas: [ação, e.g., "Notificação inicial de incidente significativo via portal CNCS"]
• CNCS - 72 Horas: [ação, e.g., "Atualização com detalhes de impacto, medidas de contenção tomadas"]
• CNCS - 30 Dias: [ação, e.g., "Relatório final com análise completa, lições aprendidas, medidas preventivas"]

Templates de Notificação:

• 📋 Notificação CNCS 24 Horas
• 📋 Notificação CNCS 72 Horas
• 📋 Relatório Final 30 Dias

5.6.2 Comunicação Interna

• Administração: [frequência, e.g., "Briefings de 4 em 4 horas durante fase crítica"]
• Colaboradores: [mensagem, e.g., "Comunicado sobre incidente, instruções de segurança, canais de suporte"]
• IT Teams: [coordenação, e.g., "War room com updates contínuos"]

5.6.3 Comunicação Externa

• Clientes/Parceiros: [quando, e.g., "Notificar se serviços afetados ou dados de clientes comprometidos"]
• Media: [estratégia, e.g., "Comunicado oficial preparado por Communications Lead, aprovado por administração"]
• Seguradoras: [timing, e.g., "Notificação imediata conforme termos da apólice"]

6. Playbook: Data Breach (Violação de Dados)

6.1 Identificação de Dados Expostos

Determinar com precisão que dados foram comprometidos:

6.1.1 Tipos de Dados

• Dados Pessoais (GDPR Art. 4): [identificar, e.g., "Nomes, emails, moradas, NIF, números de telefone, IPs"]
• Dados Pessoais Sensíveis (GDPR Art. 9): [identificar, e.g., "Dados de saúde, origem racial/étnica, convicções religiosas, dados biométricos"]
• Dados Financeiros: [identificar, e.g., "Números de cartão de crédito, IBANs, histórico de transações"]
• Credenciais de Acesso: [identificar, e.g., "Usernames, passwords (hashed/plaintext), tokens, API keys"]
• Propriedade Intelectual: [identificar, e.g., "Código-fonte, designs, trade secrets"]
• Dados de Negócio: [identificar, e.g., "Contratos, informações financeiras corporativas, estratégias"]

6.1.2 Volume e Titulares Afetados

• Número de Registos: [quantificar, e.g., "Estimar número total de registos de dados expostos"]
• Titulares de Dados: [identificar, e.g., "Clientes, colaboradores, fornecedores, prospects?"]
• Jurisdições: [mapear, e.g., "Titulares são de UE, Portugal, internacional? Implicações regulatórias"]
• Menores de Idade: [verificar, e.g., "Dados de crianças envolvidos? (GDPR Art. 8)"]

6.1.3 Vector de Exposição

• Como Ocorreu: [investigar, e.g., "Ataque cibernético, misconfiguration, insider threat, perda física?"]
• Duração da Exposição: [determinar, e.g., "Desde quando os dados estavam expostos?"]
• Acesso Confirmado: [avaliar, e.g., "Há evidência de que alguém acedeu aos dados? Ou apenas potencial de acesso?"]

6.2 Avaliação de Risco (GDPR Art. 33-34)

Determinar o nível de risco para os direitos e liberdades dos titulares:

6.3 Notificações Obrigatórias

6.3.1 Timeline de Notificações

6.3.2 Exceções à Notificação aos Titulares

Não é necessário comunicar aos titulares se (GDPR Art. 34(3)):

• Medidas técnicas: [e.g., "Dados tornados ininteligíveis (encriptação forte) e chave não comprometida"]
• Medidas Subsequentes: [e.g., "Foram tomadas medidas que asseguram que risco elevado deixou de existir"]
• Esforço Desproporcionado: [e.g., "Comunicação individual exigiria esforço desproporcionado - usar comunicação pública"]

6.4 Contenção e Remediação

6.4.1 Contenção Imediata

• Parar Exposição: [ação, e.g., "Fechar vector de acesso (e.g., tornar bucket S3 privado, desativar conta comprometida)"]
• Revogar Acessos: [ação, e.g., "Revogar tokens/API keys expostas, desativar contas comprometidas"]
• Isolar Sistemas: [ação, e.g., "Isolar base de dados comprometida enquanto se investiga"]

6.4.2 Análise Forense

• Timeline de Exposição: [investigar, e.g., "Determinar quando a exposição começou e terminou"]
• Logs de Acesso: [analisar, e.g., "Revisar logs para identificar se dados foram acedidos/exfiltrados"]
• Identificação de Atacante: [investigar, e.g., "IPs de origem, TTPs utilizadas, atribuição se possível"]

6.4.3 Remediação

• Correção da Vulnerabilidade: [ação, e.g., "Patch de vulnerabilidade explorada, correção de misconfiguration"]
• Reset de Credenciais: [ação, e.g., "Forçar reset de passwords de todas as contas afetadas"]
• Reforço de Controlos: [ação, e.g., "Implementar MFA, encriptação de dados sensíveis, DLP"]

6.5 Comunicação aos Titulares de Dados

6.5.1 Preparação da Comunicação

• Aprovação Legal: [requisito, e.g., "Revisão e aprovação pelo departamento jurídico antes de envio"]
• Linguagem Clara: [requisito, e.g., "Evitar jargão técnico, usar linguagem acessível ao público geral"]
• Transparência: [requisito, e.g., "Ser honesto sobre o que aconteceu, que dados foram afetados, que medidas foram tomadas"]

6.5.2 Conteúdo Obrigatório

A comunicação deve incluir:

• O Que Aconteceu: [descrição simples do incidente]
• Que Dados Foram Afetados: [lista específica]
• Quando Ocorreu: [timeline]
• O Que Estamos a Fazer: [medidas tomadas]
• O Que Pode Fazer: [ações recomendadas aos titulares, e.g., "alterar password, monitorizar extratos bancários"]
• Contacto para Questões: [email/telefone do DPO ou linha de apoio dedicada]
• Serviços de Apoio: [se aplicável, e.g., "Oferecemos 12 meses de serviço de monitorização de crédito gratuito"]

6.5.3 Canais de Comunicação

• Email Individual: [quando, e.g., "Método preferencial se temos emails válidos dos titulares"]
• Carta Registada: [quando, e.g., "Para dados sensíveis ou se não temos emails"]
• Comunicação Pública: [quando, e.g., "Se comunicação individual for desproporcionada - via website, imprensa"]
• FAQ Dedicada: [requisito, e.g., "Criar página web com FAQs sobre o incidente"]

6.6 Monitorização Pós-Breach

• Dark Web Monitoring: [ação, e.g., "Monitorizar fóruns e marketplaces para verificar se dados foram publicados/vendidos"]
• Alertas de Fraude: [ação, e.g., "Monitorizar para atividades fraudulentas usando dados expostos"]
• Apoio aos Titulares: [ação, e.g., "Linha de apoio dedicada durante X meses pós-incidente"]
• Reporte Periódico: [ação, e.g., "Updates aos titulares se novos desenvolvimentos (e.g., dados encontrados em leak)"]