Muitas empresas acreditam que são resilientes até o dia em que tudo para. Planos impecáveis no papel, auditorias bem avaliadas, relatórios consolidados, mas basta um ataque cibernético agressivo para revelar que existe uma diferença enorme entre parecer preparado e estar preparado de verdade.
Enquanto o discurso evolui, os dados mostram um descompasso alarmante entre a percepção das empresas e sua capacidade real de resposta:
- 67% das organizações sofreram um ataque de ransomware somente em 2024.
- 80% dos líderes afirmam confiar plenamente na estratégia de resiliência da empresa.
- 98% acreditam que conseguiriam restaurar sistemas em até 24 horas.
Mas, na prática, apenas 2% realmente conseguiram. E mais da metade levou entre 4 dias e duas semanas para recuperar operações críticas.
No episódio 102, recebemos Cleber Ferreira (diretor de segurança cibernética da Klabin) e João Paulo Teodoro (CIO | Vice-presidente de Tecnologia, Projetos e Segurança da Informação na TP) para um bate papo sobre resiliência cibernética.
Assista ao episódio completo: RedCast #102
A distância entre o plano e o que realmente acontece
Cleber Ferreira faz uma colocação precisa: “A documentação que eu tinha no passado não refletia a minha realidade no presente.”
Esse é o problema invisível da resiliência: o ambiente muda mais rápido do que a empresa atualiza seus planos. Aplicações são reescritas, APIs surgem, integrações se multiplicam, times mudam, fornecedores trocam, mas o plano continua igual.
E quando um incidente sério ocorre, a pergunta é sempre a mesma:
“Em quanto tempo conseguimos voltar e quanto de perda de dado o negócio suporta?”
Acontece que a maioria das empresas só descobre a resposta durante o incidente, quando já é tarde demais.
O teste como prova prática
Existe uma maneira eficiente de descobrir se um plano funciona: testando.
Testes são desconfortáveis. Eles expõem falhas que ninguém quer ver. São cheios de imprevistos, exigem tempo que sempre parece faltar e obrigam áreas diferentes a se coordenarem sob tensão. Mas, como pontuou João Paulo:
“Tudo tem que ser testado, tem que ser simulado para a hora que acontecer, ainda que você não vá seguir um script 100%, mas você e todo mundo que foi treinado, capacitado, vai saber o que fazer. São pouquíssimas empresas que se preocupam com esse tipo de exercício.”
E é justamente no teste, no tabletop exercise, no failover, na restauração completa, no ensaio de comunicação, que a empresa descobre o que não está documentado. Descobre que o responsável saiu da empresa. Que o número do fornecedor mudou. Que o servidor que parecia isolado dependia de outro. Que o banco de dados principal não sobe sem o secundário. Que a ordem de prioridade não faz mais sentido. Que a nuvem não baixa na velocidade esperada. Que o ambiente secundário não suporta a carga. Que ninguém sabe exatamente qual VM pertence a qual aplicação.
Essas descobertas só acontecem quando a empresa se dispõe a simular uma crise de verdade, com pressão, com tempo contado, com gente do negócio na sala e com decisões incômodas. E quanto mais se testa, menos se improvisa no dia em que realmente importa.
O conforto enganoso do backup
Entre todas as ilusões corporativas, nenhuma é tão comum quanto o sentimento de segurança ligado ao backup. É raro encontrar uma empresa que diga “não temos backup”. Todas têm. Mas ter o backup não significa ter resiliência.
Como disse um dos especialistas: “Backup todo mundo tem. Quero ver restaurar.”
Backups mal catalogados, bases que não se integram, arquivos de origem duvidosa, dados incapazes de sustentar um retorno parcial, dependências ocultas, restores que exigem uma infraestrutura já inexistente e nuvens cujo download levaria dia — quase sempre é na hora da restauração que tudo desmorona.
Em incidentes reais, já vimos backups cifrados junto, backups incompletos, backups com meses de defasagem e até ambientes inteiros que ninguém sabia reconstruir.
E quando o pânico começa, a pergunta que surge no board não é “temos backup?”, mas sim: “Em quanto tempo voltamos?”. Sem treino, a resposta nunca é clara.
A dimensão humana que os planos ignoram
Existe um elemento da resiliência que quase nunca é considerado: o emocional.
Crises cibernéticas não são apenas eventos técnicos, são eventos humanos. Elas acontecem de madrugada, em fins de semana, em feriados, quando equipes estão distribuídas, com pessoas cansadas, ansiosas e, muitas vezes, assustadas.
Na crise, a cabeça do profissional é outro sistema operacional. Não existe documento que prepare alguém para o primeiro incidente grande de sua carreira. Há culpa, medo, pressão, silos que explodem, conflitos que emergem e decisões difíceis que precisam ser tomadas em minutos. É comum ver profissionais travando, líderes entrando em pânico e times improvisando sem alinhamento.
E é por isso que simulações realistas são tão essenciais. Elas treinam não apenas processos, mas pessoas.
Risco cibernético deixou de ser técnico e virou risco de continuidade
Outro ponto destacado no debate foi a revisão da forma como o mercado encara o risco cibernético. Uma das falas mais fortes de Cleber e João Paulo foi: “Risco é risco. Tanto faz de onde vem.”
O incidente moderno não é mais “um problema de TI”. Ele atravessa todas as camadas da empresa.
Um ataque começa como uma vulnerabilidade, vira indisponibilidade, evolui para fraude, gera impacto regulatório, obriga área jurídica, envolve comunicação, toca o board, ameaça a operação e, em alguns casos, coloca a continuidade do negócio em risco real.
O incidente cibernético virou, na prática, incidente de negócio. Por isso, segurança, TI, risco, operações, fraude, compliance e comunicação precisam funcionar como um mecanismo único. Qualquer distância entre essas áreas pode ser considerada um ponto de falha.
Resiliência é um processo vivo, não uma peça de auditoria
Ao longo da conversa, ficou claro que maturidade em resiliência não nasce de um projeto isolado, nem de uma grande aquisição de tecnologia. Ela nasce de hábito. Resiliência é construída em ciclos: planejamento, teste, falha, correção, novo teste, nova correção, revisão, simulação, aprendizado.
Marcos Sena, gerente de SOC na Redbelt Security, pontua que “o plano de continuidade é um eterno rascunho. O maior benefício do teste são as lições aprendidas.”
Quanto mais a empresa abandona a ilusão do plano perfeito e se compromete com a melhoria contínua, mais resiliente ela se torna.
Ataques são inevitáveis. O despreparo não precisa ser.
Empresas não quebram porque são atacadas, mas porque não sabem responder.
O que destrói organizações não é o ransomware em si, é a falta de preparo. É descobrir, na madrugada do incidente, que o que existia era um plano desatualizado, um backup que ninguém sabe restaurar, uma cadeia de fornecedores que não responde, uma equipe exausta, um ambiente sem redundância, uma documentação antiga e uma lista de prioridades que não faz mais sentido.
A resiliência operacional nasce na prática. Ela depende de testes reais, conversas difíceis, decisões estruturais e da coragem de olhar para os pontos cegos antes que eles se tornem crises.
Convidados do episódio
Cleber Ferreira – Diretor de segurança cibernética da Klabin
Formado em Administração pela PUC-SP, com MBA em Gestão de Segurança da Informação na FIAP, há 22 anos atua na área de Gestão da Qualidade, Segurança da Informação e Gestão de Riscos, com vasta experiência na supervisão do processo de produção e testes de qualificação de produto e serviços e implantação de frameworks, gestão da qualidade e segurança da informação. Passou por empresas como a Dasa.
João Paulo Teodoro – CIO | Vice-presidente de Tecnologia, Projetos e Segurança da Informação na TP
Profissional com mais de 20 anos de experiência impulsionando inovação e excelência em organizações nacionais e multinacionais. Expertise em Tecnologia da Informação, Operações de Segurança, Arquitetura de Soluções e Transformação Digital, com forte foco na gestão de ambientes de alta criticidade. Passou por empresas como Stefanini e Contax.
