Pruebas de penetración fintech: ¿requisitos de DORA, TLPT o PCI DSS?

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

Defina la persona jurídica, la actividad regulada y el entorno de datos de tarjetas de pago antes de elegir las denominaciones de evaluación. La aplicabilidad de DORA y la selección para TLPT son cuestiones distintas. Mantenga explícitos los objetivos de seguridad del producto, incluso cuando el pentest se haya iniciado por un requisito de cumplimiento.

Identificar la actividad regulada

La denominación fintech puede referirse a una entidad de pago regulada, a un proveedor de software o a varias entidades distintas dentro de un grupo. Determine qué entidad presta el servicio y qué obligaciones le corresponden. La aplicabilidad de DORA y la selección para un TLPT son cuestiones relacionadas, pero distintas.

Delimitar por separado el alcance de las tarjetas de pago

PCI DSS se refiere a los datos de tarjetas de pago y a los sistemas incluidos en su ámbito definido. Una aplicación financiera no equivale automáticamente a un entorno de datos de titulares de tarjetas. Colabore con el equipo de cumplimiento o el evaluador responsable para determinar los límites pertinentes y las expectativas de evidencias antes de definir la prueba.

Mantener visibles los riesgos del producto

El aislamiento entre tenants, la autoridad de los tokens de servicio y la gestión del estado de las transacciones pueden ser relevantes aunque no sea aplicable un marco regulatorio concreto. Describa explícitamente estos objetivos de negocio. Una prueba diseñada únicamente en torno a la denominación de un marco puede omitir el comportamiento del producto más importante para los clientes.

Evite exagerar el alcance del resultado

Una evaluación técnica documenta los hallazgos observados y sus limitaciones. No concede un cumplimiento universal de DORA, PCI o RGPD. Alinee el informe con las evidencias solicitadas, reserve las conclusiones regulatorias para el proceso adecuado y planifique nuevas pruebas de los controles que modifique el equipo de ingeniería.

Distinguir la entidad de la arquitectura del producto

Un producto fintech puede implicar varias entidades jurídicas, actividades reguladas y proveedores de servicios. Identifique qué entidad opera el servicio pertinente y quién es responsable de las obligaciones aplicables. A continuación, asocie los sistemas que respaldan esa actividad. No deduzca una clasificación jurídica del uso de API de pago, de una asociación bancaria o de una categoría de marketing. El equipo técnico puede aportar pruebas sobre la arquitectura y los flujos de datos, mientras que las funciones jurídicas y de cumplimiento responsables determinan la aplicabilidad.

Una nota de definición del alcance debe dejar constancia de quién toma la decisión y de las preguntas pendientes. Así se evita que la propuesta de un proveedor se convierta de forma implícita en la interpretación jurídica de la organización por el mero hecho de incluir los acrónimos regulatorios adecuados.

Ajustar las afirmaciones de aseguramiento a la cobertura

Para una evaluación técnica con alcance definido, indique las aplicaciones, identidades, entornos y métodos que se hayan incluido realmente. Explique si los sistemas con datos de titulares de tarjetas, los servicios de soporte o los límites con terceros forman parte del trabajo acordado. Una evaluación de API satisfactoria no acredita por sí sola el cumplimiento de PCI DSS. Del mismo modo, un informe que menciona DORA no demuestra que se haya completado un ejercicio avanzado de pruebas basado en amenazas cuando este sea obligatorio. Relacione cada entregable solicitado con el uso previsto, en lugar de emitir una única declaración general de aseguramiento.

La guía sobre pruebas de penetración bancaria frente al TLPT de DORA explica la diferencia entre las pruebas técnicas rutinarias y un ejercicio avanzado sujeto a la supervisión de una autoridad. Para conocer el modelo de ejecución del TLPT, consulte la guía sobre TIBER-EU y DORA.

Utilice un alcance coherente con un propósito explícito

Los equipos suelen poder reutilizar la preparación de la arquitectura, las responsabilidades y las evidencias en distintos ámbitos de aseguramiento. Esa reutilización no debe borrar las diferencias entre objetivos, métodos o criterios de aceptación. Elabore una matriz que vincule cada decisión empresarial o requisito con la actividad de prueba pertinente, las evidencias y la persona responsable. Indique dónde sigue siendo necesaria otra evaluación o una revisión especializada. Así se agiliza la contratación sin afirmar que una misma prueba satisface todas las obligaciones.

Al cerrar el trabajo, conserve la versión probada, las limitaciones del alcance y las decisiones pendientes. Si el producto traslada el tratamiento de datos sensibles a otro proveedor o añade una nueva identidad de servicio, revise el límite pertinente en lugar de dar por hecho que un informe anterior cubre automáticamente el cambio. El resultado útil es una declaración clara y justificable sobre lo que se probó y lo que la organización aún debe establecer.

Ponga en práctica las directrices

Utilice la lista de preparación para documentar las premisas o consulte el informe ficticio de Fintech AG para ver ejemplos de evidencias y planes de tratamiento. Póngase en contacto con Atlant Security con una descripción no sensible del alcance.