Governação de pagamentos de resgate em ransomware para NIS2 e DORA

São 03:17 de um dia útil em 2026. Maria, Diretora de Segurança da Informação (CISO) de uma plataforma fintech em rápido crescimento, é chamada para uma ponte de crise por uma mensagem do analista principal do SOC: cifragem generalizada confirmada, serviços críticos indisponíveis e um grupo de ransomware a alegar ter exfiltrado 2 TB de dados de clientes.

O Diretor Executivo entra primeiro na chamada. Seguem-se as equipas jurídica, de privacidade, financeira e de comunicações, a seguradora cibernética, um prestador forense e a equipa de operações de nuvem. Um portal na dark web mostra uma contagem decrescente de 48 horas e um pedido de sete dígitos em criptomoeda.

O Diretor Executivo faz a pergunta que todos os CISO receiam.

“Podemos pagar, e quem tem autoridade para decidir?”

A resposta errada é tratar isto como um problema de negociação. A resposta certa é tratá-lo como um problema de governação.

Em 2026, a governação da decisão de pagamento de resgate em ransomware já não é uma escolha técnica e privada tomada em crise. Pode ser escrutinada por reguladores, auditores, seguradoras, clientes, forças de segurança, acionistas e pelo conselho de administração. Uma decisão de pagamento cruza exposição a sanções, avaliação de violação de dados pessoais, condições do ciberseguro, obrigações contratuais, comunicações de crise, preservação de evidência, reporte faseado ao abrigo da NIS2, classificação de incidentes segundo o DORA, notificação ao abrigo do RGPD da UE e melhoria pós-incidente.

É por isso que a Clarysec aconselha os clientes a criarem a governação da decisão de pagamento de resgate em ransomware dentro do SGSI antes do incidente. A ISO/IEC 27001:2022 fornece a estrutura do sistema de gestão. Os controlos da ISO/IEC 27002:2022 fornecem o modelo operacional. Zenith Blueprint: roteiro de 30 passos para auditores e Zenith Controls: guia de conformidade cruzada ajudam a transformar essa estrutura em evidência prática e auditável.

Um playbook de ransomware que diga “notificar a equipa jurídica” não é suficiente. A organização deve saber quem pode autorizar a negociação, como é realizada a verificação de sanções, quando a seguradora deve aprovar, como é documentada a classificação segundo o RGPD da UE, a NIS2 e o DORA, e como a evidência é protegida enquanto as equipas de recuperação trabalham sob pressão.

Porque falham as decisões ad hoc de pagamento de ransomware

Uma decisão de pagamento de resgate em ransomware é frequentemente descrita como binária: pagar ou não pagar. Na realidade, a decisão tem pelo menos seis camadas:

1. O evento está confirmado, contido e corretamente classificado?
2. Estão afetados dados pessoais, dados regulados ou a prestação de serviços críticos?
3. A organização está legalmente autorizada a comunicar ou transacionar com o agente de ameaça?
4. O ciberseguro exige notificação prévia, fornecedores aprovados, consentimento ou evidência específica?
5. O pagamento reduziria o impacto no negócio ou aumentaria o risco jurídico, financeiro e reputacional?
6. Quem tem autoridade para decidir e como é registada essa decisão?

Durante um incidente em curso, equipas desconectadas tendem a avançar em direções diferentes. O Diretor Financeiro pode ver o resgate como uma despesa de negócio perante o aumento do tempo de indisponibilidade. A equipa jurídica vê sanções, criminalidade financeira e exposição regulatória. O EPD está a avaliar se os dados cifrados ou exfiltrados criam uma violação de dados pessoais notificável. A função de conformidade está a acompanhar os prazos de reporte da NIS2 e do DORA. O CISO tenta preservar evidência enquanto restaura serviços. O Diretor Executivo quer uma recomendação antes de expirar o temporizador do atacante.

Sem um processo formal de decisão, a voz mais alta na sala pode tornar-se o modelo de governação. É exatamente essa a situação que a regulação moderna de cibersegurança pretende evitar.

A NIS2 torna a cibersegurança uma responsabilidade da gestão. O Article 20 aborda a governação e a responsabilização dos órgãos de gestão, enquanto o Article 21 exige medidas de gestão de riscos que abrangem tratamento de incidentes, continuidade de negócio, gestão de cópias de segurança, gestão de crises, segurança da cadeia de fornecimento, controlo de acesso, gestão de ativos, MFA e avaliação da eficácia. O Article 23 cria reporte faseado para incidentes significativos, incluindo alerta precoce no prazo de 24 horas, notificação no prazo de 72 horas e relatório final no prazo de um mês, quando aplicável.

Para entidades financeiras, o DORA é o normativo setorial de resiliência operacional. O Article 5 atribui ao órgão de gestão a responsabilidade pela gestão do risco das TIC. Os Articles 17, 18 e 19 abordam a gestão de incidentes relacionados com TIC, a classificação e a comunicação de incidentes graves relacionados com TIC. O DORA também exige capacidades de resposta e recuperação, cópia de segurança e restauro, aprendizagem pós-incidente, testes e gestão do risco de terceiros de TIC.

O RGPD da UE acrescenta uma avaliação separada, mas sobreposta. Se o ransomware causar destruição, perda, alteração, divulgação não autorizada ou acesso não autorizado a dados pessoais, de forma acidental ou ilícita, o responsável pelo tratamento deve avaliar se ocorreu uma violação de dados pessoais. Se a notificação for exigida, o prazo perante a autoridade de controlo é geralmente de 72 horas a contar da tomada de conhecimento. Se existir risco elevado para as pessoas singulares, também pode ser necessária comunicação aos titulares afetados.

A conclusão é simples: a pergunta sobre o resgate não deve ser feita pela primeira vez dentro da sala de crise.

Controlos ISO 27001:2022 que sustentam a governação do pagamento

Um SGSI ISO/IEC 27001:2022 não é uma lista de verificação para auditores. É um sistema de gestão para tomar decisões baseadas no risco. A governação de pagamentos de resgate em ransomware pertence a esse sistema porque combina avaliação de riscos, tratamento de riscos, papéis, obrigações legais, resposta a incidentes, continuidade, gestão de fornecedores e melhoria contínua.

Os controlos mais relevantes do Anexo A da ISO 27001:2022 formam uma cadeia de controlos interligada.

No Zenith Controls, a secção relativa a A.5.24, planeamento e preparação da gestão de incidentes de segurança da informação, classifica o controlo como corretivo, ligado à confidencialidade, integridade e disponibilidade, e alinhado com os conceitos de resposta e recuperação. Também liga A.5.24 à avaliação de eventos A.5.25, à aprendizagem com incidentes A.5.27, ao registo em logs A.8.15, à monitorização A.8.16, à segurança durante interrupções A.5.29, à continuidade e ao contacto com autoridades.

Isto é importante porque a governação do pagamento de resgate em ransomware é uma cadeia. Se não consegue detetar e classificar o evento, não consegue decidir. Se não consegue preservar evidência, não consegue defender a decisão. Se as obrigações legais não estiverem mapeadas, a negociação ou o pagamento podem ser ilícitos. Se as opções de recuperação não tiverem sido testadas, os executivos podem ser pressionados a decidir com base no receio e não em factos.

O Zenith Controls descreve de forma direta a relação entre preparação e tomada de decisão:

“5.25 é o ponto de decisão que determina quando um evento ultrapassa o limiar e se torna um incidente de segurança, acionando as ações descritas em 5.26. Uma avaliação tempestiva e precisa do evento garante que a resposta a incidentes não é atrasada nem mal direcionada.”

O mesmo guia liga A.5.31, requisitos legais, estatutários, regulamentares e contratuais, à privacidade, à retenção de registos, à revisão independente e ao cumprimento das políticas internas. Para ransomware, A.5.31 é onde a verificação de sanções, as obrigações do seguro, a interação com forças de segurança, os contratos de clientes, os deveres de proteção de dados e o reporte regulamentar setorial são registados num único Registo de Obrigações de Conformidade.

O modelo Clarysec de cinco portas para a governação do pagamento de resgate em ransomware

O modelo da Clarysec separa a governação da decisão de pagamento de resgate em ransomware em cinco portas. A finalidade não é tornar o pagamento mais fácil. É tornar qualquer decisão, incluindo a recusa de pagamento, baseada em evidência, revista juridicamente, autorizada e auditável.

Este modelo utiliza a lógica de tratamento de riscos da ISO 27001. Um pagamento de ransomware não é um controlo de segurança. É, no máximo, uma opção de crise considerada num contexto de tratamento de riscos e recuperação. Antes de um incidente, a organização já deve ter decidido como os riscos de ransomware são tratados: mitigar através de controlos, transferir parte da exposição financeira por meio de seguro, evitar dependências legadas inaceitáveis ou aceitar explicitamente o risco residual quando justificado.

Na fase de Gestão de Riscos, Passo 13, Planeamento do Tratamento de Riscos e Declaração de Aplicabilidade, o Zenith Blueprint instrui as organizações a determinar opções de tratamento para cada risco e a documentá-las no Registo de Riscos. Alerta que a transferência, como o ciberseguro, não elimina a necessidade de controlos, porque a transferência aborda frequentemente o impacto financeiro e não a probabilidade. Também afirma:

“A aceitação deve ser explícita e aprovada pela gestão, especialmente para quaisquer riscos Médios. Riscos Elevados raramente são aceites, salvo quando verdadeiramente inevitáveis e acordados ao nível de topo.”

Essa afirmação é diretamente relevante para a governação do pagamento de resgate em ransomware. Se for solicitado ao conselho de administração que aceite o risco residual de recusar o pagamento, ou o risco jurídico e reputacional de aprovar a negociação, a aceitação deve ser explícita, registada e aprovada pela autoridade correta.

A Política de Gestão de Riscos da Clarysec reforça o mesmo ponto:

“As decisões de tratamento do risco devem alinhar-se com as opções predefinidas”
Da cláusula 5.5.

Uma decisão sobre resgate não é, portanto, um atalho à gestão de riscos. Deve ser tratada como uma decisão formal e documentada de tratamento de riscos, sob autoridade definida.

Autoridade da política: quem pode decidir sob pressão?

Muitas falhas em ransomware são falhas de governação disfarçadas de falhas técnicas. Alguém contacta o atacante fora do canal aprovado. Alguém promete pagamento antes da aprovação da seguradora. Alguém restaura sistemas e sobrescreve evidência forense. Alguém informa os clientes demasiado cedo, demasiado tarde ou com factos imprecisos.

As políticas da Clarysec são concebidas para eliminar essa ambiguidade.

Para PME, a Política de Papéis e Responsabilidades de Governação para PME estabelece uma regra simples:

“Todas as decisões, exceções e escalonamentos significativos de segurança devem ser registados e rastreáveis.”
Da secção “Requisitos de governação”, cláusula 5.5 da política.

A Política de Resposta a Incidentes para PME atribui a autoridade de escalonamento:

“O Diretor-Geral (GM) é responsável por autorizar todas as decisões de escalonamento de incidentes, notificações regulamentares e comunicações externas.”
Da secção “Requisitos de governação”, cláusula 5.1.1 da política.

Também liga incidentes com dados de clientes a obrigações regulamentares:

“Quando estejam envolvidos dados de clientes, o Diretor-Geral deve avaliar as obrigações legais de notificação com base na aplicabilidade do RGPD da UE, NIS2 ou DORA.”
Da secção “Tratamento do risco e exceções”, cláusula 7.4.1 da política.

Para organizações de maior dimensão, a Política de Papéis e Responsabilidades de Governação empresarial exige escalonamento imediato quando possam existir exposição jurídica ou violações de dados notificáveis:

“Escalonamento jurídico-regulatório: Incidentes que envolvam potencial exposição jurídica ou violações de dados notificáveis devem ser escalados imediatamente para o Responsável Jurídico e de Conformidade e para a gestão de topo.”
Da secção “Requisitos de implementação da política”, cláusula 6.4.3 da política.

A Política de Resposta a Incidentes empresarial define a autoridade executiva durante incidentes graves. A cláusula 4.6.1 estabelece que o papel da Equipa de Gestão de Topo é:

“Tomar decisões estratégicas durante incidentes de severidade elevada, incluindo a aprovação de notificações e comunicações públicas.”

Num contexto de ransomware, a Clarysec trata a discussão sobre pagamento, a autorização de negociação, o aviso a clientes, a declaração regulamentar e a comunicação pública como decisões estratégicas, não como ações técnicas.

Daqui resulta uma regra prática de governação: o CISO pode recomendar, a equipa de incidentes pode avaliar, a equipa jurídica pode aconselhar, as finanças podem validar a mecânica de pagamento, a seguradora pode consentir ou recusar cobertura, mas a gestão de topo ou o conselho de administração devem assumir a decisão de acordo com a autoridade predefinida.

Escalonamento seguro em matéria de sanções antes de qualquer negociação

Um processo de ransomware seguro em matéria de sanções começa com uma proibição: nenhum trabalhador, contratado, fornecedor, intermediário, negociador ou responsável por resposta a incidentes pode negociar, prometer, facilitar ou transferir valor para um agente de ameaça sem revisão jurídica aprovada.

O ponto de controlo jurídico deve ocorrer antes de qualquer interação ativa com o atacante, não depois de surgir um endereço de carteira. O processo deve incluir:

• Envolvimento da assessoria jurídica antes de qualquer comunicação para além da recolha passiva de evidência.
• Identificação do agente de ameaça utilizando contributos forenses, informações sobre ameaças e forças de segurança, quando disponíveis.
• Verificação de sanções e de partes restritas para nomes de grupos, aliases, endereços de carteiras, infraestrutura, intermediários e canais de pagamento.
• Consulta às forças de segurança considerada e registada.
• Seguradora cibernética notificada de acordo com os termos da apólice antes da nomeação de fornecedores ou do início de negociações.
• EPD ou responsável de privacidade envolvido se puderem estar em causa dados pessoais.
• Diretor Financeiro ou responsável financeiro confirma controlos de pagamento, segregação de funções, verificações antifraude e requisitos de aprovação pelo conselho de administração.
• Decisão executiva registada com alternativas consideradas, incluindo restauro, contenção, suspensão de serviços, comunicação a clientes e recusa de pagamento.
• Evidência preservada para comunicações do atacante, indicadores, detalhes de carteiras, reuniões de decisão, aprovações e aconselhamento externo.

Para ransomware, o registo legal deve incluir, pelo menos, as seguintes fontes de obrigações.

As organizações também devem definir quem pode travar a decisão de pagamento. A equipa jurídica, a conformidade, o EPD, a assessoria de sanções ou o conselho de administração devem ter autoridade explícita para suspender a negociação ou o pagamento se a verificação estiver incompleta, a evidência não for fiável, as condições da seguradora não estiverem cumpridas ou a ação puder violar a lei ou o contrato.

Preservação de evidência: não destruir a prova ao restaurar o serviço

As equipas de ransomware tendem naturalmente a apressar o restauro das operações. Mas se o restauro destruir logs, snapshots, notas de resgate, amostras de malware, imagens de memória ou mensagens do atacante, a organização pode perder a capacidade de provar o que aconteceu.

Na fase Controls in Action, Passo 23, Controlos organizacionais, o Zenith Blueprint orienta as organizações a validar e testar capacidades de gestão de incidentes através da definição de eventos de segurança reportáveis, da documentação da tomada de decisão e da preservação de evidência forense. Instrui as equipas a:

“Capturar e registar em logs todas as decisões, papéis e comunicações (5.26), e atualizar o plano com as lições aprendidas (5.27). Confirmar que existem procedimentos para preservar evidência forense (5.28), incluindo snapshots de logs, cópias de segurança e isolamento seguro de sistemas impactados.”

O mesmo passo explica A.5.28 numa linguagem que qualquer conselho de administração deve compreender:

“aquilo que consegue provar é tão importante como aquilo que realmente aconteceu”

A Política de Recolha de Evidência e Análise Forense empresarial da Clarysec reforça que a evidência deve permanecer rastreável:

“Um registo de cadeia de custódia deve acompanhar toda a evidência física ou digital desde o momento da aquisição até ao arquivo ou transferência e deve documentar:”
Da secção “Requisitos de governação”, cláusula 5.6 da política.

Para PME, a Política de Recolha de Evidência e Análise Forense para PME é deliberadamente prática:

“Deve ser sempre criada uma cópia forense ou exportação; a evidência original nunca deve ser editada diretamente.”
Da secção “Requisitos de implementação da política”, cláusula 6.1.1 da política.

Também exige consulta jurídica quando possa existir impacto em Recursos Humanos, jurídico ou em clientes:

“Se o incidente envolver potencial impacto em Recursos Humanos (RH), jurídico ou em clientes, o GM deve consultar a assessoria jurídica antes de prosseguir com a aplicação ou escalonamento.”
Da secção “Requisitos de governação”, cláusula 5.4.2 da política.

Um pacote prático de evidência deve ser aberto durante a Porta 2. Crie uma pasta restrita de evidência do incidente. Exporte cronologias de SIEM, deteções de EDR, logs de auditoria da nuvem, logs de autenticação do fornecedor de identidade, estado das tarefas de cópia de segurança, notas de resgate, capturas de ecrã, mensagens do atacante, endereços de carteiras, amostras de ficheiros, referências a pareceres jurídicos, correspondência com a seguradora e decisões de reuniões. Designe um custodiante. Registe valores de hash quando adequado. Não permita que administradores limpem sistemas impactados antes da aquisição forense, salvo se a segurança de pessoas, a proteção de serviços críticos ou uma contenção aprovada pela autoridade executiva o exigirem.

Uma única folha de classificação para NIS2, DORA e RGPD da UE

Um incidente de ransomware pode acionar múltiplos prazos. O desafio não é apenas conhecer os prazos. É saber quando a organização tomou conhecimento, o que sabia nesse momento e como foram tomadas as decisões de classificação.

O Article 23 da NIS2 exige que entidades essenciais e importantes notifiquem o CSIRT ou a autoridade competente, sem demora indevida, sobre incidentes significativos. A significância está associada a perturbação operacional grave, perda financeira ou danos materiais ou imateriais consideráveis para terceiros. O modelo faseado inclui alerta precoce no prazo de 24 horas, notificação no prazo de 72 horas, atualizações intermédias se solicitadas e um relatório final no prazo de um mês após a notificação do incidente, quando aplicável.

O DORA exige que as entidades financeiras definam e implementem a gestão de incidentes relacionados com TIC, registem incidentes e ameaças cibernéticas significativas, classifiquem incidentes utilizando critérios como clientes afetados, duração, dispersão geográfica, perda de dados, criticidade e impacto económico, e comuniquem incidentes graves relacionados com TIC às autoridades competentes através de relatórios iniciais, intermédios e finais.

O RGPD da UE coloca uma pergunta diferente, mas sobreposta: o incidente causou uma violação de dados pessoais? Em caso afirmativo, é provável que resulte num risco para as pessoas singulares? Se o limiar de notificação for atingido, a notificação à autoridade de controlo deve ser avaliada face ao prazo de 72 horas. Se existir risco elevado, também pode ser necessária comunicação às pessoas singulares.

A Clarysec recomenda a utilização de uma única folha de classificação de ransomware com secções separadas para cada regime.

Esta abordagem enquadra-se nas cláusulas da ISO 27001 sobre avaliação de riscos, tratamento de riscos e informação documentada. Também se alinha com o NIST CSF 2.0. A função GOVERN do NIST CSF 2.0 espera que as organizações compreendam partes interessadas, obrigações legais e regulamentares, apetite ao risco, papéis, política, supervisão e risco de terceiros. Os seus resultados de deteção, resposta e recuperação suportam a declaração de incidentes, análise, coordenação da resposta, notificação às partes interessadas, execução da recuperação e validação do restauro.

Para entidades financeiras, o DORA pode funcionar como o regime setorial de cibersegurança para obrigações NIS2 sobrepostas, mas isso não elimina a necessidade de compreender a aplicabilidade da NIS2 a entidades do grupo, prestadores de TIC, serviços geridos ou dependências de nuvem. A resposta prática não é manter playbooks separados. É operar um único modelo de evidência do SGSI mapeado para todas as obrigações relevantes.

Ciberseguro e coordenação de fornecedores são controlos de governação

O ciberseguro pode ser valioso, mas não é uma estratégia contra ransomware. É um mecanismo de transferência de risco com condições. Durante um evento de ransomware, a seguradora pode exigir notificação imediata, utilização de entidades do painel, aprovação prévia da negociação, preservação de evidência, prova de falha das cópias de segurança, prova de controlos razoáveis e revisão jurídica antes de qualquer consideração de pagamento.

O DORA torna o risco de terceiros de TIC um domínio de conformidade de primeira ordem. O Article 21 da NIS2 também exige segurança da cadeia de fornecimento e consideração das vulnerabilidades e práticas de cibersegurança dos fornecedores. A ISO 27001 suporta a mesma lógica através de controlos de fornecedores e nuvem, como A.5.19 a A.5.23, além de controlos de incidente, continuidade e requisitos legais.

O Zenith Controls liga a preparação de incidentes a parceiros externos, incluindo empresas forenses, assessoria jurídica, relações públicas e contacto com autoridades. Numa perspetiva de auditoria, a ausência de parceiros externos previamente identificados pode ser vista como uma lacuna de preparação, porque pode atrasar a resposta durante um incidente real.

Para a governação do pagamento de resgate em ransomware, a Clarysec recomenda pré-negociar:

• Retenção forense ou termos de resposta rápida.
• Disponibilidade de assessoria jurídica externa para estratégia de violação, sanções e privilégio.
• Via de notificação da seguradora cibernética e lista de fornecedores aprovados.
• Via de escalonamento do prestador de nuvem para snapshots, logs, isolamento e recuperação.
• Procedimentos de colaboração em incidentes com MSSP ou MDR.
• Processo de revisão de relações públicas e comunicações de crise.
• Controlos de aprovação bancária ou financeira para qualquer pagamento extraordinário.
• Protocolo de contacto com forças de segurança.

Isto mapeia-se bem aos resultados da cadeia de fornecimento do NIST CSF 2.0, incluindo papéis e responsabilidades dos fornecedores, diligência prévia, requisitos contratuais de cibersegurança, coordenação de incidentes com fornecedores e atividades pós-cessação.

Um playbook prático de escalonamento do pagamento de resgate em ransomware

As cinco portas podem ser traduzidas num playbook operacional. Cada passo deve ser documentado, ter proprietário e ser ensaiado.

O objetivo não é garantir uma decisão confortável. Pode não existir uma decisão confortável. O objetivo é garantir que a decisão é autorizada, baseada em evidência, juridicamente informada e defensável.

O exercício de mesa de 90 minutos que demonstra preparação

A forma mais simples de testar a governação do pagamento de resgate em ransomware não é um exercício red team técnico. É um exercício de mesa de decisão.

Use o Zenith Blueprint, fase Controls in Action, Passo 23, para validar a capacidade de gestão de incidentes. Selecione um cenário de ransomware e execute um exercício com tempo definido. O objetivo não é decidir antecipadamente se a organização pagaria ou nunca pagaria. O objetivo é provar que a organização consegue chegar a uma decisão governada.

Cenário: uma base de dados de clientes alojada na nuvem está cifrada, o atacante alega exfiltração, existem cópias de segurança mas ainda não foram testadas quanto à integridade, a seguradora não foi notificada e o atacante fornece um endereço de carteira com prazo de 48 horas.

Lista de verificação do exercício:

• Declarar o incidente e designar o Comandante do Incidente.
• Abrir o registo de decisão sobre ransomware.
• Classificar o evento utilizando os critérios A.5.25.
• Identificar ativos e serviços de negócio afetados.
• Determinar se estão envolvidos dados pessoais.
• Acionar fluxos de avaliação do RGPD da UE, NIS2, DORA e contratuais.
• Notificar jurídico, EPD, gestão de topo, seguradora e prestador forense.
• Preservar evidência antes de ações destrutivas de recuperação.
• Verificar a integridade das cópias de segurança e as opções de restauro.
• Realizar a verificação de sanções antes de qualquer negociação.
• Registar se é necessária consulta às forças de segurança.
• Redigir declarações provisórias para clientes e reguladores.
• Apresentar opções de decisão à autoridade executiva.
• Registar decisão, fundamentação, divergências, aprovações e próximas ações.
• Agendar revisão pós-incidente e ações de melhoria de controlos.

O resultado deve ser um pacote completo de evidência: lista de participantes, cronologia, folha de classificação, registo de decisão, minutas de comunicações, itens de ação jurídica, itens de ação da seguradora, constatações sobre cópias de segurança e lições aprendidas. Esse pacote é ouro para auditoria porque mostra a governação a funcionar antes de uma crise real.

Como auditores e reguladores testarão o processo

Auditores de diferentes áreas analisarão o mesmo processo de ransomware através de lentes distintas.

O Zenith Controls fornece metodologia de auditoria detalhada para A.5.24, A.5.25 e A.5.31. Para A.5.24, os auditores examinam o plano de resposta a incidentes, classificações de severidade, papéis, listas de contactos, instruções de reporte regulamentar, exercícios e acordos com parceiros externos. Para A.5.25, reveem se existem critérios de classificação de eventos, se os registos de tratamento de alertas demonstram decisões de investigação e escalonamento, se SIEM e informações sobre ameaças são utilizados, e se as equipas de EPD ou jurídico são envolvidas quando dados pessoais podem ser afetados. Para A.5.31, os auditores procuram registos legais, mapeamento de conformidade, evidência de revisão, cobertura de auditoria interna e reporte à gestão de topo.

O risco de auditoria não é apenas a organização ter pago ou recusado pagar. O risco de auditoria é ninguém conseguir provar como a decisão foi tomada.

Da extorsão à melhoria de controlos

A governação de ransomware não termina quando os sistemas são restaurados. A ISO 27001 espera melhoria contínua. A.5.27 aprendizagem com incidentes de segurança da informação é central para essa expectativa. O DORA exige análise de causa raiz e controlos adicionais. O reporte final da NIS2 espera medidas de mitigação e causa raiz provável quando aplicável. A responsabilização ao abrigo do RGPD da UE espera documentação de decisões e salvaguardas.

Cada revisão pós-incidente de ransomware deve responder:

• Os prazos de reporte foram identificados corretamente?
• A autoridade de decisão funcionou conforme concebido?
• A revisão jurídica e de sanções ocorreu suficientemente cedo?
• A coordenação com a seguradora ajudou ou atrasou a resposta?
• As cópias de segurança estavam completas, segregadas, restauráveis e testadas?
• Os logs foram suficientes para avaliar acesso e exfiltração?
• Os fornecedores responderam de acordo com o contrato?
• As comunicações a clientes foram precisas e tempestivas?
• Os executivos receberam a informação certa no momento certo?
• Que controlos, políticas, contratos ou formação devem mudar?

Essas respostas devem atualizar o registo de riscos, a Declaração de Aplicabilidade, o plano de resposta a incidentes, a estratégia de cópias de segurança, os contratos com fornecedores, o plano de comunicação e o programa de formação.

Na fase de fundação e liderança do SGSI, Passo 5, o Zenith Blueprint enfatiza o planeamento de comunicações externas, incluindo identificar clientes, reguladores, parceiros e o público, determinar o que comunicar e quando, e definir quem comunica. Para ransomware, esse passo torna-se a ponte entre a resposta técnica e a preservação da confiança.

Construa o registo de decisão antes da nota de resgate

O melhor momento para governar uma decisão sobre resgate é antes de o atacante definir o prazo.

Se o seu playbook de ransomware não define autoridade de decisão, revisão jurídica, verificação de sanções, aprovação da seguradora, preservação de evidência, classificação NIS2 e DORA, avaliação de violação segundo o RGPD da UE e documentação ao nível do conselho de administração, a organização tem uma lacuna de governação à espera de uma crise.

A Clarysec ajuda as organizações a criar esta capacidade dentro do SGSI através de:

• Zenith Blueprint: roteiro de 30 passos para auditores para implementação faseada da ISO 27001, tratamento de riscos, planeamento de comunicações e validação da capacidade de incidentes.
• Zenith Controls: guia de conformidade cruzada para mapear controlos ISO 27001 para NIS2, DORA, RGPD da UE, NIST CSF, COBIT 2019, ISO/IEC 27035, ISO/IEC 27701, ISO/IEC 27005 e evidência de auditoria.
• Políticas empresariais e para PME da Clarysec, incluindo Política de Resposta a Incidentes, Política de Resposta a Incidentes - PME, Política de Recolha de Evidência e Análise Forense, Política de Recolha de Evidência e Análise Forense - PME, Política de Papéis e Responsabilidades de Governação, Política de Papéis e Responsabilidades de Governação - PME e Política de Gestão de Riscos.
• Modelos práticos de exercícios de mesa de ransomware, registos de decisão, matrizes de escalonamento jurídico, pacotes de evidência e folhas de reporte de conformidade cruzada.

Não espere pela chamada das 3 da manhã para descobrir quem pode decidir. Reveja o seu plano de resposta a incidentes face às cinco portas da Clarysec, execute um exercício de mesa de 90 minutos sobre pagamento de resgate em ransomware e construa um registo de decisão seguro em matéria de sanções e preparado para auditoria, capaz de resistir ao escrutínio de reguladores, seguradoras e do seu próprio conselho de administração.