Resolução BaCen 498 - Cyber Comentada

A recente Resolução BCB nº 498/2025 redefine os requisitos para o credenciamento de Prestadores de Serviços de Tecnologia da Informação (PSTI) com acesso à RSFN, elevando o patamar de segurança, governança e resiliência exigido pelo regulador. Nesta versão “cyber comentada”, analisamos a norma sob a ótica da segurança cibernética, destacando pontos fortes, lacunas e oportunidades de aprimoramento para garantir a proteção sistêmica do ecossistema e outras estruturas interdependentes.

COMPLIANCE

Canis Latrans

9/8/202517 min ler

BCB BaCen 498 2025
BCB BaCen 498 2025

Visão sobre esta "versão comentada"

O artigo pretende não ser um “resumo burocrático” da Resolução BCB nº 498/2025, apresentando e focando apenas nos pontos que realmente impactam e causam confusões no âmbito da segurança da informação - e da cibernética como o BaCen gosta de referenciar.

Tentaremos ir além do óbvio da redação: em vez de repetir o que já está bem escrito, traremos um olhar de bastidores, interpretando as entrelinhas e revelando pontos de quem atuou e atua de forma pratica na resolução de não-aderências, na aplicação dos controles e mediação de conflitos.

Os textos na "cor azul em itálico" são as referências oficiais do próprio documento enquanto as demais notas e anotações em "preto", observações, recomendações e dicas da consultoria e especialistas acostumados a mercados e setores regulados. Desejamos boa leitura e, quaisquer informações, correções ou sugestões adicionais, poderão ser direcionadas aos canais oficiais dos mantenedores deste blog.

CAPÍTULO I - DO CREDENCIAMENTO

Uma grande parte das startups financeiras e instituições de menor porte, acreditam que as recomendações específicas de Segurança estão apenas e exclusivamente à luz de:

  • CFI - Resolução Nº 5.237/2025, que atualiza, revoga e unifica diversas outras leis (foco Crédito, Financiamento e Investimento)

  • IP - Resolução BCB n° 85/2021 (antiga 3.909, com foco em IP - Instituição de Pagamento)

  • IF - Resolução BaCen 4893/2021 (antiga BaCen 4.658, foco IP - Instituição de Pagamento)

Sem dúvida, esses documentos são as cartilhas-mestras quando o assunto é Segurança da Informação, mas é importante salientar que estas, apresentarão os assuntos de forma mais macro e nem sempre estará claro qual direcionador/guia mais detalhado deve ser utilizado. É ai que entra o arcabouço de materiais dedicados da RSFN - Rede do Sistema Financeiro da Informação, referenciados em:

I - adesão aos princípios e às regras da RSFN;

Apenas como referência, neste é possível encontrar:

  • Manual de Redes do SFN

  • Manual de Segurança do Open Finance

  • Manual das Interfaces de Comunicação

  • Manual de Segurança do Pix​

  • Documento de Requisitos Técnicos - Infraestrutura de Chaves Públicas Brasileira

  • Documento de Dicionário de Domínios

  • Documento de Requisitos do Negócio - DRN e Dicionário de Domínios e Relação de Erros

  • Volume - Pagamentos Instantâneos

  • Volume - Relação de Códigos de Erros​

  • Definições - Mensagens do Catálogo de Mensagens do SPI

  • Definições - Migração SFTP

  • Formulário - Inclusão ou Alteração de Participantes na RSFN

Entre diversos outros volumes, o primeiro documento (Manual de Redes do SFN) é fortemente recomendado a leitura e o entendimento uma vez que este fará acionamentos e correlações com outros guias, requisitos e manuais. As regras fundamentais de funcionamento seguro de toda a "Rede do Sistema Financeiro Nacional" saem deste material que é constantemente atualizado. Observe que a nova norma, deixa claro essa necessidade:

IV - comprovação de capacidade técnico-operacional para prestar os serviços de processamento de dados, para fins de acesso à RSFN, observando os requisitos estabelecidos nesta Resolução e os padrões técnicos referentes à comunicação eletrônica de dados no âmbito do SFN, estabelecidos pelo Departamento de Tecnologia da Informação – Deinf do Banco Central do Brasil;

Outra parte interessante, é nomeação clara de responsáveis temáticos, com uma particularidade que o BaCen sempre deixou claro e deve começar acompanhar mais de perto: conflito de interesse. Isso pode ajuda na resolução existente em alguns casos de conflito onde área de Segurança e Tecnologia respondiam para uma mesma Diretoria que, por muitas vezes, pode configurar conflito entre "entregar um sistema a qualquer custo" para não quebrar algum indicador contra o adicionar corretamente os "regramentos esperados de Segurança". Neste ponto, não há dúvidas que a necessidade de negócio sempre vencia, mas agora vai precisar vir amparada e chancelada pelo time de Riscos, de Compliance e, talvez em algum momento do Jurídico, de forma conjunta. Observe:

V - designação de diretor ou diretores responsáveis pela segurança da informação, segurança cibernética e pela gestão de riscos e compliance, com capacitação técnica compatível com as atribuições do cargo, comprovada com base na formação acadêmica, na experiência profissional na área de atuação ou em conhecimentos técnicos específicos relativos à segurança da informação, à segurança cibernética e à gestão de riscos e compliance.

Um adendo com relação ao bloco de governança, que clarifica sobre:

I - segregação de funções entre gestão executiva, gerenciamento de riscos, compliance, segurança da informação e auditoria interna, de forma a evitar conflitos de interesse e concentração de poderes;

E embora o BaCen não deixe claro, pelo menos para esse assunto, a ISO ganha preferencia clara frente ao NIST e outros modelos, uma vez que é certificável. Frente as análises independentes, que ainda eram mais restritas neste setor, agora o ponto acabou sendo verbalizado diretamente. Se quiser ver mais sobre ISO x NIST, consulte nosso artigo comparativo.

XI - comprovação de obtenção e manutenção de certificação de segurança da informação em norma reconhecida internacionalmente, ou asseguração independente aceita pelo Banco Central do Brasil;
XII - comprovação da contratação de auditoria externa anual independente em segurança da informação e, quando aplicável, em prevenção à lavagem de dinheiro e financiamento do terrorismo, com envio dos relatórios ao Banco Central do Brasil e às instituições contratantes;

A parte de seguros recebeu atenção especial e com uma particularidade da cobertura que obrigatoriamente deve prever "incidentes cibernéticos", não comum em apólices com coberturas menos tecnológicas.

XIII - comprovação da contratação de seguro de responsabilidade civil e de riscos operacionais, com cobertura mínima definida pelo Banco Central do Brasil, incluindo incidentes de fraude e segurança cibernética;

Para alguns contextos e portes, BCP - Plano de Continuidade de Negócios (não é apenas DRP - Disaster Recovery Plan), vai precisar ser dimensionado, possuir recursos de acionamento e constar no conhecido relatório anual. Se quiser sair na frente futuramente em inspeções BaCen, certifique em "diversificar seu Plano de Continuidade" de forma a prever contextos além do trivial e mais comum "cenário de indisponibilidade". Há vida e possibilidades além do pilar "disponibilidade".

XIV - elaboração e manutenção de Plano de Continuidade de Negócios e de testes periódicos de contingência, com comprovação anual ao Banco Central do Brasil.

Na parte de certificação digital, as recomendações presentes no material da RSFN poderão ajudar, com redação direta e clara da necessidade de adequação ao modelo. Descumpriu? Sujeito a descredenciamento, como aplicável em casos de reincidências onde "adequações" são sequencialmente descumpridas em suas datas acordadas de adequação.

§ 1º A adesão de que trata o inciso I do caput se dará por meio da celebração de Termo de Adesão e Responsabilidade, firmado pelo representante legal do PSTI mediante uso de certificado digital emitido por autoridade certificadora da Infraestrutura de Chaves Públicas Brasileira – ICP-Brasil.
§ 3º O PSTI que descumprir a obrigação prevista no § 2º ficará sujeito ao descredenciamento de que trata o art. 7º, caput, inciso II.

CAPÍTULO II - DO DESCREDENCIAMENTO

Não é preciso informar que, manter esse pedido abaixo não é tarefa trivial. Há empresas que até possuem uma área chamada de governança, mas quando você questiona/pede um "indicador efetivo de governança" a conversa muda a rota. É uma palavra fácil de se dizer, mas não tão simples de implementar e manter.

II - à governança corporativa, à gestão de riscos e à segurança da informação;

CAPÍTULO III - DA GOVERNANÇA CORPORATIVA E DA GESTÃO DE RISCOS

Observe que o BaCen frisa muito o contexto "compatível com sua natureza, porte, complexidade, estrutura e perfil". Uma vez que algum participante tenha algum problema, vai ficar cada vez mais difícil negligenciar adequações que não reflitam sua responsabilidade frente ao seu porte/poder. As análises independentes devem colaborar com as partes (tanto na adequação quando na avaliação).

Art. 11. O PSTI deve possuir estrutura de governança corporativa compatível com sua natureza, porte, complexidade, estrutura e perfil de risco, assegurando processos decisórios transparentes, mecanismos de controle interno eficazes e adequada gestão de riscos.
I - segregação de funções entre gestão executiva, gerenciamento de riscos, compliance, segurança da informação e auditoria interna, de forma a evitar conflitos de interesse e concentração de poderes;
II - existência de órgão de administração colegiado (conselho de administração ou equivalente), com participação proporcional de membros independentes, sempre que o porte ou relevância sistêmica do PSTI assim justificar

É bem importante relembrar que, política precisam de sinergia entre o que está escrito, seus controles e contextos e o BaCen sempre deixou essa necessidade verbalizada. Política de Segurança tem que gerar saída para a matéria de Riscos, uma vez que a matéria de Risco gera demanda para Continuidade e todos colaboradas com as necessidades de Compliance (dentro e fora da companhia). É bidirecional? Não, é multidirecional e multialimentada, tanto na formalização (das políticas e normas) quanto na pratica do dia a dia. Se tem ponto não amarrado, é desvio e precisa ser ajustado (novamente, tanto na documentação formal quanto na pratica cotidiana).

III - elaboração e divulgação de políticas formais de governança corporativa, incluindo gestão de riscos, segurança cibernética, compliance, auditoria interna e continuidade de negócios;

Diretorias cada vez mais independentes e separadas (proporcionais ao porte, perfil...), de forma a dificultar o aceite de desvios, conflitos, desconhecimento e colaborações duvidosas, sem deixar de lado o viés de risco. Declarações de que a "informação" não chegou as camadas estratégicas ou estes não foram alertados pelos comitês intermediários não somente não ajuda como deve piorar a situação.

§ 3º O PSTI deve instituir, no âmbito da alta administração, diretores responsáveis por funções críticas, incluindo, no mínimo:
I - Diretor de Segurança da Informação e Cibernética, responsável pela implementação de políticas de cibersegurança e pela gestão de incidentes operacionais;
II - Diretor de Riscos e Compliance, responsável pela supervisão da conformidade regulatória e pela efetividade dos controles internos;
III - Diretor responsável pelo relacionamento com o Banco Central do Brasil, responsável pela prestação de informações e interlocução regulatória; e
IV - Diretor responsável pela gestão de crises operacionais e pela coordenação do Comitê de Gestão de Crises Operacionais.
Art. 14. O PSTI deve estabelecer políticas de gestão de riscos compatíveis com sua natureza, porte, complexidade, estrutura e perfil de risco, amparadas nos princípios e nas melhores práticas de mercado.

Observem como as recomendações possuem forte sinergia com Segurança (em todos os níveis, sentidos e hierarquias). Pedir reconhecimento da alta gestão em assinaturas/aprovações ajuda em todo o processo de "irretratabilidade/não-repúdio" por vezes utilizado como salvaguarda que será cada vez mais rígido e menos aceito se negligenciado.

Art. 15. O PSTI deve estabelecer políticas de gestão de riscos voltadas a tratar, no mínimo, de:
I - segurança da informação e cibernética;
II - continuidade de negócios;
III - gestão de crises operacionais;
IV - gestão de fraudes;
V - controles internos e conformidade; e
VI - auditoria interna
Parágrafo único. As políticas de que trata o caput devem ser aprovadas pelo conselho de administração ou, se inexistente, pela diretoria prevista em estatuto ou contrato social, e revisadas, no mínimo, anualmente, ou sempre que houver alteração relevante na estrutura ou no perfil de risco do PSTI.

Sobre as necessidades de Segurança by Design/Default, sem novidades para quem é do meio e opera/administra uma operação mínima sobre o assunto. A única observação é sobre o vazamento de dados que possam configurar "sigilo bancário". Importante lembrar que a LC-105 pode incorrer em retenção: Art. 10. A quebra de sigilo, fora das hipóteses autorizadas nesta Lei Complementar, constitui crime e sujeita os responsáveis à pena de reclusão, de um a quatro anos, e multa, aplicando-se, no que couber, o Código Penal, sem prejuízo de outras sanções cabíveis.

Art. 17. A política de segurança da informação e cibernética de que trata o art. 16 deve contemplar, no mínimo, os seguintes aspectos:
I - mecanismos de criptografia, de prevenção e detecção de intrusão, de prevenção de vazamentos de informações e de proteção contra softwares maliciosos;
II - mecanismos de rastreabilidade de transações;
III - gestão de cópias de segurança dos dados e das informações;
IV - avaliação e correção de vulnerabilidades do ambiente computacional e dos sistemas de informação utilizados na prestação de serviços;
V - controle de acesso;
VI - aplicação regular de correções de segurança;
VII - mecanismos de proteção da rede;
VIII - segregação dos ambientes computacionais, limitando-se o acesso ao ambiente de produção e aos recursos computacionais críticos;
IX - isolamento físico e lógico do ambiente Pix dos demais sistemas da instituição, caso seja também provedor de software como serviço para participante desse ecossistema de pagamentos, mantendo instância dedicada e apartada dos demais ambientes nos casos de uso de nuvem pública;
X - isolamento físico e lógico do ambiente Sistema de Transferência de Reservas – STR dos demais sistemas da instituição, caso seja também provedor de software como serviço para participante desse ecossistema de pagamentos, mantendo instância dedicada e apartada dos demais ambientes nos casos de uso de nuvem pública;
XI - gestão de certificados digitais;
XII - controles específicos para integração com outras partes por meio de interfaces eletrônicas;
XIII - certificação técnica das soluções de tecnologia da informação utilizadas por instituições financeiras e outras instituições supervisionadas pelo Banco Central do Brasil para integrar, por meio de interfaces eletrônicas, com os serviços providos pelo PSTI; e
XIV - ações de inteligência cibernética, incluindo o monitoramento de informações de interesse (clientes, chaves, credenciais, vulnerabilidades etc.) na Internet, Deep e Dark Web, além de grupos privados de comunicação.

Rastreabilidade e retenção, é assunto que algumas empresas não possuem definidos de forma clara em contexto, tempo e necessidade. Se essa é sua condição (ou não sabe se é), leia o contexto abaixo e visite nosso artigo para ajuda com o assunto. A OmniSec preparou um eBook sobre essa necessidade.

§ 2º Os mecanismos de rastreabilidade de transações de que trata o inciso II do caput devem contemplar, no mínimo:
I - trilhas de auditoria do processamento fim-a-fim dos dados e das informações, incluindo a definição e a geração de logs que possibilitem identificar falhas de processamento ou comportamento atípicos, bem como subsidiar análises;
II - definição de tempo de retenção de informações de acordo com o tipo de processamento realizado;
III - retenção segura das trilhas de auditoria;
IV - acesso às trilhas de auditoria pelas instituições que utilizam os serviços providos pelo PSTI, para fins de conciliação ou gestão de riscos.

Sobre os itens de vulnerabilidades e testes de invasão, estão atrelados a um processo recorrente e contínuo de "análise e gerenciamento de vulnerabilidades". O que por vezes acaba sendo mais complicado de controlar e saber, principalmente em grandes Conglomerados, é saber exatamente quais ativos fazem parte do escopo da sua classificação, seja este CFI, IP ou IF. Lembre-se que o que é realmente interessante primariamente ao BaCen, são os ativos e contextos que ofertam, utilizam ou fazer parte SFN - Sistema Financeiro Nacional. Se tem algo mais abrangente que isso, até por questões de segurança e segregação, seria muito importante que realizada as separações físicas e/ou lógicas onde aplicável.

Não é tão claro mas importante salientar que, todo ano, quando você reporta indicadores ao BaCen (sejam de treinamento de conscientização, incidentes, inventariado, pen-testings, governança de dados, tamanho do times, responsáveis por segurança etc.), o BaCen espera receber os indicadores do contexto da sua relação de alçada, seja você IF, IP, CFI ou qualquer outro tipo. Se está reportando indicadores do conglomerado como um todo (e lá existe outras operações não financeiras) está errado e, fazer esta distinção no seu inventariado/CMDB para todos os ativos pertencentes unicamente ao contexto SFN, não é tarefa das mais triviais e rápidas, principalmente se não houver um "mapa/diagrama/mapeamento do fluxo de tipos de dados", coisa não comum na grande parte dos times de "Governança de Dados" em operação (para LGPD provavelmente tenham bem definido, mas para outros tipos de rótulos não é comum).

§ 3º A avaliação e a correção de vulnerabilidades de que trata o inciso IV do caput deve contemplar, no mínimo:
I - testes e análises periódicas para detecção de vulnerabilidades em sistemas de informação;
II - varreduras físicas periódicas do ambiente tecnológico que possibilitem identificar dispositivos indevidamente conectados à rede corporativa que possam estabelecer conexão com ativos de tecnologia externos;
III - análises periódicas do ambiente tecnológico com o objetivo de identificar vulnerabilidades que possam comprometer a segurança dos ativos de tecnologia do PSTI; e
IV - testes de intrusão periódicos.

§ 4º O controle de acesso de que trata o inciso V do caput deve incluir, ao menos:
I - mecanismos para limitar o acesso à rede corporativa a usuários e dispositivos autorizados;
II - revisão periódica e tempestiva das permissões de acesso, em especial, de colaboradores terceirizados com acesso ao ambiente computacional da instituição;
III - estabelecimento de múltiplos fatores de autenticação para acesso à rede corporativa a partir de ambientes externos; e
IV - para os ambientes Pix e STR, o acesso administrativo deve ser realizado sempre utilizando múltiplos fatores de autenticação.

Desta seção, o último item costumar ser complicador, uma vez que em cenários/empresas com equipe reduzida, não há uma "definição de normalidade" mapeada para os sistemas mais críticos e quando existe, o "conceito de incidente" é divergente entre diversos times o que acaba dificultando a correta tipificação, encaminhamento e comunicação do assunto interna e externamente aos reguladores quando necessário.

IV - implementação e manutenção de processos e ferramentas para identificação, análise e tratamento de eventos atípicos no ambiente do PSTI, a exemplo da abertura de virtual private networks – VPN e de tentativas de acesso privilegiado, especialmente em horário noturno ou não convencional, assim como avaliação da implantação de controles mais robustos que mitiguem riscos de acessos indevidos nessas ocasiões.

Sobre Continuidade, definições de RPO, RTO e MTPD devem fazer parte dos BCPs (como informado, não apenas dos isolados DRPs - Planos de Recuperação de Desastre) e naturalmente, que tenham sinergia de interesse como os times de Riscos, Compliance e Engenharia de Confiabilidade, desde o momento da "declaração de crise" até processo de comunicação final com as partes interessadas, integrados naturalmente, com um Modelo/Metodologia de Gerenciamento de Incidentes (que se for seguir a mesma regra do BaCen, as empresas precisarão definir o conceito de "incidente relevante") em linha com um modelo de prevenção de fraudes (bem explicado no material que não será mencionado aqui).

Art. 19. A política de continuidade de negócios de que trata o art. 18 deve contemplar, no mínimo, o seguinte:
I - procedimentos e prazos estimados para reinício e recuperação das atividades em caso de interrupção dos processos críticos de negócio, bem como as ações de comunicação necessárias;
II - testes e revisões dos planos de continuidade de negócios com periodicidade mínima anual;
III - instalação e operação de centro de processamento secundário, sujeito a conjunto de riscos diferentes do centro de processamento principal, capaz de processar volumes no mínimo iguais ao maior volume verificado nos últimos duzentos e cinquenta e dois dias úteis, acrescido de um percentual de segurança, e com replicação de dados do centro de processamento principal; e
IV - procedimentos de emergência, no caso de impedimento simultâneo dos centros de processamento principal e secundário.

Na parte de inteligência comunitária (compartilhado de experiências), pode ser que empresas de comunicação/tratamento dedicadas entrem na jogada ou as PSTIs e interessados deverão passar a consumidor alguns padrões de mercado como o MISP ou o OpenCTI).

VII - estabelecimento de canal que possibilite a comunicação tempestiva de indícios de fraude com instituições financeiras e demais instituições supervisionadas pelo Banco Central do Brasil que possam ser impactadas por esses eventos.

Já o time de Controles Internos, parte acostumada com modelos mais generalistas e de mercado (COSO, COBIT, ISOx, SEC/SOx), precisarão conhecer em maior profundidade os documentos e anexos da RSFN, listados na abertura deste artigo. Recomendamos que iniciem essa jornada o quanto antes pois normalmente são grandes e não tão fáceis de serem digeridos. O alinhamento com o alto nível e segregação de funções/interesses (SoD e CoI) reaparecem.

Art. 27. A política de controles internos e conformidade de que trata o art. 26 deve contemplar, no mínimo, os seguintes controles:
I - testes e revisão periódica de controles internos e das medidas de contingência; e
II - mecanismo para garantir a conformidade com os dispositivos desta Resolução e com todos os requisitos técnicos da RSFN previstos no Catálogo de Serviços do SFN, no Manual de Redes do SFN e no Manual de Segurança do SFN publicados pelo Banco Central do Brasil.

Art. 29. A política de auditoria interna de que trata o art. 28 deve prever, no mínimo, os seguintes aspectos:
I - linha de reporte da auditoria interna ao conselho de administração ou, se inexistente, à diretoria prevista em estatuto ou contrato social;
II - segregação das unidades de negócio e dos órgãos de gestão de riscos, controles internos e conformidade;
III - definição de uma estrutura de auditoria interna compatível com a natureza, porte, complexidade, estrutura e perfil de risco do PSTI;
IV - elaboração de plano anual de auditoria interna, com aprovação pelo conselho de administração ou, se inexistente, pela diretoria prevista em estatuto ou contrato social, baseado na avaliação de riscos de auditoria e contendo, pelo menos, os processos que farão parte do escopo da atividade de auditoria interna, a classificação desses processos por nível de risco e a proposta de alocação dos recursos disponíveis; e
V - possibilidade de contratação de auditoria externa independente, para validar ou complementar a auditoria interna, com compartilhamento dos relatórios com o Banco Central do Brasil e instituições contratantes.

CAPÍTULO IV - DA PRESTAÇÃO DE INFORMAÇÕES AO BaCen

Da redação geral, nos parece importante mencionar:

II - certificação técnica requerida no art. 3º, caput, inciso XI sempre que renovada ou atualizada;
IV - incidentes operacionais ou de segurança da informação que possam comprometer a integridade, a disponibilidade ou a confidencialidade dos serviços prestados, imediatamente após a ciência da ocorrência, acompanhados de relatório no prazo de até dez dias;

CAPÍTULO V - DAS MEDIDAS CAUTELARES

Caso o contexto se expanda para o SBP - Sistema Brasileiro de Pagamentos, importante relembrar que assuntos sobre resiliência/continuidade não são opcionais neste contexto. Leia especificamente sobre e prepare sua infraestrutura de contingência com os respectivos testes.

Art. 31. Fica o Banco Central do Brasil autorizado a adotar medida cautelar em relação ao PSTI nas seguintes situações:
I - ocorrência de incidentes operacionais, tecnológicos ou de segurança, incluindo os originados por ataque cibernético ou evento de fraude, os que possam impactar o regular funcionamento do SPB, ou os relacionados a situações em que não há causa raiz identificada ou comprovação de resolução definitiva do problema;
III - descumprimento grave ou reiterado das obrigações de reporte e de transparência previstas nesta Resolução;
IV - determinação de reforço imediato em requisitos técnicos de segurança, governança ou continuidade de negócios, com prazos definidos para comprovação;
VIII - execução total ou parcial do plano de saída ordenada; e

CAPÍTULO V - DAS DISPOSIÇÕES FINAIS

Sobre a seção de disposições e encerramento, ressaltamos observar:

V - não utilizar o mesmo certificado entre ambientes, como homologação e produção, e função, como assinatura de mensagens e estabelecimento de canal do Pix;
§ 4º A não apresentação de pedido de credenciamento no prazo de que trata o § 3º acarretará o descredenciamento de ofício do PSTI, que deverá elaborar e implementar plano de saída ordenada.
Art. 39. Esta Resolução entra em vigor na data de sua publicação (5 setembro de 2025).

(+) Pontos positivos?

  • Barreira mínima de robustez do provedor, reduzindo “PSTI aventureiro” e induzindo a maturidade

  • Governança mais forte e segregação com comitê de crises, segregação de funções e ambientes

  • Controles técnicos explícitos de segurança fundamental

  • Indicadores de monitoramento e interrupção de fluxo

  • Continuidade e resiliência mais rígida com capacidade de absorver picos

  • Medidas cautelares com previsão de suspensão de conexão/serviços, seguros e controles e auditoria

  • Maior sinergia com clareza da base do RSFN elevando o nível mínimo de todo ecossistema

(!) Pontos de atenção

  • Barreiras de entrada mais altas que envolvem capital e mais recursos (pode encarecer a infra/serviços)

  • Algumas exigências são abertas/vagas como “certificação em norma reconhecida internacionalmente”

  • Previsão de interrupção total do fluxo e suspensões cautelares sem parâmetros públicos

  • Obrigações de isolamento para PIX/STR quando o PSTI também provê SaaS, mas faltam detalhes sobre multi-tenant/co-tenancy e segregação de chaves

  • Necessidades de LGPD pouco explícita, com referências a dados sensíveis, minimização e transparência

  • Custo/complexidade e requisitos para a continuidade considerando o pico (252 dias)

Observações finais

A resolução traz avanços importantes e reais impactos no contexto da segurança. Cabe agora ao mercado transformar regra em prática — sem esquecer que, no fim, o detalhe é sempre onde mora o risco. Caso precise de ajuda ou sanar dúvidas sobre, estamos à disposição.