Na madrugada de 23 para 24 de junho de 2026, a Prefeitura de Porto Nacional (TO) acordou com os sistemas internos criptografados por ransomware. O backup existia, era diário e funcionou — e mesmo assim o secretário-executivo de TI do município precisou avisar que a volta “vai demorar um pouco devido ao tamanho dos arquivos a serem restaurados”: cerca de 20 TB, volume cuja simples cópia levaria mais de uma semana. Ninguém sabia disso porque ninguém havia restaurado antes. É o ponto cego que a Trinity TI encontra na auditoria de entrada de quase toda empresa de 20 a 200 funcionários no Rio: o backup roda todo dia, fecha com log verde, e nunca foi restaurado de verdade.

O tamanho dessa ilusão já foi medido. No Data Trust & Resilience Report 2026 da Veeam — 906 líderes de TI, segurança e risco ouvidos em dezembro de 2025 em dez países, inclusive o Brasil — 90% se diziam confiantes de recuperar o ambiente dentro do próprio RTO, o tempo máximo de parada que a empresa considera tolerável. Entre as organizações de fato atingidas por ransomware, só 28% recuperaram todos os dados. A ressalva importa: amostra autodeclarada, de empresas com mais de mil funcionários — gente com time de TI próprio e orçamento. Mesmo ali, a distância entre confiança e resultado é essa.

O log verde mede o trabalho, não o resultado

Um job que termina com sucesso prova uma coisa só: a ferramenta leu a origem e escreveu algo no destino. Não prova que aquele “algo” abre, que o banco sobe consistente, que a chave de criptografia ainda existe, nem que a empresa aguenta o tempo da volta. É o extintor com lacre intacto e etiqueta de inspeção em dia que ninguém nunca acionou: o selo é verdadeiro, mas se há pressão lá dentro nenhuma etiqueta responde.

O State of Ransomware 2026 da Sophos, com 2.158 líderes de TI de empresas atingidas nos 12 meses anteriores, mostra o outro lado: 66% dos que tiveram dados criptografados recuperaram pelo backup — melhor marca em anos, 12 pontos acima de 2025, e o jeito elegante de dizer que um em cada três não conseguiu, tendo backup. O recorte por porte é o mais duro para a PME: só 34% das empresas de 100 a 250 funcionários barraram o ataque antes da criptografia, contra 46% das de 3.001 a 5.000.

O que aparece quando a empresa restaura de verdade

Nos testes que a Trinity conduz em ambientes novos, os achados se repetem:

• O tempo real é múltiplo do imaginado. O gestor estima “umas duas horas”; a restauração completa leva dois dias — e a empresa descobre o próprio RTO na pior hora possível.
• A cópia mais recente está inservível. Banco copiado com a aplicação aberta, sem snapshot consistente, volta corrompido — e o job ficou verde todas as noites.
• Falta o que ninguém lembrou de copiar. Certificado digital A1, licença do ERP, regra de firewall, caixa compartilhada do Microsoft 365. O dado volta; o sistema que o lê, não.
• A chave de criptografia do backup mora no servidor que morreu. Sem ela, o conjunto inteiro é ruído.
• Erros silenciosos. O job que falha parcialmente há seis meses avisa uma caixa de e-mail que ninguém lê desde que o técnico anterior saiu.

O que as normas realmente exigem

Quem já ouviu “temos backup, estamos conformes” precisa conhecer a redação dos controles. A ISO/IEC 27002:2022, no controle 8.13, não pede apenas que as cópias existam: pede que sejam mantidas e regularmente testadas, conforme política específica de backup. Teste não é adorno do controle, é parte dele.

Os CIS Controls v8 são mais explícitos na cadência. A Safeguard 11.2 (backup automatizado, semanal ou mais frequente) está no grupo IG1, o patamar básico. A Safeguard 11.5 — Test Data Recovery manda testar a recuperação trimestralmente, por amostragem dos ativos em escopo; começa no IG2, e a especificação de avaliação do próprio CIS é taxativa: passados mais de três meses do último teste, o controle recebe nota zero. Some o artigo 46 da LGPD, que exige medidas capazes de proteger dados pessoais de destruição acidental — e backup que não restaura não protege de destruição nenhuma.

Como testar a restauração sem parar a operação

1. Escolha o que dói, não o que é fácil

Liste os três sistemas que param o faturamento — em geral ERP, arquivos do financeiro e e-mail. O teste vale para esses; restaurar uma pasta de fotos não mede nada.

2. Restaure para um lugar separado

Use uma VM isolada ou pasta temporária, nunca sobre o dado de produção. Assim o teste não tem risco e cabe no horário comercial.

3. Cronometre e compare com o RTO

Marque o relógio até alguém da área abrir o arquivo e confirmar que está certo. Esse número é o seu RTO real. Se for maior que o tolerável, o problema é de arquitetura, não de disciplina.

4. Faça a área de negócio validar

A TI confirma que o serviço subiu; só o financeiro sabe se o relatório fecha. Sem esse “de acordo”, o teste provou metade.

5. Simule a volta do zero uma vez por ano

Restaurar arquivo é rotina trimestral. Uma vez ao ano, simule o cenário completo: servidor perdido, ambiente reconstruído, chave de criptografia recuperada.

O registro é o que transforma teste em prova

Teste sem ata não existe para auditoria, seguro cibernético ou contrato grande. Registre cinco campos numa linha de planilha: data, escopo, quem executou, tempo medido e resultado, com o “de acordo” de quem validou. Em três trimestres isso vira histórico — e histórico permite discutir investimento com número, não com opinião.

Entre todos os achados de uma auditoria de TI, o backup nunca testado é o de pior relação entre risco e custo de correção. Não exige ferramenta nova, contratação nem troca de servidor: exige duas horas no calendário por trimestre e um registro. Enquanto isso não acontece, a empresa não tem backup — tem a expectativa de ter.

🔐 Quando foi a última vez que alguém restaurou um backup da sua empresa e cronometrou? Fale com os especialistas da Trinity TI e transforme o log verde em prova de recuperação, com teste trimestral, tempo medido e registro assinado.