Pruebas de DORA para las apps que usan sus clientes.

1. 01

   DORA, artículo 8

   Sepa qué apps y componentes sustentan funciones críticas

   Qué dice el texto

   Identifique, clasifique y documente todas las funciones empresariales respaldadas por las TIC y los activos de información y de TIC que las sustentan, incluidas sus dependencias y los procesos que dependen de proveedores terceros de servicios TIC. Revise la clasificación al menos una vez al año y evalúe de forma continua las ciberamenazas y las vulnerabilidades de TIC.

   Fuente:DORA, artículo 8

   Qué supone para su app móvil

   Una app de banca móvil que los clientes usan para iniciar sesión, pagar y gestionar sus cuentas suele sustentar una función esencial o importante, al igual que las API a las que llama y los SDK que integra. Esa clasificación determina con qué frecuencia y profundidad debe realizar las pruebas.

   Cómo ayuda Ostorlab

   Ostorlab muestra qué contiene cada versión de su app: los SDK de terceros y las bibliotecas nativas, con sus versiones y su ubicación en el paquete de la app; qué intercambian la app y sus SDK con los backends a través de la red, y qué datos personales recopila y comparte la app.

   Qué sigue en sus manos

   La clasificación de las funciones empresariales, el propio inventario y su revisión anual.

2. 02

   Reglamento Delegado (UE) 2024/1774, artículo 10

   Explore automáticamente los activos críticos, al menos cada semana

   Qué dice el texto

   Los procedimientos de gestión de vulnerabilidades deben incluir exploraciones y evaluaciones automatizadas de vulnerabilidades, al menos semanalmente en el caso de los activos de TIC que sustentan funciones esenciales o importantes. También debe hacer un seguimiento de las bibliotecas de terceros y de código abierto, priorizar los parches según su criticidad, verificar la corrección y registrar cada vulnerabilidad detectada hasta que se resuelva.

   Fuente:Reglamento Delegado (UE) 2024/1774, artículo 10

   Qué supone para su app móvil

   Su app móvil y sus API necesitan una periodicidad de exploración automatizada que se mantenga incluso en las semanas sin nueva versión, y un registro de cada hallazgo desde su detección hasta su corrección.

   Cómo ayuda Ostorlab

   Ejecute escaneos automatizados desde su pipeline de CI/CD en cada compilación y supervise las versiones publicadas en las tiendas sin activación manual. Las ejecuciones programadas de su pipeline mantienen una periodicidad semanal entre versiones. Los hallazgos se califican como críticos, altos, medios o bajos, se registran como tickets en la plataforma o en Jira y ServiceNow, y se vuelven a probar una vez publicada la corrección.

   Qué sigue en sus manos

   Los plazos de aplicación de parches y los procedimientos de escalado, y la exploración del resto de sus activos de TIC.

3. 03

   Reglamento Delegado (UE) 2024/1774, artículo 16

   Pruebe el código de forma estática y dinámica antes de producción

   Qué dice el texto

   Pruebe y apruebe cada sistema de TIC antes de su uso y después de su mantenimiento, en proporción a su criticidad. Las pruebas incluyen revisiones del código fuente que abarcan pruebas tanto estáticas como dinámicas, pruebas de seguridad de los sistemas y aplicaciones expuestos a internet, y un plan de acción para las vulnerabilidades detectadas. El código de terceros y de código abierto se analiza y se prueba, cuando sea factible, antes de su despliegue en producción.

   Fuente:Reglamento Delegado (UE) 2024/1774, artículo 16

   Qué supone para su app móvil

   Una app de banca móvil es una aplicación expuesta a internet. Cada versión debería superar pruebas de seguridad estáticas y dinámicas antes de llegar a la tienda, y los SDK que integra son código de terceros sujeto a la misma norma.

   Cómo ayuda Ostorlab

   Mobile SAST analiza directamente el APK, AAB o IPA, sin necesidad de código fuente, incluido el análisis de propagación (taint) en los SDK integrados. Mobile DAST ejecuta la app, mantiene las sesiones autenticadas y captura el tráfico, las trazas de pila y capturas de pantalla. SCA identifica mediante huellas las bibliotecas compiladas estáticamente que los escáneres basados en manifiestos pueden pasar por alto.

   Qué sigue en sus manos

   Las revisiones del código fuente ajeno a la app, el paso de aprobación de la versión y la titularidad del plan de acción.

4. 04

   DORA, artículo 9, apartado 4, letra d); Reglamento Delegado (UE) 2024/1774, artículo 21

   Autenticación fuerte, probada como cualquier otro control

   Qué dice el texto

   Aplique políticas y protocolos para mecanismos de autenticación fuerte basados en normas pertinentes. El RTS exige métodos de autenticación acordes con la clasificación y el perfil de riesgo de cada activo de TIC, y autenticación fuerte para el acceso a los activos que sustentan funciones esenciales o importantes o que son accesibles al público.

   Fuente:DORA, artículo 9, apartado 4, letra d); Reglamento Delegado (UE) 2024/1774, artículo 21

   Qué supone para su app móvil

   El inicio de sesión, los códigos de un solo uso y las verificaciones reforzadas son controles de autenticación, y un fallo en cómo los aplica el backend es un fallo de esos controles. Forman parte del alcance de su programa de pruebas.

   Cómo ayuda Ostorlab

   Ostorlab inicia sesión con sus cuentas de prueba, completa los códigos de un solo uso por SMS, correo electrónico o TOTP, y prueba el inicio y el cierre de sesión, la renovación de tokens, los tiempos de espera, la invalidación de sesiones y la aplicación de la MFA, incluidos los flujos de autenticación reforzada.

   Qué sigue en sus manos

   El acceso del personal y el acceso privilegiado, la gestión del ciclo de vida de las identidades y la elección de las normas de autenticación.

5. 05

   DORA, artículos 24 y 25

   Lleve a cabo un programa de pruebas basado en el riesgo, con pruebas anuales

   Qué dice el texto

   Establezca, mantenga y revise un programa de pruebas de resiliencia operativa digital como parte de su marco de gestión del riesgo relacionado con las TIC. El programa prevé las pruebas adecuadas, como evaluaciones y exploraciones de vulnerabilidad, análisis de fuentes abiertas, revisiones del código fuente cuando sea factible, pruebas basadas en escenarios, pruebas de extremo a extremo y pruebas de penetración, con pruebas al menos una vez al año de todos los sistemas y aplicaciones de TIC que sustentan funciones esenciales o importantes.

   Fuente:DORA, artículos 24 y 25

   Qué supone para su app móvil

   Su app móvil necesita un lugar definido en el programa: qué pruebas se ejecutan, con qué frecuencia y sobre qué compilación. Un pentest anual por sí solo deja sin probar todas las versiones intermedias.

   Cómo ayuda Ostorlab

   Los escaneos rápidos suelen terminar en 1 a 5 minutos y los completos en 15 a 45 minutos, por lo que encajan en cada versión. Un pentest con agentes de IA profundiza más, normalmente en unas horas, con un exploit funcional que puede reproducir para cada hallazgo de un agente de IA, para los cambios críticos y sus pruebas en profundidad periódicas.

   Qué sigue en sus manos

   El documento del programa, su diseño basado en el riesgo y las pruebas ajenas a la capa de aplicación, como las pruebas de red, de seguridad física y de rendimiento.

6. 06

   DORA, artículo 24, apartados 4 y 5

   Recurra a probadores independientes y demuestre cada corrección

   Qué dice el texto

   Las pruebas deben realizarlas partes independientes, internas o externas, con recursos suficientes y sin conflictos de intereses. Debe priorizar, clasificar y corregir todos los problemas que revelen las pruebas, y disponer de métodos de validación internos para confirmar que cada debilidad se ha tratado de manera exhaustiva.

   Fuente:DORA, artículo 24, apartados 4 y 5

   Qué supone para su app móvil

   El equipo que desarrolla la app no debería ser el único que la prueba, y un ticket cerrado no es una prueba: necesita evidencia de que la corrección funciona.

   Cómo ayuda Ostorlab

   Su equipo de seguridad o de segunda línea ejecuta las pruebas y es el titular de los resultados. Cada hallazgo incluye una calificación de riesgo, los pasos de reproducción, los registros de solicitudes y respuestas y capturas de pantalla, y una nueva prueba confirma si el problema de fondo está resuelto.

   Qué sigue en sus manos

   Decidir quién se considera independiente en su organización, y la aprobación de la validación.

7. 07

   DORA, artículos 26 y 27; Reglamento Delegado (UE) 2025/1190

   TLPT al menos cada 3 años, si su entidad ha sido identificada

   Qué dice el texto

   Las entidades identificadas por su autoridad competente deben realizar pruebas de penetración basadas en amenazas al menos cada 3 años, sobre los sistemas de producción activos que sustenten funciones esenciales o importantes. Los probadores deben cumplir los requisitos del artículo 27, y las entidades de crédito significativas deben recurrir a probadores externos. Tras la prueba, los planes de corrección y la documentación se remiten a la autoridad de TLPT.

   Fuente:DORA, artículos 26 y 27; Reglamento Delegado (UE) 2025/1190

   Qué supone para su app móvil

   Una TLPT es un ejercicio de equipo rojo guiado por inteligencia que se prolonga durante varios meses (consulte las fases más abajo). Las debilidades de la app y de las API que unas pruebas periódicas podrían haber detectado consumen tiempo del equipo rojo y acaban en el plan de corrección.

   Cómo ayuda Ostorlab

   Ostorlab no realiza la TLPT ni la sustituye. Le ayuda a afrontar una TLPT con los problemas conocidos de la app y de las API ya corregidos, y a volver a probar después los elementos de la app y de las API de su plan de corrección.

   Qué sigue en sus manos

   La propia TLPT: el equipo de control, el proveedor de inteligencia sobre amenazas, los probadores del equipo rojo y el diálogo con la autoridad de TLPT.

8. 08

   DORA, artículos 28 a 30

   Gestione a sus proveedores de pruebas como proveedores terceros de servicios TIC

   Qué dice el texto

   Las entidades financieras siguen siendo plenamente responsables del cumplimiento cuando recurren a proveedores terceros de servicios TIC, y mantienen un registro de información sobre esos acuerdos. Los contratos deben abarcar la protección de datos y, en el caso de los servicios que sustentan funciones esenciales o importantes, derechos ilimitados de acceso, inspección y auditoría, así como la participación del proveedor en las TLPT.

   Fuente:DORA, artículos 28 a 30

   Qué supone para su app móvil

   Una plataforma de pruebas SaaS que recibe los binarios de su app y credenciales de prueba es un proveedor que revisará su proceso de gestión del riesgo de terceros.

   Cómo ayuda Ostorlab

   Ostorlab cuenta con una auditoría SOC 2 Tipo II. Con el plan Enterprise puede elegir la residencia de datos en la UE o ejecutar los escaneos on-premises, y con BYOK la IA se ejecuta en la cuenta de su propio proveedor con un límite de gasto por escaneo. SSO/SAML, el control de acceso basado en roles y los registros de auditoría están disponibles como complemento y se incluyen en Enterprise.

   Qué sigue en sus manos

   Su diligencia debida, las cláusulas contractuales y el registro de información.

Resumen del Reglamento (UE) 2022/2554 y de los Reglamentos Delegados (UE) 2024/1774 y 2025/1190. Las microempresas y las entidades sujetas al marco simplificado tienen obligaciones menos exigentes. Esta página no constituye asesoramiento jurídico.