
O seu último teste de intrusão incluiu a integração com a empresa que registra os contratos de veículos do banco no Detran? Se a resposta for “não sei” ou “isso é com o fornecedor”, vale revisitar o escopo. A alteração da Res. CMN 4.893, aprovada em 18 de dezembro de 2025, passou a exigir teste de intrusão anual e independente, com resultados guardados por cinco anos, e estendeu os controles mínimos de segurança a sistemas desenvolvidos por terceiros. O prazo de adequação venceu em 1º de março de 2026.
A regra, em poucas linhas
A mudança foi fundamentada no Voto CMN 88/2025 e veio por resolução que bases secundárias identificam como a de número 5.274. Além do teste de intrusão, ela listou controles mínimos — certificados, integração por APIs, rastreabilidade, controle de acesso, configurações seguras e autenticação multifator — e determinou que valem também para sistemas de terceiros. Em outras palavras, a fronteira do teste deixou de coincidir com a fronteira do data center do banco.
O movimento não é isolado. Em 5 de setembro de 2025, a Res. BCB 498 disciplinou o credenciamento de provedores de serviços de TI da Rede do Sistema Financeiro Nacional. O recado regulatório é consistente: quem presta serviço de tecnologia ao sistema financeiro está cada vez mais perto do centro da supervisão, e não da sua periferia. Para os bancos, isso reforça a necessidade de olhar a cadeia de fornecedores com o mesmo rigor aplicado aos próprios sistemas.
Onde o escopo costuma falhar
Em muitas instituições, o teste de intrusão nasceu para cobrir aplicações internas e canais digitais voltados ao cliente. As integrações com fornecedores ficavam fora, sob o argumento de que a segurança do outro lado era responsabilidade contratual do parceiro. A alteração da 4.893 enfraquece esse argumento quando o sistema de terceiro faz parte do fluxo de dados da instituição. Afinal, um dado vazado na ponta do parceiro continua sendo um dado do cliente do banco.
O registro de contratos é um exemplo claro. Chaves de API, certificados, filas de envio, retornos de status e arquivos digitalizados de contratos trafegam entre o banco e a registradora todos os dias. Um teste que avalia o portal do cliente com rigor, mas ignora esse canal, pode produzir um relatório limpo e, ainda assim, deixar exposta uma das rotas mais sensíveis da operação de crédito.
Com guarda obrigatória de cinco anos, o relatório do teste de intrusão feito em 2026 precisa continuar disponível até 2031. Isso significa que a instituição terá, em pouco tempo, uma série histórica de testes capaz de mostrar à supervisão não só o estado atual da segurança, mas também a evolução das correções ao longo dos ciclos.
Um roteiro prático para o ciclo de 2026
Nem tudo precisa ser testado pelo próprio banco. O lado do fornecedor pode ser coberto pelo teste independente que ele mesmo contrata, desde que o banco receba evidências suficientes e acompanhe as correções. O que não pode existir é uma zona cinzenta, em que cada parte supõe que a outra testou. Os contratos com fornecedores devem prever esse fluxo de informação, com prazos e formato definidos. Um roteiro mínimo para fechar a lacuna inclui:
- Inventariar as integrações com terceiros que tratam dados de clientes, incluindo a registradora.
- Incluir no escopo do teste as APIs, a autenticação e o uso de certificados dessas integrações.
- Exigir do fornecedor o resumo do seu teste independente anual e o plano de correção.
- Arquivar relatórios e evidências por cinco anos, com responsável definido.
A One IT estrutura suas integrações de registro pensando em quem vai testá-las: documentação das APIs, ambiente de homologação para ensaios coordenados e trilhas de auditoria por contrato. Para o banco, isso facilita incluir a registradora no escopo do teste anual — ou receber dela evidências claras quando o teste for de responsabilidade do fornecedor. 🛡️
Referências
- Voto CMN 88/2025 (BCB 185/2025) · Fundamentação da alteração da Res. CMN 4.893: teste de intrusão anual e controles para sistemas de terceiros. — acessar
- Resolução BCB 498/2025 · Credenciamento de provedores de serviços de TI da Rede do Sistema Financeiro Nacional, citado no mesmo voto. — acessar
Escrito por quem acredita que o melhor teste de intrusão é aquele que encontra o problema antes de outra pessoa. Nenhuma API foi ferida na produção deste texto.
— Núcleo Técnico One IT · Registro · Tecnologia · ConformidadeComo a One IT ajuda: Quer incluir a integração de registro no seu ciclo de testes de segurança?
Segurança da informaçãoFoto do infográfico: Marc Mueller seven11nash / Wikimedia Commons, CC0 (adaptada)

Did your last penetration test include the integration with the company that registers the bank's vehicle contracts with the Detran? If the answer is “I don't know” or “that's the supplier's job”, the scope is worth revisiting. The amendment to CMN Resolution 4,893, approved on 18 December 2025, introduced an annual, independent penetration test, with results kept for five years, and extended minimum security controls to systems developed by third parties. The compliance deadline expired on 1 March 2026.
The rule, in a few lines
The change was grounded in CMN Vote 88/2025 and came through a resolution that secondary databases identify as number 5,274. Besides penetration testing, it listed minimum controls — certificates, API integration, traceability, access control, secure configurations and multi-factor authentication — and made them apply to third-party systems as well. In other words, the boundary of the test no longer coincides with the boundary of the bank's data centre.
The move is not isolated. On 5 September 2025, BCB Resolution 498 set rules for accrediting IT service providers on the National Financial System Network (RSFN). The regulatory message is consistent: those who provide technology services to the financial system are moving ever closer to the centre of supervision, not its periphery. For banks, this reinforces the need to look at the supplier chain with the same rigour applied to their own systems.
Where scoping usually fails
In many institutions, penetration testing was born to cover internal applications and customer-facing digital channels. Supplier integrations were left out, on the grounds that security on the other side was the partner's contractual responsibility. The amendment to Resolution 4,893 weakens that argument whenever the third-party system is part of the institution's data flow. After all, data leaked on the partner's side is still data belonging to the bank's customer.
Contract registration is a clear example. API keys, certificates, submission queues, status returns and digitised contract files travel between the bank and the registration company every day. A test that rigorously assesses the customer portal but ignores this channel may produce a clean report and still leave one of the most sensitive routes in the lending operation exposed — precisely the kind of gap an incident tends to reveal first.
With a mandatory five-year retention period, the report from a penetration test carried out in 2026 must remain available until 2031. This means that, before long, institutions will have a historical series of tests able to show supervisors not only the current state of security but also how remediation has evolved over successive cycles.
A practical roadmap for the 2026 cycle
Not everything has to be tested by the bank itself. The supplier's side can be covered by the independent test the supplier commissions, provided the bank receives sufficient evidence and follows up on remediation. What cannot exist is a grey zone in which each party assumes the other has tested. Supplier contracts should provide for this flow of information, with agreed timing and format. A minimum roadmap to close the gap includes:
- Inventory third-party integrations that handle customer data, including the registration company.
- Bring the APIs, authentication and certificate use of those integrations into the test scope.
- Require the supplier's summary of its annual independent test and remediation plan.
- File reports and evidence for five years, with a named owner.
One IT structures its registration integrations with the tester in mind: API documentation, a staging environment for coordinated exercises and per-contract audit trails. For the bank, this makes it easier to include the registration provider in the scope of the annual test — or to receive clear evidence from it when testing is the supplier's responsibility. 🛡️
References
- Voto CMN 88/2025 (BCB 185/2025) · Grounds for amending CMN Resolution 4,893: annual penetration testing and controls for third-party systems. — open
- Resolução BCB 498/2025 · Accreditation of IT service providers on the National Financial System Network, cited in the same vote. — open
Written by people who believe the best penetration test is the one that finds the problem before someone else does. No APIs were harmed in the making of this article.
— One IT Technical Team · Registry · Technology · ComplianceHow One IT helps: Want to bring the registration integration into your security testing cycle?
Information securityInfographic photo: Marc Mueller seven11nash / Wikimedia Commons, CC0 (adaptada)

¿Su última prueba de intrusión incluyó la integración con la empresa que registra los contratos de vehículos del banco en el Detran? Si la respuesta es “no lo sé” o “eso es del proveedor”, revise el alcance. La modificación de la Resolución CMN 4.893, aprobada el 18 de diciembre de 2025, exige una prueba de intrusión anual e independiente, con resultados conservados cinco años, y extendió los controles mínimos a sistemas desarrollados por terceros. El plazo de adecuación venció el 1 de marzo de 2026.
La regla, en pocas líneas
El cambio se fundamentó en el Voto CMN 88/2025 y llegó mediante una resolución que bases secundarias identifican con el número 5.274. Además de la prueba de intrusión, enumeró controles mínimos — certificados, integración por API, trazabilidad, control de acceso, configuraciones seguras y autenticación multifactor — y estableció que valen también para sistemas de terceros. En otras palabras, la frontera de la prueba dejó de coincidir con la del centro de datos del banco.
El movimiento no es aislado. El 5 de septiembre de 2025, la Resolución BCB 498 reguló la acreditación de proveedores de servicios de TI de la Red del Sistema Financiero Nacional. El mensaje regulatorio es coherente: quien presta servicios de tecnología al sistema financiero está cada vez más cerca del centro de la supervisión, y no de su periferia. Para los bancos, la cadena de proveedores merece el mismo rigor que los sistemas propios.
Dónde suele fallar el alcance
En muchas instituciones, la prueba de intrusión nació para cubrir aplicaciones internas y canales digitales orientados al cliente. Las integraciones con proveedores quedaban fuera, con el argumento de que la seguridad del otro lado era responsabilidad contractual del socio. La modificación de la 4.893 debilita ese argumento cuando el sistema de terceros forma parte del flujo de datos de la institución. Al fin y al cabo, un dato filtrado del lado del socio sigue siendo un dato del cliente del banco.
El registro de contratos es un ejemplo claro. Claves de API, certificados, colas de envío, respuestas de estado y archivos digitalizados de contratos circulan entre el banco y la registradora todos los días. Una prueba que evalúa con rigor el portal del cliente, pero ignora ese canal, puede producir un informe limpio y, aun así, dejar expuesta una de las rutas más sensibles de la operación de crédito.
Con una conservación obligatoria de cinco años, el informe de la prueba de intrusión realizada en 2026 debe seguir disponible hasta 2031. Eso significa que, en poco tiempo, la institución tendrá una serie histórica de pruebas capaz de mostrar a la supervisión la evolución de las correcciones a lo largo de los ciclos.
Una hoja de ruta para el ciclo de 2026
No todo tiene que probarlo el propio banco. El lado del proveedor puede cubrirse con la prueba independiente que él mismo contrata, siempre que el banco reciba evidencias suficientes y haga seguimiento de las correcciones. Lo que no puede existir es una zona gris en la que cada parte supone que la otra ya probó. Los contratos con proveedores deben prever ese flujo de información, con plazos y formato definidos. Una hoja de ruta mínima incluye:
- Inventariar las integraciones con terceros que tratan datos de clientes, incluida la registradora.
- Incluir en el alcance las API, la autenticación y el uso de certificados de esas integraciones.
- Exigir al proveedor el resumen de su prueba independiente anual y el plan de corrección.
- Archivar informes y evidencias cinco años, con un responsable definido.
One IT estructura sus integraciones de registro pensando en quien va a probarlas: documentación de las API, entorno de homologación para ensayos coordinados y trazas de auditoría por contrato. Para el banco, esto facilita incluir a la registradora en el alcance de la prueba anual — o recibir de ella evidencias claras cuando la prueba sea responsabilidad del proveedor. 🛡️
Referencias
- Voto CMN 88/2025 (BCB 185/2025) · Fundamentación de la modificación de la Res. CMN 4.893: prueba de intrusión anual y controles para sistemas de terceros. — acceder
- Resolução BCB 498/2025 · Acreditación de proveedores de servicios de TI de la Red del Sistema Financiero Nacional, citada en el mismo voto. — acceder
Escrito por quienes creen que la mejor prueba de intrusión es la que encuentra el problema antes que otra persona. Ninguna API resultó herida aquí.
— Núcleo Técnico One IT · Registro · Tecnología · CumplimientoCómo ayuda One IT: ¿Quiere incluir la integración de registro en sus pruebas de seguridad?
Seguridad de la informaciónFoto de la infografía: Marc Mueller seven11nash / Wikimedia Commons, CC0 (adaptada)


