Las normas del QCB para la app de banca móvil que usan sus clientes.
El Qatar Central Bank pide a los bancos que prueben las aplicaciones web y móviles antes y después de su puesta en producción y tras cualquier cambio importante, que realicen evaluaciones de vulnerabilidades, revisiones de código y pruebas de penetración al menos dos veces al año, y que protejan la autenticación frente a la reproducción y el secuestro. Ostorlab le ayuda a probar su app y sus API en cada versión, entre las rondas programadas.
- Pruebas de penetración mediante agentes de IA detrás del inicio de sesión, con un exploit reproducible para cada hallazgo de un agente de IA
- Pruebas estáticas y dinámicas de la versión que publica, sin necesidad de código fuente
- Sesiones, códigos de un solo uso y flujos de verificación reforzada probados con sus cuentas de prueba
- Escaneo on-premises cuando los datos deben permanecer en una infraestructura que usted controla
- A quién se aplica
- Bancos del Estado de Catar
- Base jurídica
- Reglamento Technology Risks del QCB, enero de 2018, con un informe anual de cumplimiento al QCB
- Frecuencia
- Evaluaciones de vulnerabilidades, revisiones de código y pruebas de penetración al menos dos veces al año
- Referencia
- Reglamento Technology Risks del QCB, Cloud Computing Regulation, Data Handling and Protection Regulation
Las normas de riesgo tecnológico del QCB, fecha a fecha
Los textos del QCB citados en esta página están hoy en vigor. Estas son las fechas y cadencias con las que se mide la realización de las pruebas de su app.
- 22 de noviembre de 2012
Circular sobre riesgos de la banca electrónica
Circular n.º 105/2012 sobre los riesgos de las tecnologías modernas y de los servicios de banca electrónica, reforzada posteriormente por el reglamento de 2018.
- Enero de 2018
Reglamento Technology Risks
Requisitos de ciberseguridad del QCB para los bancos, incluidas las pruebas de aplicaciones, las pruebas de penetración y la banca en línea y móvil.
- 15 de abril de 2024
Cloud Computing Regulation
Aprobación del QCB antes de cualquier acuerdo de nube, y tratamiento de la PII y la información financiera únicamente en Catar.
- Dos veces al año
Evaluaciones y pruebas de penetración
Evaluaciones de vulnerabilidades, revisiones de código y pruebas de penetración, como mínimo dos al año, o con más frecuencia si es necesario.
- Cada seis meses
Revisión de los riesgos aceptados
La aceptación de riesgos para las vulnerabilidades existentes se revisa semestralmente.
- Cada año
Informe de cumplimiento al QCB
Una evaluación anual del cumplimiento y un informe al QCB firmado por el consejo o por un comité autorizado por el consejo.
Las normas de riesgo tecnológico del QCB, aplicadas a su app móvil
El reglamento Technology Risks del QCB fija las normas de pruebas y seguridad para los bancos, y sus normas sobre nube y datos determinan qué proveedores pueden ver sus datos. Para cada norma: qué dice el texto, qué supone para una app de banca móvil, cómo ayuda Ostorlab y qué sigue correspondiendo a su equipo.
- Reglamento Technology Risks del QCB, 9.4.2.2
Pruebe las apps web y móviles en todo su ciclo de vida
Qué dice el texto
El banco deberá realizar pruebas de seguridad de las aplicaciones web y móviles a lo largo de todo su ciclo de vida: antes de la implantación, después de la implantación y tras cualquier cambio importante. Los informes se comparten con las partes interesadas y se hace un seguimiento hasta su cierre.
Qué supone para su app móvil
Cada versión de la app que introduce un cambio significativo necesita una prueba de seguridad antes y después de su puesta en producción, y cada hallazgo necesita un responsable y una fecha de cierre.
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 activaciones manuales. Los hallazgos se clasifican como críticos, altos, medios o bajos, se gestionan 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
Definir qué se considera un cambio importante y compartir los informes con las partes interesadas.
- Reglamento Technology Risks del QCB, 9.4.2.3 y 9.4.3.3
Evaluaciones de vulnerabilidades, revisiones de código y pentests dos veces al año
Qué dice el texto
El banco deberá realizar evaluaciones de vulnerabilidades, revisiones de código y pruebas de penetración como mínimo dos veces, o con más frecuencia si es necesario, cada año, para toda la infraestructura de aplicaciones, y llevar a cabo dos ejercicios de pruebas de penetración al año, o más si es necesario.
Fuente:Reglamento Technology Risks del QCB, 9.4.2.3 y 9.4.3.3
Qué supone para su app móvil
Su app móvil y las API que la sustentan necesitan al menos dos rondas de evaluación y pentest cada año. Las versiones publicadas entre rondas quedan sin probar, salvo que añada más.
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
Programar los dos ejercicios anuales, elegir a los evaluadores y las pruebas de infraestructura ajenas a la app.
- Reglamento Technology Risks del QCB, 9.4.3.1 a 9.4.3.4
Combine herramientas y trabajo manual, y compare con la última vez
Qué dice el texto
Utilice una combinación de herramientas automatizadas y técnicas manuales para una evaluación exhaustiva de vulnerabilidades, siguiendo prácticas como OWASP, OSSTMM o SANS. Compare los resultados con los escaneos anteriores para verificar que las vulnerabilidades se han corregido, comparta un plan de acción con la alta dirección y revise semestralmente los riesgos aceptados.
Fuente:Reglamento Technology Risks del QCB, 9.4.3.1 a 9.4.3.4
Qué supone para su app móvil
Un hallazgo que reaparece en la ronda siguiente es una corrección fallida. Necesita el historial de escaneos de cada app para demostrar la diferencia.
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
Las pruebas manuales, el plan de acción para la alta dirección y las decisiones de aceptación de riesgos.
- Reglamento Technology Risks del QCB, 9.4.2.4, 9.7.1.1, 9.7.1.4 y 9.7.2.1
Desarrollo seguro y revisión del código fuente
Qué dice el texto
Formule directrices de desarrollo seguro de aplicaciones conformes con OWASP, las normas de codificación segura del CERT y MITRE CWE. Realice una revisión del código fuente para detectar vulnerabilidades derivadas de problemas de codificación, malas prácticas o intentos maliciosos, y revise las aplicaciones para determinar si intentan establecer conexiones externas.
Fuente:Reglamento Technology Risks del QCB, 9.4.2.4, 9.7.1.1, 9.7.1.4 y 9.7.2.1
Qué supone para su app móvil
La revisión de código debería abarcar lo que se incluye en la app, incluidos los SDK de terceros, y usted debería saber con qué backends se comunican la app y sus SDK.
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. Ostorlab muestra lo que la app y sus SDK intercambian con los backends a través de la red, y enumera los SDK y las bibliotecas nativas de cada versión.
Qué sigue en sus manos
Redactar las directrices de desarrollo, revisar el código fuente ajeno a la app y el depósito del código fuente (escrow).
- Reglamento Technology Risks del QCB, 8.10.2.9, 8.10.2.13 y 10.10.3
Proteja la autenticación frente a la reproducción y el secuestro
Qué dice el texto
Los datos de autenticación del sistema en uso deben estar protegidos y no ser vulnerables a ataques como la reproducción, el man-in-the-middle y el secuestro de sesión. El acceso debe suspenderse tras no más de tres intentos de autenticación fallidos. En la banca en línea, el banco debe implantar la autenticación de dos factores para la firma de transacciones.
Fuente:Reglamento Technology Risks del QCB, 8.10.2.9, 8.10.2.13 y 10.10.3
Qué supone para su app móvil
Los tokens, los códigos de un solo uso y la gestión de sesiones de la app y de sus API deben resistir la reproducción y el secuestro, y la firma de transacciones debe exigir un segundo factor en el servidor.
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
Las políticas de contraseñas, los valores de bloqueo y la gestión del acceso del personal.
- Reglamento Technology Risks del QCB, 10.10.8
Pruebe la banca en línea frente a ataques man-in-the-middle
Qué dice el texto
El banco deberá llevar a cabo una evaluación de vulnerabilidades y pruebas de penetración de su sistema de banca en línea para minimizar la exposición a ciberataques como los ataques man-in-the-middle, man-in-the-browser o man-in-the-application.
Qué supone para su app móvil
En una app móvil, man-in-the-application significa hooking y manipulación en el dispositivo, y man-in-the-middle significa interceptación del tráfico. Ambos se pueden probar.
Cómo ayuda Ostorlab
Mobile Shielding Scan ejecuta la app en entornos con root y jailbreak, intenta eludir la detección de root y jailbreak, la protección contra manipulación, la anti-instrumentación y el TLS pinning, y muestra si la app bloquea el flujo, se niega a iniciarse o sigue funcionando. Obtiene una puntuación de endurecimiento y evidencia de elusión.
Qué sigue en sus manos
La elección y la configuración de su producto de blindaje o de protección en tiempo de ejecución.
- Reglamento Technology Risks del QCB, 10.11.1 a 10.11.3
Proteja los servicios en línea y los pagos móviles
Qué dice el texto
El banco debe implantar medidas de seguridad para los servicios en línea y los pagos móviles, realizar una evaluación de riesgos para identificar posibles escenarios de fraude y garantizar una protección adecuada de la información sensible o confidencial utilizada en los servicios en línea y los pagos móviles.
Fuente:Reglamento Technology Risks del QCB, 10.11.1 a 10.11.3
Qué supone para su app móvil
Los datos que la app almacena y envía, y las API que sustentan los pagos, son donde los escenarios de fraude se convierten en pérdidas.
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, y prueba en las API los fallos de autorización (BOLA, BFLA, IDOR), el uso indebido de tokens y sesiones, y abusos como la enumeración, la reproducción y la automatización.
Qué sigue en sus manos
La evaluación del riesgo de fraude, la supervisión del fraude en tiempo real y la formación de los clientes.
- Reglamento Technology Risks del QCB, II y 7.1
Informe al QCB del cumplimiento cada año
Qué dice el texto
Los bancos deben cumplir la circular, realizar como mínimo una evaluación anual del cumplimiento y presentar al QCB un informe de cumplimiento como mínimo una vez al año, firmado por el consejo o por un comité autorizado por el consejo. Las deficiencias significativas requieren medidas correctoras, y el QCB puede auditar al banco en cualquier momento.
Qué supone para su app móvil
Su informe anual necesita evidencia de que las pruebas de la app y de las API se realizaron según lo exigido y de que los hallazgos se corrigieron.
Cómo ayuda Ostorlab
Los resultados de los escaneos, los hallazgos con pasos de reproducción y los resultados de las nuevas pruebas le proporcionan un registro fechado de cómo se probaron y corrigieron los controles de la app, versión tras versión.
Qué sigue en sus manos
La evaluación del cumplimiento, el informe, la aprobación del consejo y el diálogo con el QCB.
- Data Handling and Protection Regulation, 7.6, 7.7 y 15.1; Cloud Computing Regulation, 21.4
Mantenga los datos de los clientes en Catar, también en los proveedores
Qué dice el texto
El entorno principal de almacenamiento y tratamiento de la información personal, personal sensible y financiera sensible debe residir en Catar, salvo que el QCB apruebe otra cosa. Estos datos no deben almacenarse ni transferirse al extranjero sin la aprobación del QCB y, conforme a la Cloud Computing Regulation, la PII y la información financiera se tratan únicamente en Catar.
Fuente:Data Handling and Protection Regulation, 7.6, 7.7 y 15.1; Cloud Computing Regulation, 21.4
Qué supone para su app móvil
Un proveedor de pruebas que recibe binarios de la app, cuentas de prueba y capturas de tráfico es un tercero al que se aplican sus normas sobre datos.
Cómo ayuda Ostorlab
Con el plan Enterprise puede ejecutar los escaneos on-premises, en una infraestructura que usted controla, o elegir la residencia de datos en el CCG. Ostorlab cuenta con una auditoría SOC 2 Tipo II.
Qué sigue en sus manos
Decidir si algún dato de clientes llega al proveedor, y las posibles aprobaciones del QCB.
Resumen de los textos del QCB publicados en el sitio web del QCB, consultados el 27 de septiembre de 2026. Esta página no constituye asesoramiento jurídico.
Las normas del QCB, control por control
Los controles a los que remite el reglamento Technology Risks del QCB, cómo los prueba Ostorlab en su app y sus API, y la evidencia que puede conservar.
| Control | Cómo ayuda Ostorlab | Evidencia que conserva |
|---|---|---|
| Pruebas de seguridad de aplicaciones antes y después de la puesta en producciónTR 9.4.2.2 | Mobile SAST sobre el binario y Mobile DAST sobre la app en ejecución, antes de la publicación. Detalles | Resultados del escaneo de cada compilación |
| Pruebas de penetración al menos dos veces al añoTR 9.4.2.3, 9.4.3.3 | Pentest con agentes de IA de la app y de sus API, detrás del inicio de sesión, sobre la versión que publica. Detalles | Un exploit funcional que puede reproducir para cada hallazgo de un agente de IA, y un mapa de calor de cobertura |
| Comparación con escaneos anteriores y seguimiento hasta el cierreTR 9.4.2.2, 9.4.3.1 | Agrupa los hallazgos en tickets en la plataforma o en Jira y ServiceNow, y vuelve a probar tras la corrección. Detalles | Historial de tickets y resultado de la nueva prueba de cada hallazgo |
| Revisión del código de lo que se incluye en la appTR 9.7.1.4 | Análisis de propagación (taint) en los SDK integrados y análisis de dependencias de la app compilada. Detalles | Hallazgos atribuidos al SDK o a la biblioteca de la que proceden |
| Conexiones externas establecidas por la appTR 9.7.2.1 | Enumera los SDK y las bibliotecas nativas de cada versión con sus números de versión, y muestra con qué backends se comunican la app y sus SDK. Detalles | Identidad, versión y ubicación de cada componente en el paquete de la app, por versión de la app |
| Aplicación de parches a vulnerabilidades conocidas de los componentesTR 8.3 | Identifica mediante huellas las bibliotecas compiladas estáticamente y las relaciona con vulnerabilidades conocidas, de una versión a otra. Detalles | Vulnerabilidades asociadas con recomendaciones de actualización o sustitución, y seguimiento del cierre entre versiones |
| Reproducción, man-in-the-middle y secuestro de sesiónTR 8.10.2.9 | Prueba el inicio y el cierre de sesión, la renovación de tokens, los tiempos de espera y la invalidación de sesiones. Detalles | Hallazgos sobre sesiones y tokens, con registros de solicitudes y respuestas |
| Firma de transacciones con dos factores y bloqueoTR 8.10.2.13, 10.10.3 | Inicia sesión con códigos de un solo uso y prueba la aplicación de la MFA y los flujos de autenticación reforzada, así como las llamadas a la API que hay detrás. Detalles | Hallazgos sobre los flujos de inicio de sesión y de autenticación reforzada, con los pasos de reproducción |
| Ataques man-in-the-applicationTR 10.10.8 | Inyecta depuradores y hooks, y adapta el intento para sortear las defensas anti-instrumentación. Detalles | Evidencia de qué protecciones resistieron y cuáles se eludieron |
| Protección de los datos sensibles en los servicios móviles y las API de pagoTR 10.11.3 | Intercepta el tráfico incluso con TLS pinning y prueba la autorización, el uso indebido de tokens y abusos como la enumeración y la repetición. Detalles | Evidencia de solicitudes y respuestas para cada hallazgo de API |
Ostorlab prueba los controles de la app y de sus API. La gobernanza, los RR. HH., la continuidad de negocio, los centros de datos, la supervisión de la seguridad, la supervisión del fraude, la formación de los clientes y la notificación al QCB siguen correspondiendo a sus equipos.
Controles de la app según el QCB para este año
Una lista práctica para los equipos de seguridad y cumplimiento que trabajan con el reglamento Technology Risks del QCB.
Dos rondas de pruebas en el calendario
Planifique al menos dos rondas de evaluación de vulnerabilidades y pruebas de penetración al año para la app y sus API, y escaneos en cada versión entre ellas.
Antes y después de la puesta en producción
Pruebe cada versión importante antes de su implantación y de nuevo una vez en producción, y haga un seguimiento de cada hallazgo hasta su cierre.
Compare con la última ronda
Compruebe que los hallazgos de la ronda anterior han desaparecido y revise los riesgos aceptados cada seis meses.
Lo que se incluye en la app
Enumere los SDK y las bibliotecas de cada versión, así como los backends a los que se conectan la app y sus SDK.
Sesiones y códigos de un solo uso
Pruebe la reproducción de tokens y códigos, el secuestro de sesión, el bloqueo tras tres intentos fallidos y la firma de transacciones con dos factores.
Hooking e interceptación
Ejecute la app en dispositivos con root y jailbreak, con hooks e interceptación del tráfico, y confirme que reacciona.
Datos en el dispositivo y en las API
Busque tokens y datos personales en el almacenamiento, las cachés, los registros y las capturas de pantalla, y pruebe la autorización en cada API de pago.
Evidencia para el informe anual
Conserve los resultados de los escaneos, los tickets y las nuevas pruebas de cada versión, listos para el informe de cumplimiento al QCB.
Una lista sugerida, no una plantilla del QCB. Esto no constituye asesoramiento jurídico.
Las capacidades detrás de esta página
Cada una tiene su propia página con los detalles.
- Mobile Agentic Deep ScanLos agentes de IA realizan el pentest de la versión publicada en cada release, con un exploit funcional que puede reproducir para cada hallazgo de un agente de IA.Más información
- Mobile SASTAnálisis estático basado en el binario de archivos APK, AAB e IPA, con análisis de propagación (taint) en toda la app y sus SDK integrados.Más información
- Pruebas de API y backendIntercepte el tráfico de la app incluso con TLS pinning y pruebe las API y los backends detrás de cuentas y pagos.Más información
- Pruebas autenticadasPruebe el inicio de sesión, los códigos de un solo uso y la autenticación reforzada con sus cuentas de prueba.Más información
- Mobile Shielding ScanPruebe en tiempo de ejecución la detección de root y jailbreak, la protección contra manipulación y el pinning, y vea qué protecciones resistieron y cuáles se evadieron.Más información
- SCA y SBOMDetecte dependencias vulnerables, incluidas las bibliotecas nativas compiladas estáticamente, y haga un seguimiento de su cierre versión tras versión.Más información
- Escaneo on-premisesEscanee apps de preproducción, API y repositorios detrás de su firewall o VPN, en una infraestructura que usted controla.Más información
- Su propia clave de IAEjecute los escaneos con agentes de IA con la clave de su proveedor de IA y un límite de gasto por escaneo, según sus políticas internas.Más información
Bancos y fintechs confían en nosotros, entre ellos
Fuentes
Los textos oficiales en los que se basa esta página, consultados el 27 de septiembre de 2026.
- QCB Technology Risks regulation for banksQatar Central Bank, enero de 2018. Se aplica a los bancos de Catar y refuerza la circular sobre los riesgos de las tecnologías modernas y de los servicios de banca electrónica. Abarca las pruebas de seguridad de aplicaciones, las pruebas de penetración, la autenticación, la banca en línea y móvil y el informe anual de cumplimiento
- QCB Instructions to Banks, Annex 192: Modern Technology and E-Banking Services RisksQatar Central Bank, Circular n.º 105/2012, de 22 de noviembre de 2012, en las Instructions to Banks de septiembre de 2013. La circular anterior sobre riesgo tecnológico que reforzó el reglamento de 2018
- QCB Cloud Computing RegulationQatar Central Bank, en vigor desde el 15 de abril de 2024, para todas las entidades reguladas por el QCB que utilizan computación en la nube. Aprobación del QCB antes de un acuerdo de nube; PII e información financiera tratadas únicamente en Catar
- QCB Data Handling and Protection RegulationQatar Central Bank, para todas las instituciones financieras supervisadas por el QCB. Entorno principal de datos en Catar, aprobación del QCB para el almacenamiento o la transferencia al extranjero, acceso de terceros. El documento no indica su fecha de emisión
- QCB Information and Cyber Security Regulation for Payment Service ProvidersQatar Central Bank, 2022, para los proveedores de servicios de pago sujetos a la QCB Payment Services Regulation, no para los bancos. Incluye pruebas de penetración al menos dos veces al año
Preguntas frecuentes
Respuestas claras sobre cobertura, configuración y cómo llegan los resultados a su equipo.
¿No encuentra su respuesta? Reserve una demo o contáctenos.
Pruebe su app de banca móvil entre rondas del QCB
Empiece con un escaneo gratuito de su app desde la tienda, o reserve una demo para realizar con nuestro equipo pruebas con sesión iniciada y de API.