Normas cibernéticas del CBB: pruebe su app de banca móvil en cada versión y para el test semestral.
El módulo de gestión del riesgo operacional del Rulebook del CBB pide a los bancos convencionales evaluar las apps, los sistemas externos y las conexiones con terceros, y realizar pruebas de penetración de sistemas, aplicaciones y dispositivos de red al menos dos veces al año, con cobertura grey box y black box. El capítulo de banca electrónica fija la autenticación fuerte del cliente y la PDPL regula los datos de los clientes. Ostorlab prueba su app y las API que la sustentan, con sesión iniciada, en cada versión.
- Prueba la app y las API a las que llama, incluidas las conexiones con terceros, en la versión que descargan sus clientes
- Inicia sesión con sus cuentas de prueba y comprueba la autenticación fuerte del cliente, los códigos de un solo uso y los flujos de autenticación reforzada
- Enumera los SDK y las bibliotecas nativas de cada versión y los asocia a vulnerabilidades conocidas
- Demuestra cada hallazgo con un exploit reproducible o evidencia de solicitudes y respuestas
- A quién se aplica
- Bancos convencionales autorizados en Baréin, incluidas las sucursales de bancos extranjeros, conforme al Volumen 1 del Rulebook del CBB
- Base jurídica
- Directiva del CBB en el módulo de gestión del riesgo operacional, dictada al amparo del artículo 38 de la Ley de 2006 del Banco Central de Baréin y las instituciones financieras; la PDPL es la Ley n.º 30 de 2018
- Objeto
- Evaluaciones técnicas, pruebas de penetración dos veces al año, autenticación de banca electrónica, continuidad y datos personales
- Referencia
- CBB Rulebook Volumen 1, módulo OM: OM-5.5 Cyber Security Risk Management, actualizado en mayo de 2026
Los textos del CBB detrás de su canal móvil
La sección de ciberseguridad forma parte del módulo de gestión del riesgo operacional, junto a los capítulos de banca electrónica y continuidad de negocio. Las fechas siguientes corresponden a los textos citados en esta página.
- 12 de julio de 2018
Ley de Protección de Datos Personales
Se promulga la Ley n.º 30 de 2018. Exige medidas técnicas y organizativas para los datos personales, confidencialidad, un guardián de datos personales y normas para las transferencias fuera del Reino, y entra en vigor en 2019.
- Enero de 2020
Módulo OM revisado
El CBB revisa todo el módulo de gestión del riesgo operacional para alinearlo con los principios del Comité de Basilea. Las normas de gobernanza, autenticación segura y otros sistemas y controles para la banca electrónica y las transferencias electrónicas de fondos se integran en esta estructura.
- Julio de 2021
Nueva sección de ciberseguridad
Se añade OM-5.5 Cyber Security Risk Management como nueva sección reforzada, junto con el Apéndice C, las directrices de control basadas en el marco de ciberseguridad del NIST. Las pruebas de penetración se fijan en al menos dos veces al año.
- Abril de 2022
Notificación de incidentes modificada
Se modifican las normas de notificación de incidentes de ciberseguridad al CBB: contacto en una hora, sección A del informe de incidente en dos horas y sección B en 10 días naturales.
- 5 de marzo de 2026
Consulta sobre servicios de pago
Se cierra la consulta sobre un módulo propuesto de requisitos para los servicios de pago. Es una propuesta, no está en vigor; mientras tanto se aplican las normas de autenticación de banca electrónica del módulo OM-3.
- Mayo de 2026
Actualización del módulo OM
El CBB actualiza todo el módulo, incluido OM-5.5, para alinearlo con el nuevo módulo de delitos financieros. Se modifica el párrafo sobre el comité de ciberseguridad del consejo (OM-5.5.9).
- Cada año
Pruebas de continuidad
Los planes de continuidad de negocio deben probarse al menos una vez al año, incluidas las sedes alternativas, los servicios de recuperación de proveedores y la recuperación de documentos vitales.
Las normas del CBB, aplicadas a su app móvil
Para cada norma: qué dice el texto, qué supone para una app de banca móvil, cómo ayuda Ostorlab y qué sigue en manos de su equipo. Las citas provienen del Rulebook del CBB en inglés.
- CBB Rulebook Volumen 1, OM-5.5.25 y OM-5.5.26
Evaluar las apps, los sistemas externos y las conexiones con terceros
Qué dice el texto
Realizar evaluaciones técnicas periódicas para identificar posibles vulnerabilidades de seguridad en sistemas, aplicaciones y dispositivos de red. Las evaluaciones deben ser exhaustivas y abarcar la tecnología interna, la tecnología externa y las conexiones con terceros. Es preferible realizar las evaluaciones de la tecnología interna cada mes, y las de los servicios y sistemas externos expuestos al público cada semana o con más frecuencia. La tecnología externa se refiere a la tecnología expuesta al público, como sitios web, apps y servidores externos; las conexiones con terceros incluyen cualquier API u otras conexiones con fintechs, proveedores de tecnología y proveedores de servicios externalizados.
Qué supone para su app móvil
El texto incluye las apps en su definición de tecnología externa, así que la app móvil y las API a las que llama entran en el alcance de la evaluación, y los sistemas expuestos al público tienen la cadencia más exigente.
Cómo ayuda Ostorlab
Mobile Agentic Deep Scan prueba la versión publicada y las API que la sustentan en cada versión, con un exploit funcional que puede reproducir para cada hallazgo de un agente de IA. Sigue a la app en sus conexiones con terceros probando los servicios que llaman la app y sus SDK.
Qué sigue en sus manos
El programa de evaluación, el escaneo de servidores internos y dispositivos de red, y el plan de tratamiento de los riesgos residuales.
- CBB Rulebook Volumen 1, OM-5.5.28 y OM-5.5.61
Realizar pruebas de penetración al menos dos veces al año
Qué dice el texto
Todos los licenciatarios deben realizar pruebas de penetración de sus sistemas, aplicaciones y dispositivos de red para verificar la solidez de los controles de seguridad implantados, al menos dos veces al año. Las pruebas deben simular ciberataques del mundo real, seguir una metodología basada en riesgos y reconocida internacionalmente, como NIST u OWASP, incluir pruebas grey box y black box, ser realizadas por profesionales de seguridad cualificados y experimentados, certificados en la prestación de servicios de pruebas de penetración, ser ejecutadas por terceros internos y externos independientes que deberían cambiarse al menos cada dos años, y realizarse en el entorno de producción o en réplicas exactas fuera de producción. El informe y las medidas de mitigación deben conservarse cinco años y entregarse al CBB en los dos meses siguientes al final del mes en que se realizó la prueba.
Qué supone para su app móvil
Dos veces al año es el mínimo, no el máximo. Las versiones móviles se publican mucho más a menudo, y la app y las API a las que llama están dentro del alcance.
Cómo ayuda Ostorlab
Ostorlab actúa en cada versión entre las dos pruebas anuales, sobre la versión que descargan los clientes, y cubre pruebas grey box con sesión iniciada usando sus cuentas de prueba. Obtiene un exploit, o evidencia de solicitudes y respuestas, para cada hallazgo que deba incluirse en el informe.
Qué sigue en sus manos
La elección y rotación de los probadores independientes, la metodología formal, el informe y la entrega al CBB.
- CBB Rulebook Volumen 1, OM-5.5.29 y OM-5.5.30
Red teaming cuando el CBB lo exija
Qué dice el texto
El CBB puede exigir ejercicios adicionales de red teaming cuando sea necesario. Un equipo rojo es un grupo de hackers éticos de perfiles variados que pone a prueba la actividad de respuesta del equipo azul de la organización; puede atacar los frentes ciber, social y físico, y el objetivo es probar la capacidad de detección y respuesta, no encontrar el mayor número posible de vulnerabilidades. Cuando se haya exigido a un licenciatario realizar un ejercicio de red teaming, los resultados deben entregarse al CBB en el mes siguiente a su finalización, junto con un plan completo para abordar las debilidades observadas.
Qué supone para su app móvil
El red teaming es un ejercicio de toda la institución, no una prueba de la app. Sale mejor cuando los problemas conocidos de la app y las API ya están corregidos.
Cómo ayuda Ostorlab
Ostorlab no ejecuta red teaming ni lo sustituye. Le ayuda a cerrar los problemas conocidos de la app y las API antes del ejercicio y a reprobar después los elementos de app y API del plan de mitigación.
Qué sigue en sus manos
El alcance y la ejecución del ejercicio, los frentes social y físico, y el informe al CBB en el plazo de un mes.
- CBB Rulebook Volumen 1, OM-5.5.18(d), (h) e (i)
Probar con rigor durante el desarrollo y después del despliegue
Qué dice el texto
Las medidas preventivas deben incluir pruebas de seguridad rigurosas en la fase de desarrollo del software y después del despliegue para limitar el número de vulnerabilidades, y la creación de una lista blanca de aplicaciones y componentes de aplicación, como bibliotecas y archivos de configuración, autorizados a estar presentes o activos en los sistemas de la organización. Las soluciones de gestión de dispositivos móviles y las políticas BYOD deben proteger todos los dispositivos móviles con acceso a los sistemas, aplicaciones y redes del banco, mediante medidas como el cifrado, el borrado remoto y la exigencia de contraseñas.
Qué supone para su app móvil
Cada versión de la app es un cambio en la tecnología externa del banco. El texto pide pruebas antes y después del despliegue, sobre la versión que los clientes usan realmente.
Cómo ayuda Ostorlab
Ostorlab ejecuta escaneos automatizados desde su pipeline de CI/CD en cada compilación y supervisa las versiones publicadas en las tiendas sin activación manual. Mobile SAST trabaja sobre el APK, AAB o IPA, sin código fuente. El inventario de SCA es la lista de componentes autorizados, con evidencia.
Qué sigue en sus manos
La política de desarrollo seguro, los controles de MDM y BYOD, y la propia lista de componentes autorizados.
- CBB Rulebook Volumen 1, OM-5.5.15(d), OM-5.5.27 y OM-5.5.4(e)
Gestionar vulnerabilidades y parches con plazos
Qué dice el texto
Disponer de procesos de gestión de vulnerabilidades y parches, incluidos procesos de mitigación, para que las vulnerabilidades identificadas se aborden y los parches de seguridad se apliquen en un plazo proporcional al riesgo que plantea cada vulnerabilidad. La política de ciberseguridad debe abarcar la gestión de vulnerabilidades, el desarrollo seguro de aplicaciones y la gestión segura de cambios, y el consejo debería recibir los resultados de los ejercicios de pruebas de penetración en su información de ciberseguridad.
Fuente:CBB Rulebook Volumen 1, OM-5.5.15(d), OM-5.5.27 y OM-5.5.4(e)
Qué supone para su app móvil
Las bibliotecas y los SDK dentro de su app son software que usted publica. Cada uno necesita una versión conocida, una gravedad cuando aparece una vulnerabilidad y un plazo de corrección que pueda demostrar.
Cómo ayuda Ostorlab
SCA identifica mediante huellas las bibliotecas compiladas estáticamente y las asocia a vulnerabilidades conocidas, versión tras versión. 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 publicado el correctivo.
Qué sigue en sus manos
La aplicación de parches en servidores e infraestructura, los contratos de mantenimiento de proveedores y las decisiones de aceptación del riesgo.
- CBB Rulebook Volumen 1, OM-3.2.1, OM-3.2.2, OM-3.2.4 y OM-3.2.6
Usar autenticación fuerte del cliente para la banca electrónica y el EFTS
Qué dice el texto
Los licenciatarios deben adoptar medidas apropiadas para autenticar la identidad y la autorización de los clientes, y usar métodos predefinidos de autenticación de transacciones que favorezcan el no repudio y establezcan la responsabilidad de las transacciones, con procedimientos detallados para identificar a la persona que origina las transferencias electrónicas de fondos y para las llamadas de verificación (call backs) cuando proceda. El proceso de autenticación fuerte del cliente debe garantizar que no pueda deducirse información sobre sus elementos de la divulgación del código de autenticación, que no pueda generarse un nuevo código a partir del conocimiento de otro código generado previamente, y que el código no pueda falsificarse. La autenticación del cliente debe usar los tres elementos de conocimiento, posesión e inherencia.
Fuente:CBB Rulebook Volumen 1, OM-3.2.1, OM-3.2.2, OM-3.2.4 y OM-3.2.6
Qué supone para su app móvil
La app es donde se recogen los factores, pero la aplicación debe residir en el servidor, incluso cuando la app o un atacante se salta un paso.
Cómo ayuda Ostorlab
Las pruebas autenticadas cubren el inicio y el cierre de sesión, la renovación de tokens, los tiempos de espera, la invalidación de sesiones y la autenticación fuerte del cliente, incluidos los flujos de autenticación reforzada y cómo intentan manipularlos los atacantes, junto con las llamadas a la API que hay detrás.
Qué sigue en sus manos
La elección de los métodos y umbrales de autenticación, y los procedimientos de llamada de verificación para las transferencias electrónicas.
- CBB Rulebook Volumen 1, OM-3.1.2(b), (e) y (f); OM-3.3.1 a OM-3.3.6
Probar sus API y controlar el acceso a los sistemas de banca electrónica
Qué dice el texto
Las políticas y procedimientos de banca electrónica y transferencias electrónicas de fondos deben cubrir las pruebas de las interfaces de programación de aplicaciones (API), la autenticación de los usuarios, la protección de la confidencialidad de los datos de los clientes conforme a la Ley de Protección de Datos Personales, y una supervisión reforzada del fraude en los movimientos de las cuentas de los clientes mediante herramientas y medidas como límites de valor, volumen y velocidad. Los licenciatarios también deben garantizar la segregación de funciones, controles de autorización y privilegios de acceso adecuados, la integridad de los datos, pistas de auditoría claras y la conservación de registros para los sistemas, bases de datos y aplicaciones de banca electrónica y EFTS.
Fuente:CBB Rulebook Volumen 1, OM-3.1.2(b), (e) y (f); OM-3.3.1 a OM-3.3.6
Qué supone para su app móvil
Las API que sustentan la app transportan los mismos datos que la app. El texto pide probarlas y controlar el acceso a ellas, con los límites antifraude aplicados en el servidor.
Cómo ayuda Ostorlab
Ostorlab intercepta el tráfico de la app, incluso con TLS pinning, y prueba las API en busca de autorización defectuosa (BOLA, BFLA, IDOR), uso indebido de tokens y sesiones, y abusos como la enumeración, la repetición y la automatización, con evidencia de solicitudes y respuestas para cada hallazgo.
Qué sigue en sus manos
Las reglas y límites de supervisión del fraude, los parches de los servidores, y la pista de auditoría y la conservación de registros.
- CBB Rulebook Volumen 1, OM-4.2.1, OM-4.5.4, OM-4.9.2, OM-3.3.9 y OM-3.3.10
Probar la continuidad de negocio del canal móvil
Qué dice el texto
El plan de continuidad de negocio debe abordar la copia de seguridad y la recuperación de datos, la continuidad de los sistemas y actividades críticos, medios de comunicación alternativos y el acceso rápido de los clientes a sus fondos en caso de interrupción. Los licenciatarios deben definir objetivos de tiempo de recuperación (RTO), objetivos de punto de recuperación (RPO) y el periodo máximo tolerable de interrupción para las funciones críticas, aprobados por la alta dirección, y deben probar sus planes de continuidad al menos una vez al año, incluida la activación de sedes alternativas, los servicios de recuperación de proveedores y la recuperación de documentos vitales. Los sistemas de banca electrónica deben contar con capacidad, continuidad y planificación de contingencia eficaces, y con planes de respuesta a incidentes que cubran ataques internos y externos.
Fuente:CBB Rulebook Volumen 1, OM-4.2.1, OM-4.5.4, OM-4.9.2, OM-3.3.9 y OM-3.3.10
Qué supone para su app móvil
La app y sus API forman parte del servicio crítico que los clientes usan para acceder a sus fondos. Su comportamiento cuando falla una dependencia es testeable.
Cómo ayuda Ostorlab
Ostorlab prueba la app y sus API en busca de comportamientos que rompen la disponibilidad y la integridad de los datos, como el manejo de errores, el comportamiento de las sesiones y los límites de la lógica de negocio, en entornos de preproducción o similares a producción, con evidencia que puede añadir a la revisión del plan de continuidad.
Qué sigue en sus manos
El propio plan de continuidad, las sedes alternativas, las copias de seguridad, la aprobación de RTO y RPO, y la prueba anual.
- Ley de Protección de Datos Personales (Ley n.º 30 de 2018), artículos 8, 9, 12 y 13
Proteger los datos personales conforme a la PDPL
Qué dice el texto
El responsable del tratamiento debe implantar medidas técnicas y organizativas apropiadas para proteger los datos personales contra la destrucción accidental o no autorizada, la pérdida accidental, la alteración o la divulgación, y contra el acceso no autorizado o cualquier otra forma de tratamiento no autorizado, teniendo en cuenta las medidas de seguridad tecnológicas más recientes, el coste y los riesgos implicados. Las medidas deben quedar registradas y ser accesibles para las partes pertinentes. El responsable debe elegir un encargado que ofrezca garantías suficientes y vincular el tratamiento a un contrato escrito con obligaciones equivalentes de seguridad y confidencialidad. Los datos personales no deben divulgarse sin consentimiento, y las transferencias fuera del Reino están prohibidas salvo que el destino ofrezca protección adecuada, la Autoridad autorice la transferencia o se aplique una de las exenciones de la ley.
Fuente:Ley de Protección de Datos Personales (Ley n.º 30 de 2018), artículos 8, 9, 12 y 13
Qué supone para su app móvil
La app almacena y transmite datos personales, y sus SDK a menudo los envían a backends de terceros. Esos flujos necesitan las mismas medidas técnicas y organizativas y la misma disciplina de transferencia.
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 mapea con qué backends de terceros intercambian datos la app y sus SDK.
Qué sigue en sus manos
El programa de protección de datos, el guardián de datos personales, los registros de tratamiento y las autorizaciones de transferencia.
- CBB Rulebook Volumen 1, OM-5.5.57 y OM-5.5.58
Notificar al CBB los incidentes ciber graves en una hora
Qué dice el texto
Cuando se produzca o detecte un incidente de ciberseguridad, interno o externo, que comprometa información de clientes o interrumpa servicios críticos que afecten a las operaciones, los licenciatarios deben contactar con el CBB de inmediato, en el plazo de una hora, y enviar la sección A del informe de incidente de ciberseguridad en el plazo de dos horas. La sección B se envía en los 10 días naturales siguientes al incidente, con el análisis completo de causas raíz, el impacto en las operaciones y los clientes, y todas las medidas adoptadas para detener el ataque y evitar su repetición, además de una actualización semanal del progreso hasta que el incidente quede totalmente resuelto.
Qué supone para su app móvil
De la detección a la notificación hay una carrera de una hora. Saber exactamente qué podía hacer el atacante en su app y sus API es lo que necesita la sección de análisis de causas raíz del informe.
Cómo ayuda Ostorlab
Ostorlab no notifica incidentes al CBB ni actúa como su SOC. Le proporciona exploits y evidencia de solicitudes y respuestas de sus hallazgos de app y API, que respaldan el análisis de causas raíz del informe.
Qué sigue en sus manos
El proceso de respuesta a incidentes, la llamada al CBB en una hora, las secciones del informe y las actualizaciones semanales.
Resumen de textos públicos del CBB, consultados el 27 de septiembre de 2026. El módulo de gestión del riesgo operacional se actualizó por última vez en mayo de 2026. Esta página no constituye asesoramiento jurídico.
Normas del CBB, control por control
Los controles a los que apuntan los textos del CBB, 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 |
|---|---|---|
| Evaluaciones técnicas de apps, sistemas externos y conexiones con tercerosOM-5.5.25, 5.5.26 | Pentest con agentes de IA de la app y sus API, con sesión iniciada, sobre la versión que publica, incluidos los servicios que llaman la app y sus SDK. Detalles | Un exploit funcional que puede reproducir para cada hallazgo de un agente de IA, y un mapa de calor de cobertura |
| Pruebas de penetración al menos dos veces al año, grey box y black boxOM-5.5.28 | Pentest con agentes de IA de la app y sus API, con sesión iniciada, junto con un análisis de las interacciones entre la app, sus SDK y el backend. Detalles | Un exploit funcional o una solicitud validada para cada hallazgo del informe de pruebas de penetración |
| Pruebas de seguridad en el desarrollo y después del despliegueOM-5.5.18(d) | Mobile SAST y DAST en el CI/CD en cada compilación, y supervisión de las versiones publicadas en las tiendas. Detalles | Resultados de escaneo por compilación y por versión publicada |
| Componentes y bibliotecas de aplicación autorizadosOM-5.5.18(h) | Enumera los SDK y las bibliotecas nativas de cada versión con sus versiones, y muestra a qué backends se conectan la app y sus SDK. Detalles | Identidad, versión y ubicación del componente en el paquete de la app, por versión |
| Plazos de corrección de vulnerabilidadesOM-5.5.27 | Identifica mediante huellas las bibliotecas compiladas estáticamente y las asocia a vulnerabilidades conocidas, versión tras versión. Detalles | Vulnerabilidades mapeadas con recomendaciones de actualización o sustitución, y cierre seguido entre versiones |
| Autenticación fuerte del cliente y autenticación de transaccionesOM-3.2.4, 3.2.6 | Inicia sesión con códigos de un solo uso y prueba la aplicación de la autenticación del cliente, los flujos de autenticación reforzada y 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 |
| Pruebas de API y controles de autorizaciónOM-3.1.2(b), OM-3.3.1, 3.3.2 | 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 |
| Confidencialidad de los datos de clientes en la app y en tránsitoPDPL art. 8, 9; OM-3.3.6 | Busca tokens y datos personales en el almacenamiento, las cachés, los registros y las capturas de pantalla, y comprueba las protecciones del transporte. Detalles | Evidencia del sistema de archivos que muestra qué se escribió, dónde y cuándo |
| Credenciales y claves en el paquete de la appOM-3.3.2; PDPL art. 8 | Detecta claves de API, tokens y credenciales en el paquete de la app y valida si funcionan. Detalles | Secretos validados, con los permisos y servicios que exponen |
| Preparación para la recuperación y evidencia de incidentesOM-4.9.2; OM-5.5.57 | Vuelve a probar después de cada corrección, de modo que el estado de la app y las API quede documentado antes de una prueba de continuidad o un análisis posterior a un incidente. | Historial de tickets y resultados de reprobación que puede adjuntar a la revisión de continuidad o al informe de incidente |
Ostorlab prueba los controles de la app y de sus API. La supervisión del SOC, la notificación de incidentes al CBB, el red teaming, la continuidad de negocio, las copias de seguridad y la recuperación, la gobernanza y la seguridad física corresponden a sus equipos.
Controles del CBB que probar en su app móvil
Una lista práctica para los equipos de seguridad y riesgo operacional, basada en el módulo OM y la Ley de Protección de Datos Personales.
Alcance de la evaluación
Incluya la app móvil, sus API y las conexiones con terceros en el alcance de sus evaluaciones técnicas, con la cadencia más exigente que el texto da a los sistemas expuestos al público.
Prueba de penetración semestral
Planifique dos pruebas de penetración al año con cobertura grey box y black box, probadores certificados y un proveedor independiente renovado al menos cada dos años.
Informe al CBB
Conserve cada informe de pruebas de penetración y sus medidas de mitigación durante cinco años, y envíe el informe en los dos meses siguientes al mes de la prueba.
CI/CD y versiones de las tiendas
Ejecute pruebas de seguridad automatizadas en cada compilación y escanee la versión publicada en la tienda, no solo la que probó el trimestre pasado.
Componentes y plazos
Mantenga una lista versionada de los SDK y bibliotecas de cada versión, y fije plazos de mitigación por gravedad.
Autenticación
Verifique en el servidor la autenticación fuerte del cliente y la autenticación de transacciones, incluidos los códigos de un solo uso, los flujos de autenticación reforzada y los tres elementos de conocimiento, posesión e inherencia.
Datos en el dispositivo
Revise el paquete de la app en busca de claves y credenciales, busque datos personales en el almacenamiento, las cachés, los registros y las capturas de pantalla, y revise las transferencias fuera del Reino frente a la PDPL.
Simulacro de incidente y continuidad
Ensaye la llamada al CBB en una hora y el informe de incidente, mantenga el registro de incidentes y pruebe el plan de continuidad al menos una vez al año.
Una lista sugerida, no una plantilla del CBB. 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
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.
- CBB Rulebook Volumen 1: bancos convencionales, módulo OM de gestión del riesgo operacionalBanco Central de Baréin, parte A Business Standards. El módulo OM se revisó en enero de 2020 y se actualizó por última vez en mayo de 2026. Contiene los capítulos de banca electrónica, continuidad de negocio y ciberseguridad aplicables a los bancos convencionales autorizados
- OM-5.5 Cyber Security Risk ManagementCBB Rulebook Volumen 1. Añadida como nueva sección reforzada en julio de 2021. Evaluaciones técnicas (OM-5.5.25, OM-5.5.26), gestión de vulnerabilidades y parches (OM-5.5.27), pruebas de penetración al menos dos veces al año (OM-5.5.28), red teaming (OM-5.5.29, OM-5.5.30), notificación de incidentes (OM-5.5.57, OM-5.5.58) y conservación durante cinco años y entrega en dos meses del informe de pruebas de penetración (OM-5.5.61)
- OM-3 Electronic Money and Electronic Banking ActivitiesCBB Rulebook Volumen 1. Gobernanza, pruebas de interfaces de programación de aplicaciones, confidencialidad de datos conforme a la PDPL y supervisión del fraude (OM-3.1.2); autenticación segura, incluida la autenticación fuerte del cliente y los tres elementos de autenticación (OM-3.2); segregación de funciones, privilegios de acceso, pistas de auditoría y continuidad para los sistemas de banca electrónica y transferencias electrónicas (OM-3.3)
- OM-4 Business Continuity ManagementCBB Rulebook Volumen 1. Contenido del plan de continuidad de negocio (OM-4.2.1), objetivos de tiempo de recuperación, objetivos de punto de recuperación y periodo máximo tolerable de interrupción (OM-4.5.4), y prueba del plan de continuidad al menos una vez al año (OM-4.9.2)
- Apéndice C: directrices de control de ciberseguridadCBB Rulebook Volumen 1. Añadido en julio de 2021. Directrices de control basadas en el marco de ciberseguridad del NIST, agrupadas en Identificar, Proteger, Detectar, Responder y Recuperar, utilizadas como referencia para la estrategia y la política de ciberseguridad
- Ley de Protección de Datos Personales (Ley n.º 30 de 2018)Reino de Baréin, promulgada el 12 de julio de 2018, en vigor desde 2019. Seguridad del tratamiento (artículo 8), confidencialidad (artículo 9), guardián de datos personales (artículo 10) y transferencias fuera del Reino (artículos 12 y 13). El texto inglés publicado por la Autoridad de Protección de Datos Personales es una traducción; prevalece el texto en árabe
- Consultas del CBB: módulo propuesto de requisitos para los servicios de pagoBanco Central de Baréin, consulta cerrada el 5 de marzo de 2026. Una propuesta, no en vigor, sobre un nuevo marco para los servicios de pago. Mientras tanto se aplican las normas de autenticación de banca electrónica del módulo OM
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.
Evalúe su app de banca móvil como lo describe el CBB
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 de su app y sus API.