Seguro cibernético: os controles que qualificam a apólice (e o que faz o sinistro ser negado)

O que é o seguro cibernético e o que ele cobre

O seguro cibernético é a transferência do risco financeiro de um incidente digital para uma seguradora — ele cobre parte das perdas de um ataque, não impede o ataque. Funciona como qualquer seguro: a empresa paga um prêmio e, diante de um sinistro coberto, a seguradora arca com custos definidos na apólice. É a última camada de proteção financeira, acionada quando as demais falham, e não um substituto para a segurança que evita o incidente. No Brasil, o tema ganhou tração também por via regulatória: no setor financeiro, prestadores de serviço de TI ligados ao Sistema Financeiro Nacional passaram a ter exigência de cobertura de responsabilidade e riscos cyber sob a Resolução BCB nº 498^[4].

As coberturas típicas de uma apólice

Uma apólice abrangente costuma cobrir custos de resposta a incidente, recuperação, notificação, interrupção de negócio, extorsão por ransomware e responsabilidade perante terceiros. Materiais de mercado descrevem essas categorias de forma consistente: custos de primeira parte (forense, recuperação de dados, comunicação de crise, perda por indisponibilidade), responsabilidade de terceiros (clientes e parceiros afetados por um vazamento originado na empresa) e custos ligados a ransomware, incluindo negociação^[1]. Guias em português para o mercado brasileiro listam as mesmas frentes: resposta a incidentes, indenização a terceiros, interrupção de negócios e multas regulatórias quando previstas em lei^[5].

O que costuma ficar de fora

Tão importante quanto a cobertura são as exclusões — e elas são a razão mais comum de um sinistro não ser pago. Entre as exclusões recorrentes estão: incidentes que começaram antes do início da apólice (comprometimento pré-existente), incidentes atribuíveis a vulnerabilidades conhecidas e não corrigidas, e eventos patrocinados por Estado, que passaram a ser excluídos de muitas apólices padrão^[1]. Há ainda os sublimites: categorias como fraude por engenharia social costumam ter teto muito abaixo do limite geral da apólice. Ler as exclusões é parte de entender o que se está de fato contratando.

A fronteira: a TI cuida do controle, não da decisão de contratar

A decisão de contratar o seguro, o limite e os termos são do negócio; o papel da TI é ter e evidenciar os controles técnicos. Este artigo fica desse lado da fronteira. Não trata de qual apólice escolher nem de aconselhamento de seguro — trata do que a TI precisa implementar e conseguir provar para que a empresa qualifique e para que, no momento do sinistro, a declaração se sustente. A escolha da cobertura é conversa do financeiro e do jurídico com a corretora.

Os controles que o questionário de risco exige

Os controles tipicamente exigidos formam um checklist previsível: MFA, EDR, backup imutável e testado, gestão de patches, controle de acesso privilegiado, filtro de e-mail, treinamento e plano de resposta a incidente. Guias de requisitos de seguro cibernético descrevem esse mesmo conjunto como a base que as seguradoras pedem antes de emitir a apólice^[2]. As seguradoras convergiram para esse núcleo porque são os controles que mais reduzem a frequência e a severidade dos sinistros que elas pagam. Conhecer a lista antes de responder ao questionário evita a situação pior: descobrir uma lacuna já com a cotação em andamento.

O checklist de controles esperados

Antes de responder ao questionário, a TI deve conseguir dizer "sim, e provo" para cada item desta lista:

1. MFA em acessos remotos, e-mail e contas privilegiadas — muitas seguradoras já perguntam a cobertura por aplicação, não um "sim" genérico.
2. EDR em todos os endpoints, não só nos servidores; antivírus tradicional já não basta para a maioria das apólices.
3. Backup imutável e isolado, com teste de restauração — backup que nunca foi testado tende a ser tratado como ausência de backup.
4. Gestão de patches com processo documentado e prazos razoáveis de correção de vulnerabilidades críticas.
5. Controle de acesso privilegiado (PAM), com MFA e separação entre acesso comum e administrativo.
6. Filtro de e-mail e proteção contra phishing, principal vetor de acesso inicial.
7. Treinamento de conscientização, com registro de entrega e, em muitos casos, simulação de phishing.
8. Plano de resposta a incidente testado — um plano que nunca passou por exercício vale menos que um testado com resultado registrado.

Por que a seguradora exige MFA e EDR

Porque são os dois controles que mais alteram a probabilidade e a contenção de um sinistro. O MFA barra a maioria dos acessos indevidos por credencial roubada — por isso é frequentemente o requisito mais importante do questionário, e vários casos públicos de grande impacto envolveram justamente um acesso sem MFA^[3]. O EDR detecta e contém a ameaça no endpoint antes que ela se espalhe, e as seguradoras cada vez mais distinguem EDR gerenciado de não gerenciado, dando termos melhores ao gerenciado^[1]. São controles de alto retorno para quem paga o sinistro — daí a exigência.

Por que backup imutável e plano de resposta fecham o núcleo

Porque são o que permite recuperar sem pagar resgate e reduzir o dano quando o incidente acontece. O backup imutável e isolado é o que garante uma cópia intacta mesmo se o ransomware alcançar a rede — e, sem teste de restauração, essa cópia é uma promessa não verificada. O plano de resposta a incidente organiza quem faz o quê nas primeiras horas, encurtando o tempo de contenção; várias apólices o listam como condição. Guias em português destacam o backup imutável seguindo a lógica 3-2-1 e o treinamento contínuo como itens que a seguradora avalia para definir o prêmio^[5].

Por que sinistros de seguro cibernético são negados

O motivo recorrente de negativa é declaração inconsistente: o controle marcado como existente no questionário não estava implementado — ou não cobria todos os ativos — no momento do ataque. A seguradora paga com base no risco que aceitou, e esse risco foi descrito pela empresa. Quando a realidade não bate com a declaração, a cobertura cai. "Sim" sem evidência é o maior risco na hora do sinistro, porque é exatamente ali que a seguradora verifica o que foi declarado.

A negativa por controle ausente ou parcial

A causa mais comum é o controle que existia "no papel", mas não na prática ou não em todo o ambiente. Um "sim" para MFA que na verdade cobria só parte dos acessos, um backup declarado como isolado que estava na mesma rede da produção, um plano de resposta que nunca saiu da gaveta — cada um desses vira base para negativa quando o incidente explora justamente a lacuna. Não é má-fé necessária: basta a declaração otimista descolar da configuração real. Por isso o "parcialmente, e aqui está o que temos" é mais seguro que o "sim" sem lastro.

As exclusões que anulam a cobertura

Além da declaração inconsistente, as exclusões da própria apólice respondem por boa parte das negativas. Comprometimento pré-existente ao início da apólice, incidente ligado a vulnerabilidade conhecida e não corrigida e evento patrocinado por Estado são exclusões que, quando aplicáveis, derrubam o pagamento independentemente dos controles^[1]. Somadas, exclusões e inconsistência de declaração explicam por que uma parcela relevante dos sinistros cyber termina sem pagamento — segundo o guia da Kaseya, mais de 40% dos sinistros não resultam em indenização, com as exclusões como razão mais frequente^[1].

O que a TI controla nesse desfecho

A TI controla exatamente o que separa uma declaração sustentável de uma frágil: implementar o controle de fato, cobrir todos os ativos e guardar a evidência. Não está no alcance da TI mudar as exclusões contratuais — isso é leitura de apólice, tarefa do negócio e do jurídico. Mas está no alcance da TI garantir que, quando a seguradora perguntar "o MFA cobria este servidor?" ou "o backup foi testado?", a resposta seja um sim comprovável. É aí que a atuação técnica decide se a apólice paga.

Como evidenciar cada controle

Evidenciar é transformar "temos o controle" em prova documentada que a seguradora aceita — e é o que dá lastro ao questionário. A diferença entre uma apólice que paga e uma que nega muitas vezes está na evidência: um "parcialmente" acompanhado de relatório técnico vale mais, na hora do sinistro, que um "sim" sem nada por trás. A regra prática é gerar, para cada controle, um artefato que mostre cobertura, funcionamento e teste.

De "temos MFA" para "aqui está a cobertura de MFA"

A evidência de MFA é o relatório de cobertura por sistema, mostrando onde ele está ativo e onde não está. Em vez de afirmar que "a empresa usa MFA", a TI apresenta a lista de acessos remotos, contas de e-mail e contas privilegiadas com o status de MFA em cada um. Isso responde exatamente à forma como as seguradoras passaram a perguntar — cobertura por aplicação, não um sim único — e expõe lacunas antes que a seguradora as encontre no sinistro.

Backup e patches: prova de que funciona, não só de que existe

Para backup, a evidência é a política escrita somada ao log de restauração testada; para patches, o relatório de aplicação com os prazos de correção. Um backup só conta como controle quando há registro de que uma restauração foi executada e funcionou — a existência do backup não prova a capacidade de recuperar. No caso de patches, a seguradora migrou de "vocês têm gestão de patches?" para métricas: tempo médio para corrigir vulnerabilidades críticas e percentual de endpoints dentro da política^[1]. A evidência acompanha essa exigência.

Plano de resposta: o registro do tabletop

A evidência do plano de resposta é o registro do exercício de mesa (tabletop) que o testou. Um plano documentado, mas nunca exercitado, é evidência fraca; um plano com registro de um tabletop — data, participantes, cenário, lições — mostra que a organização sabe executá-lo. Guardar esse registro, e repeti-lo periodicamente, é o que converte o plano de um documento em um controle verificável. O mesmo raciocínio vale para a simulação de phishing que sustenta o item de treinamento.

Renovação, reavaliação e a relação com o programa de segurança

A apólice é uma foto do risco no momento da contratação — e na renovação a seguradora tira uma foto nova. Os controles evoluem, o ambiente muda e as exigências tendem a se estender com o tempo; manter a evidência viva ao longo do ano é o que evita surpresa no ciclo seguinte. E há um ponto de fundo: o seguro reflete o programa de segurança, não o substitui. Os mesmos controles que qualificam a apólice reduzem o risco real de incidente.

O que muda na renovação

Na renovação, a seguradora reavalia o risco e pode exigir novos controles ou evidências que não pedia antes. O underwriting endureceu de forma crescente: o que se qualificava com uma atestação de uma página passou a exigir questionário técnico detalhado e, em empresas maiores, avaliação externa antes de fechar^[1]. Quem manteve a evidência atualizada ao longo do ciclo chega à renovação com a documentação pronta; quem deixou envelhecer descobre lacunas na pior hora. Histórico de sinistro também pesa: o período após um incidente costuma ser o de termos mais duros.

O seguro reflete o programa de segurança, não o substitui

O seguro é a última camada, não a primeira — ele cobre parte da perda, mas não impede o ataque nem repõe reputação. Tratar a apólice como alternativa a investir em segurança inverte a lógica: sem os controles, a empresa nem qualifica, e se qualificar por declaração frágil, o sinistro pode ser negado. Os controles exigidos existem porque reduzem o risco real, e não por acaso derivam de frameworks consolidados: as exigências típicas — MFA, EDR, backup testado, gestão de patches, acesso privilegiado, resposta a incidente — mapeiam para controles descritos em referências como CIS Controls e ISO/IEC 27001. Estruturar o programa de segurança a partir desses frameworks tende a cobrir de forma natural o que a seguradora vai perguntar, e ainda organiza a evidência, porque frameworks pedem justamente a documentação que o questionário quer ver. Implementá-los serve à segurança primeiro e à qualificação depois.

Checklist de prontidão por porte

A prontidão para o questionário difere por porte na profundidade da evidência, não na natureza dos controles — o núcleo (MFA, EDR, backup, resposta) vale para todos. O que muda é quanto se precisa provar e com que formalidade. O roteiro abaixo serve para a TI se preparar antes de responder ao questionário, evitando descobrir lacunas com a cotação em andamento.

O que ter e conseguir provar em cada porte