Pentest obrigatório para instituições do Banco Central: o que a BCB 538 e a CMN 5.274 exigem

O que mudou: pentest anual deixou de ser boa prática e virou obrigação

Até 2025, muita fintech tratava teste de intrusão como item de checklist de cliente ou de auditoria: fazia quando um parceiro pedia, guardava o PDF e seguia em frente. As Resoluções CMN nº 5.274/2025 e BCB nº 538/2025, publicadas em dezembro de 2025, mudaram esse cenário. Elas atualizam a política de segurança cibernética das instituições autorizadas pelo Banco Central (a base vinha das Resoluções CMN 4.893/2021 e BCB 85/2021) e dão ao pentest uma regra própria: ele deve ser feito no mínimo uma vez por ano, por empresa ou profissional independente, com documentação formal dos resultados e dos planos de ação. O prazo de adequação para instituições já em operação foi 1º de março de 2026.

Se a sua instituição passou dessa data sem um teste documentado, a pergunta já não é "se", e sim "quando e com qual evidência". Se fez o teste em 2026, o próximo ciclo vence em 2027 e o supervisor vai comparar os dois relatórios. Este guia resume o que as normas pedem, o que ainda convém confirmar no texto oficial, como escopar o teste com um exemplo concreto, o que costuma reprovar um relatório e como escolher quem vai executar.

Quem está no alcance

As resoluções se aplicam às instituições financeiras e de pagamento autorizadas a funcionar pelo Banco Central: bancos, cooperativas de crédito, corretoras e distribuidoras de valores, instituições de pagamento, sociedades de crédito direto (SCD), sociedades de empréstimo entre pessoas (SEP) e demais entidades do Sistema Financeiro Nacional. A CMN 5.274 trata das instituições sob a regulação do Conselho Monetário Nacional; a BCB 538 cobre instituições de pagamento e demais autorizadas pelo Banco Central. A regra depende do tipo de autorização, então confirme o enquadramento exato com o jurídico ou o compliance. O porte não é isenção: ele muda a profundidade do escopo, não a existência do teste.

O que as normas exigem sobre pentest

Não conseguimos abrir o texto oficial no portal de normativos do Banco Central (a página depende de JavaScript). Os pontos abaixo vêm de análises de escritórios de advocacia e de empresas do setor financeiro que citam as resoluções, e as fontes concordam entre si nos itens principais.

• Periodicidade mínima anual. O pentest deve ocorrer, no mínimo, uma vez por ano. Mudança relevante de ambiente (migração de nuvem, novo produto, nova integração crítica) justifica teste complementar.
• Independência. A execução cabe a empresa ou profissional independente de quem construiu e opera o ambiente testado. Varredura automática interna não substitui o teste.
• Documentação formal. Resultados e planos de ação para os riscos encontrados precisam ser formalizados, e o tema deve chegar à governança da instituição em relatórios periódicos.
• Sistemas críticos no escopo. As normas tratam os serviços da RSFN, incluindo Pix e STR, como críticos, e ampliam os controles para sistemas adquiridos ou desenvolvidos por terceiros. Na prática, o teste precisa justificar a cobertura dessas interfaces e dependências.
• Guarda por cinco anos. Várias análises do setor reportam que a documentação do teste e os planos de ação devem ficar disponíveis ao Banco Central por cinco anos. Como não verificamos o artigo no texto oficial, trate o prazo como orientação forte e confirme o dispositivo exato com o jurídico antes de fixar a política interna.

Outros controles entram no mesmo pacote e costumam aparecer no escopo do teste: autenticação multifator em acessos administrativos, trilhas de auditoria íntegras, gestão de certificados e chaves criptográficas, correção periódica de vulnerabilidades, isolamento de redes críticas e regras mais rígidas para contratação de serviços de nuvem.

O que a norma não faz é ditar o formato do relatório. Exploração demonstrada, mapeamento para os controles e reteste são recomendações de boa prática que tornam o documento defensável, não cláusulas que citamos como texto da resolução.

Exemplo prático: escopo de uma instituição de pagamento

O caso abaixo é hipotético e serve só para mostrar o raciocínio. Imagine uma instituição de pagamento de médio porte, com carteira digital em app móvel, APIs de integração para lojistas, conexão ao Pix e infraestrutura em nuvem.

Ativo	Por que entra	Foco do teste
App móvel (iOS e Android)	Acesso do cliente final a saldo e transferências	Autenticação, armazenamento local, pinning, lógica de limite
APIs transacionais e de lojistas	Movimentam dinheiro e expõem dados	Autorização por objeto (BOLA), limites, idempotência, mass assignment
Integração Pix / mensageria com a RSFN	Serviço tratado como crítico pela norma	Segregação de rede, MFA administrativo, validação de mensagens
Painel administrativo e back-office	Privilégio alto, alvo de fraude interna	Controle de acesso, trilha de auditoria, sessão
Nuvem (contas, IAM, storage, segredos)	Hospeda os sistemas acima	Permissões excessivas, segredos expostos, rede entre ambientes
Software e SaaS de terceiros	Controles se estendem a sistemas adquiridos	Contrato e autorização de teste, configuração, integração

Nesse exemplo, um teste que cobrisse só o site institucional deixaria de fora cinco das seis linhas da tabela. É exatamente esse tipo de lacuna que o auditor encontra ao cruzar o escopo com o inventário de ativos. Para as APIs, o roteiro do guia de pentest de API pelo OWASP API Top 10 ajuda a definir o que testar.

O que o Banco Central e o auditor esperam versus o que um scanner entrega

O que precisa estar no relatório	Relatório de scanner	Pentest manual bem feito
Independência de quem desenvolve e opera	Muitas vezes gerado pela própria equipe	Equipe externa, com declaração de independência
Evidência de exploração	Lista de possíveis vulnerabilidades	Request/response, passos reproduzíveis e impacto demonstrado
Falhas de lógica de negócio e autorização	Não detecta	Foco central do teste
Encadeamento de falhas	Cada item isolado	Cenário de ataque do acesso inicial ao impacto
Plano de tratamento	Sugestão genérica	Responsável e prazo por achado, pronto para a diretoria
Reteste	Novo scan	Status por achado: corrigido, parcial, pendente, risco aceito
Rastreabilidade	PDF solto	Escopo, metodologia e evidências arquivados

A diferença entre as duas colunas aparece em detalhe no comparativo scanner, pentest ou bug bounty.

O que o relatório precisa mostrar (na prática)

Para sobreviver a uma auditoria interna, externa ou a uma solicitação do supervisor, o relatório precisa responder a três perguntas: o que foi testado, o que foi encontrado e o que foi feito a respeito. Recomendamos, e entregamos por padrão:

1. Escopo e regras de engajamento que batam com o inventário de ativos e o diagrama da arquitetura.
2. Metodologia nomeada (OWASP WSTG, PTES, NIST SP 800-115).
3. Evidência de exploração por achado, com impacto de negócio descrito.
4. Mapeamento regulatório, uma tabela ligando cada resultado aos controles das resoluções (autenticação, segregação, gestão de vulnerabilidades, proteção de chaves).
5. Plano de tratamento com responsável e prazo, pronto para a alta administração.
6. Reteste documentado, com data e status por achado.
7. Atestado identificando a equipe independente e o período do teste.

Muitas instituições reaproveitam o mesmo pacote para o PCI DSS. Veja o que o auditor de cartões espera em Pentest para PCI DSS 4.0 e BACEN.

Cronograma sugerido: do kickoff ao arquivo

Um ciclo completo cabe em cerca de oito a doze semanas, dependendo do escopo. Use como ponto de partida:

• Semana 0 a 1: preparação. Atualize o inventário de ativos, defina responsáveis, separe contas de teste (usuário comum, lojista, administrador) e confirme o que é de terceiros.
• Semana 1 a 2: autorizações. Formalize o escopo, as regras de engajamento e as autorizações de provedores de nuvem e de fornecedores cujos sistemas serão tocados.
• Semana 2 a 5: execução. Teste manual, com canal direto para achados críticos, que não devem esperar o relatório final.
• Semana 5 a 6: relatório. Entrega com evidências, mapeamento e plano de tratamento; reunião de apresentação com tecnologia e risco.
• Semana 6 a 10: correção. Os times tratam os achados por prioridade.
• Semana 10 a 12: reteste e fechamento. Reteste por achado, atestado final e arquivo de todo o material.
• Depois: governança. Leve o resultado à diretoria, registre decisões de risco aceito e guarde o dossiê em local recuperável.

Motivos comuns de reprovação

• Apresentar scan de vulnerabilidades como pentest.
• Contratar a mesma equipe que desenvolveu ou opera o sistema, o que compromete a independência.
• Testar só o site institucional e deixar de fora APIs, app móvel e back-office.
• Escopo que não bate com o inventário de ativos.
• Relatório sem plano de tratamento nem responsáveis.
• Achados críticos sem reteste, ou "corrigidos" apenas com regra de WAF.
• Não arquivar relatório, plano de ação e evidências de forma recuperável.
• Fazer o teste uma vez e esquecer: o ciclo é anual.

Como escolher quem executa

Peça à proposta respostas objetivas. O checklist para contratar um pentest traz dez perguntas; as que mais pesam para uma instituição regulada são:

• A equipe é independente de quem desenvolve e opera os seus sistemas?
• O teste é manual? Peça um relatório de exemplo anonimizado e confira se há evidência de exploração.
• O relatório traz mapeamento para as resoluções do Banco Central e plano de tratamento?
• O reteste está incluído? Quantas rodadas, e em qual janela de tempo?
• Quem executa tem experiência com APIs financeiras, app móvel e nuvem?
• Como o fornecedor protege os dados e as evidências que coleta durante o teste?
• Como serão tratados achados críticos durante a execução?

Quanto ao preço, ele varia com o número de aplicações, APIs e o modelo de teste (caixa-preta, cinza ou branca). As faixas reais estão em Quanto custa um pentest em 2026. Para entender os modelos, leia O que é pentest.

Como a Pentest Machine ajuda

Fazemos pentest manual com relatório pensado para auditoria: evidência de exploração por achado, mapeamento para as resoluções do Banco Central, plano de tratamento e reteste incluso. Se você precisa fechar o ciclo de 2026 ou planejar o de 2027, peça uma proposta: respondemos com escopo e prazo em até um dia útil.

Perguntas frequentes

O pentest é obrigatório para fintech pequena?

As normas valem para as instituições autorizadas pelo Banco Central no alcance das resoluções, independentemente do porte. O que muda com o tamanho é o escopo e a profundidade. Confirme o enquadramento com compliance ou jurídico.

Um scan de vulnerabilidades basta?

Não. As normas falam em teste de intrusão e exigem independência e documentação formal. A leitura de mercado é que o supervisor distingue relatório de scanner de relatório com exploração manual documentada.

Quem pode ser a equipe independente?

Empresas ou profissionais sem conflito de interesse com o desenvolvimento e a operação do sistema testado. Uma equipe interna que também constrói o sistema tende a não atender ao requisito. Mantenha o registro de quem executou e de qual vínculo existe com o ambiente.

Quanto tempo devo guardar o relatório?

Análises do setor indicam cinco anos para a documentação e os planos de ação. Valide o prazo exato com o jurídico e registre-o na política interna de retenção.

O teste precisa cobrir Pix?

Se a instituição opera ou se conecta ao Pix, ao STR ou à RSFN, esses serviços são tratados como críticos pelas normas e devem estar no escopo, ou o escopo precisa justificar por que não estão.

Posso fazer o pentest uma vez e usar o relatório por dois anos?

Não. A periodicidade é no mínimo anual, e mudanças relevantes de ambiente justificam um teste complementar. Planeje o ciclo de 2027 já agora para não repetir a corrida de 2026.

O reteste conta como outro pentest?

Não. O reteste verifica se cada achado foi corrigido e fecha o ciclo de tratamento. Ele complementa o pentest anual, mas não o substitui.

Posso testar sistemas de fornecedores?

Só com autorização contratual e do provedor. Combine o escopo e as regras por escrito antes de testar qualquer ativo que não seja seu, e registre isso no relatório.