# Comunicação de crise após um ataque

> Comunicação de crise após um ciberataque: a quem informar e quando, o que deve constar de uma comunicação aos clientes e que afirmações evitar.

Fonte: https://phpsos.de/pt/compliance/krisenkommunikation/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**Em resumo:** uma boa comunicação de crise após um ciberataque é rápida, honesta e coerente. Informe primeiro internamente, depois os afetados e os parceiros, e diga apenas o que está confirmado, claramente separado do que ainda está a ser investigado. Os deveres de comunicação, por exemplo nos termos do Art. 34 do RGPD, têm de ser combinados com o encarregado da proteção de dados e o aconselhamento jurídico; esta página não é aconselhamento jurídico.

## Porque é que a comunicação faz parte do tratamento do incidente

Um ataque a um servidor web é, em primeiro lugar, um problema técnico. Muito depressa, porém, passa também a ser uma questão de confiança: os clientes notam que o site não está acessível, os parceiros recebem mensagens de correio eletrónico estranhas, os colaboradores fazem perguntas. Quem então se cala ou responde de forma contraditória perde mais confiança do que pelo próprio incidente.

A situação atual em torno do PHP2Shell torna isto palpável. Muitas empresas retiraram os seus sites da rede por precaução ou fizeram manutenção de curta duração. Isso não significa automaticamente que foram atacadas com êxito. É precisamente esta distinção que deve saber explicar para o exterior de forma clara e calma.

## Comunicação de crise após ciberataque: a ordem certa

Uma ordem comprovada evita que grupos importantes saibam pela imprensa ou por terceiros:

1. **Equipa de crise interna:** gerência, área técnica, proteção de dados, se necessário aconselhamento jurídico e seguradora. É aqui que se decide o que será dito.
2. **Colaboradores:** informação interna breve, com o pedido de reencaminhar pedidos para o ponto designado e indicações de cuidado com mensagens suspeitas.
3. **Autoridades, quando necessário:** por exemplo a autoridade de proteção de dados nos termos do Art. 33 do RGPD, o BSI em caso de obrigação NIS2, a polícia em caso de queixa. A ordem combina-a com o seu aconselhamento jurídico.
4. **Clientes e parceiros afetados:** diretamente e, se possível, antes de uma declaração pública.
5. **Público:** aviso no site e, se for o caso, comunicado à imprensa.

Nos termos do Art. 34 do RGPD, os afetados têm de ser informados sem demora injustificada quando uma violação de dados for suscetível de implicar um risco elevado para eles. Os princípios explica-os o [Dever de notificação segundo o RGPD: 72 horas](https://phpsos.de/pt/compliance/dsgvo-meldepflicht-72-stunden/).

## O que deve constar de uma comunicação

Uma boa comunicação é curta e responde às perguntas que os afetados colocam. Esta estrutura revelou-se eficaz:

| Secção | Conteúdo |
|---|---|
| O que aconteceu? | Descrição objetiva em palavras simples, com o período |
| O que sabemos e o que não sabemos? | Factos confirmados separados da investigação em curso |
| Quem está afetado? | Grupos de pessoas ou de dados, na medida do que for conhecido |
| O que fizemos? | Medidas imediatas, envolvimento de especialistas e de autoridades |
| O que deve fazer? | Recomendações concretas, por exemplo alterar a palavra-passe, ter atenção a phishing |
| Como nos pode contactar? | Ponto de contacto fixo para perguntas |

Anuncie quando voltará a informar e cumpra essa promessa. Também um “ainda sem novas conclusões” na hora anunciada cria confiança.

> **Dica:**
> Prepare modelos para a informação interna, a comunicação aos clientes e o aviso no site antes de acontecer alguma coisa. Na emergência, só resta então inserir os factos.

## O que é melhor evitar

Algumas formulações e comportamentos prejudicam regularmente:

- **Alívio precipitado:** “Não foram extraídos dados” só é admissível se estiver comprovado. Um patch instalado não prova que antes não aconteceu nada.
- **Desvalorização:** expressões como “pequeno incidente técnico” parecem desonestas se mais tarde se souber mais.
- **Atribuição de culpa:** referências ao fornecedor de alojamento, a prestadores de serviços ou ao fabricante não ajudam os afetados e podem ter consequências jurídicas.
- **Pormenores técnicos úteis a atacantes:** vulnerabilidades concretas dos seus sistemas não pertencem a comunicações públicas.
- **Garantias:** afirmações como “completamente seguro” ou “impossível de piratear” não se podem manter.

## Site, motores de busca e vaga de phishing

Após um ataque a um site, surgem muitas vezes dois efeitos concomitantes. Primeiro, o Google pode mostrar um aviso se tiver sido encontrado código malicioso; como o fazer remover depois da limpeza está em [Remover o aviso do Google](https://phpsos.de/pt/ratgeber/google-warnung-entfernen/). Segundo, burlões aproveitam incidentes conhecidos para mensagens falsas em nome da empresa afetada. Alerte ativamente os seus clientes para isso e indique por que vias comunica realmente.

Se retirar o site da rede por precaução, basta uma página estática simples com um aviso breve e uma via de contacto que não dependa do servidor afetado.

Quando o incidente estiver encerrado, compensa uma comunicação final a todos os que informou antes: o que a investigação apurou, que medidas foram aplicadas de forma duradoura e a quem podem continuar a dirigir-se. Muitas empresas omitem este passo, porque a pressão diminui. Mas é precisamente ele que mostra que levou o incidente a sério. Avalie também internamente o que correu bem e o que não correu na comunicação e adapte em conformidade os modelos e as responsabilidades no seu plano de emergência.

## Como ajuda concretamente a PHP SOS?

- Fornecemos os factos técnicos de forma compreensível e separamos claramente entre comprovado, provável e desconhecido.
- Verificamos os rascunhos das suas comunicações quanto à correção técnica e a pormenores que possam ajudar atacantes.
- Disponibilizamos em curto prazo uma página de manutenção estática, que funciona independentemente do sistema afetado.
- Através da [resposta a incidentes](https://phpsos.de/pt/leistungen/incident-response/), mantemos a parte técnica ao ritmo da sua comunicação, para que as promessas sobre o estado da informação possam ser cumpridas.


## Perguntas frequentes

**Devemos tornar um ataque público enquanto nem tudo está claro?**  
Depende da situação, dos deveres e dos afetados. Muitas vezes, uma comunicação curta e objetiva, com o que já se sabe, é melhor do que o silêncio, porque os clientes e parceiros saberiam de outras fontes. Combine o momento com o aconselhamento jurídico e a seguradora.

**O que nunca deve constar de uma comunicação aos clientes?**  
Suposições que parecem factos, atribuições de culpa a terceiros, pormenores técnicos que ajudem os atacantes e promessas que não pode cumprir com segurança. Formulações como completamente excluído só deve usá-las se estiverem comprovadas.

**Quem deve falar para o exterior?**  
Uma pessoa designada, em regra da gerência ou da comunicação da empresa, apoiada pela área técnica e pelo aconselhamento jurídico. Todos os outros remetem para esse ponto. Assim, as declarações permanecem coerentes.

**Temos de retirar o nosso site da rede e explicá-lo?**  
Se retirar o site da rede por precaução, ajuda um aviso breve, por exemplo numa página de manutenção estática. Não precisa de ser técnico. Retirar da rede por precaução não significa automaticamente que um ataque tenha tido êxito.

## Fontes

- [RGPD Art. 33](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [BSI (Gabinete Federal Alemão para a Segurança da Informação)](https://www.bsi.bund.de/)
- [Ajuda do Google Search Console](https://support.google.com/webmasters/)