Pentest obligatorio para instituciones del Banco Central de Brasil: qué exigen BCB 538 y CMN 5.274

Qué cambió: el pentest anual pasó de buena práctica a obligación

Hasta 2025, muchas fintech brasileñas trataban el test de intrusión como un ítem de checklist de un cliente o de una auditoría: lo hacían cuando un socio lo pedía, guardaban el PDF y seguían. Las Resoluciones CMN n.º 5.274/2025 y BCB n.º 538/2025, publicadas en diciembre de 2025, cambiaron ese escenario. Actualizan la política de ciberseguridad de las instituciones autorizadas por el Banco Central de Brasil (la base venía de las Resoluciones CMN 4.893/2021 y BCB 85/2021) y le dan al pentest una regla propia: debe realizarse como mínimo una vez al año, por una empresa o un profesional independiente, con documentación formal de los resultados y de los planes de acción. El plazo de adecuación para las instituciones ya en operación fue el 1 de marzo de 2026.

Si tu institución pasó esa fecha sin un test documentado, la pregunta ya no es "si", sino "cuándo y con qué evidencia". Si lo hiciste en 2026, el próximo ciclo vence en 2027 y el supervisor comparará ambos informes. Esta guía resume qué piden las normas, qué conviene aún confirmar en el texto oficial, cómo definir el alcance con un ejemplo concreto, qué suele hacer rechazar un informe y cómo elegir a quien lo ejecuta.

Quién está en el alcance

Las resoluciones se aplican a las instituciones financieras y de pago autorizadas a funcionar por el Banco Central de Brasil: bancos, cooperativas de crédito, corredoras y distribuidoras de valores, instituciones de pago, sociedades de crédito directo (SCD), sociedades de préstamo entre personas (SEP) y demás entidades del Sistema Financiero Nacional. La CMN 5.274 trata de las instituciones bajo la regulación del Consejo Monetario Nacional; la BCB 538 cubre las instituciones de pago y otras autorizadas por el Banco Central. La regla depende del tipo de autorización, así que confirma tu encuadre exacto con legal o compliance. El tamaño no es una exención: cambia la profundidad del alcance, no la existencia del test.

Qué exigen las normas sobre el pentest

No pudimos abrir el texto oficial en el portal de normativas del Banco Central (la página depende de JavaScript). Los puntos siguientes provienen de análisis de estudios jurídicos y de empresas del sector financiero que citan las resoluciones, y las fuentes coinciden en lo principal.

• Periodicidad mínima anual. El pentest debe realizarse, como mínimo, una vez al año. Un cambio relevante del entorno (migración a la nube, nuevo producto, nueva integración crítica) justifica un test complementario.
• Independencia. La ejecución corresponde a una empresa o profesional independiente de quien construyó y opera el entorno probado. Un escaneo automático interno no sustituye el test.
• Documentación formal. Los resultados y los planes de acción para los riesgos encontrados deben formalizarse, y el tema debe llegar a la gobernanza de la institución en informes periódicos.
• Sistemas críticos en el alcance. Las normas tratan los servicios de la RSFN, incluidos Pix y STR, como críticos, y extienden los controles a sistemas adquiridos o desarrollados por terceros. En la práctica, el test debe justificar la cobertura de esas interfaces y dependencias.
• Conservación por cinco años. Varios análisis del sector indican que la documentación del test y los planes de acción deben quedar disponibles para el Banco Central durante cinco años. Como no verificamos el artículo en el texto oficial, trata el plazo como una orientación firme y confirma la disposición exacta con legal antes de fijar la política interna.

Otros controles llegan en el mismo paquete y suelen aparecer en el alcance del test: autenticación multifactor en accesos administrativos, trazas de auditoría íntegras, gestión de certificados y claves criptográficas, corrección periódica de vulnerabilidades, aislamiento de redes críticas y reglas más estrictas para contratar servicios en la nube.

Lo que la norma no hace es dictar el formato del informe. La explotación demostrada, el mapeo a controles y el retest son recomendaciones de buena práctica que vuelven defendible el documento, no cláusulas que citemos como texto de la resolución.

Ejemplo práctico: alcance de una institución de pago

El caso siguiente es hipotético y solo sirve para mostrar el razonamiento. Imagina una institución de pago mediana, con billetera digital en una app móvil, APIs de integración para comercios, conexión a Pix e infraestructura en la nube.

Activo	Por qué entra	Foco del test
App móvil (iOS y Android)	Acceso del cliente final a saldo y transferencias	Autenticación, almacenamiento local, pinning, lógica de límites
APIs transaccionales y de comercios	Mueven dinero y exponen datos	Autorización por objeto (BOLA), límites, idempotencia, mass assignment
Integración Pix / mensajería con la RSFN	Servicio que la norma trata como crítico	Segregación de red, MFA administrativo, validación de mensajes
Panel administrativo y back office	Privilegio alto, blanco de fraude interno	Control de acceso, traza de auditoría, sesión
Nube (cuentas, IAM, almacenamiento, secretos)	Aloja todo lo anterior	Permisos excesivos, secretos expuestos, red entre entornos
Software y SaaS de terceros	Los controles se extienden a sistemas adquiridos	Contrato y autorización de test, configuración, integración

En este ejemplo, un test que cubriera solo el sitio institucional dejaría fuera cinco de las seis filas de la tabla. Es exactamente el tipo de laguna que encuentra el auditor al cruzar el alcance con el inventario de activos. Para las APIs, la hoja de ruta de la guía de pentest de API según el OWASP API Top 10 ayuda a definir qué probar.

Qué espera el regulador y el auditor frente a lo que entrega un escáner

Qué debe haber en el informe	Informe de escáner	Pentest manual bien hecho
Independencia de quien desarrolla y opera	A menudo lo genera el propio equipo	Equipo externo, con declaración de independencia
Evidencia de explotación	Lista de posibles vulnerabilidades	Request/response, pasos reproducibles e impacto demostrado
Fallos de lógica de negocio y autorización	No los detecta	Foco central del test
Encadenamiento de fallos	Cada ítem aislado	Escenario de ataque desde el acceso inicial hasta el impacto
Plan de tratamiento	Sugerencia genérica	Responsable y plazo por hallazgo, listo para la dirección
Retest	Un nuevo escaneo	Estado por hallazgo: corregido, parcial, pendiente, riesgo aceptado
Trazabilidad	Un PDF suelto	Alcance, metodología y evidencias archivados

La diferencia entre las dos columnas se explica en detalle en escáner, pentest o bug bounty.

Qué debe mostrar el informe (en la práctica)

Para resistir una auditoría interna, externa o una solicitud del supervisor, el informe debe responder tres preguntas: qué se probó, qué se encontró y qué se hizo al respecto. Recomendamos, y entregamos por defecto:

1. Alcance y reglas de compromiso que coincidan con el inventario de activos y el diagrama de arquitectura.
2. Metodología nombrada (OWASP WSTG, PTES, NIST SP 800-115).
3. Evidencia de explotación por hallazgo, con el impacto de negocio descrito.
4. Mapeo regulatorio, una tabla que vincula cada resultado con los controles de las resoluciones (autenticación, segregación, gestión de vulnerabilidades, protección de claves).
5. Plan de tratamiento con responsable y plazo, listo para la alta dirección.
6. Retest documentado, con fecha y estado por hallazgo.
7. Atestado que identifique al equipo independiente y el período del test.

Muchas instituciones reutilizan el mismo paquete para PCI DSS. Mira qué espera el auditor de tarjetas en Pentest para PCI DSS 4.0.

Cronograma sugerido: del kickoff al archivo

Un ciclo completo cabe en unas ocho a doce semanas, según el alcance. Úsalo como punto de partida:

• Semana 0 a 1: preparación. Actualiza el inventario de activos, define responsables, separa cuentas de prueba (usuario común, comercio, administrador) y confirma qué es de terceros.
• Semana 1 a 2: autorizaciones. Formaliza el alcance, las reglas de compromiso y las autorizaciones de proveedores de nube y de terceros cuyos sistemas se tocarán.
• Semana 2 a 5: ejecución. Test manual, con un canal directo para hallazgos críticos, que no deben esperar al informe final.
• Semana 5 a 6: informe. Entrega con evidencias, mapeo y plan de tratamiento; reunión de presentación con tecnología y riesgo.
• Semana 6 a 10: corrección. Los equipos tratan los hallazgos por prioridad.
• Semana 10 a 12: retest y cierre. Retest por hallazgo, atestado final y archivo de todo el material.
• Después: gobernanza. Lleva el resultado a la dirección, registra las decisiones de riesgo aceptado y guarda el dossier en un lugar recuperable.

Motivos comunes de rechazo

• Presentar un escaneo de vulnerabilidades como pentest.
• Contratar al mismo equipo que desarrolló u opera el sistema, lo que compromete la independencia.
• Probar solo el sitio institucional y dejar fuera APIs, app móvil y back office.
• Un alcance que no coincide con el inventario de activos.
• Informe sin plan de tratamiento ni responsables.
• Hallazgos críticos sin retest, o "corregidos" solo con una regla de WAF.
• No archivar informe, plan de acción y evidencias de retest de forma recuperable.
• Hacer el test una vez y olvidarlo: el ciclo es anual.

Cómo elegir quién lo ejecuta

Pide a la propuesta respuestas objetivas. El checklist para contratar un pentest trae diez preguntas; las que más pesan para una institución regulada son:

• ¿El equipo es independiente de quien desarrolla y opera tus sistemas?
• ¿El test es manual? Pide un informe de ejemplo anonimizado y verifica que haya evidencia de explotación.
• ¿El informe incluye mapeo a las resoluciones del Banco Central y plan de tratamiento?
• ¿El retest está incluido? ¿Cuántas rondas y en qué ventana de tiempo?
• ¿Quien ejecuta tiene experiencia con APIs financieras, apps móviles y nube?
• ¿Cómo protege el proveedor los datos y las evidencias que recoge durante el test?
• ¿Cómo se tratarán los hallazgos críticos durante la ejecución?

En cuanto al precio, varía con el número de aplicaciones, APIs y el modelo de test (caja negra, gris o blanca). Los rangos reales están en Cuánto cuesta un pentest en 2026. Para entender los modelos, lee Qué es un pentest.

Cómo ayuda Pentest Machine

Hacemos pentest manual con un informe pensado para la auditoría: evidencia de explotación por hallazgo, mapeo a las resoluciones del Banco Central, plan de tratamiento y retest incluido. Si necesitas cerrar el ciclo de 2026 o planificar el de 2027, pide una propuesta: respondemos con alcance y plazo en hasta un día hábil.

Preguntas frecuentes

¿El pentest es obligatorio para una fintech pequeña?

Las normas valen para las instituciones autorizadas por el Banco Central dentro del alcance de las resoluciones, sin importar el tamaño. Lo que cambia con el tamaño es el alcance y la profundidad. Confirma el encuadre con compliance o legal.

¿Basta con un escaneo de vulnerabilidades?

No. Las normas hablan de test de intrusión y exigen independencia y documentación formal. La lectura del mercado es que el supervisor distingue un informe de escáner de uno con explotación manual documentada.

¿Quién puede ser el equipo independiente?

Empresas o profesionales sin conflicto de intereses con el desarrollo y la operación del sistema probado. Un equipo interno que también construye el sistema tiende a no cumplir el requisito. Mantén el registro de quién ejecutó el test y qué vínculo tiene con el entorno.

¿Cuánto tiempo debo guardar el informe?

Los análisis del sector indican cinco años para la documentación y los planes de acción. Valida el plazo exacto con legal y regístralo en la política interna de retención.

¿El test debe cubrir Pix?

Si la institución opera o se conecta a Pix, STR o RSFN, esos servicios son tratados como críticos por las normas y deben estar en el alcance, o el alcance debe justificar por qué no lo están.

¿Puedo hacer el pentest una vez y usar el informe por dos años?

No. La periodicidad es como mínimo anual, y los cambios relevantes del entorno justifican un test complementario. Planifica el ciclo de 2027 desde ahora para no repetir la carrera de 2026.

¿El retest cuenta como otro pentest?

No. El retest verifica si cada hallazgo fue corregido y cierra el ciclo de tratamiento. Complementa el pentest anual, pero no lo sustituye.

¿Puedo probar sistemas de proveedores?

Solo con autorización contractual y del proveedor. Acuerda el alcance y las reglas por escrito antes de probar cualquier activo que no sea tuyo, y regístralo en el informe.