Um sistema de emissão de apólices fica indisponível às 9h de uma segunda-feira. Não por um ataque sofisticado — um servidor de banco de dados legado simplesmente para de responder, e ninguém na equipe sabe, com precisão, quanto tempo leva para restaurar a operação sem perder dados de sinistros abertos naquela manhã. Esse tipo de cenário raramente entra no radar até acontecer de fato.
Continuidade de negócios em seguradoras deixou de ser apenas uma prática recomendada de gestão de crises. Desde 2021, a Circular Susep nº 638/2021 exige que a política de segurança cibernética de seguradoras, resseguradoras locais, entidades de previdência aberta e sociedades de capitalização preveja um plano de continuidade capaz de identificar vulnerabilidades e de detectar, responder e recuperar a operação de um incidente.
Os prazos de adequação previstos nessa norma já venceram para todos os portes e também para contratos terceirizados — em 2026, essa não é mais uma exigência em fase de transição, mas um requisito plenamente vigente, que qualquer fiscalização pode cobrar de imediato.
O problema é que muitas seguradoras têm um documento chamado “plano de continuidade de negócios” e não têm, na prática, continuidade de negócios. A diferença entre os dois só aparece no momento em que um incidente real testa a estrutura.
Este artigo explica o que a continuidade de negócios significa para uma seguradora, onde o risco de interrupção realmente se concentra, o que a regulação exige, o que costuma falhar quando o plano nunca foi testado e quais critérios usar para decidir entre ajustar, evoluir ou reestruturar a capacidade de resposta da operação.
Principais pontos
- Continuidade de negócios é uma exigência regulatória formalizada pela Circular Susep nº 638/2021, com prazos de adequação já vencidos — não é mais um tema em fase de adaptação, é um requisito em vigor.
- Ter um documento de continuidade não é o mesmo que ter continuidade: a diferença aparece no primeiro incidente real, quando o plano nunca foi testado sob pressão.
- O risco de interrupção raramente está em um único ponto — ele se distribui entre sistemas legados sem redundância, integrações críticas com corretoras e resseguradoras, e dependência de conhecimento concentrado em poucas pessoas.
- Critérios objetivos — tempo de indisponibilidade tolerável, existência de testes de recuperação, dependência de sistemas legados e capacidade interna — ajudam a decidir se o caminho é ajuste pontual ou reestruturação da arquitetura.
- O próximo passo recomendado não é reescrever o plano de continuidade do zero, mas mapear onde a operação realmente para quando um componente específico falha.
⚠️ Ponto de atenção: quando o plano de continuidade de negócios (PCN) existe apenas como documento — sem testes periódicos, sem tempo de recuperação definido por sistema e sem confirmação de que a equipe sabe executá-lo sob pressão — o risco tende a ficar invisível até o primeiro incidente real.
Nesse momento, a diferença entre um plano testado e um documento arquivado aparece de uma vez, com a operação parada. O ponto central é garantir estrutura, teste e capacidade de resposta antes que um evento force essa verificação sob pressão.
O que é continuidade de negócios em seguradoras, na prática
Continuidade de negócios é a capacidade de uma organização manter suas funções essenciais em um nível aceitável durante e depois de um evento que interrompe o funcionamento normal, retomando a capacidade plena dentro de um prazo definido.
A ISO 22301, norma internacional de referência para sistemas de gestão de continuidade de negócios (SGCN), trata o tema como um processo contínuo de gestão — não como um documento técnico produzido uma única vez.
Aplicado a uma seguradora, isso significa: mesmo diante de uma falha de sistema, um ataque cibernético, a indisponibilidade de um fornecedor crítico ou um evento físico que afete a infraestrutura, a operação precisa continuar emitindo apólices, processando sinistros já abertos e respondendo a corretoras e segurados dentro de um tempo tolerável.
O que separa “ter um documento” de “ter continuidade” são três elementos concretos:
Tempo de recuperação definido e testado para cada sistema crítico — o RTO (recovery time objective), ou quanto tempo a operação pode ficar sem aquele sistema.
Ponto de recuperação de dados definido — o RPO (recovery point objective), ou quanto dado a operação pode perder sem comprometer sinistros e apólices em andamento.
Evidência de que a equipe já executou o plano, em um teste ou simulação, e não apenas o escreveu.
Vale uma distinção que costuma gerar confusão: disaster recovery (recuperação de desastres) é o subconjunto técnico da continuidade de negócios, focado em restaurar infraestrutura, sistemas e dados depois de uma falha. Continuidade de negócios é mais ampla — inclui pessoas, processos, fornecedores e comunicação, não apenas os sistemas de TI.
Uma seguradora pode ter um plano de disaster recovery robusto para o core system e, ainda assim, não ter continuidade de negócios: se a emissão de apólices depende de uma pessoa específica para autorizar uma exceção, por exemplo, nenhum backup resolve isso.
No Brasil, esse conceito ganhou peso regulatório específico: a Circular Susep nº 638/2021 trata continuidade de negócios como parte obrigatória da política de segurança cibernética das supervisionadas — não como uma boa prática opcional de gestão de crises.
O tema está diretamente conectado à discussão mais ampla de segurança cibernética em seguradoras, já que ambos nascem da mesma norma e da mesma lógica: reduzir vulnerabilidade e garantir capacidade de resposta.
O que a regulação exige e por que isso já não está em fase de adaptação
A Circular Susep nº 638/2021 é a norma central sobre o tema. Ela determina que a política de segurança cibernética das seguradoras, resseguradoras locais, entidades abertas de previdência complementar e sociedades de capitalização preveja processos, procedimentos e controles para identificar e reduzir vulnerabilidades, e para detectar, responder e se recuperar de incidentes — capacidades que devem estar formalizadas no plano de continuidade de negócios.
A norma também estabelece prazo de 5 dias úteis, a partir do conhecimento do evento, para comunicar à Susep a ocorrência de um incidente relevante, com detalhamento da extensão do dano e das medidas corretivas adotadas.
Os prazos de adequação a essa circular já se encerraram: segmentos S1 e S2 tiveram até 30 de junho de 2022 para se adequar, os segmentos S3 e S4 até 1º de setembro de 2022, e a adaptação de contratos de terceirização de processamento e armazenamento de dados teve prazo até 1º de setembro de 2024.
Na prática, isso significa que, em setembro de 2026, não existe mais janela de transição: qualquer seguradora supervisionada pela Susep já deveria ter uma política de segurança cibernética com plano de continuidade formalizado e testado.
Esse requisito específico se conecta a um arcabouço mais amplo de governança de riscos. A Resolução CNSP nº 416/2021, em vigor desde 3 de janeiro de 2022 e aplicada de forma proporcional ao porte e à complexidade de cada segmento, estabelece as regras do Sistema de Controles Internos e da Estrutura de Gestão de Riscos das supervisionadas — o ambiente de governança dentro do qual a continuidade de negócios deve ser tratada como parte da gestão de risco operacional, e não como iniciativa isolada de TI.
Além disso, o Manual de Orientações sobre Segurança Cibernética, publicado pela Susep em julho de 2026 com base nessa resolução e na Circular nº 638/2021, tem caráter orientativo — não substitui as normas vigentes — mas consolida boas práticas de supervisão em temas como governança, gestão de riscos e continuidade, servindo como referência do que a Susep espera encontrar em uma auditoria.
Vale uma distinção importante: a Circular 638/2021 é a norma que estabelece a obrigação; o Manual de Orientações é interpretação e boa prática, não obrigação adicional; e a Resolução CNSP 416/2021 é o contexto mais amplo de governança de risco em que a continuidade se insere.
Nenhuma das três, isoladamente, resolve a lacuna prática mais comum: a existência de um documento que nunca foi posto à prova.
Onde a interrupção realmente aparece na operação
Falar em “continuidade de negócios” de forma genérica esconde onde a interrupção de fato se manifesta no dia a dia de uma seguradora. Quatro frentes concentram a maior parte do risco.
Sistemas legados sem redundância
Core systems antigos, muitas vezes mantidos por décadas, raramente foram desenhados com replicação ativa, failover automático ou capacidade de recuperação rápida. Quando falham, a recuperação depende de restaurar backups manualmente — um processo que pode levar horas ou dias, não minutos.
Integrações críticas com corretoras, prestadores e resseguradoras
Emissão de apólices, cotação e processamento de sinistros dependem cada vez mais de integrações em tempo real com corretoras, oficinas credenciadas, prestadores de saúde e resseguradoras. Quando uma dessas integrações falha — por indisponibilidade do parceiro, não da seguradora —, o efeito na operação pode ser o mesmo de uma falha interna, mas o controle sobre a recuperação é menor. Esse ponto é aprofundado em Integração de Sistemas Empresariais no setor de seguros.
Backups e planos de recuperação nunca testados
É comum existir rotina de backup, mas nunca ter sido feito um teste completo de restauração sob condições realistas. A diferença entre “ter backup” e “conseguir restaurar a operação dentro do prazo tolerável” só aparece quando alguém tenta, de fato, executar a recuperação — e descobre que ela demora mais, ou perde mais dados, do que o esperado.
Conhecimento concentrado em poucas pessoas
Quando apenas uma ou duas pessoas sabem como reiniciar um sistema crítico, reconectar uma integração ou executar o plano de contingência, a continuidade da operação depende da disponibilidade dessas pessoas no momento exato do incidente — um risco que se agrava em férias, desligamentos ou trocas de equipe.
Boa parte desses riscos começa nos sistemas mais antigos, sem qualquer mecanismo de redundância.
Impactos que ficam ocultos até a interrupção acontecer
O custo de não ter continuidade estruturada raramente aparece no orçamento até que um evento o torne visível. Três tipos de impacto costumam permanecer ocultos:
Regulatório.
O não cumprimento do prazo de 5 dias úteis para comunicar um incidente relevante à Susep, ou a ausência de um plano de continuidade formalizado e testado, expõe a seguradora a questionamentos de supervisão — independentemente de o incidente ter afetado diretamente o segurado.
Operacional.
Uma interrupção em sistema core ou integração crítica pode travar emissão de apólices, processamento de sinistros ou atendimento a corretoras por horas ou dias, com efeito direto sobre receita, prazos contratuais e relacionamento comercial.
Contratual e de resseguro.
Contratos de resseguro e acordos de distribuição com corretoras frequentemente incluem cláusulas de nível de serviço e de segurança da informação. Uma interrupção prolongada, sem plano de resposta demonstrável, pode se tornar ponto de atrito em renovações e auditorias de parceiros — o mesmo tipo de exposição contratual já discutido em Segurança Cibernética em Seguradoras.
O que costuma dar errado na prática
| Erro recorrente | Por que acontece | Consequência | Como reduzir o risco |
|---|---|---|---|
| Plano de continuidade nunca testado | Documento criado para atender auditoria, sem simulação real de execução | Equipe descobre falhas do plano durante o próprio incidente, sob pressão | Testar o plano periodicamente, com cenários realistas e revisão dos resultados |
| RTO e RPO não definidos por sistema | Continuidade tratada de forma genérica, sem diferenciar sistemas críticos de sistemas secundários | Tempo e critério de recuperação ficam a critério de quem estiver disponível no momento | Definir RTO e RPO por sistema, priorizando emissão, sinistros e integrações críticas |
| Dependência de fornecedor sem SLA de continuidade claro | Contratação de nuvem ou integração feita sem cláusula específica de recuperação de desastres | Recuperação depende de terceiro sem compromisso formal de prazo | Formalizar SLA de continuidade e recuperação com fornecedores críticos |
| Backup sem teste de restauração | Rotina de backup automatizada, mas nunca validada com restauração completa | Backup existe, mas falha ou demora além do tolerável na hora de restaurar | Testar restauração completa periodicamente, não apenas a execução do backup |
| Conhecimento concentrado em poucas pessoas | Poucas pessoas entendem como executar o plano de contingência ou reconectar integrações | Resposta lenta ou impossível quando essas pessoas não estão disponíveis | Documentar procedimentos e treinar mais de uma pessoa para cada função crítica |
| Plano desatualizado frente a novos sistemas | Novos sistemas e integrações entram em produção sem atualizar o plano de continuidade | Plano cobre uma operação que já não existe mais na forma descrita | Revisar o plano a cada mudança relevante de arquitetura, não apenas anualmente |
Reconhecer esses padrões é o primeiro passo prático.
Esses erros nascem da mesma exigência regulatória tratada em profundidade no artigo sobre segurança cibernética em seguradoras.
Critérios de decisão para avaliar a maturidade da sua continuidade
Antes de decidir entre ajustar, evoluir ou reestruturar, avalie a operação atual segundo estes critérios:
Definição de criticidade. Existe uma lista clara de quais sistemas são críticos (emissão, sinistros, integrações regulatórias) e quais podem tolerar mais tempo de indisponibilidade?
RTO e RPO. Cada sistema crítico tem um tempo de recuperação e um ponto de recuperação de dados definidos — ou a expectativa de recuperação é apenas “o mais rápido possível”?
Teste periódico. O PCN já foi testado em simulação nos últimos 12 meses, com resultado documentado?
Redundância de sistemas legados. Os sistemas mais antigos e críticos têm algum mecanismo de redundância, ou uma falha única pode parar a operação inteira?
Governança de fornecedores. Fornecedores de nuvem, integração e infraestrutura têm SLA de continuidade e recuperação formalizado em contrato?
Capacidade interna. A equipe consegue executar o plano de continuidade sem depender de uma ou duas pessoas específicas?
Conformidade regulatória. A operação consegue demonstrar, hoje, o cumprimento da Circular Susep nº 638/2021 caso solicitado em fiscalização?
Muitos desses critérios dependem de como os sistemas da sua operação estão integrados entre si.
Quando faz sentido e quando não faz
Considere manter a estrutura atual quando…
O plano de continuidade já é testado periodicamente, RTO e RPO estão definidos por sistema crítico, e os fornecedores relevantes têm SLA de recuperação formalizado. Nesse cenário, o foco deve ser manutenção contínua e atualização do plano a cada mudança relevante de arquitetura.
Considere uma evolução gradual quando…
A base já existe — há um documento de continuidade e alguma rotina de backup —, mas faltam testes periódicos, definição clara de RTO/RPO ou cobertura de todos os sistemas críticos. Nesse caso, priorizar testes e definições objetivas costuma reduzir risco sem exigir reestruturação completa da arquitetura.
Considere uma reestruturação mais profunda quando…
Sistemas legados concentram parte relevante da operação sem qualquer redundância, o plano de continuidade nunca foi testado, e não há capacidade interna dedicada a manter isso atualizado frente a uma arquitetura que muda com frequência. Nesse cenário, modernização, integração e continuidade precisam ser tratadas como projeto estruturado, não como ajuste incremental.
Comparação com alternativas
| Alternativa | Quando pode funcionar | Limitação principal | Impacto possível | Critério para avançar |
|---|---|---|---|---|
| Backup manual, sem plano formal | Operações muito pequenas, com poucos sistemas críticos | Sem RTO/RPO definidos nem teste de restauração | Recuperação lenta e imprevisível quando um incidente ocorre | Volume de apólices e sistemas críticos já não cabe em recuperação improvisada |
| Documento de continuidade nunca testado | Primeira etapa de maturidade, sempre necessária como ponto de partida | Falhas do plano só aparecem durante o incidente real | Falsa sensação de preparo: plano existe no papel, não na prática | A auditoria ou a Susep pedem evidência de teste, não apenas de documento |
| Redundância pontual em sistemas isolados | Quando apenas um ou dois sistemas concentram risco crítico identificado | Não cobre a operação como um todo nem integrações externas | Sistema mais crítico protegido, mas outros pontos de falha permanecem | Mapeamento já identificou onde a redundância pontual resolve a maior parte do risco |
| Desenvolvimento interno de toda a estrutura de continuidade | Empresas com equipe de infraestrutura robusta e tempo para maturar internamente | Exige conhecimento especializado e testes recorrentes sustentados ao longo do tempo | Custo de oportunidade alto se a equipe não tiver capacidade dedicada | Equipe interna tem tempo e conhecimento para sustentar o processo continuamente |
| Modernização de legado + integração via API + squads especializados | Quando a limitação está na arquitetura (sistemas legados, integrações frágeis) e na capacidade de manter o processo | Exige alinhamento de escopo e governança compartilhada com o parceiro | Redução de pontos únicos de falha e do tempo entre diagnóstico e estrutura testada | Mapeamento aponta dependência crítica de sistemas legados ou de poucas pessoas |
Não existe alternativa universalmente certa: a escolha depende da criticidade dos sistemas envolvidos, do estágio atual de maturidade e da capacidade interna disponível para sustentar testes e atualizações ao longo do tempo.
Se o caminho de modernização, integração e squads especializados parece o mais aderente à sua realidade,
avalie com um especialista da Tecnologia Única quais sistemas concentram mais risco de interrupção na sua operação.
Diagnóstico rápido: sua operação resiste a uma interrupção real?
Use o diagnóstico interativo a seguir para identificar rapidamente quais frentes da sua seguradora concentram mais risco de descontinuidade hoje.
Sua operação resiste a uma interrupção real?
Marque as situações que descrevem sua operação hoje. Ao final, você recebe uma leitura consultiva sobre onde sua continuidade de negócios concentra mais risco — sem substituir uma análise técnica completa.
0 de 8 situações marcadas
Como uma arquitetura mais resiliente sustenta a continuidade de negócios
Nenhuma das frentes descritas até aqui se resolve isoladamente. Sistema legado sem redundância, integração frágil com terceiros e conhecimento concentrado em poucas pessoas são, na prática, sintomas de uma mesma causa: a ausência de uma arquitetura pensada para distribuir risco, em vez de concentrá-lo.
É nesse ponto que a atuação da Tecnologia Única se conecta ao tema — não como fornecedora de uma ferramenta isolada de backup ou disaster recovery, mas como parceira estruturadora da arquitetura, das integrações e da capacidade de manutenção que sustentam uma operação mais resiliente. Isso acontece de três formas.
Primeiro, por meio da modernização de sistemas legados, que reduz a concentração de risco em sistemas antigos sem redundância — normalmente o ponto de maior fragilidade em um plano de continuidade. [
Segundo, por meio de projetos de integração de sistemas orientados a arquitetura de microsserviços e APIs, que distribuem a operação em componentes desacoplados — reduzindo o efeito de uma falha isolada sobre o conjunto.
Terceiro, por meio de squads especializados em outsourcing de tecnologia, que sustentam a capacidade interna de manter, testar e atualizar o plano de continuidade ao longo do tempo, em vez de tratá-lo como um projeto único.
Um exemplo desse tipo de arquitetura em operação é o case da Herval Seguradora, que utiliza a plataforma Proteo — desenvolvida pela Tecnologia Única com a InsureMO — como core baseado em microsserviços e integrações via API, em uma operação autorizada pela Susep.
Uma arquitetura de microsserviços distribui a operação em componentes independentes: a falha de um componente específico não precisa, necessariamente, derrubar toda a plataforma — um contraste direto com o modelo monolítico, em que uma falha central compromete o sistema inteiro.
O caso ilustra, na prática, como uma arquitetura desacoplada sustenta tanto agilidade quanto resiliência operacional, ainda que não substitua a necessidade de um plano de continuidade formal, testado e documentado.
Mapeie quais sistemas da sua arquitetura ainda dependem de um único ponto de falha
É normalmente aí que a interrupção também se concentra. Squads especializados em outsourcing de tecnologia costumam ajudar a estruturar essa priorização sem exigir contratações extensas.
💡Vale reforçar: nem toda seguradora precisa de reestruturação completa da arquitetura. Quando a base já é sólida, o caminho mais adequado costuma ser testar e formalizar o que já existe, não substituir toda a estrutura.
Como estruturar o próximo passo
Antes de qualquer investimento em nova ferramenta ou projeto de modernização, faz sentido organizar o ponto de partida:
Mapear todos os sistemas e integrações críticos para emissão, sinistros e atendimento.
Registrar o tempo de recuperação (RTO) e o ponto de recuperação de dados (RPO) tolerável para cada um.
Validar se os fornecedores críticos de nuvem, integração e infraestrutura têm SLA de continuidade formalizado.
Priorizar os sistemas legados e integrações sem qualquer redundância identificada no mapeamento.
Documentar o plano de continuidade de forma acessível a mais de uma pessoa da equipe.
Testar o plano em simulação realista, não apenas revisar o documento.
Monitorar continuamente a cobertura do plano frente a novos sistemas e integrações.
Quando esse mapeamento aponta lacunas estruturais — legado extenso sem redundância, integrações frágeis, plano nunca testado —, uma conversa técnica com um especialista ajuda a transformar o diagnóstico em um plano de estruturação realista, com prioridades claras em vez de um projeto genérico de "continuidade".
Conclusão
Continuidade de negócios em seguradoras deixou de ser uma pauta apenas de gestão de crises: é hoje uma exigência regulatória em vigor, sem prazo de transição pendente, e um fator direto de risco operacional, contratual e reputacional. O problema raramente está na ausência de um documento — está na distância entre o que o documento descreve e o que a operação de fato consegue executar quando um sistema falha, uma integração para ou um fornecedor fica indisponível.
Testar essa distância antes que um incidente real o faça é o que separa uma seguradora preparada de uma seguradora que apenas cumpriu, formalmente, uma exigência da Susep. Avançar não significa reconstruir toda a arquitetura de uma vez — significa mapear onde a operação realmente para, definir tempos de recuperação por sistema e priorizar a partir de critérios claros.
Se hoje o PCN da sua seguradora ainda depende de sistemas legados sem redundância, integrações frágeis com terceiros ou conhecimento concentrado em poucas pessoas, a Tecnologia Única pode apoiar a estruturação de uma arquitetura mais resiliente e testável — para que a operação tenha um tempo de recuperação conhecido, e não estimado, diante do próximo incidente. Isso acontece por meio de modernização de sistemas legados, integração de sistemas ou squads especializados.
O próximo passo é conversar com um especialista sobre os pontos de falha que mais pesam na continuidade da sua operação.
Perguntas Frequentes (FAQ)
Sim. A Circular Susep nº 638/2021 exige que a política de segurança cibernética de seguradoras, resseguradoras locais, entidades abertas de previdência complementar e sociedades de capitalização preveja um plano de continuidade de negócios, com prazos de adequação já encerrados para todos os portes e para contratos terceirizados.
O plano de resposta a incidentes foca em identificar, conter e comunicar um evento de segurança dentro do prazo exigido. O plano de continuidade de negócios é mais amplo: define como a operação continua funcionando — ou volta a funcionar dentro de um prazo tolerável — durante e depois desse mesmo evento, ou de qualquer outra interrupção.
Não. Disaster recovery é o subconjunto técnico da continuidade de negócios, focado em restaurar sistemas e dados de TI depois de uma falha. Continuidade de negócios é mais ampla: inclui pessoas, processos e fornecedores, e também cobre interrupções que não têm origem tecnológica, como a indisponibilidade de um prestador de serviço crítico.
O que são RTO e RPO, e por que eles importam para continuidade de negócios? RTO (recovery time objective) é o tempo máximo tolerável para restaurar um sistema após uma falha. RPO (recovery point objective) é a quantidade máxima de dados que a operação pode perder sem comprometer sinistros e apólices em andamento. Sem esses dois parâmetros definidos por sistema, a recuperação depende de improviso no momento do incidente.
Não sozinho. Backup é uma condição necessária, mas não suficiente: garante que os dados existem em outro lugar, mas não garante que a restauração funcione dentro do prazo tolerável, nem que a equipe saiba executá-la sob pressão. Isso só é confirmado com testes periódicos de restauração.
Terceirizar não aumenta o risco por si só, mas exige que o fornecedor tenha SLA de continuidade e recuperação formalizado em contrato. Sem isso, a capacidade de recuperação da operação passa a depender de um terceiro sem compromisso de prazo definido.
Com que frequência um plano de continuidade de negócios deve ser testado? Não há uma periodicidade única definida em norma para todos os casos, mas a boa prática — refletida na ISO 22301 e nas orientações da Susep — é testar o plano ao menos uma vez por ano, e sempre que houver mudança relevante na arquitetura de sistemas ou nas integrações críticas da operação.
Referências externas
[1] LegisWeb. Circular Susep nº 638/2021.
[2] Susep/Gov.br. Resolução CNSP nº 416/2021.
[3] Susep. Manual de Orientações sobre Segurança Cibernética.
[4] ISO 22301:2019 — Security and resilience — Business continuity management systems.
DE 
PT 
EN 
ES 
FR 
IT 