Resiliencia operativa PRA y FCA: evalúe su app de banca móvil antes y después de cada versión.

1. 01

   Manual de la FCA, SYSC 15A.2; PRA SS1/21, marzo de 2022

   Identificar los servicios de negocio importantes y fijar tolerancias de impacto

   Qué dice el texto

   Según SYSC 15A de la FCA y las partes de resiliencia operativa de la PRA, una entidad debe identificar sus servicios de negocio importantes y fijar para cada uno una tolerancia de impacto, la perturbación máxima tolerable. Debe poder mantenerse dentro de cada tolerancia de impacto ante una perturbación grave pero plausible, y revisar sus evaluaciones al menos una vez al año o tras un cambio importante. SS1/21 de la PRA recoge las expectativas que sustentan las normas.

   Fuente:Manual de la FCA, SYSC 15A.2; PRA SS1/21, marzo de 2022

   Qué supone para su app móvil

   La banca móvil es casi siempre un servicio de negocio importante, y la app es la principal vía de acceso de los clientes. Si la app o sus API fallan o se ven comprometidas, la entidad debe poder mantenerse dentro de la tolerancia fijada.

   Cómo ayuda Ostorlab

   Ostorlab prueba la app y sus API en cada versión, para que las debilidades que podrían perturbar el servicio se detecten antes de que las vean los clientes. Los hallazgos se puntúan y se siguen hasta su cierre.

   Qué sigue en sus manos

   Identificar los servicios y fijar las tolerancias, y los dispositivos de respuesta y recuperación que las sustentan.

2. 02

   Manual de la FCA, SYSC 15A.4.1; PRA SS1/21, 4.2 y 4.15

   Mapear los recursos y corregir las vulnerabilidades a tiempo

   Qué dice el texto

   Las entidades deben identificar y documentar las personas, procesos, tecnología, instalaciones e información necesarios para prestar cada servicio de negocio importante, con el detalle suficiente para identificar vulnerabilidades y remediarlas. La PRA espera que la velocidad de corrección sea proporcional al impacto potencial de una perturbación, y que las entidades elaboren y apliquen planes de remediación cuando un servicio no pudiera mantenerse dentro de su tolerancia de impacto.

   Fuente:Manual de la FCA, SYSC 15A.4.1; PRA SS1/21, 4.2 y 4.15

   Qué supone para su app móvil

   El binario de la app, sus SDK y las API que la sustentan son recursos tecnológicos de ese mapa. Una vulnerabilidad en cualquiera de ellos es una vulnerabilidad del servicio.

   Cómo ayuda Ostorlab

   El SAST móvil analiza el binario, incluidos los SDK integrados, el SCA asocia componentes a vulnerabilidades conocidas y el pentest con agentes de IA prueba la app en ejecución y sus API. Los hallazgos se convierten en tickets en la plataforma o en Jira y ServiceNow, y se vuelven a probar tras la corrección.

   Qué sigue en sus manos

   Fijar los plazos de corrección, asignar recursos para los arreglos y seguirlos hasta su cierre.

3. 03

   Manual de la FCA, SYSC 15A.5 y 15A.6; PRA SS1/21, capítulo 6

   Realizar pruebas de escenarios y aprender de ellas

   Qué dice el texto

   Las entidades deben elaborar y mantener actualizado un plan de pruebas y realizar pruebas de escenarios de perturbaciones graves pero plausibles, incluida la indisponibilidad de servicios de terceros, la pérdida o reducción de la prestación de tecnología, y la corrupción o el borrado de datos críticos. Las pruebas pueden ser sobre papel, simulaciones o sistemas en producción, pero no deben plantear un riesgo material de crear una perturbación. Tras una prueba o una perturbación, las entidades deben realizar un ejercicio de lecciones aprendidas y aplicar las mejoras identificadas. Los registros se conservan al menos seis años.

   Fuente:Manual de la FCA, SYSC 15A.5 y 15A.6; PRA SS1/21, capítulo 6

   Qué supone para su app móvil

   Las pruebas de escenarios ejercitan todo el servicio, no solo la app. Los hallazgos de app y API de esas pruebas solo sirven si las debilidades subyacentes se corrigen y se puede demostrar que se han corregido.

   Cómo ayuda Ostorlab

   Ostorlab no realiza pruebas de escenarios ni ejercicios. Prueba los controles de la app y las API de los que dependen sus escenarios, antes y después del ejercicio, para que los elementos técnicos de sus lecciones aprendidas tengan evidencia.

   Qué sigue en sus manos

   Diseñar y ejecutar los escenarios, los planes de continuidad y recuperación, y los ejercicios de lecciones aprendidas.

4. 04

   CBEST Implementation Guide, edición 2024, Banco de Inglaterra

   Prepararse para las evaluaciones CBEST dirigidas por inteligencia de amenazas

   Qué dice el texto

   CBEST es el marco de evaluación dirigido por inteligencia de amenazas de los reguladores, utilizado desde 2014 para las entidades e infraestructuras de mercado financiero que seleccionan la PRA, el Banco de Inglaterra y la FCA. Un CBEST imita las acciones de atacantes reales contra los sistemas y servicios que sustentan los servicios de negocio importantes, se desarrolla en cuatro fases, desde el inicio hasta un plan de remediación supervisado por el regulador, y lo ejecutan proveedores de inteligencia de amenazas y pruebas de penetración acreditados por CREST. La edición de 2024 de la CBEST Implementation Guide añade orientaciones sobre la documentación de la remediación y sobre los terceros de los servicios de negocio importantes.

   Fuente:CBEST Implementation Guide, edición 2024, Banco de Inglaterra

   Qué supone para su app móvil

   CBEST está dirigido por el regulador y se delimita en torno a sus servicios de negocio importantes. No sustituye a las pruebas periódicas de su app y sus API entre evaluaciones.

   Cómo ayuda Ostorlab

   Ostorlab no ejecuta CBEST. Le ayuda a afrontar un CBEST con los problemas conocidos de la app y las API ya corregidos, y vuelve a probar después los elementos de app y API de su plan de remediación.

   Qué sigue en sus manos

   Delimitar y ejecutar el CBEST, elegir proveedores acreditados y el plan de remediación que supervisa el regulador.

5. 05

   PRA SS2/21, versión de noviembre de 2024, capítulos 7 y 8

   Gestionar la externalización y el riesgo de terceros

   Qué dice el texto

   Según SS2/21 de la PRA, las entidades siguen siendo responsables de los servicios externalizados, incluida la externalización material. La PRA espera controles sólidos para los datos en tránsito, en memoria y en reposo, incluidos el cifrado y la gestión de claves, la gestión de identidades y accesos, el registro de accesos y actividad, y la detección y respuesta ante incidentes. Para la externalización material, los acuerdos escritos deben otorgar derechos de acceso y auditoría que cubran los resultados de las pruebas de penetración de seguridad realizadas sobre las aplicaciones, datos y sistemas del proveedor. El texto también cubre la continuidad y los planes de salida.

   Fuente:PRA SS2/21, versión de noviembre de 2024, capítulos 7 y 8

   Qué supone para su app móvil

   Su app integra SDK de terceros que hablan con sus propios backends, y sus API pueden ejecutarse en servicios en la nube. Su seguridad forma parte de su visión de externalización y riesgo de terceros.

   Cómo ayuda Ostorlab

   Ostorlab enumera los SDK y bibliotecas nativas de cada versión con sus versiones, los asocia a vulnerabilidades conocidas y muestra qué intercambian la app y sus SDK con los backends por la red.

   Qué sigue en sus manos

   La diligencia debida, los contratos, los derechos de auditoría, los planes de salida y la configuración de la nube.

6. 06

   FCA, Critical Third Parties: Strengthening UK Financial Services; PRA PS16/24 y FCA PS24/16

   Conocer a los terceros críticos detrás de sus servicios

   Qué dice el texto

   El régimen de terceros críticos, en vigor desde el 1 de enero de 2025, permite al Tesoro británico designar a terceros cuyo fallo o perturbación podría amenazar la estabilidad del sistema financiero británico o la confianza en él, y a los reguladores supervisar los servicios que prestan. Las primeras designaciones, que abarcan a cuatro proveedores globales de nube y tecnología, entraron en vigor el 13 de julio de 2026. El régimen complementa, en lugar de sustituir, las responsabilidades de las propias entidades: las entidades y sus consejos siguen siendo responsables de gestionar el riesgo de terceros y de mantener la resiliencia operativa.

   Fuente:FCA, Critical Third Parties: Strengthening UK Financial Services; PRA PS16/24 y FCA PS24/16

   Qué supone para su app móvil

   Si su app o su backend se ejecutan en un proveedor designado, el riesgo sigue siendo suyo. El régimen da a los reguladores otra palanca; no transfiere sus obligaciones.

   Cómo ayuda Ostorlab

   Ostorlab prueba los controles de su app y sus API allí donde se ejecuten, para que la evidencia que conserva no dependa de las garantías del proveedor.

   Qué sigue en sus manos

   Los acuerdos contractuales con los proveedores, y sus propias obligaciones de externalización y resiliencia.

7. 07

   Payment Services Regulations 2017, artículo 100; FCA, Strong Customer Authentication

   Aplicar la autenticación reforzada del cliente a la app y sus pagos

   Qué dice el texto

   Según el artículo 100 de las Payment Services Regulations 2017, un proveedor de servicios de pago debe aplicar la autenticación reforzada del cliente cuando el cliente accede online a su cuenta de pago, inicia una operación de pago electrónico o realiza cualquier acción por un canal remoto que pueda implicar un riesgo de fraude en el pago u otros abusos. Los pagos remotos deben usar una autenticación que vincule dinámicamente la operación a un importe y un beneficiario concretos. Los proveedores también deben mantener medidas de seguridad adecuadas para proteger la confidencialidad e integridad de las credenciales de seguridad personalizadas. La FCA espera soluciones de autenticación que funcionen para todos los grupos de consumidores, incluidos los clientes que no usan teléfono móvil.

   Fuente:Payment Services Regulations 2017, artículo 100; FCA, Strong Customer Authentication

   Qué supone para su app móvil

   El inicio de sesión, los pagos y los cambios sensibles de cuenta en la app entran dentro de SCA. Los controles deben aplicarlos el backend, no solo presentarlos la app.

   Cómo ayuda Ostorlab

   Ostorlab completa códigos de un solo uso por SMS, correo o TOTP con sus cuentas de prueba y prueba la aplicación de SCA, la vinculación dinámica y los flujos de autenticación escalonada, incluido cómo intentan manipularlos los atacantes, junto con las llamadas de API que hay detrás.

   Qué sigue en sus manos

   Elegir los métodos de autenticación y las exenciones, la monitorización de transacciones y la accesibilidad de los métodos que ofrece.

8. 08

   Payment Services Regulations 2017, artículos 98 y 99; FCA PS26/2, 18 de marzo de 2026

   Gestionar los riesgos operativos y de seguridad, y notificar incidentes

   Qué dice el texto

   El artículo 98 de las Payment Services Regulations 2017 exige a cada proveedor de servicios de pago mantener un marco con medidas de mitigación y controles adecuados para los riesgos operativos y de seguridad de sus servicios de pago, incluida una gestión eficaz de incidentes y la detección y clasificación de incidentes operativos y de seguridad graves, con una evaluación actualizada remitida a la FCA al menos una vez al año. El artículo 99 exige notificar a la FCA sin demora indebida cualquier incidente operativo o de seguridad grave, e informar a los usuarios de servicios de pago cuando se vean afectados sus intereses financieros. A partir del 18 de marzo de 2027, las normas PS26/2 de la FCA crean un régimen único de la FCA, la PRA y el Banco de Inglaterra para la notificación de incidentes operativos, con una definición única de incidente operativo, umbrales de notificación e informes estándar o reforzados.

   Fuente:Payment Services Regulations 2017, artículos 98 y 99; FCA PS26/2, 18 de marzo de 2026

   Qué supone para su app móvil

   Los incidentes que empiezan en la app o en una API son incidentes operativos y de seguridad. La evidencia que conserva durante las pruebas es lo que le permite clasificarlos y notificarlos con rapidez.

   Cómo ayuda Ostorlab

   Ostorlab no notifica incidentes a los reguladores. Conserva por hallazgo la evidencia, la gravedad y el historial de repeticiones de prueba que sus equipos de incidentes y reporting pueden usar.

   Qué sigue en sus manos

   La gestión de incidentes, su clasificación, la notificación a la FCA y la comunicación con los clientes.

9. 09

   UK GDPR, artículo 32; ICO, A guide to data security

   Proteger los datos personales y probar sus medidas de seguridad

   Qué dice el texto

   El artículo 32 del RGPD británico exige a responsables y encargados del tratamiento aplicar medidas técnicas y organizativas apropiadas al riesgo, incluidos el cifrado o la seudonimización, la capacidad de garantizar de forma continuada la confidencialidad, integridad, disponibilidad y resiliencia, y un proceso para probar, evaluar y valorar periódicamente la eficacia de esas medidas. La ICO señala que esas pruebas pueden realizarse mediante técnicas como el escaneo de vulnerabilidades y las pruebas de penetración, y que las organizaciones deben documentar los resultados y actuar sobre las recomendaciones, o tener una razón válida para no hacerlo.

   Fuente:UK GDPR, artículo 32; ICO, A guide to data security

   Qué supone para su app móvil

   La app es donde se recogen, muestran y almacenan los datos de los clientes en un dispositivo que el banco no controla. Las medidas que los protegen necesitan pruebas periódicas y documentadas.

   Cómo ayuda Ostorlab

   Ostorlab busca tokens de sesión y datos personales en el almacenamiento local, las cachés, los registros y las capturas de pantalla, comprueba las protecciones del transporte y encuentra claves de API y credenciales en el paquete de la app, con evidencia del sistema de archivos de qué se escribió, dónde y cuándo.

   Qué sigue en sus manos

   La evaluación de riesgos, las propias medidas, las evaluaciones de impacto relativas a la protección de datos y la notificación de brechas.

10. 10

    Declaración conjunta del Banco de Inglaterra, la FCA y el Tesoro británico sobre modelos de IA de frontera y resiliencia cibernética, 15 de mayo de 2026

    Vigilar y parchear las vulnerabilidades más rápido

    Qué dice el texto

    En una declaración conjunta del 15 de mayo de 2026, el Banco de Inglaterra, la FCA y el Tesoro británico señalaron que los modelos de IA de frontera pueden identificar rápidamente y facilitar la explotación de un número potencialmente elevado de vulnerabilidades en los parques tecnológicos de las entidades, y que estas deben poder clasificar, priorizar, evaluar el riesgo y corregir vulnerabilidades más rápido, con más frecuencia y a escala, incluso mediante automatización cuando proceda. La declaración también señala los riesgos de los terceros, las cadenas de suministro y el software de código abierto, y las prácticas eficaces de respuesta y recuperación cibernética publicadas por el Banco, la PRA y la FCA en octubre de 2025.

    Fuente:Declaración conjunta del Banco de Inglaterra, la FCA y el Tesoro británico sobre modelos de IA de frontera y resiliencia cibernética, 15 de mayo de 2026

    Qué supone para su app móvil

    Una versión publicada puede ser vulnerable al día siguiente de salir. El descubrimiento de vulnerabilidades y el parcheo deben seguir un ritmo que el pipeline de publicación pueda mantener.

    Cómo ayuda Ostorlab

    Ostorlab ejecuta escaneos desde su pipeline de CI/CD en cada compilación y monitoriza las versiones publicadas en las tiendas sin disparadores manuales, para que los nuevos hallazgos aparezcan en la versión afectada y los arreglos se vuelvan a probar en cuanto se publican.

    Qué sigue en sus manos

    Las decisiones de parcheo, la gestión del cambio y el riesgo operativo de remediar a escala.

Resumen de textos públicos de la PRA, la FCA, el Banco de Inglaterra, la ICO y la legislación británica, consultados el 27 de septiembre de 2026. Esta página no constituye asesoramiento jurídico.