blog conviso

Res. 4893 e pentest: o gap entre o que a resolução exige e o que a maioria das IPs entrega

July 13, 2026

By

Vinicius

Wiesehofer

A Res. 4893 existe desde 2021. Nesse tempo, a maioria das Instituições de Pagamento estruturou alguma forma de teste de segurança. O que ainda é raro é conseguir demonstrar, sob demanda, que existe um programa que sustenta o que a resolução exige na prática.

O que a Res. 4893 exige na prática

A Resolução BCB nº 4.893 estabelece os requisitos mínimos de segurança cibernética para Instituições de Pagamento autorizadas pelo Bacen (IPs, SCDs e SCFIs). Entre entender o que ela exige e ter um processo que sustente isso a cada ciclo de auditoria, existe um gap que aparece cedo na primeira visita do regulador.

Quatro obrigações concentram a maior parte desse gap:

Testes periódicos e sistemáticos. O processo precisa ser contínuo, não uma ação isolada para cumprir tabela antes de uma visita. A diferença entre "fizemos um pentest no ano passado" e "temos um programa de testes com calendário definido e histórico por ativo" é justamente o que o Bacen distingue quando chega.

Independência do testador. Quem conduz o pentest não pode ser responsável pelos sistemas testados. Isso elimina o modelo em que o próprio time de desenvolvimento valida o código que escreveu e impacta diretamente como as IPs estruturam ou terceirizam essa atividade.

Retenção de evidências por 5 anos. Não o PDF do relatório de pentest, o ciclo completo: escopo, metodologia dos testes, vulnerabilidades, plano de remediação e status de correção. Disponível para fiscalização do Bacen por no mínimo cinco anos, independentemente de quem executou o teste.

Rastreabilidade do finding à correção. Além de testar e documentar as vulnerabilidades, é preciso demonstrar que elas foram endereçadas, com evidência de remediação e reteste. Esse é o requisito que mais pega IPs desprevenidas, porque exige um processo que vai além do escopo do fornecedor de pentest.

O problema é o modelo de execução

A maioria das IPs que passa por uma visita do Bacen com lacunas em AppSec não desconhecia a resolução. O modelo de pentest por projeto, que envolve contratar uma empresa, receber o relatório e fechar o projeto, simplesmente não produz o que a Res. 4893 exige operacionalmente.

Quando a IP faz pentest por projeto, a rastreabilidade fica dispersa: as vulnerabilidades estão num PDF, o status de remediação numa planilha desatualizada e o reteste, se aconteceu, está no email de outra pessoa. E quando o Bacen pede evidências de testes realizados em 2022, o time passa a tarde montando uma narrativa a partir de arquivos dispersos.

Cinco anos é tempo suficiente para trocar de fornecedor, reestruturar o time e perder completamente o rastro de um ciclo de pentest. O ônus da prova é da IP, não de quem executou o teste.


O requisito de independência do testador torna isso ainda mais crítico. Se a IP terceiriza o pentest e o fornecedor não mantém registros ou encerra as atividades, a evidência simplesmente deixa de existir. A resolução não transfere essa responsabilidade para o fornecedor.

Pentest por projeto vs. programa contínuo

A resolução não proíbe o pentest por projeto, mas ao exigir rastreabilidade contínua, retenção por 5 anos e evidência de remediação, ela cria uma carga operacional que o modelo pontual não consegue sustentar sem uma estrutura de gestão por baixo. A diferença prática:

Critério Pentest por Projeto Programa Contínuo
Frequência 1–2× por ano, por demanda Ciclos regulares definidos por ativo
Cobertura Snapshot no momento do teste Evolui com as mudanças do produto
Rastreabilidade PDF por projeto Histórico por ativo numa plataforma
Remediação Processo manual, fora do pentest Integrada ao workflow de desenvolvimento
Retenção Depende do fornecedor e do email Centralizada por 5+ anos
Evidência para Bacen Compilada manualmente antes da visita Exportável sob demanda, com trilha auditável
Gap entre ciclos Vulnerabilidades introduzidas sem cobertura DAST automatizado cobre o intervalo

O que precisa estar documentado e retido

A pergunta prática para qualquer IP é esta: se o Bacen pedir evidências de um ciclo de pentest de três anos atrás, você consegue gerar em menos de uma hora? Para a maioria, a resposta honesta é não. Para isso, o que precisa estar centralizado:

  • Escopo do teste
    • Quais sistemas, APIs, ambientes e versões foram testados em cada ciclo.
  • Metodologia utilizada
    • Referência à metodologia aplicada e quem conduziu o teste.
  • Vulnerabilidade e severidades
    • Lista completa de vulnerabilidades identificadas, classificadas por risco.
  • Plano de remediação
    • Para cada vulnerabilidade: responsável, prazo acordado e critério de aceite.
  • Status de remediação
    • Evidência de que as vulnerabilidades foram corrigidas, não apenas marcadas como resolvidas.
  • Reteste
    • Confirmação de que a correção foi validada por um novo teste após a remediação.


Como estruturar o programa

Estruturar um programa de pentest contínuo não exige substituir todos os fornecedores atuais nem contratar um time interno de dez pessoas. Ao separar a execução do pentest da gestão do programa, você garante que os resultados fiquem centralizados na IP, não no fornecedor.

Inventariar os ativos sob escopo

Quais aplicações, APIs, ambientes e infraestruturas precisam estar cobertos pela Res. 4893? Sem um inventário atualizado, não é possível saber o que está sendo testado. O Bacen vai perguntar exatamente isso.

Definir o calendário de ciclos

A resolução não especifica frequência mínima além do "anual", mas a prática consolidada é pelo menos um ciclo por ativo crítico, com DAST automatizado cobrindo o intervalo entre os ciclos manuais.


Separar execução de gestão

A execução do pentest pode ser terceirizada, enquanto a gestão (escopo, vulnerabilidades, remediação e evidências) precisa estar centralizada internamente. Isso garante que a IP não perca o histórico quando troca de fornecedor.


Integrar remediação ao workflow de desenvolvimento

Cada finding precisa virar um item rastreável no workflow do time de dev, um ticket no Jira ou no Azure DevOps. Sem esse vínculo, a remediação existe no papel mas não no código.


Gerar e reter evidências numa plataforma

A evidência para o Bacen não é o PDF do pentest. É o histórico completo: ativo testado, finding, responsável, prazo, status de correção e reteste. Tudo em um único lugar, retido por 5 anos e com exportação sob demanda.

Peça para alguém do time gerar a evidência de que um ativo específico foi testado em determinada data, que uma vulnerabilidade foi encontrada e corrigida. Se isso levar mais de 30 minutos, ou se não for possível, o processo precisa ser estruturado antes que o Bacen pergunte.

Quer fechar esse gap antes da próxima visita do Bacen?

A Conviso Platform gere o ciclo completo de pentest: escopo, vulnerabilidades, remediação, reteste e retenção, com trilha auditável e exportação sob demanda.

Agende 20 minutos com um especialista.

Sobre o autor

Vinicius
Wiesehofer

Bachelor's degree in Computer Science from the Federal University of Alagoas. He has spoken at events such as the NullByte Security Conference and Hackers to Hackers Conference, and presented research projects at national and international events. He has experience in application security, exploit development, and vulnerability research in both userland and kernel land, having discovered vulnerabilities for companies like Microsoft, AMD, and Intel. His interests include operating system internals, compilers, malware development, vulnerability research, and EDR evasion.

Saiba mais