# Seguro ciber: o que conta em caso de sinistro > Seguro ciber em caso de sinistro: quando informar a seguradora, que deveres são típicos e como preservar as provas de forma correta. Fonte: https://phpsos.de/pt/compliance/cyberversicherung/ 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:** num sinistro, no seguro ciber contam sobretudo três coisas: informar cedo a seguradora, preservar provas em vez de reinstalar precipitadamente e combinar previamente os passos importantes. O que se aplica exatamente consta das suas condições de seguro. Esta página dá indicações gerais, não é aconselhamento jurídico e não substitui o acordo com a seguradora, o mediador ou o advogado. > **Importante:** > Não é aconselhamento jurídico nem de seguros: só contam o seu contrato e a informação da sua seguradora. O melhor é ler as condições já agora, e não só em caso de emergência. ## Porque é que o sinistro é especial nos riscos cibernéticos Num dano causado pela água é evidente o que aconteceu. Num ataque a um servidor web é diferente: no início há muitas vezes apenas uma suspeita, por exemplo um ficheiro estranho, um processo invulgar ou um aviso do fornecedor de alojamento. Se realmente ocorreu um dano só se vê com a investigação. O PHP2Shell é um bom exemplo. As duas vulnerabilidades CVE-2026-109618 e CVE-2026-109619 permitem a execução de código sem autenticação. Quem só aplicou o patch dias depois de 21/10/2026 não pode excluir com segurança que antes tenha acontecido alguma coisa. Um patch não remove software malicioso já introduzido e não prova que nada aconteceu. A questão de saber se e quando existe um sinistro coberto não é, por isso, muitas vezes inequívoca. ## Seguro ciber em caso de sinistro: os deveres típicos Os deveres (Obliegenheiten) são obrigações do tomador do seguro cuja violação pode pôr em risco a prestação. Muitas apólices contêm pontos semelhantes, mas em pormenor diferem bastante: - **Participação:** informar a seguradora sem demora logo que ocorra ou seja iminente um sinistro coberto. - **Minimização do dano:** tomar medidas razoáveis para manter o dano reduzido, por exemplo retirar da rede os sistemas afetados. - **Acordo prévio:** esclarecer previamente com a seguradora os passos essenciais, contratações e pagamentos. - **Informação e documentos:** prestar informações e disponibilizar os documentos necessários para apurar o dano. - **Preservação de provas:** não destruir vestígios desnecessariamente, para que a causa e a dimensão possam continuar a ser apuradas. Alguns contratos contêm, além disso, requisitos de segurança anteriores ao dano, como atualizações regulares, cópias de segurança ou autenticação multifator. Também as informações prestadas no questionário de risco na celebração do contrato podem ter importância. ## O primeiro telefonema para a seguradora Muitos seguros ciber oferecem uma linha de emergência. Tenha à mão o número da apólice e uma breve descrição da situação. No primeiro contacto, esclareça estas questões e anote as respostas com data, hora e nome do interlocutor: 1. O caso deve ser oficialmente participado e de que forma? 2. A seguradora disponibiliza prestadores próprios para forense e recuperação, ou podemos contratar os nossos? 3. Que custos estão previamente autorizados e quais precisam de aprovação? 4. Que documentos são necessários? 5. Existem indicações quanto à comunicação para o exterior ou ao recurso a advogados? ## Preservar provas antes de reinstalar O reflexo compreensível após um ataque é reinstalar o servidor de imediato. Para o seguro, a proteção de dados e uma eventual denúncia criminal, isso é muitas vezes desfavorável, porque desaparecem vestígios. É melhor: isolar os sistemas afetados, preservar registos e imagens de memória, elaborar listas de ficheiros com carimbos de data e hora e só depois limpar ou reconstruir. No caso do PHP2Shell, a imprensa especializada recomenda guardar os registos do servidor a partir de 20/10/2026. Até agora não existem Indicators of Compromise publicados e confirmados; a deteção assenta em análise de comportamento. Por isso, é ainda mais importante que os dados brutos se mantenham. Uma preservação profissional é feita pela [forense informática](https://phpsos.de/pt/leistungen/it-forensik/). ## Articulação com a proteção de dados e a denúncia criminal Um sinistro raramente vem sozinho. Se dados pessoais puderem estar afetados, aplica-se o dever de notificação do Art. 33 do RGPD, se possível no prazo de 72 horas após o conhecimento. Mais sobre isto em [Dever de notificação segundo o RGPD](https://phpsos.de/pt/compliance/dsgvo-meldepflicht-72-stunden/). Muitas seguradoras apoiam neste ponto com advogados que indicam. Também uma denúncia à polícia pode fazer sentido ou ser desejada pela seguradora. Os pontos de contacto centrais para cibercrime das polícias criminais dos estados federados alemães (Zentrale Ansprechstellen Cybercrime) são o endereço certo para isso, veja [Apresentar queixa](https://phpsos.de/pt/compliance/anzeige-polizei-zac/). Combine a ordem dos passos com a seguradora. ## Prevenção: conciliar contrato e plano de emergência Aproveite a situação atual para ler o seu contrato e incorporar os deveres no seu plano de emergência. Registe o número da linha de emergência e o número da apólice num local acessível mesmo sem TI a funcionar. Verifique se as suas informações sobre o nível de segurança ainda estão corretas. Um [plano de emergência de TI](https://phpsos.de/pt/compliance/notfallplan-erstellen/) estruturado ajuda nisso. É útil, além disso, uma breve conversa com o mediador ou a seguradora fora de um sinistro. Pergunte como a seguradora lida com medidas preventivas como retirar um site da rede, que comprovativos espera quanto a atualizações e se existem recomendações para a conservação de registos. As respostas devem ficar por escrito no plano de emergência. ## Como ajuda concretamente a PHP SOS? - Preservamos registos e estados do sistema de forma rastreável, antes de limpar, e documentamos cada medida com a hora. - Elaboramos um relatório técnico sobre a causa, a dimensão e as medidas tomadas, que pode apresentar à seguradora. - Se desejar, coordenamo-nos com os prestadores de serviços da seguradora. - Através da [resposta a incidentes](https://phpsos.de/pt/leistungen/incident-response/), acompanhamos o incidente até à recuperação documentada. ## Perguntas frequentes **Quando tenho de informar o seguro ciber?** Isso é regulado pelo seu contrato. Muitas condições exigem uma participação sem demora logo que ocorra um sinistro coberto ou que este seja seriamente iminente. Em caso de dúvida, participe cedo, mesmo que a dimensão ainda não esteja clara. **Posso eu próprio contratar um prestador de serviços de TI?** Algumas apólices preveem uma linha de emergência e prestadores próprios da seguradora ou exigem um acordo prévio antes da contratação de terceiros. Esclareça isto logo no primeiro telefonema, para que os custos não fiquem em disputa. A resposta deve ficar registada por escrito. **O seguro paga se faltava uma atualização?** Depende das condições, das informações prestadas na celebração do contrato e do caso concreto. Alguns contratos contêm requisitos quanto ao estado da técnica ou às atualizações. Peça ao seu mediador de seguros ou a uma advogada que avalie esta questão. **Aplicar apenas um patch já é um sinistro coberto?** Uma atualização preventiva, em regra, ainda não é um dano. Mas se existirem indícios de uma intrusão, isso pode mudar. Pergunte à sua seguradora a partir de quando quer ser informada. ## Fontes - [BSI (Gabinete Federal Alemão para a Segurança da Informação)](https://www.bsi.bund.de/) - [RGPD Art. 33](https://dsgvo-gesetz.de/art-33-dsgvo/) - [php.net: avisos de segurança](https://www.php.net/)