Règles cyber de la CBB : testez votre application bancaire mobile à chaque release, et pour le test semestriel.
Le module de gestion du risque opérationnel du Rulebook de la CBB demande aux banques conventionnelles d'évaluer les applications, les systèmes externes et les connexions avec des tiers, et de réaliser des tests d'intrusion des systèmes, des applications et des équipements réseau au moins deux fois par an, en grey box et black box. Le chapitre de la banque électronique fixe les règles d'authentification forte du client, et la PDPL encadre les données des clients. Ostorlab teste votre application et les API qui la sous-tendent, derrière la connexion, à chaque release.
- Teste l'application et les API qu'elle appelle, y compris les connexions tierces, sur la version que téléchargent vos clients
- Se connecte avec vos comptes de test et vérifie l'authentification forte du client, les codes à usage unique et les parcours d'authentification renforcée
- Recense les SDK et les bibliothèques natives de chaque version et les associe aux vulnérabilités connues
- Prouve chaque résultat par un exploit à rejouer ou des preuves de requêtes et réponses
- Qui est concerné
- Les banques conventionnelles agréées à Bahreïn, y compris les succursales de banques étrangères, au titre du Volume 1 du Rulebook de la CBB
- Base juridique
- Directive de la CBB dans le module de gestion du risque opérationnel, prise en application de l'article 38 de la loi de 2006 sur la Banque centrale de Bahreïn et les institutions financières ; la PDPL est la loi n° 30 de 2018
- Objet
- Évaluations techniques, tests d'intrusion deux fois par an, authentification de la banque électronique, continuité et données personnelles
- Référence
- CBB Rulebook Volume 1, module OM : OM-5.5 Cyber Security Risk Management, mis à jour en mai 2026
Les textes de la CBB derrière votre canal mobile
La section de cybersécurité se trouve dans le module de gestion du risque opérationnel, aux côtés des chapitres sur la banque électronique et la continuité d'activité. Les dates ci-dessous concernent les textes cités sur cette page.
- 12 juillet 2018
Loi sur la protection des données personnelles
La loi n° 30 de 2018 est promulguée. Elle impose des mesures techniques et organisationnelles pour les données personnelles, la confidentialité, un guardian des données personnelles et des règles pour les transferts hors du Royaume, et entre en vigueur en 2019.
- Janvier 2020
Module OM révisé
La CBB révise l'ensemble du module de gestion du risque opérationnel pour l'aligner sur les principes du Comité de Bâle. Les règles de gouvernance, d'authentification sécurisée et d'autres systèmes et contrôles pour la banque électronique et le virement électronique s'inscrivent dans cette structure.
- Juillet 2021
Nouvelle section de cybersécurité
OM-5.5 Cyber Security Risk Management est ajoutée comme nouvelle section renforcée, avec l'annexe C, les lignes directrices de contrôle fondées sur le cadre de cybersécurité du NIST. Les tests d'intrusion sont fixés à au moins deux fois par an.
- Avril 2022
Notification des incidents modifiée
Les règles de notification des incidents de cybersécurité à la CBB sont modifiées : contact sous une heure, section A du rapport d'incident sous deux heures, et section B sous 10 jours calendaires.
- 5 mars 2026
Consultation sur les services de paiement
La consultation sur un projet de module d'exigences pour les services de paiement se clôt. Il s'agit d'une proposition, non en vigueur ; les règles d'authentification de la banque électronique du module OM-3 s'appliquent en attendant.
- Mai 2026
Mise à jour du module OM
La CBB met à jour l'ensemble du module, y compris OM-5.5, pour l'aligner sur le nouveau module de lutte contre la criminalité financière. Le paragraphe sur le comité de cybersécurité du conseil (OM-5.5.9) est modifié.
- Chaque année
Tests de continuité
Les plans de continuité d'activité doivent être testés au moins une fois par an, y compris les sites alternatifs, les services de reprise des prestataires et la récupération des documents vitaux.
Les règles de la CBB, appliquées à votre application mobile
Pour chaque règle : ce que dit le texte, ce que cela implique pour une application bancaire mobile, comment Ostorlab vous aide et ce qui reste du ressort de votre équipe. Les citations proviennent du Rulebook de la CBB en anglais.
- CBB Rulebook Volume 1, OM-5.5.25 et OM-5.5.26
Évaluer les applications, les systèmes externes et les connexions tierces
Ce que dit le texte
Réaliser régulièrement des évaluations techniques pour identifier les vulnérabilités de sécurité potentielles des systèmes, des applications et des équipements réseau. Les évaluations doivent être exhaustives et couvrir la technologie interne, la technologie externe et les connexions avec des tiers. Il est préférable de réaliser les évaluations de la technologie interne tous les mois, et celles des services et systèmes externes exposés au public toutes les semaines ou plus souvent. La technologie externe désigne la technologie exposée au public, comme les sites web, les applications et les serveurs externes ; les connexions avec des tiers incluent toute API ou autre connexion avec des fintechs, des fournisseurs de technologie et des prestataires externalisés.
Ce que cela implique pour votre application mobile
Le texte cite les applications dans sa définition de la technologie externe : l'application mobile et les API qu'elle appelle entrent donc dans le périmètre d'évaluation, et les systèmes exposés au public relèvent de la fréquence la plus élevée.
Comment Ostorlab vous aide
Mobile Agentic Deep Scan teste la version publiée et les API qui la sous-tendent à chaque release, avec un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA. Il suit l'application dans ses connexions tierces en testant les services que l'application et ses SDK appellent.
Ce qui reste de votre ressort
Le programme d'évaluation, les scans des serveurs internes et des équipements réseau, et le plan de traitement des risques résiduels.
- CBB Rulebook Volume 1, OM-5.5.28 et OM-5.5.61
Réaliser des tests d'intrusion au moins deux fois par an
Ce que dit le texte
Tous les établissements agréés doivent réaliser des tests d'intrusion de leurs systèmes, de leurs applications et de leurs équipements réseau pour vérifier la robustesse des contrôles de sécurité en place, au moins deux fois par an. Ces tests doivent simuler de véritables cyberattaques, suivre une méthodologie fondée sur les risques et internationalement reconnue, comme le NIST ou l'OWASP, inclure à la fois des tests en grey box et en black box, être menés par des professionnels de la sécurité qualifiés et expérimentés, certifiés pour fournir des services de tests d'intrusion, être réalisés par des tiers internes et externes indépendants qui devraient être changés au moins tous les deux ans, et se dérouler sur l'environnement de production ou sur des répliques exactes hors production. Le rapport et les mesures d'atténuation doivent être conservés cinq ans et fournis à la CBB dans les deux mois suivant la fin du mois au cours duquel le test a eu lieu.
Ce que cela implique pour votre application mobile
Deux fois par an est un plancher, pas un plafond. Les versions mobiles sortent bien plus souvent, et l'application et les API qu'elle appelle figurent dans le périmètre.
Comment Ostorlab vous aide
Ostorlab intervient à chaque release entre les deux tests annuels, sur la version que téléchargent les clients, et couvre les tests en grey box derrière la connexion avec vos comptes de test. Vous obtenez un exploit, ou des preuves de requêtes et réponses, pour chaque résultat à intégrer au rapport.
Ce qui reste de votre ressort
Le choix et la rotation des testeurs indépendants, la méthodologie formelle, le rapport et la soumission à la CBB.
- CBB Rulebook Volume 1, OM-5.5.29 et OM-5.5.30
Red teaming lorsque la CBB l'exige
Ce que dit le texte
La CBB peut exiger des exercices de red teaming supplémentaires en tant que de besoin. Une red team est un groupe de hackers éthiques aux profils variés qui teste l'activité de réponse de la blue team de l'organisation ; elle peut attaquer sur les plans cyber, social et physique, et l'objectif est de tester les capacités de détection et de réponse, et non de trouver le plus de vulnérabilités possible. Lorsqu'un établissement a été tenu de réaliser un exercice de red teaming, les résultats doivent être fournis à la CBB dans le mois suivant la fin de l'exercice, accompagnés d'un plan complet de traitement des faiblesses constatées.
Ce que cela implique pour votre application mobile
Le red teaming est un exercice à l'échelle de l'institution, pas un test d'application. Il se déroule mieux lorsque les problèmes connus de l'application et des API sont déjà corrigés.
Comment Ostorlab vous aide
Ostorlab ne réalise pas de red teaming et ne le remplace pas. Il vous aide à corriger les problèmes connus de l'application et des API avant l'exercice, puis à retester les éléments application et API du plan de remédiation.
Ce qui reste de votre ressort
Le cadrage et la conduite de l'exercice, les volets social et physique, et le rapport à la CBB dans le mois.
- CBB Rulebook Volume 1, OM-5.5.18(d), (h) et (i)
Tester rigoureusement au stade du développement et après le déploiement
Ce que dit le texte
Les mesures préventives doivent inclure des tests de sécurité rigoureux au stade du développement logiciel ainsi qu'après le déploiement, afin de limiter le nombre de vulnérabilités, et la création d'une liste d'applications et de composants applicatifs en liste blanche, comme les bibliothèques et les fichiers de configuration, autorisés à être présents ou actifs sur les systèmes de l'organisation. Les solutions de gestion des appareils mobiles et les politiques BYOD doivent sécuriser tous les appareils mobiles ayant accès aux systèmes, aux applications et aux réseaux de la banque, par des mesures telles que le chiffrement, l'effacement à distance et l'imposition de mots de passe.
Ce que cela implique pour votre application mobile
Chaque version de l'application est un changement apporté à la technologie externe de la banque. Le texte demande de tester avant et après le déploiement, sur la version que les clients utilisent réellement.
Comment Ostorlab vous aide
Ostorlab lance des scans automatisés depuis votre pipeline CI/CD à chaque build et surveille les versions des stores sans déclenchement manuel. Mobile SAST travaille sur l'APK, l'AAB ou l'IPA, sans code source. L'inventaire SCA, c'est la liste des composants autorisés, preuves à l'appui.
Ce qui reste de votre ressort
La politique de développement sécurisé, les contrôles MDM et BYOD, et la liste des composants autorisés elle-même.
- CBB Rulebook Volume 1, OM-5.5.15(d), OM-5.5.27 et OM-5.5.4(e)
Gérer les vulnérabilités et les correctifs avec des délais
Ce que dit le texte
Disposer de processus de gestion des vulnérabilités et des correctifs, y compris des processus de remédiation, afin que les vulnérabilités identifiées soient traitées et que les correctifs de sécurité soient appliqués dans un délai proportionné aux risques que présente chaque vulnérabilité. La politique de cybersécurité doit couvrir la gestion des vulnérabilités, le développement sécurisé des applications et la gestion sécurisée des changements, et le conseil devrait recevoir les résultats des exercices de tests d'intrusion dans son reporting de cybersécurité.
Source :CBB Rulebook Volume 1, OM-5.5.15(d), OM-5.5.27 et OM-5.5.4(e)
Ce que cela implique pour votre application mobile
Les bibliothèques et les SDK intégrés à votre application sont des logiciels que vous livrez. Chacun a besoin d'une version connue, d'une gravité en cas de vulnérabilité et d'un délai de correction que vous pouvez prouver.
Comment Ostorlab vous aide
SCA identifie par empreinte les bibliothèques compilées statiquement et les associe aux vulnérabilités connues, version après version. Les résultats sont classés critiques, élevés, moyens ou faibles, suivis sous forme de tickets dans la plateforme ou dans Jira et ServiceNow, et retestés une fois le correctif livré.
Ce qui reste de votre ressort
La mise à jour des serveurs et de l'infrastructure, les contrats de maintenance des fournisseurs et les décisions d'acceptation des risques.
- CBB Rulebook Volume 1, OM-3.2.1, OM-3.2.2, OM-3.2.4 et OM-3.2.6
Utiliser l'authentification forte du client pour la banque électronique et l'EFTS
Ce que dit le texte
Les établissements doivent prendre des mesures appropriées pour authentifier l'identité et l'autorisation des clients, et utiliser des méthodes d'authentification des transactions prédéfinies qui favorisent la non-répudiation et établissent la responsabilité des transactions, avec des procédures détaillées pour identifier la personne à l'origine des virements électroniques et pour les rappels téléphoniques (call backs) le cas échéant. Le dispositif d'authentification forte du client doit garantir qu'aucune information sur ses éléments ne peut être déduite de la divulgation du code d'authentification, qu'aucun nouveau code ne peut être généré à partir de la connaissance d'un autre code déjà généré, et que le code ne peut pas être falsifié. L'authentification du client doit utiliser les trois éléments que sont la connaissance, la possession et l'inhérence.
Source :CBB Rulebook Volume 1, OM-3.2.1, OM-3.2.2, OM-3.2.4 et OM-3.2.6
Ce que cela implique pour votre application mobile
L'application collecte les facteurs, mais l'application effective doit se trouver côté serveur, y compris lorsque l'application ou un attaquant saute une étape.
Comment Ostorlab vous aide
Les tests authentifiés couvrent la connexion et la déconnexion, le renouvellement des jetons, les délais d'expiration, l'invalidation des sessions et l'authentification forte du client, y compris les parcours d'authentification renforcée et la manière dont les attaquants tentent de les manipuler, ainsi que les appels d'API qui les sous-tendent.
Ce qui reste de votre ressort
Le choix des méthodes et seuils d'authentification, et les procédures de rappel pour les virements électroniques.
- CBB Rulebook Volume 1, OM-3.1.2(b), (e) et (f) ; OM-3.3.1 à OM-3.3.6
Tester vos API et contrôler l'accès aux systèmes de banque électronique
Ce que dit le texte
Les politiques et procédures relatives à la banque électronique et aux virements électroniques doivent couvrir les tests des interfaces de programmation applicative (API), l'authentification des utilisateurs, la protection de la confidentialité des données clients conformément à la loi sur la protection des données personnelles, et une surveillance renforcée de la fraude sur les mouvements des comptes clients au moyen d'outils et de mesures tels que des limites de valeur, de volume et de vélocité. Les établissements doivent également garantir la séparation des tâches, des contrôles d'autorisation et des privilèges d'accès appropriés, l'intégrité des données, des pistes d'audit claires et la conservation des journaux pour les systèmes, bases de données et applications de banque électronique et d'EFTS.
Source :CBB Rulebook Volume 1, OM-3.1.2(b), (e) et (f) ; OM-3.3.1 à OM-3.3.6
Ce que cela implique pour votre application mobile
Les API qui sous-tendent l'application transportent les mêmes données que l'application. Le texte demande de les tester et d'en contrôler l'accès, avec les limites antifraude appliquées côté serveur.
Comment Ostorlab vous aide
Ostorlab intercepte le trafic de l'application, même avec TLS pinning, et teste les API pour détecter les autorisations défaillantes (BOLA, BFLA, IDOR), les usages abusifs de jetons et de sessions, et les abus comme l'énumération, le rejeu et l'automatisation, avec des preuves de requêtes et réponses pour chaque résultat.
Ce qui reste de votre ressort
Les règles et limites de surveillance de la fraude, la mise à jour des serveurs, et la piste d'audit et la conservation des journaux.
- CBB Rulebook Volume 1, OM-4.2.1, OM-4.5.4, OM-4.9.2, OM-3.3.9 et OM-3.3.10
Tester la continuité d'activité pour le canal mobile
Ce que dit le texte
Le plan de continuité d'activité doit couvrir la sauvegarde et la restauration des données, la poursuite des systèmes et activités critiques, des moyens de communication alternatifs et l'accès rapide des clients à leurs fonds en cas de perturbation. Les établissements doivent définir des objectifs de temps de reprise (RTO), des objectifs de point de reprise (RPO) et la durée maximale tolérable d'interruption pour les fonctions critiques, approuvés par la direction générale, et doivent tester leurs plans de continuité au moins une fois par an, y compris l'activation des sites alternatifs, les services de reprise fournis par les prestataires et la récupération des documents vitaux. Les systèmes de banque électronique doivent disposer de capacités, d'une continuité et d'une planification de contingence efficaces, et de plans de réponse aux incidents couvrant les attaques internes et externes.
Source :CBB Rulebook Volume 1, OM-4.2.1, OM-4.5.4, OM-4.9.2, OM-3.3.9 et OM-3.3.10
Ce que cela implique pour votre application mobile
L'application et ses API font partie du service critique que les clients utilisent pour accéder à leurs fonds. Leur comportement en cas de défaillance d'une dépendance peut être testé.
Comment Ostorlab vous aide
Ostorlab teste l'application et ses API pour les comportements qui nuisent à la disponibilité et à l'intégrité des données, notamment la gestion des erreurs, le comportement des sessions et les limites de logique métier, sur des environnements de préproduction ou proches de la production, avec des preuves à joindre à la revue du plan de continuité.
Ce qui reste de votre ressort
Le plan de continuité lui-même, les sites alternatifs, les sauvegardes, l'approbation des RTO et RPO, et le test annuel.
- Loi sur la protection des données personnelles (loi n° 30 de 2018), articles 8, 9, 12 et 13
Protéger les données personnelles au titre de la PDPL
Ce que dit le texte
Le responsable du traitement doit mettre en œuvre des mesures techniques et organisationnelles appropriées pour protéger les données personnelles contre la destruction accidentelle ou non autorisée, la perte accidentelle, l'altération ou la divulgation, et contre l'accès non autorisé ou toute autre forme de traitement non autorisé, en tenant compte des mesures de sécurité technologiques les plus récentes, du coût et des risques encourus. Ces mesures doivent être consignées et accessibles aux parties concernées. Le responsable du traitement doit choisir un sous-traitant offrant des garanties suffisantes et encadrer le traitement par un contrat écrit prévoyant des obligations équivalentes de sécurité et de confidentialité. Les données personnelles ne doivent pas être divulguées sans consentement, et les transferts hors du Royaume sont interdits sauf si le pays de destination offre une protection adéquate, si l'Autorité autorise le transfert, ou si une exemption prévue par la loi s'applique.
Source :Loi sur la protection des données personnelles (loi n° 30 de 2018), articles 8, 9, 12 et 13
Ce que cela implique pour votre application mobile
L'application stocke et transmet des données personnelles, et ses SDK les envoient souvent à des backends tiers. Ces flux nécessitent les mêmes mesures techniques et organisationnelles et la même discipline de transfert.
Comment Ostorlab vous aide
Ostorlab recherche les jetons de session et les données personnelles dans le stockage local, les caches, les journaux et les captures d'écran, vérifie les protections du transport et cartographie les backends tiers avec lesquels l'application et ses SDK échangent des données.
Ce qui reste de votre ressort
Le programme de protection des données, le guardian des données personnelles, les registres de traitement et les autorisations de transfert.
- CBB Rulebook Volume 1, OM-5.5.57 et OM-5.5.58
Signaler à la CBB les incidents cyber graves dans l'heure
Ce que dit le texte
En cas de survenance ou de détection d'un incident de cybersécurité, interne ou externe, compromettant des informations clients ou perturbant des services critiques affectant les opérations, les établissements doivent contacter la CBB immédiatement, dans l'heure, et soumettre la section A du rapport d'incident de cybersécurité dans les deux heures. La section B suit dans les 10 jours calendaires suivant l'incident, avec l'analyse complète des causes racines, l'impact sur les opérations et les clients, et toutes les mesures prises pour arrêter l'attaque et éviter sa récurrence, ainsi qu'une mise à jour hebdomadaire de l'avancement jusqu'à la résolution complète de l'incident.
Ce que cela implique pour votre application mobile
De la détection à la notification, la course se joue en une heure. Savoir exactement ce que l'attaquant pouvait faire dans votre application et vos API est ce dont la section d'analyse des causes racines a besoin.
Comment Ostorlab vous aide
Ostorlab ne déclare pas les incidents à la CBB et ne joue pas le rôle de votre SOC. Il fournit des exploits et des preuves de requêtes et réponses pour vos résultats d'application et d'API, qui étayent l'analyse des causes racines du rapport.
Ce qui reste de votre ressort
Le processus de réponse aux incidents, l'appel à la CBB dans l'heure, les sections du rapport et les mises à jour hebdomadaires.
Synthèse des textes publics de la CBB, vérifiés le 27 septembre 2026. Le module de gestion du risque opérationnel a été mis à jour pour la dernière fois en mai 2026. Cette page ne constitue pas un avis juridique.
Les règles de la CBB, contrôle par contrôle
Les contrôles visés par les textes de la CBB, la manière dont Ostorlab les teste dans votre application et ses API, et les preuves que vous pouvez conserver.
| Contrôle | Comment Ostorlab vous aide | Preuves conservées |
|---|---|---|
| Évaluations techniques des applications, des systèmes externes et des connexions tiercesOM-5.5.25, 5.5.26 | Pentest par agents IA de l'application et de ses API, derrière la connexion, sur la version que vous livrez, y compris les services qu'appellent l'application et ses SDK. Détails | Un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA, et une heatmap de couverture |
| Tests d'intrusion au moins deux fois par an, en grey box et black boxOM-5.5.28 | Pentest par agents IA de l'application et de ses API, derrière la connexion, ainsi qu'une analyse des interactions entre l'application, ses SDK et le backend. Détails | Un exploit fonctionnel ou une requête validée pour chaque résultat du rapport de tests d'intrusion |
| Tests de sécurité au stade du développement et après le déploiementOM-5.5.18(d) | Mobile SAST et DAST dans le CI/CD à chaque build, et surveillance des versions publiées sur les stores. Détails | Résultats de scan par build et par version publiée |
| Composants et bibliothèques applicatifs autorisésOM-5.5.18(h) | Recense les SDK et les bibliothèques natives de chaque version avec leurs versions, et montre à quels backends l'application et ses SDK s'adressent. Détails | Identité, version et emplacement du composant dans le bundle de l'application, par version |
| Délais de correction des vulnérabilitésOM-5.5.27 | Identifie par empreinte les bibliothèques compilées statiquement et les associe aux vulnérabilités connues, version après version. Détails | Vulnérabilités cartographiées avec recommandations de mise à jour ou de remplacement, et clôture suivie entre les versions |
| Authentification forte du client et authentification des transactionsOM-3.2.4, 3.2.6 | Se connecte avec des codes à usage unique et teste l'application de l'authentification du client, les parcours d'authentification renforcée et les appels d'API qui les sous-tendent. Détails | Résultats sur la connexion et les parcours d'authentification renforcée, avec étapes de reproduction |
| Tests d'API et contrôles d'autorisationOM-3.1.2(b), OM-3.3.1, 3.3.2 | Intercepte le trafic même avec TLS pinning et teste les autorisations, les usages abusifs de jetons et les abus comme l'énumération et le rejeu. Détails | Preuves de requêtes et réponses pour chaque résultat d'API |
| Confidentialité des données clients dans l'application et en transitPDPL art. 8, 9 ; OM-3.3.6 | Recherche les jetons et les données personnelles dans le stockage, les caches, les journaux et les captures d'écran, et vérifie la protection du transport. Détails | Preuves sur le système de fichiers montrant ce qui a été écrit, où et quand |
| Identifiants et clés dans le package de l'applicationOM-3.3.2 ; PDPL art. 8 | Détecte les clés d'API, les jetons et les identifiants dans le package de l'application et vérifie s'ils fonctionnent. Détails | Secrets validés, avec les permissions et les services qu'ils exposent |
| Préparation à la reprise et preuves d'incidentOM-4.9.2 ; OM-5.5.57 | Reteste après chaque correction, afin que l'état de l'application et des API soit documenté avant un test de continuité ou un post-mortem d'incident. | Historique des tickets et résultats de retest à joindre à la revue de continuité ou au rapport d'incident |
Ostorlab teste les contrôles dans l'application et ses API. La surveillance du SOC, la déclaration des incidents à la CBB, le red teaming, la continuité d'activité, les sauvegardes et la reprise, la gouvernance et la sécurité physique restent du ressort de vos équipes.
Les contrôles de la CBB à tester dans votre application mobile
Une liste pratique pour les équipes sécurité et risque opérationnel, fondée sur le module OM et la loi sur la protection des données personnelles.
Périmètre d'évaluation
Inscrivez l'application mobile, ses API et les connexions tierces dans le périmètre de vos évaluations techniques, avec la fréquence resserrée que le texte prévoit pour les systèmes exposés au public.
Tests d'intrusion semestriels
Planifiez deux tests d'intrusion par an avec une couverture grey box et black box, des testeurs certifiés et un prestataire indépendant renouvelé au moins tous les deux ans.
Rapport à la CBB
Conservez chaque rapport de tests d'intrusion et ses mesures d'atténuation pendant cinq ans, et transmettez le rapport dans les deux mois suivant le mois du test.
CI/CD et versions des stores
Lancez des tests de sécurité automatisés à chaque build et scannez la version publiée sur le store, pas seulement celle testée le trimestre dernier.
Composants et délais
Tenez une liste versionnée des SDK et des bibliothèques de chaque version, et fixez des délais de remédiation par gravité.
Authentification
Vérifiez l'authentification forte du client et l'authentification des transactions côté serveur, y compris les codes à usage unique, les parcours d'authentification renforcée et les trois éléments connaissance, possession et inhérence.
Données sur l'appareil
Vérifiez le package de l'application pour les clés et identifiants, recherchez les données personnelles dans le stockage, les caches, les journaux et les captures d'écran, et examinez les transferts hors du Royaume au regard de la PDPL.
Exercice d'incident et de continuité
Entraînez-vous à l'appel à la CBB dans l'heure et au rapport d'incident, tenez le journal des incidents et testez le plan de continuité au moins une fois par an.
Une liste indicative, et non un modèle de la CBB. Ceci ne constitue pas un avis juridique.
Les capacités associées à cette page
Chacune a sa propre page détaillée.
- Mobile Agentic Deep ScanDes agents IA pentestent la version publiée à chaque release, avec un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA.En savoir plus
- Tests authentifiésTestez la connexion, les codes à usage unique et les parcours d'authentification renforcée avec vos comptes de test.En savoir plus
- Tests des API et du backendInterceptez le trafic de l'application même avec TLS pinning, puis testez les API et backends derrière les comptes et les paiements.En savoir plus
- Mobile SASTAnalyse statique des binaires APK, AAB et IPA, avec analyse de propagation (taint) sur l'application et ses SDK intégrés.En savoir plus
- SCA et SBOMDétectez les dépendances vulnérables, y compris les bibliothèques natives compilées statiquement, et suivez leur résolution version après version.En savoir plus
- Mobile Shielding ScanTestez à l'exécution la détection du root et du jailbreak, l'anti-altération et le pinning, et voyez quelles protections ont tenu et lesquelles ont été contournées.En savoir plus
- Votre propre clé IALancez les scans par agents IA avec la clé de votre fournisseur d'IA et un plafond de dépense par scan, pour respecter vos politiques internes.En savoir plus
- Scan on-premisesScannez les applications de préproduction, API et dépôts derrière votre pare-feu ou VPN, sur une infrastructure que vous contrôlez.En savoir plus
Des banques et fintechs nous font confiance, dont
Sources
Les textes officiels sur lesquels s'appuie cette page, vérifiés le 27 septembre 2026.
- CBB Rulebook Volume 1 : banques conventionnelles, module OM de gestion du risque opérationnelBanque centrale de Bahreïn, partie A Business Standards. Le module OM a été révisé en janvier 2020 et mis à jour pour la dernière fois en mai 2026. Il contient les chapitres sur la banque électronique, la continuité d'activité et la cybersécurité applicables aux banques conventionnelles agréées
- OM-5.5 Cyber Security Risk ManagementCBB Rulebook Volume 1. Ajoutée comme nouvelle section renforcée en juillet 2021. Évaluations techniques (OM-5.5.25, OM-5.5.26), gestion des vulnérabilités et des correctifs (OM-5.5.27), tests d'intrusion au moins deux fois par an (OM-5.5.28), red teaming (OM-5.5.29, OM-5.5.30), notification des incidents (OM-5.5.57, OM-5.5.58) et conservation cinq ans et transmission sous deux mois du rapport de tests d'intrusion (OM-5.5.61)
- OM-3 Electronic Money and Electronic Banking ActivitiesCBB Rulebook Volume 1. Gouvernance, tests des interfaces de programmation applicative, confidentialité des données conforme à la PDPL et surveillance de la fraude (OM-3.1.2) ; authentification sécurisée, y compris l'authentification forte du client et les trois éléments d'authentification (OM-3.2) ; séparation des tâches, privilèges d'accès, pistes d'audit et continuité pour les systèmes de banque électronique et de virement électronique (OM-3.3)
- OM-4 Business Continuity ManagementCBB Rulebook Volume 1. Contenu du plan de continuité d'activité (OM-4.2.1), objectifs de temps de reprise, objectifs de point de reprise et durée maximale tolérable d'interruption (OM-4.5.4), et test du plan de continuité au moins une fois par an (OM-4.9.2)
- Annexe C : lignes directrices de contrôle de cybersécuritéCBB Rulebook Volume 1. Ajoutée en juillet 2021. Lignes directrices de contrôle fondées sur le cadre de cybersécurité du NIST, organisées en Identifier, Protéger, Détecter, Répondre et Récupérer, utilisées comme référence pour la stratégie et la politique de cybersécurité
- Loi sur la protection des données personnelles (loi n° 30 de 2018)Royaume de Bahreïn, promulguée le 12 juillet 2018, en vigueur depuis 2019. Sécurité du traitement (article 8), confidentialité (article 9), guardian des données personnelles (article 10) et transferts hors du Royaume (articles 12 et 13). Le texte anglais publié par l'Autorité de protection des données personnelles est une traduction ; le texte arabe prévaut
- Consultations de la CBB : projet de module d'exigences pour les services de paiementBanque centrale de Bahreïn, consultation clôturée le 5 mars 2026. Une proposition, non en vigueur, portant sur un nouveau cadre pour les services de paiement. Les règles d'authentification de la banque électronique du module OM s'appliquent en attendant
Questions fréquentes
Des réponses claires sur la couverture, la mise en place et la façon dont les résultats parviennent à vos équipes.
Vous ne trouvez pas votre réponse ? Réservez une démo ou contactez-nous.
Évaluez votre application bancaire mobile comme le décrit la CBB
Commencez par un scan gratuit de votre application depuis le store, ou réservez une démo pour lancer des tests authentifiés de votre application et de vos API avec notre équipe.