Cybersécurité selon la CBK : testez votre application bancaire mobile et les API qui la sous-tendent.
La Guidance Note on Cybersecurity de la Central Bank of Kenya (CBK) de 2017 demande aux banques de réaliser un test indépendant des cybermenaces au moins une fois par an, et inscrit les évaluations des menaces et vulnérabilités et les tests d'intrusion complets dans le périmètre de l'audit interne et externe. Sa directive de 2019 pour les prestataires de services de paiement fixe des scans de vulnérabilité trimestriels et un test d'intrusion annuel. La loi sur la protection des données de 2019 exige des garanties dès la conception et par défaut. Ostorlab teste votre application et les API qui la sous-tendent, derrière la connexion, à chaque version.
- Teste l'application mobile et les API qu'elle appelle, sur le build que téléchargent vos clients
- Teste la connexion, les codes à usage unique, les vérifications d'authentification renforcée et la gestion des sessions avec vos comptes de test
- Recense les SDK et bibliothèques natives de chaque version et les rapproche des vulnérabilités connues
- Prouve chaque résultat par un exploit rejouable ou par les requêtes et réponses à l'appui
- Qui est concerné
- Les banques agréées au titre du Banking Act et les prestataires de services de paiement autorisés au titre du National Payment System Act de 2011
- Date clé
- Guidance Note on Cybersecurity publiée en août 2017 ; directive pour les prestataires de services de paiement en juillet 2019 ; la CBK met à jour les orientations de 2017
- Objet
- Test indépendant des cybermenaces, évaluation des vulnérabilités et tests d'intrusion, risque lié aux tiers et protection des données
- Texte de référence
- Guidance Note on Cybersecurity for the Banking Sector de la CBK, août 2017
Les textes de la CBK qui encadrent votre canal mobile
Les orientations bancaires de 2017, la directive pour les prestataires de services de paiement et les règles du National Payment System complètent la loi sur la protection des données. Les dates ci-dessous concernent les textes et les évolutions cités sur cette page.
- 2011 et 2014
National Payment System Act et Regulations
Le National Payment System Act (loi n° 39 de 2011) confie à la CBK la surveillance du système de paiement et le pouvoir d'émettre des directives et des lignes directrices. Les règlements de 2014 ajoutent, pour les prestataires de services de paiement, des obligations d'exploitation, de piste d'audit, de reporting et d'audit annuel de la sécurité du système.
- Janvier 2013
Risk Management Guidelines
La CBK publie ses lignes directrices sur la gestion des risques. La section 7 traite du risque ICT, notamment des scanners de vulnérabilité et des tests d'intrusion comme outils d'identification des vulnérabilités, et du programme de sécurité de l'information.
- Août 2017
Guidance Note on Cybersecurity
La CBK publie la Guidance Note on Cybersecurity for the Banking Sector en vertu de l'article 33(4) du Banking Act. Elle exige un test indépendant des cybermenaces au moins une fois par an, inscrit les évaluations des menaces et vulnérabilités et les tests d'intrusion complets dans le périmètre de l'audit, et impose de signaler à la CBK les incidents significatifs dans les 24 heures.
- Juillet 2019
Directive pour les prestataires de services de paiement
La CBK publie la Guideline on Cybersecurity for Payment Service Providers. Elle fixe des scans de vulnérabilité trimestriels des actifs cybernétiques critiques, un test d'intrusion annuel et des évaluations de vulnérabilité semestrielles, avec 90 jours pour se mettre en conformité.
- Mars 2025
Enquête sur l'adoption
La CBK enquête sur l'adoption de la Guidance Note de 2017 par les banques. Tous les répondants ont indiqué réaliser des évaluations de vulnérabilité et des tests d'intrusion, à un rythme annuel, trimestriel ou mensuel, et 92 % disposaient d'auditeurs informatiques dans leur équipe d'audit interne. Le rapport est publié en juin 2025.
- 22 septembre 2025
SOC du secteur bancaire
La CBK annonce le Banking Sector Cyber Security Operations Centre, rattaché à sa Cyber Fusion Unit, et commence à aligner les orientations de 2017 et 2019 sur le règlement de 2024 relatif aux infrastructures d'information critiques. Les institutions doivent continuer à respecter les deux ensembles d'exigences et signaler les incidents au centre.
- 22 septembre 2026
Orientations en cours de révision
Le rapport annuel de supervision bancaire 2025 indique que la CBK a engagé la mise à jour de la Guidance Note de 2017. Les banques interrogées ont demandé que la sécurité des API, l'intelligence artificielle, le cloud et la détection de la fraude sur le mobile money y soient traités.
- Septembre 2026
Projets de textes soumis à commentaires
La CBK publie le 10 septembre 2026 des projets révisés de Prudential Guidelines, de Risk Management Guidelines et de Guidance Notes pour commentaires, et le Trésor national et la CBK publient le 21 septembre 2026 le projet de National Payment System Policy and Bill 2026. Ce sont des projets, pas encore en vigueur.
Les textes de la CBK, appliqués à 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.
- Guidance Note on Cybersecurity for the Banking Sector, août 2017, section 3.2
Réaliser un test indépendant des cybermenaces au moins une fois par an
Ce que dit le texte
Les institutions devraient faire appel à des consultants externes disposant d'une expertise suffisante en cybersécurité pour les aider à comprendre leur paysage de cybermenaces, et devraient réaliser un test indépendant des cybermenaces au moins une fois par an. Les auditeurs externes devraient réaliser des évaluations indépendantes des menaces et vulnérabilités et des tests d'intrusion complets dans le cadre du périmètre de l'audit informatique, et rendre compte annuellement au conseil et à la Central Bank of Kenya des résultats.
Source :Guidance Note on Cybersecurity for the Banking Sector, août 2017, section 3.2
Ce que cela implique pour votre application mobile
Le test annuel est un minimum, pas un plafond. L'application et les API qu'elle appelle font partie des systèmes concernés, et chaque version publiée sur les stores les modifie.
Comment Ostorlab vous aide
Un pentest par agents IA teste l'application et ses API derrière la connexion, sur la version que vous livrez, avec un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA. Il peut s'exécuter à chaque version, entre les tests annuels.
Ce qui reste de votre ressort
Le choix des consultants externes, le périmètre de l'audit, et le rapport annuel au conseil et à la CBK.
- Guidance Note on Cybersecurity for the Banking Sector, section 3.2 (fonctions d'audit interne et de gestion des risques)
Inscrire les tests de menaces et de vulnérabilités dans le périmètre de l'audit
Ce que dit le texte
L'audit interne devrait inclure des auditeurs ICT qualifiés, en interne ou externalisés. Leur périmètre comprend l'examen et le reporting continus des cyberrisques et des contrôles des systèmes ICT et des connexions tierces associées, l'évaluation de la conception et de l'efficacité du dispositif de cybersécurité, la réalisation régulière d'évaluations indépendantes des menaces et vulnérabilités, la réalisation de tests d'intrusion complets, et le reporting des résultats au conseil. La gestion des risques devrait tenir un registre des cyberrisques et un inventaire complet des actifs informatiques classés par criticité métier, et mener des exercices de red team.
Ce que cela implique pour votre application mobile
Le périmètre de l'audit mentionne les connexions tierces. Pour une application bancaire mobile, cela signifie l'application, les SDK qu'elle embarque et les API qu'elle appelle, pas seulement le système bancaire central.
Comment Ostorlab vous aide
Mobile DAST exécute l'application et ses parcours et fournit des résultats avec le contexte du code décompilé, le trafic, les traces d'exécution et des captures d'écran, pour donner à l'équipe d'audit des preuves exploitables.
Ce qui reste de votre ressort
Le plan d'audit, l'exercice de red team, et les résultats présentés au conseil.
- Guideline on Cybersecurity for Payment Service Providers, juillet 2019, sections 3.2.5 et 4.0
Respecter la cadence de tests des prestataires de services de paiement
Ce que dit le texte
La Guideline on Cybersecurity for Payment Service Providers de 2019 exige un programme de cybersécurité avec une surveillance continue et des tests d'intrusion et évaluations de vulnérabilité périodiques. En l'absence de surveillance continue efficace, les prestataires devraient réaliser des scans de vulnérabilité trimestriels de tous les actifs cybernétiques critiques, un test d'intrusion annuel couvrant au moins les actifs cybernétiques critiques déterminés pour l'année à partir de l'évaluation des risques, et des évaluations de vulnérabilité semestrielles. Les prestataires disposaient de 90 jours à compter de la date d'effet de la directive pour s'y conformer.
Source :Guideline on Cybersecurity for Payment Service Providers, juillet 2019, sections 3.2.5 et 4.0
Ce que cela implique pour votre application mobile
Si votre institution ou votre groupe exploite un service de paiement, la cadence est celle des scans trimestriels, d'un test d'intrusion annuel et d'évaluations semestrielles. Le canal mobile et les API qui le sous-tendent sont des actifs cybernétiques critiques.
Comment Ostorlab vous aide
Ostorlab s'exécute depuis votre pipeline CI/CD à chaque build et peut scanner les versions publiées sur les stores sans déclenchement manuel : un rythme trimestriel ou plus fréquent devient une planification, pas un projet.
Ce qui reste de votre ressort
La définition de ce qui constitue un actif cybernétique critique, la surveillance continue, et l'évaluation des risques qui détermine le périmètre annuel.
- National Payment System Regulations, 2014, règlements 27 et 29
Sécuriser le service de paiement et tenir la piste d'audit
Ce que dit le texte
Les prestataires de services de paiement doivent mettre en place des dispositions opérationnelles adéquates pour leurs services, y compris des mesures assurant la sûreté, la sécurité et la fiabilité opérationnelle du service et des dispositions de continuité. Ils doivent utiliser des systèmes offrant une piste d'audit précise et entièrement accessible des transactions, de leur origine à leur finalité, conserver les enregistrements de chaque virement électronique pendant au moins sept ans, déclarer chaque mois à la Central Bank of Kenya les incidents de fraude et les interruptions de service matérielles ou les violations de sécurité majeures, et fournir chaque année un rapport d'audit de la sécurité du système établi par un cabinet d'audit indépendant réputé.
Source :National Payment System Regulations, 2014, règlements 27 et 29
Ce que cela implique pour votre application mobile
La piste d'audit, la conservation sur sept ans et le rapport mensuel relèvent du prestataire. L'application et ses API sont le point de départ des transactions : leur comportement fait partie des preuves.
Comment Ostorlab vous aide
Ostorlab teste l'application et ses API et conserve les requêtes et réponses à l'appui de chaque résultat, prêtes à être jointes à l'audit annuel de la sécurité du système et au suivi des corrections.
Ce qui reste de votre ressort
La conservation des enregistrements, les rapports mensuels à la CBK, et la désignation du cabinet d'audit indépendant.
- Guidance Note on Cybersecurity for the Banking Sector, sections 2.4 et 3.1
Déployer une authentification forte pour les données et les transactions des clients
Ce que dit le texte
La direction générale devrait superviser le déploiement de mesures d'authentification fortes pour protéger les données, les transactions et les systèmes des clients. La Guidance Note cite les contrôles d'authentification insuffisants parmi les sources de cyberrisque, et attend du CISO qu'il veille à ce que l'institution maintienne une base de connaissances actualisée à l'échelle de l'entreprise sur ses utilisateurs, ses appareils et ses applications, y compris l'inventaire des logiciels et du matériel et les cartographies réseau.
Source :Guidance Note on Cybersecurity for the Banking Sector, sections 2.4 et 3.1
Ce que cela implique pour votre application mobile
Le second facteur doit être imposé par le serveur lors des opérations clés, et pas seulement affiché par l'application. Les codes à usage unique, les délais d'expiration et les vérifications d'authentification renforcée sont des comportements testables.
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'application effective de la MFA, y compris les parcours d'authentification renforcée, avec vos comptes de test.
Ce qui reste de votre ressort
Le choix des méthodes d'authentification, l'envoi des codes à usage unique, et l'assistance aux clients verrouillés.
- Guidance Note on Cybersecurity, section 3.3 ; Prudential Guidelines, CBK/PG/16 sur l'externalisation, sections 4.1.4 et 4.5
Gérer les tiers et l'externalisation
Ce que dit le texte
Les institutions devraient s'assurer que leurs tiers respectent les cadres légaux et réglementaires et les bonnes pratiques internationales. Elles devraient disposer d'une gouvernance adéquate des accords d'externalisation, incluant la diligence raisonnable sur les prestataires pressentis, des accords documentés et un suivi adéquat de la prestation ; sélectionner les fournisseurs sur la base d'évaluations de conformité et de risque ; exiger des prestataires qu'ils respectent les cadres légaux et réglementaires applicables ; les surveiller pour détecter les changements dans leur activité et leur posture cyber ; et prévoir des accords de niveau de service avec des dispositions solides en matière de sécurité, de disponibilité, d'indicateurs de performance et de pénalités. Au titre de la Prudential Guideline CBK/PG/16, l'externalisation matérielle nécessite l'approbation de la Central Bank of Kenya, et la fourniture de canaux ou de technologies de services financiers mobiles est citée comme exemple d'activité matérielle.
Ce que cela implique pour votre application mobile
Les SDK de votre application et les backends qu'ils appellent sont des tiers. Leur posture de sécurité fait partie de votre diligence et de votre surveillance, et certaines externalisations nécessitent l'approbation préalable de la CBK.
Comment Ostorlab vous aide
SCA et SBOM recensent les SDK et bibliothèques natives de chaque version avec leurs versions, et l'analyse réseau montre avec quels backends communiquent l'application et ses SDK.
Ce qui reste de votre ressort
La diligence raisonnable, les contrats, les approbations de la CBK, et les plans de sortie.
- Risk Management Guidelines, janvier 2013, sections 7.3.4, 7.4 et 7.5
Mettre en place un cadre de risque ICT et tester avec les bons outils
Ce que dit le texte
Les Risk Management Guidelines exigent un cadre de gestion du risque ICT avec une supervision du conseil, une politique de risque ICT et un programme de sécurité de l'information qui promeut la sensibilisation et rend compte au conseil de l'évaluation de la sécurité de l'information. Pour identifier les vulnérabilités, les lignes directrices citent les scanners de vulnérabilité, qui comparent un système ou ses réponses à une base de signatures de failles, et les tests d'intrusion, une tentative d'analystes de sécurité humains d'exercer des menaces contre un système, y compris des vulnérabilités opérationnelles comme l'ingénierie sociale. Les risques sont évalués, mesurés, atténués et documentés.
Source :Risk Management Guidelines, janvier 2013, sections 7.3.4, 7.4 et 7.5
Ce que cela implique pour votre application mobile
Les scanners et les tests d'intrusion sont les deux outils nommés pour trouver les vulnérabilités. Une application mobile a besoin des deux : l'analyse du build et les tests dynamiques de l'application en exécution et de ses API.
Comment Ostorlab vous aide
Mobile SAST analyse l'APK, l'AAB ou l'IPA avec une analyse de propagation (taint) sur l'application et ses SDK intégrés, et Mobile DAST exécute l'application. Les deux s'exécutent dans la CI/CD à chaque build.
Ce qui reste de votre ressort
La politique de risque ICT, le reporting au conseil, et le programme de sécurité de l'information dans son ensemble.
- Data Protection Act, 2019, sections 41 et 42 ; Data Protection (General) Regulations, 2021, règlement 32
Protéger les données personnelles dès la conception et par défaut
Ce que dit le texte
La loi sur la protection des données de 2019 impose à chaque responsable de traitement ou sous-traitant de mettre en œuvre des mesures techniques et organisationnelles appropriées conçues pour appliquer effectivement les principes de protection des données et intégrer les garanties nécessaires au traitement, aussi bien au moment de la détermination des moyens du traitement qu'au moment du traitement. Par défaut, seules les données personnelles nécessaires à chaque finalité spécifique devraient être traitées. Les mesures à envisager comprennent l'identification des risques internes et externes pesant sur les données personnelles, le maintien de garanties contre ces risques, la pseudonymisation et le chiffrement, le rétablissement de la disponibilité après un incident, la vérification de l'efficacité des garanties et leur mise à jour face aux nouveaux risques ou manquements. Lorsque le traitement implique une transmission sur un réseau, le responsable doit tenir compte de l'état de la technologie, du coût des mesures, des risques particuliers et de la nature des données. Les règlements généraux énumèrent les éléments du principe d'intégrité, de confidentialité et de disponibilité, notamment l'évaluation des risques pesant sur la sécurité des données personnelles, les pistes d'audit et la surveillance des événements, et l'examen et le test réguliers des logiciels pour détecter les vulnérabilités des systèmes qui soutiennent le traitement.
Ce que cela implique pour votre application mobile
L'application est le lieu où les données personnelles sont collectées, stockées et envoyées. Les choix de conception, comme ce qui est mis en cache, comment c'est chiffré et ce qui est journalisé, font partie des mesures demandées par la loi.
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 la protection du transport, et détecte les clés d'API, jetons et identifiants dans le package de l'application en vérifiant s'ils sont fonctionnels.
Ce qui reste de votre ressort
Les analyses d'impact sur la protection des données, le consentement, les règles de conservation, et le traitement des violations.
- Guidance Note on Cybersecurity, partie IV ; Data Protection Act 2019, section 43 ; National Payment System Regulations, 2014, règlement 29(2)
Signaler les incidents et tenir le registre
Ce que dit le texte
La Guidance Note impose aux institutions de notifier à la Central Bank of Kenya, dans les 24 heures, tout incident de cybersécurité susceptible d'avoir un impact significatif et défavorable sur la capacité de l'institution à fournir des services adéquats à ses clients, sur sa réputation ou sur sa situation financière, et de soumettre un rapport trimestriel sur les incidents et leur traitement. La loi sur la protection des données impose au responsable du traitement de notifier au Data Commissioner sans délai et dans les 72 heures la survenance d'un accès ou d'une acquisition non autorisés de données personnelles présentant un risque réel de préjudice pour la personne concernée, et de communiquer par écrit avec elle ; le sous-traitant doit notifier le responsable sans délai et, lorsque cela est raisonnablement possible, dans les 48 heures. Les prestataires de services de paiement déclarent également chaque mois à la CBK les interruptions de service matérielles et les violations de sécurité majeures.
Ce que cela implique pour votre application mobile
Le signalement des incidents vous incombe, mais le compte à rebours commence dès la détection. Les tests vous aident à trouver et corriger les problèmes avant qu'ils ne deviennent des événements à déclarer.
Comment Ostorlab vous aide
Ostorlab fournit les preuves techniques et les étapes de reproduction de chaque résultat, et reteste après correction, pour que le registre soit complet au moment de votre déclaration.
Ce qui reste de votre ressort
La détection, les rapports à 24 heures, à 72 heures et mensuels, et la communication avec les clients.
Synthèse des textes publics de la CBK et de l'ODPC, vérifiés le 27 septembre 2026. Les projets de textes soumis à consultation ne sont pas traités comme des exigences sur cette page. Cette page ne constitue pas un avis juridique.
Les règles de la CBK, contrôle par contrôle
Les contrôles visés par les textes de la CBK et de l'ODPC, 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 |
|---|---|---|
| Test indépendant des cybermenaces, au moins une fois par anGuidance Note 3.2 | Pentest par agents IA de l'application et de ses API, derrière la connexion, sur la version que vous livrez. Détails | Un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA, et une heatmap de couverture |
| Évaluations des menaces et vulnérabilités et tests d'intrusion completsGuidance Note 3.2 | Mobile DAST exécute la version et ses parcours, avec des résultats associés au contexte décompilé, au trafic, aux traces d'exécution et à des captures d'écran. Détails | Résultats avec le contexte du code décompilé, le trafic, les traces d'exécution et des captures d'écran |
| Scans trimestriels, test d'intrusion annuel et évaluations semestrielles pour les prestataires de services de paiementDirective PSP 3.2.5 | Intercepte le trafic même avec TLS pinning et teste les autorisations, les usages abusifs des jetons et les abus comme l'énumération et le rejeu. Détails | Requêtes et réponses à l'appui de chaque résultat d'API, et résultats de scan par cycle |
| Sûreté, sécurité et fiabilité opérationnelle du service de paiementNPS Regulations, règlement 27 | Teste les parcours applicatifs et d'API qui composent le service client, y compris la gestion des pannes et des erreurs. | Preuves de test à joindre au rapport annuel d'audit de la sécurité du système |
| Piste d'audit, enregistrements et reportingNPS Regulations, règlement 29 | Regroupe les résultats en tickets dans la plateforme ou dans Jira et ServiceNow, et reteste après correction. | Historique des tickets et résultat du retest pour chaque résultat |
| Authentification forte pour les données et les transactions des clientsGuidance Note 3.1(b)(v) | Se connecte avec des codes à usage unique et teste l'application effective de la MFA, les parcours d'authentification renforcée et les appels d'API qui les sous-tendent. Détails | Résultats sur les parcours de connexion et d'authentification renforcée, avec étapes de reproduction |
| Risque lié aux tiers et à l'externalisationGuidance Note 3.3 ; CBK/PG/16 | Recense les SDK et bibliothèques natives de chaque version avec leurs versions, et montre avec quels backends l'application et ses SDK communiquent. Détails | Identité, version et emplacement de chaque composant dans le bundle de l'application, par version |
| Cadre de risque ICT et identification des vulnérabilitésRisk Management Guidelines 7.3.4 | Mobile SAST analyse le binaire avec une analyse de propagation (taint) sur l'application et ses SDK intégrés. Détails | Résultats avec le contexte du code décompilé, par build |
| Données personnelles sur l'appareil et en transitData Protection Act, section 41 | 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 |
| Examen et test réguliers des logiciels pour détecter les vulnérabilitésDP General Regulations 32(k) | Analyse statique des binaires APK, AAB et IPA, dans la CI/CD à chaque build. Détails | Résultats de scan par build, avec le contexte du code décompilé |
Ostorlab teste les contrôles de l'application et de ses API. La surveillance SOC, la détection des incidents et les rapports à la CBK, au Data Commissioner ou au BS-SOC, la continuité et la reprise, l'opinion de l'audit annuel de sécurité du système, la gouvernance et la sécurité physique restent du ressort de vos équipes.
Les contrôles de la CBK à tester dans votre application mobile
Une liste pratique pour les équipes sécurité et audit, fondée sur la Guidance Note de 2017, la directive pour les prestataires de services de paiement et la loi de 2019 sur la protection des données.
Test indépendant annuel
Inscrivez l'application mobile et les API qu'elle appelle dans le périmètre du test indépendant annuel des cybermenaces, et testez à chaque version entre les audits.
Périmètre d'audit et de risque
Incluez l'application et ses connexions tierces dans le périmètre de l'audit interne : évaluations des menaces et vulnérabilités, tests d'intrusion complets et preuves pour le conseil.
Cadence des services de paiement
Si votre groupe exploite un service de paiement, planifiez des scans de vulnérabilité trimestriels, un test d'intrusion annuel et des évaluations de vulnérabilité semestrielles des actifs cybernétiques critiques.
Authentification et sessions
Testez la connexion, les codes à usage unique, les vérifications d'authentification renforcée, les délais d'expiration et l'invalidation des sessions, avec les contrôles imposés côté serveur.
Tiers et SDK
Tenez une liste versionnée des SDK et des backends de chaque version, et vérifiez si un accord d'externalisation nécessite l'approbation de la CBK avant sa mise en place.
Données sur l'appareil
Recherchez les jetons et les données personnelles dans le stockage, les caches, les journaux et les captures d'écran, ainsi que dans le package de l'application.
Protection des données dès la conception
Passez en revue les sections 41 et 42 pour l'application : ce qui est collecté, ce qui est mis en cache, comment c'est chiffré, et comment vous vérifiez les garanties.
Signaler et retester
Connaissez les délais de 24 heures pour la CBK et de 72 heures pour le Data Commissioner, conservez les preuves techniques et retestez après correction.
Une liste indicative, et non un modèle de la CBK. 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.
- National Payment System Act, No. 39 of 2011, and National Payment System Regulations, 2014La loi confie à la Central Bank of Kenya la surveillance du système de paiement national et le pouvoir d'émettre des directives et des lignes directrices. Les règlements de 2014 imposent aux prestataires de services de paiement de maintenir des services sûrs, sécurisés et fiables (règlement 27), de tenir une piste d'audit et de conserver les enregistrements pendant au moins sept ans (règlement 29(1)), de déclarer chaque mois les interruptions de service matérielles et les violations de sécurité majeures (règlement 29(2)(c)), et de fournir un rapport annuel d'audit de la sécurité du système établi par un cabinet d'audit indépendant réputé (règlement 29(3)(c))
- Risk Management Guidelines, janvier 2013Central Bank of Kenya. La section 7 traite du risque ICT : responsabilités du conseil et de la direction, cadre de gestion du risque ICT, identification des vulnérabilités avec les scanners de vulnérabilité et les tests d'intrusion (7.3.4), évaluation et atténuation des risques (7.4), et programme de sécurité de l'information (7.5)
- Prudential Guidelines, 2013, dont la Guideline on Outsourcing (CBK/PG/16)Central Bank of Kenya. CBK/PG/16 exige l'approbation de la CBK pour l'externalisation matérielle, cite la fourniture de canaux ou de technologies de services financiers mobiles comme exemple d'activité matérielle (4.1.4), et fixe des attentes en matière de diligence, de surveillance et de contrats. L'institution reste responsable des activités externalisées (4.2)
- Guidance Note on Cybersecurity for the Banking Sector, août 2017Central Bank of Kenya, publiée en vertu de l'article 33(4) du Banking Act et applicable à toutes les institutions agréées au titre de cette loi. Gouvernance, test indépendant des cybermenaces au moins une fois par an, tests d'audit interne et externe incluant des tests d'intrusion complets, externalisation, et signalement des incidents dans les 24 heures (sections 3.1 à 3.4 et partie IV)
- Guideline on Cybersecurity for Payment Service Providers, juillet 2019Central Bank of Kenya, publiée en vertu de l'article 31(2)(b) du National Payment System Act de 2011 et applicable aux prestataires de services de paiement autorisés au titre de cette loi. Scans de vulnérabilité trimestriels, test d'intrusion annuel et évaluations de vulnérabilité semestrielles (3.2.5), notification des externalisations 30 jours à l'avance (3.4.2), et période transitoire de 90 jours (4.0)
- Data Protection Act, 2019République du Kenya, loi n° 24 de 2019, publiée par l'Office of the Data Protection Commissioner. Protection des données dès la conception et par défaut et mesures exigées (sections 41 et 42), notification des violations dans les 72 heures (section 43), et conditions de transfert des données personnelles hors du Kenya (sections 48 à 50)
- Data Protection (General) Regulations, 2021Office of the Data Protection Commissioner. Les éléments de la protection des données dès la conception et par défaut, notamment l'évaluation des risques pesant sur la sécurité des données personnelles, les pistes d'audit et la surveillance des événements, et l'examen et le test réguliers des logiciels pour détecter les vulnérabilités des systèmes qui soutiennent le traitement (règlement 32)
- Communiqué : Establishment of the Banking Sector Cyber Security Operations Centre (BS-SOC)Central Bank of Kenya, 22 septembre 2025. La CBK indique avoir commencé à aligner les orientations de cybersécurité de 2017 et 2019 sur le règlement de 2024 relatif aux infrastructures d'information critiques, que les institutions doivent continuer à respecter les deux ensembles d'exigences, et que les incidents de cybersécurité doivent être signalés au BS-SOC dans les délais prévus par ce règlement
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.
Testez votre application bancaire mobile comme le décrit la CBK
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.