Reteste de pentest: o que é, por que o auditor exige e com que frequência testar

O problema: o relatório saiu, a correção "foi feita", e ninguém provou

Um pentest termina com uma lista de falhas. O valor real aparece depois: o time corrige, e alguém precisa provar que a correção funciona. É isso que o reteste faz. Sem ele, a empresa tem um relatório que diz "havia um problema" e nenhuma evidência de que ele deixou de existir.

Pense no que acontece na prática. O relatório chega com doze achados. O time abre doze tickets, fecha onze em duas sprints e deixa um "para depois". Seis meses mais tarde, o auditor pergunta: "qual é o status daquelas falhas?". A resposta honesta é "acreditamos que foram corrigidas". Para um auditor, acreditar não é evidência.

Auditores, QSAs e áreas de risco sabem disso. Por isso o reteste aparece como item separado nas conversas de conformidade, e é um dos pontos em que mais relatórios ficam incompletos. Neste guia explicamos o que é, o que ele precisa entregar, quais correções costumam falhar, com que frequência testar e o que perguntar ao fornecedor antes de assinar.

O que é reteste

Reteste é a repetição, de forma direcionada, dos testes que originaram cada achado, depois que o time aplicou a correção. O pentester reproduz o mesmo ataque, com as mesmas condições, e registra se ele ainda funciona.

Não é um novo pentest. O escopo é fechado nos achados já reportados: não procura vulnerabilidades novas, não cobre funcionalidades que mudaram depois e não substitui o teste anual. Essa fronteira importa para as duas partes: o cliente sabe exatamente o que está pagando, e o fornecedor sabe exatamente o que precisa provar.

	Pentest	Reteste
Objetivo	Descobrir o que é explorável	Confirmar que o que foi encontrado foi corrigido
Escopo	Aplicação, rede ou ambiente completo	Somente os achados do relatório anterior
Resultado	Lista de achados com evidência	Status por achado com nova evidência
Esforço típico	Dias ou semanas, conforme o escopo	Fração do teste original, proporcional ao número de achados
Quando	Anual e após mudança relevante	Depois da correção, em janela combinada

O ciclo de vida de um achado

O reteste só faz sentido dentro de um ciclo. Cada achado percorre as mesmas etapas, e cada etapa deixa um registro que o auditor pode seguir:

Etapa	O que acontece	Registro que fica
1. Descoberta	O pentester explora a falha e documenta a evidência	Achado no relatório, com severidade e passos de reprodução
2. Triagem	O time define dono, prazo e abordagem de correção	Ticket vinculado ao ID do achado
3. Correção	O código, a configuração ou o processo é alterado	Commit, pull request ou change request
4. Reteste	O pentester repete o ataque original em produção	Requisição, resposta ou log novos
5. Status	O achado é fechado, reaberto ou aceito como risco	Relatório atualizado com status e data

Se qualquer etapa falta, o ciclo quebra. O erro mais comum é pular da etapa 3 direto para o fechamento do ticket, sem a etapa 4: a falha "some" do backlog, mas ninguém verificou o ambiente.

Por que auditores e reguladores esperam reteste

No PCI DSS 4.0, o requisito 11.4 trata o pentest como um ciclo, não um evento: vulnerabilidades exploráveis encontradas devem ser corrigidas e o teste repetido para verificar a correção. Veja como isso entra no relatório em Pentest para PCI DSS 4.0 e BACEN.

No setor financeiro, as normas do Banco Central pedem que a instituição trate o que o teste encontra e consiga comprovar esse tratamento na supervisão. Reteste documentado é a forma mais direta de comprovar. Confira o texto vigente das resoluções aplicáveis ao seu tipo de instituição antes de montar o pacote de evidências.

A lógica é a mesma em ISO 27001 e SOC 2: o auditor não quer só saber que você testou, e sim que a gestão de vulnerabilidades fechou o ciclo. O mesmo vale para o questionário de segurança de um cliente enterprise: "vocês corrigiram o que o pentest achou?" é uma pergunta que o reteste responde com um documento, não com uma promessa.

O que um relatório de reteste mostra

Um bom reteste devolve, para cada achado original:

1. Identificador e severidade originais, para rastrear contra o relatório anterior.
2. Status: corrigido, parcialmente corrigido, não corrigido ou risco aceito (este último com justificativa e aprovação formal da empresa).
3. Evidência nova: a requisição e a resposta, o print ou o log mostrando que o ataque original falha (ou continua funcionando).
4. Data e responsável pelo teste, para a trilha de auditoria.
5. Novos achados introduzidos pela correção, quando surgem de forma evidente, registrados à parte.

Um reteste que diz apenas "todas as falhas foram corrigidas" não serve como evidência. Quem lê precisa ver o que foi tentado. A tabela abaixo resume o que cada status exige para ser aceito por um auditor:

Status	Significado	Evidência necessária
Corrigido	O ataque original e as variações razoáveis falham	Requisição e resposta mostrando a falha do ataque, data e ambiente testado
Parcialmente corrigido	O vetor original falha, mas há variação ou instância que ainda funciona	Evidência do que passou a falhar e do que continua explorável
Não corrigido	O ataque original continua funcionando	Evidência da exploração repetida e do impacto atual
Risco aceito	A empresa decidiu conviver com a falha	Justificativa, controle compensatório, aprovação formal e data de revisão
Não aplicável	O componente foi desativado ou removido	Prova da remoção, e não apenas a exclusão do achado do escopo

Quando fazer o reteste

O melhor momento é logo depois que o time marcar as correções como implantadas em produção (ou no ambiente equivalente). Retestar em homologação pode ser útil como checagem prévia, mas só a verificação no ambiente real comprova o resultado final.

Combine com o time uma janela: por exemplo, o fornecedor aceita solicitações de reteste por um período após a entrega do relatório. Pergunte isso na contratação. Janela curta demais obriga a correr as correções; sem janela nenhuma, o reteste vira novo orçamento.

Duas dicas de agenda ajudam bastante. Primeiro, agrupe as correções em lotes em vez de pedir um reteste por achado: o fornecedor ganha eficiência e o cliente tem menos rodadas. Segundo, trabalhe de trás para frente a partir do prazo de auditoria ou fiscalização: se o relatório final atualizado precisa estar pronto em março, a janela de correção termina bem antes disso.

Erros comuns na correção

São os padrões que mais vemos fazer um achado voltar como "não corrigido":

• Corrigir o sintoma, não a causa. Bloquear o payload do teste em vez de corrigir a validação. O pentester muda uma vírgula e a falha volta.
• Resolver só com WAF. Uma regra no WAF reduz o risco imediato, mas não elimina a vulnerabilidade na aplicação. Vale como mitigação temporária, registrada como tal.
• Validar só no cliente. Esconder um botão ou checar um campo no navegador não impede quem chama a API diretamente. A regra precisa existir no servidor.
• Corrigir uma instância e esquecer a classe. A mesma falha de autorização em cinco endpoints e correção em um. A falha de autorização em APIs é o exemplo clássico: a correção certa é um controle central, não cinco remendos.
• Introduzir regressão. A correção quebra outra proteção, ou uma versão futura reintroduz a falha. Teste automatizado para o caso corrigido evita que o achado volte.
• Mudar o escopo para "sumir" com o achado. Retirar o sistema do relatório não é correção, e o auditor percebe pelo diagrama de rede.
• Corrigir sem registrar. Sem ticket, commit ou changelog, a equipe não consegue explicar o que mudou.

Com que frequência fazer pentest

A regra de mercado, e o que o PCI DSS e a maioria dos auditores esperam, é no mínimo uma vez por ano e depois de qualquer mudança significativa: nova funcionalidade crítica, migração de nuvem, troca de provedor de autenticação, integração com terceiros, mudança de arquitetura. Para instituições reguladas pelo Banco Central, a periodicidade mínima vem da norma aplicável; confirme o texto vigente e trate o anual como piso, não como teto.

Para quem vende para clientes enterprise, o relatório precisa estar recente. Um pentest de 2023 apresentado em 2026 depois de duas migrações costuma ser recusado.

Uma cadência baseada em risco costuma funcionar melhor do que uma data fixa no calendário:

Situação	Cadência sugerida
Base	Pentest completo anual, com reteste após as correções
Mudança significativa (autenticação, pagamento, exposição de dados, nova arquitetura)	Teste focado na mudança, antes ou logo depois do lançamento
Ativos de alto risco (APIs públicas, ambiente de cartão, dados sensíveis)	Ciclos mais curtos, definidos pela análise de risco da empresa
Entre testes	Varredura contínua e testes automatizados no CI para pegar regressões

Ferramentas automatizadas no pipeline complementam o pentest, mas não o substituem. Elas encontram classes conhecidas de falha com rapidez; o teste manual encontra falhas de lógica de negócio e encadeamentos que nenhum scanner enxerga. Veja a diferença em Scanner, pentest ou bug bounty.

O que perguntar ao fornecedor

Antes de assinar, confirme por escrito:

• O reteste está incluso no preço ou é cobrado à parte?
• Quantas rodadas de reteste estão previstas? Uma costuma bastar se as correções forem bem feitas; duas dão margem real.
• Qual é a janela para solicitar o reteste, e o que acontece depois que ela fecha?
• O relatório final é atualizado com o status de cada achado, ou o reteste vem em documento separado?
• O reteste é feito em produção e entrega evidência nova para cada achado?
• Quem executa: a mesma equipe do teste original?
• Como são tratados os achados que a correção deixou parcialmente abertos?

O que muda o custo de um reteste costuma ser o número de achados, a complexidade de reproduzir cada um e o número de rodadas, e não um valor fixo universal. Por isso vale pedir a política por escrito em vez de comparar apenas o preço do teste inicial. Mais perguntas para comparar propostas estão em 10 perguntas antes de contratar um pentest, e a influência do reteste no preço aparece em Quanto custa um pentest.

Como a Pentest Machine trata o reteste

O reteste está incluído nos nossos pacotes. Cada achado volta com status e evidência nova, e o relatório final é atualizado para refletir o estado pós-correção. Se a sua auditoria ou fiscalização está no calendário, o ideal é fechar escopo e janela de reteste antes do teste começar. Peça um orçamento e informe o prazo de conformidade.

Perguntas frequentes

Reteste é a mesma coisa que um novo pentest?

Não. O reteste verifica apenas os achados já reportados, com o mesmo método. Um novo pentest procura falhas novas em todo o escopo. Os dois se complementam: o pentest descobre, o reteste prova a correção.

Quanto tempo depois da correção devo fazer o reteste?

Logo que as correções estiverem em produção. Combine com o fornecedor uma janela de solicitação para não perder o prazo, e agrupe as correções em lotes para reduzir o número de rodadas.

Quantas rodadas de reteste preciso?

Depende da quantidade de achados e da qualidade das correções. Pergunte quantas rodadas estão incluídas e o que acontece se uma correção falhar. Uma rodada costuma bastar para correções bem feitas; uma segunda dá margem para ajustes.

Um WAF basta para considerar o achado corrigido?

Em geral não. O WAF mitiga, mas a vulnerabilidade continua na aplicação. O relatório deve registrar como mitigação, não como correção, e o achado permanece aberto até a causa ser tratada.

Posso fazer o reteste com a minha equipe interna?

Pode, como checagem prévia. Para auditoria e conformidade, porém, o que vale é o reteste executado por quem fez o teste original ou por um terceiro independente, com evidência documentada. Quem corrige não deve ser o único a validar.

O que acontece com um achado que a empresa decide não corrigir?

Ele entra como risco aceito, com justificativa, controle compensatório, aprovação formal da gestão e data de revisão. O reteste registra esse status em vez de fingir que o achado foi resolvido.

Com que frequência devo fazer pentest?

No mínimo uma vez por ano e após mudanças significativas na aplicação ou na infraestrutura, com reteste após cada rodada de correções. Ambientes regulados devem confirmar a periodicidade na norma aplicável.