Órgão emissor
Banco Central do Brasil (BCB)
Publicação
18/12/2025
Vigência
Imediata · adequação até 01/03/2026
Aplicabilidade
Instituições de pagamento, corretoras e distribuidoras de valores mobiliários, corretoras de câmbio
Norma alterada
Resolução BCB nº 85/2021
Norma correlata
Resolução CMN nº 5.274/2025 (bancos e demais IFs)
Última revisão
27/04/2026
Prazo de adequação encerrado em 01/03/2026. Esta ficha foi revisada após o vencimento. Instituições ainda fora de conformidade estão expostas a fiscalização e à dosimetria do BCB. As fases do checklist abaixo refletem prioridades para quem precisa entrar em compliance retroativamente e para quem precisa sustentar os controles já implantados.

Resumo executivo

A Resolução BCB nº 538/2025 endurece os requisitos de segurança cibernética e de contratação de serviços de processamento, armazenamento de dados e computação em nuvem aplicáveis a instituições de pagamento, corretoras e distribuidoras. A norma altera a Resolução BCB nº 85/2021 e expande substancialmente o Art. 3º, estabelecendo um piso mínimo de 14 procedimentos e controles obrigatórios. Exige isolamento físico e lógico dos ambientes do Pix e do STR, veda o acesso de terceiros (incluindo prestadores de serviço de TI) às chaves privadas usadas para assinatura de mensagens de pagamento, formaliza estrutura de Threat Intelligence e torna obrigatório o teste de intrusão anual conduzido por profissional independente, com retenção de evidência por cinco anos. A norma irmã para bancos e demais instituições financeiras é a Resolução CMN nº 5.274/2025, publicada em conjunto. O prazo de adequação encerrou em 01/03/2026 — instituições fora de compliance já estão sujeitas à fiscalização do BCB.

Impacto de negócio

Artigos-chave

Art. 1º Escopo de aplicação
A norma se dirige às instituições de pagamento, corretoras e distribuidoras de títulos e valores mobiliários e corretoras de câmbio autorizadas a funcionar pelo Banco Central, alterando a Resolução BCB nº 85/2021.

Na prática: bancos e demais instituições financeiras seguem regra equivalente pela Resolução CMN nº 5.274/2025. Conglomerados mistos (banco + IP + corretora) precisam harmonizar política única, coberta pelas duas normas, sem perder a especificidade aplicável a cada licença.

Art. 2º Política de segurança cibernética e governança
A política deve contemplar princípios, objetivos, controles, papéis e responsabilidades; ser aprovada pela alta administração; e ter compatibilidade com o porte, perfil de risco, modelo de negócio e relevância sistêmica da instituição.

Na prática: a política herdada da Res. 85/2021 não basta — precisa ser revisada, reaprovada e ter trilha de aprovação documentada pós-538. O Conselho e a Diretoria são responsáveis pela aprovação e pela supervisão; o tema entra em pauta recorrente, não anual.

Art. 3º (caput) 14 controles mínimos obrigatórios
O artigo foi substancialmente expandido e estabelece a base mínima de procedimentos e controles que a política de segurança cibernética deve contemplar — autenticação, criptografia, gestão de chaves, prevenção de intrusão e vazamento, registro e monitoramento, threat intelligence, gestão de vulnerabilidades, resposta a incidente e demais controles correlatos.

Na prática: é o núcleo técnico da norma. Funciona como um piso — não um teto. Cada controle precisa ter dono, evidência de funcionamento, métrica e revisão periódica. Em supervisão, o BCB pede mapeamento explícito controle-a-controle, com referência cruzada a documentos internos, configurações e logs.

Art. 3º (Pix/STR) Isolamento de ambientes críticos
As instâncias que processam mensagens do Pix e do Sistema de Transferência de Reservas (STR) devem ser isoladas física e logicamente dos demais sistemas. Em ambiente de nuvem, devem residir em instância dedicada, segregada das demais cargas.

Na prática: VPC compartilhada, namespace Kubernetes misto ou banco de dados multitenant não atendem. Operadoras precisam revisar topologia de rede, contas/projetos cloud e contratos com CSP para evidenciar dedicated tenancy e segregação ponta a ponta — desde rede até processo, runtime e dados.

Art. 3º (chaves privadas) Vedação de acesso de terceiros a chaves de assinatura
Fica vedado o acesso de prestadores de serviço de tecnologia, inclusive provedores de nuvem, às chaves privadas utilizadas na assinatura digital de mensagens de pagamento, devendo a custódia e o uso permanecer sob controle exclusivo da instituição.

Na prática: arranjos com HSM-as-a-Service, KMS gerenciado por terceiro ou modelos em que o CSP detém poder operacional sobre a chave precisam ser redesenhados. A trilha de operação da chave (geração, custódia, uso, rotação, destruição) precisa demonstrar, em walkthrough, ausência de acesso por terceiros.

Art. 3º (incidentes) Plano de ação e resposta a incidentes
A instituição deve manter plano de ação e de resposta a incidentes de segurança cibernética, abrangendo escalonamento, papéis, comunicação interna e externa (inclusive ao BCB) e simulações periódicas.

Na prática: o BCB quer ver runbook escrito, treinado, com simulações realistas (não só tabletop teórico). O incidente em ambiente Pix/STR aciona comunicação acelerada — qualquer atraso aparece no exame e agrava a dosimetria. Integração com o canal de comunicação à ANPD é parte do mesmo processo.

Art. 3º (pentest) Teste de intrusão anual independente
Deve ser realizado, no mínimo anualmente, teste de intrusão por profissional ou empresa independente, com documentação dos resultados e dos planos de ação para correção das vulnerabilidades identificadas, mantida à disposição do Banco Central por cinco anos.

Na prática: "independente" significa empresa sem conflito de interesse — não pode ser o mesmo fornecedor que opera o ambiente, nem incumbent de longa data sem rotação. Escopo mínimo cobre canais externos, ambientes críticos (Pix/STR), acesso interno privilegiado e cadeia de suprimento. O plano de remediação precisa ter prazo, dono e evidência de fechamento — não basta listar achados.

Art. 3º (threat intel) Inteligência de Ameaças (Threat Intelligence)
A instituição deve dispor de estrutura — própria ou contratada — de inteligência de ameaças, com monitoramento ativo, inclusive em fóruns abertos e em deep/dark web, detecção de vazamentos de credenciais e análise de novos vetores de ataque relevantes ao seu modelo de negócio.

Na prática: não basta ter feed comercial pago — precisa haver operação. Triagem, priorização, ação tomada por achado, métrica de credenciais expostas, integração com SOC e gestão de vulnerabilidades. Em supervisão, o BCB pede exemplos concretos de ameaças identificadas e da resposta correspondente.

Arts. 4º-7º Contratação de processamento, armazenamento e nuvem
Os requisitos para contratação de serviços relevantes de processamento, armazenamento de dados e computação em nuvem foram reforçados: análise de risco prévia, due diligence do prestador, cláusulas mínimas (SLAs robustos, plano de continuidade, segurança da informação, encerramento), direito de auditoria do contratante e acesso do Banco Central aos relatórios e ao ambiente do prestador.

Na prática: contratos antigos sem cláusula de acesso do regulador, sem SLA verificável ou sem plano de continuidade explícito precisam ser repactuados. A lista de serviços considerados "relevantes" exige classificação interna documentada e processo formal de aprovação por instância colegiada.

Disp. transitórias Prazo de adequação
As instituições em funcionamento na data de publicação devem se adequar às novas exigências até 1º de março de 2026.

Na prática: prazo encerrado. A partir de 02/03/2026, qualquer fiscalização encontra a instituição em descumprimento se houver gap. Recomenda-se manter trilha clara de "data efetiva de implementação" por controle, para sustentar argumentação de boa-fé na dosimetria caso haja achado.

Controles ITGC impactados

Access Management

  • MFA obrigatório para acesso administrativo aos ambientes Pix e STR. Evidência típica: política de IAM formalizada, configuração no IdP (Okta, Azure AD/Entra) com policy específica para grupos administrativos de Pix/STR, registro de exceções e teste anual de bypass.
  • Custódia de chaves privadas de assinatura sob controle exclusivo da instituição. Evidência típica: arquitetura do HSM/KMS com prova de não acesso por CSP ou fornecedor (BYOK + non-exportable, dual control, M-of-N), trilha de auditoria de operações sobre a chave, política de rotação e segregação de papéis.
  • Segregação de funções entre operação, segurança e auditoria nos ambientes críticos. Evidência típica: matriz RACI por processo de pagamento, revisão trimestral de acessos a tabelas/serviços do Pix/STR, recertificação independente.

Change Management

  • Mudanças que tocam ambientes Pix/STR exigem fluxo dedicado, com revisão de segurança e aprovação por instância colegiada. Evidência típica: trilha no ServiceNow/Jira com flag "Pix/STR", aprovação obrigatória do CISO ou delegado, registro de teste de regressão de controle.
  • Pipeline de CI/CD com gates obrigatórios de SAST, SCA, varredura de secrets e revisão de configuração de cloud. Evidência típica: resultado dos scans anexado ao change, política de bloqueio de deploy em achados críticos, log no orquestrador.

Operations / Monitoring

  • SIEM com correlação dedicada para Pix/STR e retenção alinhada ao prazo regulatório (5 anos para evidência de pentest e correlatos). Evidência típica: dashboard de eventos críticos, política de retenção formalizada, configuração no SIEM (Splunk, Sentinel, Elastic) com cold storage compatível.
  • Operação de Threat Intelligence com triagem, priorização e ação documentadas. Evidência típica: registros de IOCs aplicados em controles, relatórios mensais de credenciais vazadas e ações de invalidação, integração com SOC.
  • Runbook de incidente em ambiente de pagamento com escalonamento ao BCB. Evidência típica: documento versionado, simulação realizada no último ciclo com lições aprendidas, prazo de comunicação ao regulador definido em horas.

SDLC

  • Secure SDLC com modelagem de ameaças em features que tocam Pix/STR. Evidência típica: threat model versionado, requisitos de segurança no épico, casos de teste de abuso, sign-off de segurança no go-live.
  • Gestão de vulnerabilidades com SLA por severidade e por exposição. Evidência típica: plataforma de vuln management com SLA configurado, painel de dívida técnica de segurança, evidência de remediação no prazo.

Third-Party / Cloud

  • Contratos com CSPs e prestadores de serviços relevantes contemplam cláusulas mandatórias da Res. BCB 538. Evidência típica: addendum padronizado, base contratual com flag de conformidade, processo de recontratação anual, cláusula de direito de auditoria do contratante e do BCB.
  • Due diligence reforçada em onboarding e revisão periódica de fornecedores classificados como relevantes. Evidência típica: questionário, classificação de risco, relatórios de auditoria do prestador (SOC 2 Type II, ISO 27001, AOC PCI), análise de concentração de fornecedores.
  • Isolamento de ambiente em cloud — instâncias dedicadas para Pix/STR. Evidência típica: diagrama de arquitetura, contas/projetos segregados, política de IAM da cloud, configuração de rede (VPC, peering, private endpoints) demonstrando segregação.

Business Continuity / Resilience

  • Pentest anual por empresa independente com escopo cobrindo Pix/STR e cadeia de suprimentos. Evidência típica: contrato com fornecedor independente (sem conflito), relatório completo, plano de remediação com prazo e dono, evidência de fechamento, retenção por 5 anos.
  • Simulação realista de incidente cibernético envolvendo Pix/STR no calendário anual de testes de continuidade. Evidência típica: playbook, relatório do exercício, lições aprendidas, integração com plano de comunicação ao BCB.
  • BIA atualizado classificando os fluxos de pagamento como de máxima criticidade. Evidência típica: RTO/RPO compatíveis, dependência mapeada de fornecedores, plano de saída em caso de descontinuidade do CSP.

Checklist de implementação

O prazo de adequação encerrou em 01/03/2026. As fases abaixo estão calibradas para dois cenários: (a) instituições ainda fora de compliance, que precisam priorizar gap crítico imediatamente; e (b) instituições em compliance, que precisam sustentar e amadurecer os controles para o ciclo de fiscalização.

Imediato

0–30 dias · sem compliance / sustentação inicial

  • Diagnóstico de gap formal contra os 14 controles do Art. 3º, com classificação por severidade e prazo de remediação.
  • Comunicação formal à Diretoria e ao Conselho sobre o status de compliance, com plano de ação aprovado em ata.
  • Verificação imediata de acesso de terceiros a chaves privadas de assinatura — caso exista, plano de remediação acelerado.
  • Inventário de ambientes Pix/STR e identificação de pontos de não isolamento (VPC compartilhada, multitenant, namespace misto).
  • Mapeamento dos contratos relevantes de tecnologia/nuvem e gap de cláusulas mandatórias.
  • Confirmação de status do último pentest: independência, cobertura, plano de remediação.
Curto prazo

31–90 dias

  • Implementar isolamento físico e lógico dos ambientes Pix/STR (instância dedicada em cloud, segregação de rede, IAM dedicado).
  • Redesenhar custódia de chaves privadas de assinatura para eliminar acesso de terceiros (BYOK não exportável, dual control, M-of-N).
  • Contratar (ou internalizar) estrutura de Threat Intelligence com triagem, priorização e ação operacionalizadas.
  • Renegociar/aditar contratos com CSPs e prestadores relevantes para incluir cláusulas mandatórias da Res. 538 (SLA, continuidade, auditoria, acesso do BCB).
  • Reaprovar a política de segurança cibernética em Conselho/Diretoria, com trilha documentada pós-538.
  • Configurar SIEM e cold storage para retenção compatível com a norma (incluindo evidência de pentest por 5 anos).
Médio prazo

91–180 dias e ciclo recorrente

  • Pentest anual por empresa independente, com escopo cobrindo Pix/STR, cadeia de suprimentos e canais externos; plano de remediação com SLA por severidade.
  • Simulação realista de incidente cibernético em ambiente de pagamento, com participação de Diretoria, jurídico e comunicação ao BCB.
  • Métrica de maturidade de cibersegurança e plano de evolução de 12 meses, reportado periodicamente ao Conselho.
  • Harmonização da política com a Res. CMN 5.274/2025 quando o grupo econômico tiver banco ou demais IFs.
  • Revisão da matriz de fornecedores relevantes e teste de plano de saída ("exit strategy") do CSP principal.
  • Programa de treinamento dirigido — administradores Pix/STR, time de segurança, operação e Diretoria — com avaliação de efetividade.

Perguntas típicas de auditor

  1. Apresentem a política de segurança cibernética vigente, com trilha de aprovação pelo Conselho/Diretoria pós-538/2025. Qual a periodicidade de revisão?
  2. Mostrem o mapeamento controle-a-controle dos 14 itens do Art. 3º, com dono, evidência de funcionamento, métrica e data efetiva de implementação.
  3. Demonstrem o isolamento físico e lógico dos ambientes Pix e STR. Quero ver topologia, segregação de rede, contas/projetos cloud e IAM aplicado.
  4. Como é feita a custódia das chaves privadas de assinatura de mensagens? Mostrem que o CSP/fornecedor não tem acesso operacional, com prova técnica.
  5. Apresentem o último relatório de teste de intrusão. A empresa é independente? Como foi selecionada? Mostrem o plano de remediação e a evidência de fechamento dos achados.
  6. Como opera a estrutura de Threat Intelligence? Mostrem três casos concretos de ameaças identificadas e a resposta tomada.
  7. Mostrem o último incidente cibernético classificado como relevante. Qual foi o prazo de comunicação ao BCB e quais ações de contenção foram tomadas?
  8. Apresentem os contratos com CSPs e prestadores de serviços relevantes. Quais cláusulas foram aditadas para atender à Res. 538? Mostrem direito de auditoria do BCB.
  9. Como é feita a classificação de relevância de um serviço de tecnologia contratado? Mostrem a matriz vigente e a aprovação por instância colegiada.
  10. Demonstrem a simulação de incidente realizada no último ciclo, envolvendo Pix/STR. Quem participou? Quais foram as lições aprendidas?
  11. Apresentem o BIA dos fluxos de pagamento e o plano de saída do CSP principal. Já foi testado?
  12. Mostrem o programa de treinamento dirigido (administradores Pix/STR, segurança, Diretoria) e a avaliação de efetividade do último ciclo.

Gaps mais comuns

Política herdada da Res. 85 sem revisão pós-538

Documento mantido como estava em 2021/2024, sem reaprovação pelo Conselho após a publicação da nova norma. É o primeiro item que aparece em walkthrough e enfraquece toda a defesa subsequente.

Acesso de fornecedor a chaves privadas de assinatura

Arranjos de HSM-as-a-Service ou KMS gerenciado por CSP em que o fornecedor detém poder operacional sobre a chave. Vedação expressa da norma — exige redesenho da custódia.

Pix/STR rodando em VPC compartilhada

Multitenancy lógica com outras cargas, namespace Kubernetes misto ou banco de dados compartilhado. Não atende ao requisito de isolamento físico e lógico.

Pentest sem independência real

Empresa contratada é fornecedora incumbent que também opera o ambiente, ou fornecedor recorrente há anos sem rotação. O BCB questiona conflito de interesse.

Threat Intelligence reduzida a feed comercial

Assinatura de plataforma sem operação — sem triagem, sem ação tomada, sem métrica. O auditor pede exemplos concretos e a inexistência expõe o gap.

Contratos antigos de cloud sem cláusula de acesso do regulador

Contratos firmados antes de 2025 que não foram aditados. Em supervisão, a ausência da cláusula bloqueia o exercício de auditoria do BCB e é tratada como descumprimento direto.

Cibersegurança em pauta anual de Conselho, em vez de recorrente

A norma exige supervisão do Conselho/Diretoria. Pauta anual única não evidencia governança ativa — espera-se recorrência mínima trimestral, com indicadores e decisões registradas.

Frameworks relacionados

Framework Controles / seções relacionados
Resolução BCB nº 85/2021 Norma alterada — base sobre cibersegurança e contratação de processamento, armazenamento e nuvem para IPs, corretoras e distribuidoras.
Resolução CMN nº 5.274/2025 Norma irmã com requisitos equivalentes para bancos e demais instituições financeiras autorizadas pelo BCB.
ISO/IEC 27001:2022 A.5.30 (continuidade de SI), A.5.34 (privacidade), A.8.9 (configuração), A.8.11 (mascaramento), A.8.12 (DLP), A.8.24 (criptografia), A.8.29 (testes de segurança).
NIST CSF 2.0 Funções Govern, Identify, Protect, Detect, Respond, Recover — alinhamento direto com a expansão do Art. 3º.
CIS Controls v8 Mapeamento direto para grande parte dos 14 controles mínimos (IG2/IG3): inventário, hardening, MFA, gestão de vulnerabilidades, monitoramento, resposta a incidente.
PCI-DSS v4.0 Sobreposição em controles aplicáveis ao ambiente de pagamento, criptografia, segmentação de rede e gestão de chaves.
CSA CCM v4 Governança de cloud, gestão de fornecedor, criptografia/KMS, identidade, isolamento de tenant — referência para a contratação e operação de CSP.
Resolução CMN nº 4.893/2021 Norma original sobre política de segurança cibernética para IFs (substituída pela Res. CMN 5.274/2025); ainda relevante para histórico e transição.

Fontes oficiais

Aviso. Ficha curada por Pedro Amaral — IT Governance Manager. Revisada em 27/04/2026. Esta ficha reflete opinião técnica individual para fins de discussão profissional e não constitui aconselhamento jurídico. As citações de artigos refletem o conteúdo regulatório e não reproduzem o texto literal da norma — em caso de aplicação prática, consulte o texto oficial publicado pelo Banco Central do Brasil e seu jurídico interno.