Blog
Artigo 5 min de leitura

Resolução BCB 538 e CMN 5.274: o guia prático da nova segurança cibernética do sistema financeiro

Em 18 de dezembro de 2025, o Banco Central publicou a Resolução BCB nº 538 e o Conselho Monetário Nacional a Resolução CMN nº 5.274 — a maior atualização das regras de segurança cibernética do sistema financeiro brasileiro desde 2021. O prazo de conformidade venceu em 1º de março de 2026, e o contexto não deixa dúvida sobre a disposição do regulador: com os desvios por ataques a instituições financeiras somando mais de R$ 1,5 bilhão em 12 meses, o BC já sinalizou publicamente que pode restringir o acesso ao Pix de instituições com segurança cibernética considerada fraca.

Este guia resume, em linguagem de operação, o que as duas normas exigem, quem está obrigado e — a parte que mais derruba instituição em supervisão — como provar a conformidade.

Quem está obrigado

As duas resoluções são irmãs: mudam o mesmo conjunto de exigências, cada uma para o seu público.

  • Resolução BCB 538/2025 (altera a Resolução BCB 85/2021): instituições de pagamento, corretoras e distribuidoras de títulos e valores mobiliários e corretoras de câmbio autorizadas pelo Banco Central.
  • Resolução CMN 5.274/2025 (altera a Resolução CMN 4.893/2021): bancos, financeiras e sociedades de crédito direto (SCDs).

Na prática, qualquer instituição autorizada pelo BC — ou que opere infraestrutura crítica do Sistema Financeiro Nacional — está no alcance de uma das duas.

O que muda: os seis blocos

1. Teste de intrusão vira regra própria — e anual. O pentest deixa de ser uma boa prática implícita e ganha exigência explícita: deve ser realizado no mínimo uma vez por ano, por profissionais independentes — ou seja, com separação clara entre quem opera o ambiente e quem o testa. Resultados, vulnerabilidades identificadas e planos de ação precisam ser formalmente documentados e retidos por 5 anos, à disposição do Banco Central. O escopo inclui não só os sistemas próprios, mas também ativos de terceiros usados na infraestrutura.

2. Controles técnicos mínimos. Autenticação com múltiplos fatores em operações sensíveis, criptografia de dados, proteção contra malware e intrusões, prevenção e detecção de vazamentos — e security by design: segurança como requisito de desenvolvimento, não como remendo posterior.

3. Rastreabilidade. Trilhas de auditoria completas de operações e acessos, com políticas de retenção definidas por tipo de operação e garantia de integridade, confidencialidade e disponibilidade durante a guarda. Quando algo acontece, a pergunta do supervisor é sempre a mesma: quem fez o quê, quando, de onde, com qual conta? — e a resposta precisa sair da trilha, não da memória do time.

4. Gestão contínua de vulnerabilidades. Análises periódicas, varredura de ativos indevidos na rede e planos de ação documentados. O espírito da norma: vulnerabilidade não é evento, é fila de trabalho com dono e prazo.

5. Exigências específicas para Pix, STR e RSFN. Autenticação multifator para acessos administrativos, isolamento físico e lógico dos ambientes e controles rigorosos sobre certificados digitais e chaves criptográficas. Tratamos esse bloco em detalhe no artigo sobre segurança do Pix.

6. Governança. Reportes periódicos às instâncias de governança, com o tema entrando na agenda de diretoria e conselho. Segurança cibernética deixa de ser assunto do time técnico e vira responsabilidade estatutária.

O ponto central: ter não basta — é preciso provar

O fio que costura os seis blocos é a evidência. O BC já enviou questionário a 1.745 instituições autorizadas mapeando controles de segurança, e declarou que vai cruzar as respostas com o monitoramento cotidiano. A pergunta da supervisão não é "vocês têm política de segurança?" — é "vocês conseguem demonstrar que ela funciona?".

Isso muda o critério de qualidade de tudo: um pentest sem laudo rastreável não protege ninguém em fiscalização; um MFA que existe no manual mas não em produção é passivo regulatório; uma trilha de auditoria que não garante integridade não é trilha, é log.

Checklist de preparação

  1. Mapeie em qual norma você cai (538 ou 5.274) e formalize o gap assessment contra a versão atualizada da BCB 85/2021 ou CMN 4.893/2021.
  2. Contrate ou agende o pentest anual com independência comprovável entre quem testa e quem opera — e trate o laudo como documento regulatório (guarda de 5 anos), não como PDF de gaveta.
  3. Inclua os terceiros no escopo: provedores de tecnologia, software de mercado e integrações fazem parte da sua superfície aos olhos do regulador.
  4. Valide os controles mínimos em produção — MFA em operações sensíveis, criptografia, antimalware, prevenção de vazamento — e guarde a evidência de cada validação.
  5. Audite suas trilhas: cobertura (todas as operações e acessos críticos?), retenção (política formal por tipo de operação?) e integridade.
  6. Estabeleça o ciclo de vulnerabilidades: análise periódica → registro → plano de ação → reteste → evidência.
  7. Leve o tema à governança com reporte periódico formal — ata de reunião de diretoria citando segurança cibernética também é evidência.

Onde o Defender360 entra

O Defender360 Security AI foi construído exatamente para essa equação: teste de intrusão contínuo (não só o mínimo anual — entenda a diferença) com laudo estruturado para a supervisão, documentação de vulnerabilidades e planos de ação prontos para os 5 anos de guarda, e monitoramento da superfície exposta — incluindo os terceiros que a norma agora coloca no seu escopo. Se a sua instituição está no alcance da 538 ou da 5.274, vale uma conversa.

Fontes

Este artigo é informativo e não substitui aconselhamento jurídico. Consulte o texto integral das resoluções e o seu jurídico/compliance para a adequação da sua instituição.

Radar semanal

Receba estas análises toda semana na sua caixa de entrada.

Assinar grátis
Sua superfície aguenta escrutínio?

Teste contínuo de intrusão com evidência técnica para o regulador.

Conhecer o Security IA