Teste de intrusão obrigatório para instituições do Banco Central do Brasil: o que exigem a BCB 538 e a CMN 5.274

O que mudou: o teste de intrusão anual deixou de ser boa prática e passou a obrigação

Até 2025, muitas fintechs brasileiras tratavam o teste de intrusão como um item de checklist de um cliente ou de uma auditoria: faziam-no quando um parceiro o pedia, arquivavam o PDF e seguiam em frente. As Resoluções CMN n.º 5.274/2025 e BCB n.º 538/2025, publicadas em dezembro de 2025, alteraram esse cenário. Atualizam a política de cibersegurança das instituições autorizadas pelo Banco Central do Brasil (a base vinha das Resoluções CMN 4.893/2021 e BCB 85/2021) e dão ao teste de intrusão uma regra própria: deve ser realizado pelo menos uma vez por ano, por uma empresa ou um profissional independente, com documentação formal dos resultados e dos planos de ação. O prazo de adequação para as instituições já em atividade foi 1 de março de 2026.

Se a sua instituição passou essa data sem um teste documentado, a questão já não é "se", mas "quando e com que evidência". Se o fez 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 convém ainda confirmar no texto oficial, como definir o âmbito com um exemplo concreto, o que costuma levar à rejeição de um relatório e como escolher quem o executa.

Quem está abrangido

As resoluções aplicam-se às instituições financeiras e de pagamento autorizadas a funcionar pelo Banco Central do Brasil: 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 abrange as instituições de pagamento e outras autorizadas pelo Banco Central. A regra depende do tipo de autorização, pelo que deve confirmar o enquadramento exato com o departamento jurídico ou de compliance. A dimensão não é uma isenção: altera a profundidade do âmbito, não a existência do teste.

O que as normas exigem sobre o teste de intrusão

Não conseguimos abrir o texto oficial no portal de normativos do Banco Central (a página depende de JavaScript). Os pontos abaixo resultam de análises de escritórios de advogados e de empresas do setor financeiro que citam as resoluções, e as fontes coincidem no essencial.

• Periodicidade mínima anual. O teste deve realizar-se, no mínimo, uma vez por ano. Uma alteração relevante do ambiente (migração para a cloud, novo produto, nova integração crítica) justifica um teste complementar.
• Independência. A execução cabe a uma empresa ou profissional independente de quem construiu e opera o ambiente testado. Uma análise automática interna não substitui o teste.
• Documentação formal. Os resultados e os planos de ação para os riscos encontrados têm de ser formalizados, e o tema deve chegar à governação da instituição em relatórios periódicos.
• Sistemas críticos no âmbito. As normas tratam os serviços da RSFN, incluindo o Pix e o STR, como críticos, e alargam os controlos a sistemas adquiridos ou desenvolvidos por terceiros. Na prática, o teste tem de justificar a cobertura dessas interfaces e dependências.
• Conservação durante cinco anos. Várias análises do setor indicam que a documentação do teste e os planos de ação devem ficar disponíveis para o Banco Central durante cinco anos. Como não verificámos o artigo no texto oficial, trate o prazo como orientação firme e confirme a disposição exata com o jurídico antes de fixar a política interna.

Outros controlos chegam no mesmo pacote e costumam surgir no âmbito do teste: autenticação multifator em acessos administrativos, registos de auditoria íntegros, gestão de certificados e chaves criptográficas, correção periódica de vulnerabilidades, isolamento de redes críticas e regras mais rigorosas para a contratação de serviços cloud.

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

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

O caso seguinte é hipotético e serve apenas para mostrar o raciocínio. Imagine uma instituição de pagamento de média dimensão, com carteira digital numa aplicação móvel, APIs de integração para comerciantes, ligação ao Pix e infraestrutura na cloud.

Ativo	Porque entra	Foco do teste
Aplicação móvel (iOS e Android)	Acesso do cliente final a saldo e transferências	Autenticação, armazenamento local, pinning, lógica de limites
APIs transacionais e de comerciantes	Movimentam dinheiro e expõem dados	Autorização por objeto (BOLA), limites, idempotência, mass assignment
Integração Pix / mensagens 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 elevado, alvo de fraude interna	Controlo de acessos, registo de auditoria, sessão
Cloud (contas, IAM, armazenamento, segredos)	Aloja tudo o que está acima	Permissões excessivas, segredos expostos, rede entre ambientes
Software e SaaS de terceiros	Os controlos estendem-se a sistemas adquiridos	Contrato e autorização de teste, configuração, integração

Neste exemplo, um teste que cobrisse apenas o site institucional deixaria de fora cinco das seis linhas da tabela. É precisamente o tipo de lacuna que o auditor encontra ao cruzar o âmbito com o inventário de ativos. Para as APIs, o roteiro do guia de teste de intrusão a APIs pelo OWASP API Top 10 ajuda a definir o que testar.

O que o regulador e o auditor esperam face ao que um scanner entrega

O que o relatório deve conter	Relatório de scanner	Teste manual bem executado
Independência de quem desenvolve e opera	Muitas vezes gerado pela própria equipa	Equipa 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 as deteta	Foco central do teste
Encadeamento de falhas	Cada item isolado	Cenário de ataque desde o acesso inicial até ao impacto
Plano de tratamento	Sugestão genérica	Responsável e prazo por achado, pronto para a administração
Reteste	Nova análise automática	Estado por achado: corrigido, parcial, pendente, risco aceite
Rastreabilidade	PDF solto	Âmbito, metodologia e evidências arquivados

A diferença entre as duas colunas é explicada em detalhe em scanner, pentest ou bug bounty.

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

Para resistir a uma auditoria interna, externa ou a um pedido do supervisor, o relatório tem de responder a três perguntas: o que foi testado, o que foi encontrado e o que foi feito a esse respeito. Recomendamos, e entregamos por defeito:

1. Âmbito e regras de atuação que coincidam com o inventário de ativos e o diagrama de arquitetura.
2. Metodologia nomeada (OWASP WSTG, PTES, NIST SP 800-115).
3. Evidência de exploração por achado, com o impacto no negócio descrito.
4. Mapeamento regulatório, uma tabela que liga cada resultado aos controlos 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 administração.
6. Reteste documentado, com data e estado por achado.
7. Atestado que identifique a equipa independente e o período do teste.

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

Cronograma sugerido: do arranque ao arquivo

Um ciclo completo cabe em cerca de oito a doze semanas, consoante o âmbito. Use-o como ponto de partida:

• Semana 0 a 1: preparação. Atualize o inventário de ativos, defina responsáveis, separe contas de teste (utilizador comum, comerciante, administrador) e confirme o que pertence a terceiros.
• Semana 1 a 2: autorizações. Formalize o âmbito, as regras de atuação e as autorizações dos fornecedores de cloud e dos terceiros cujos sistemas vão ser tocados.
• Semana 2 a 5: execução. Teste manual, com um canal direto para achados críticos, que não devem esperar pelo 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. As equipas tratam os achados por prioridade.
• Semana 10 a 12: reteste e encerramento. Reteste por achado, atestado final e arquivo de todo o material.
• Depois: governação. Leve o resultado à administração, registe as decisões de risco aceite e guarde o dossiê num local recuperável.

Motivos comuns de rejeição

• Apresentar uma análise de vulnerabilidades como teste de intrusão.
• Contratar a mesma equipa que desenvolveu ou opera o sistema, o que compromete a independência.
• Testar apenas o site institucional e deixar de fora as APIs, a aplicação móvel e o back-office.
• Um âmbito que não coincide com o inventário de ativos.
• Relatório sem plano de tratamento nem responsáveis.
• Achados críticos sem reteste, ou "corrigidos" apenas com uma regra de WAF.
• Não arquivar o relatório, o plano de ação e as evidências de reteste de forma recuperável.
• Fazer o teste uma vez e esquecê-lo: 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 equipa é independente de quem desenvolve e opera os seus sistemas?
• O teste é manual? Peça um relatório de exemplo anonimizado e verifique se há evidência de exploração.
• O relatório inclui mapeamento para as resoluções do Banco Central e plano de tratamento?
• O reteste está incluído? Quantas rondas, e em que janela de tempo?
• Quem executa tem experiência com APIs financeiras, aplicações móveis e cloud?
• Como protege o fornecedor os dados e as evidências que recolhe durante o teste?
• Como serão tratados os achados críticos durante a execução?

Quanto ao preço, varia com o número de aplicações, APIs e o modelo de teste (caixa preta, cinzenta ou branca). Os intervalos reais estão em Quanto custa um teste de intrusão em 2026. Para perceber os modelos, leia O que é um teste de intrusão.

Como a Pentest Machine ajuda

Fazemos testes de intrusão manuais com um relatório pensado para a auditoria: evidência de exploração por achado, mapeamento para as resoluções do Banco Central, plano de tratamento e reteste incluído. Se precisa de fechar o ciclo de 2026 ou de planear o de 2027, peça uma proposta: respondemos com âmbito e prazo no máximo em um dia útil.

Perguntas frequentes

O teste de intrusão é obrigatório para uma fintech pequena?

As normas valem para as instituições autorizadas pelo Banco Central dentro do âmbito das resoluções, independentemente da dimensão. O que muda com a dimensão é o âmbito e a profundidade. Confirme o enquadramento com o compliance ou o jurídico.

Uma análise de vulnerabilidades basta?

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

Quem pode ser a equipa independente?

Empresas ou profissionais sem conflito de interesses com o desenvolvimento e a operação do sistema testado. Uma equipa interna que também constrói o sistema tende a não cumprir o requisito. Mantenha o registo de quem executou o teste e de que ligação tem ao ambiente.

Durante quanto tempo devo guardar o relatório?

As 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 registe-o na política interna de retenção.

O teste tem de cobrir o Pix?

Se a instituição opera ou se liga ao Pix, ao STR ou à RSFN, esses serviços são tratados como críticos pelas normas e devem estar no âmbito, ou o âmbito tem de justificar porque não estão.

Posso fazer o teste uma vez e usar o relatório durante dois anos?

Não. A periodicidade é, no mínimo, anual, e alterações relevantes do ambiente justificam um teste complementar. Planeie o ciclo de 2027 desde já para não repetir a correria de 2026.

O reteste conta como outro teste de intrusão?

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

Posso testar sistemas de fornecedores?

Apenas com autorização contratual e do fornecedor. Acorde o âmbito e as regras por escrito antes de testar qualquer ativo que não seja seu, e registe-o no relatório.