Alcance de las pruebas de penetración bancaria: obtenga ofertas realmente comparables

La decisión que le ayudará a tomar esta guía

Un presupuesto para una prueba de penetración bancaria solo es significativo si se han definido el objetivo y el alcance. Especifique los canales de clientes, las operaciones de pago o las rutas de confianza internas que deben evaluarse, los accesos facilitados y las evidencias que aceptará. Diferencie las pruebas de penetración rutinarias de cualquier requisito formal de TLPT conforme a DORA.

Indique el objetivo del encargo

Defina la decisión que debe tomar el banco: poner en producción una aplicación, evaluar un límite de confianza definido, investigar una exposición conocida o validar una corrección. Identifique al responsable del servicio y al público destinatario del informe. No utilice «pentest completo» como sustituto del alcance. Los proveedores pueden interpretar esa expresión de formas muy distintas: desde un análisis limitado sin autenticación hasta una evaluación amplia con acceso privilegiado y pruebas de lógica de negocio.

Distinga las pruebas de penetración habituales de cualquier ejercicio avanzado basado en amenazas. Si se requiere TLPT, utilice el proceso de gobernanza y contratación aplicable. La guía sobre los requisitos del artículo 27 de DORA para proveedores explica aspectos que no deben reducirse a un cuestionario genérico para proveedores.

Describa los sistemas mediante operaciones y roles

Facilite un inventario de las aplicaciones, API, límites de identidad, entornos e integraciones pertinentes. Añada las operaciones y los roles relevantes: cliente, soporte, persona aprobadora, administrador e identidad de carga de trabajo, cuando corresponda. Explique qué cuentas y objetos sintéticos puede proporcionar el banco. Un recuento de puntos de acceso sin este contexto ofrece una base deficiente para estimar la cobertura de la lógica de negocio.

Señale los componentes de terceros, los entornos compartidos y los permisos aún sin resolver. Pida a los licitadores que indiquen cómo afecta cada supuesto a la cobertura y a la ejecución. Mantenga los detalles confidenciales de la arquitectura en el canal de contratación confidencial acordado, en lugar de incluirlos en un formulario público de consulta.

Hacer visibles las limitaciones operativas

Indique los entornos aprobados, las ventanas de ejecución, los límites de solicitudes y los métodos prohibidos. Identifique los servicios en los que incluso un efecto secundario menor requiera una decisión aparte. Describa quién tiene autoridad para detener las pruebas, el modelo de comunicación y los procedimientos de escalado de incidentes. Si se proponen pruebas en producción, exija una justificación basada en riesgos de las evidencias necesarias allí y de las salvaguardas que las respaldan.

Para los productos con un uso intensivo de API, nuestra guía para definir el alcance de las pruebas de penetración de API fintech ayuda a convertir un inventario de funcionalidades en comparaciones verificables entre actor, objeto y operación. Los bancos pueden aplicar este enfoque junto con sus propios controles de gestión de cambios y proveedores.

Especifique qué debe incluir un hallazgo útil

Solicite información sobre la situación inicial sometida a prueba, el límite afectado, la observación reproducible, las pruebas técnicas, el razonamiento sobre el impacto y las limitaciones. Exija una distinción clara entre las acciones demostradas y las consecuencias plausibles pero no comprobadas. El informe debe registrar tanto la cobertura bloqueada o excluida como los hallazgos. Acuerde cómo se comunicarán las observaciones urgentes antes de entregar el documento final.

Revise un hallazgo de ejemplo con responsables técnicos y de riesgos. Debe poder entenderse qué ha fallado, qué equipo puede corregirlo y cómo verificará el banco el resultado. El diseño visual debe apoyar ese razonamiento, no sustituirlo.

Definir las pruebas de repetición antes de comparar precios

Identificar el periodo de repetición de pruebas incluido, los límites de los escenarios y las evidencias necesarias para cerrar los hallazgos. Acordar qué ocurre si la corrección modifica la arquitectura, aparecen nuevas vías de acceso o deja de estar disponible el rol de prueba necesario. Aclarar si el proveedor validará únicamente los hallazgos especificados o también los casos relacionados que se acuerden. Así se evita que una verificación presupuestada de forma limitada se interprete como una repetición implícita de todo el encargo.

Defina un criterio de aceptación para la propia prestación: el banco recibe evidencias útiles, un registro de cobertura, una transferencia técnica y una explicación clara de las pruebas de repetición. Recibir un archivo PDF a tiempo es solo una parte del resultado.

Normalice las ofertas antes de seleccionarlas

Prepare una tabla comparativa que abarque el alcance, los supuestos, los roles de ejecución, las salvaguardas operativas, las evidencias, las exclusiones y el cierre. Pida a los proveedores que aclaren por escrito cualquier ambigüedad sustancial. Un precio más bajo puede reflejar una ejecución eficiente, pero también puede deberse a que no incluye roles, integraciones o trabajos de validación que sí contempla otra oferta. Compare expresamente esas diferencias en lugar de basarse en las tarifas diarias o en el número de hallazgos.

Utilice la lista de preparación para pruebas de penetración en bancos para preparar la información necesaria. La declaración final del trabajo debe ser comprensible para la persona responsable del servicio, el equipo de pruebas y quien revise la contratación, sin que cada cual tenga que inventar las premisas que faltan.