Directives du CBSL sur le risque technologique : évaluez votre application bancaire mobile avant et après chaque version.

1. 01

   Banking Act Directions No. 16 of 2021, 5.8.1 ; échéance de conformité au 31 décembre 2025 telle que modifiée par les Directions No. 05 of 2023

   Tester avant la mise en production et avant chaque changement

   Ce que dit le texte

   Les systèmes d'information critiques et les systèmes exposés aux données clients doivent passer des tests de sécurité de l'information avant mise en production, avant l'implémentation initiale comme avant chaque modification, sauf si une politique d'exclusion approuvée par le conseil couvre la modification mineure concernée. Le dispositif nomme les tests : analyse statique de sécurité des applications (SAST) ou revue du code source, analyse dynamique de sécurité des applications (DAST), contrôles de durcissement de l'infrastructure informatique et réseau, et évaluations de vulnérabilité de l'infrastructure. Les tests doivent être menés par une équipe indépendante de celle qui développe ou implémente le système.

   Source :Banking Act Directions No. 16 of 2021, 5.8.1 ; échéance de conformité au 31 décembre 2025 telle que modifiée par les Directions No. 05 of 2023

   Ce que cela implique pour votre application mobile

   Chaque version mobile qui touche un système critique ou exposé aux données clients est une modification. Le pipeline et le processus de livraison doivent comporter des tests de sécurité automatisés et indépendants sur le build que téléchargent vos clients.

   Comment Ostorlab vous aide

   Mobile SAST fonctionne sur l'APK, l'AAB ou l'IPA, sans besoin du code source, et Mobile DAST teste l'application en cours d'exécution dans la CI/CD. Le pentest par agents IA teste l'application et ses API derrière la connexion, avec un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA.

   Ce qui reste de votre ressort

   La politique d'exclusion et son approbation par le conseil, l'indépendance de l'équipe de test, l'accès au code source et l'approbation des mises en production.

2. 02

   Banking Act Directions No. 16 of 2021, 5.8.2 et 5.2.4 (telles que modifiées par les Directions No. 05 of 2023)

   Réaliser des évaluations de vulnérabilité au moins trimestriellement

   Ce que dit le texte

   Les systèmes d'information critiques et les systèmes exposés aux données clients font l'objet d'évaluations de vulnérabilité au moins trimestrielles. Ces évaluations portent à la fois sur les vulnérabilités d'infrastructure et sur les vulnérabilités applicatives, et sont réalisées sur les environnements de production. Les vulnérabilités identifiées doivent être corrigées dans un délai approuvé par le comité de sécurité de l'information de la banque. Le même dispositif exige des revues des privilèges d'accès au moins trimestrielles pour les systèmes critiques et semestrielles pour les systèmes non critiques exposés aux données clients ou aux données confidentielles de non-clients.

   Source :Banking Act Directions No. 16 of 2021, 5.8.2 et 5.2.4 (telles que modifiées par les Directions No. 05 of 2023)

   Ce que cela implique pour votre application mobile

   Quatre cycles d'évaluation par an sur l'application de production et ses API ne laissent guère de place aux tests manuels ponctuels. Le rythme doit être automatisé et reproductible.

   Comment Ostorlab vous aide

   Ostorlab lance des scans planifiés depuis votre pipeline CI/CD et surveille les versions publiées sur les stores sans déclenchement manuel. Les résultats sont classés critiques, élevés, moyens ou faibles et suivis sous forme de tickets dans la plateforme ou dans Jira et ServiceNow.

   Ce qui reste de votre ressort

   Les délais de correction approuvés par l'ISC, l'application des correctifs d'infrastructure et la gestion des changements en production.

3. 03

   Banking Act Directions No. 16 of 2021, 5.8.3 ; échéance en production au 31 décembre 2028 telle que modifiée par les Directions No. 05 of 2023

   Tests d'intrusion par des experts externes indépendants

   Ce que dit le texte

   Les systèmes d'information critiques, les systèmes exposés aux données clients et les référentiels de données clients, y compris chez les agents et les prestataires tiers, doivent être testés par des experts externes indépendants en tests d'intrusion. Les systèmes critiques au moins une fois par an, et tous les autres systèmes concernés au moins une fois tous les deux ans. Les tests sont fondés sur le renseignement sur les menaces, menés sur des systèmes de production réels dans des conditions d'exploitation normales, sans modifier les mesures de sécurité habituellement en place, et couvrent les menaces externes et internes. Des tests en boîte noire et des tests en boîte grise avec des identifiants fournis par la banque pour les catégories d'utilisateurs clients, opérationnels et managériaux sont exigés. Une spécification du périmètre de test définit les systèmes, les scénarios de menace, les cibles et la période, le conseil d'administration approuve l'exercice, et un résumé exécutif est adressé au Director of Bank Supervision dans les 60 jours suivant le rapport du prestataire.

   Source :Banking Act Directions No. 16 of 2021, 5.8.3 ; échéance en production au 31 décembre 2028 telle que modifiée par les Directions No. 05 of 2023

   Ce que cela implique pour votre application mobile

   Le test d'intrusion annuel est l'évaluation la plus poussée du dispositif, et l'application, ses API et les comptes de test sont les parties qu'un prestataire spécialisé dans le mobile peut couvrir. À noter : les tests d'intrusion en production sont exigés avant le 31 décembre 2028.

   Comment Ostorlab vous aide

   Le pentest par agents IA teste l'application et ses API derrière la connexion avec vos comptes de test, y compris les parcours en boîte grise, et fournit un exploit rejouable pour chaque résultat d'un agent IA. Les résultats sont regroupés en tickets et retestés après la publication du correctif.

   Ce qui reste de votre ressort

   L'approbation par le conseil de la spécification de périmètre et de l'exercice, l'équipe de direction du projet, l'accréditation du prestataire externe, les vérifications et les références, et le rapport à 60 jours au Director of Bank Supervision.

4. 04

   Banking Act Directions No. 16 of 2021, 5.8.4

   Se préparer aux exercices de red team

   Ce que dit le texte

   Les exercices de red team étendent les tests d'intrusion aux couches humaine et physique de la sécurité. Les D-SIB doivent les mener au moins une fois tous les deux ans et les autres banques agréées au moins une fois tous les trois ans, sur la base d'une Red Teaming Scope Statement approuvée par le conseil d'administration et associée à un test d'intrusion du même cycle. Lorsque le conseil estime que la maturité de sécurité de la banque n'est pas encore suffisante, les exercices sont reportés de 12 mois au maximum.

   Source :Banking Act Directions No. 16 of 2021, 5.8.4

   Ce que cela implique pour votre application mobile

   Le red team teste toute la banque, pas seulement l'application. C'est un exercice d'une autre nature qu'un test d'intrusion externe, et il est attendu en complément.

   Comment Ostorlab vous aide

   Ostorlab ne réalise pas d'exercices de red team et ne les remplace pas. Il maintient les éléments application et API de votre plan de remédiation testés et retestés, pour que la couche technologique soit prête avant un cycle de red team.

   Ce qui reste de votre ressort

   Le cadrage et la conduite des exercices de red team, la RTSS, les décisions du conseil et les évaluations des couches humaine et physique.

5. 05

   Guidelines on Minimum Compliance Standard for Payment Related Mobile Applications No. 1 of 2020, sections 5, 6 et 8

   Mettre en œuvre les contrôles des applications de paiement : MFA, rattachement d'appareil, sessions et verrouillage

   Ce que dit le texte

   La ligne directrice de paiement exige que les comptes utilisateurs et les appareils soient enregistrés auprès du fournisseur avec le numéro de mobile et un identifiant unique d'appareil, qu'un compte ne soit utilisable que sur des appareils enregistrés et qu'aucune utilisation simultanée du même compte depuis plusieurs appareils ne soit permise. L'authentification doit être traitée côté backend, sauf pour les méthodes fondées sur la biométrie ou une puce. La MFA combine le numéro de mobile, l'identifiant d'appareil, le mot de passe ou PIN et un identifiant propre à l'application. L'application doit comporter un verrouillage de compte configurable après plusieurs tentatives de connexion invalides, un identifiant de session aléatoire, une déconnexion automatique après une période d'inactivité, une déconnexion clairement visible qui efface les données sensibles propres à l'application de la mémoire temporaire et permanente, une détection côté serveur des tentatives de connexion simultanées et une procédure pour désactiver l'application de façon centralisée pour un appareil signalé perdu ou volé.

   Source :Guidelines on Minimum Compliance Standard for Payment Related Mobile Applications No. 1 of 2020, sections 5, 6 et 8

   Ce que cela implique pour votre application mobile

   Ce sont des comportements testables, et ils doivent tenir côté backend, pas seulement dans l'interface de l'application. Un attaquant qui appelle directement l'API doit rencontrer les mêmes contrôles.

   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, le verrouillage des comptes et l'application effective de la MFA avec vos comptes de test, ainsi que les appels d'API qui les sous-tendent.

   Ce qui reste de votre ressort

   La gestion des identités et des accès, les registres d'enregistrement des appareils et le processus en cas d'appareil perdu.

6. 06

   Guidelines on Minimum Compliance Standard for Payment Related Mobile Applications No. 1 of 2020, sections 12, 13, 14 et 15

   Durcir l'application : altération, root, débogage et pinning

   Ce que dit le texte

   La ligne directrice exige des contrôles d'intégrité côté serveur portant sur les valeurs de hachage ou sommes de contrôle des blocs de code, sur la taille et les horodatages de modification des fichiers et sur la signature du paquet, l'application étant désactivée en cas d'échec. L'application ne doit pas s'exécuter sur des appareils rootés ou jailbreakés. La détection de débogueur et d'émulateur doit être implémentée, la minification et l'obfuscation du code source doivent être utilisées, et aucun tiers ne doit pouvoir déboguer l'application à l'exécution. Le chiffrement de la couche transport est exigé pour toutes les communications, avec des certificats SSL valides émis par une autorité de certification de confiance, un certificate pinning correctement implémenté avec une gestion d'exception appropriée et des contrôles pour limiter le contournement du pinning. L'application doit cesser de fonctionner jusqu'à ce que les erreurs de certificat SSL soient correctement traitées.

   Source :Guidelines on Minimum Compliance Standard for Payment Related Mobile Applications No. 1 of 2020, sections 12, 13, 14 et 15

   Ce que cela implique pour votre application mobile

   Ces protections sont les premières qu'un attaquant teste sur une application de paiement. Un contrôle présent dans le code mais contournable à l'exécution ne compte pas.

   Comment Ostorlab vous aide

   Mobile Shielding Scan teste à l'exécution la détection du root et du jailbreak, l'anti-altération, la détection de débogueur et d'émulateur et le pinning, et montre quelles protections ont tenu et lesquelles ont été contournées.

   Ce qui reste de votre ressort

   L'infrastructure d'obfuscation et de signature de code, les publications sur les stores et le comportement de l'application sur le terrain.

7. 07

   Guidelines on Minimum Compliance Standard for Payment Related Mobile Applications No. 1 of 2020, sections 11 et 16 ; Banking Act Directions No. 16 of 2021, 5.8.2

   Maintenir les composants à jour et le prouver

   Ce que dit le texte

   Les applications mobiles de paiement ne doivent pas utiliser de composants, protocoles, bibliothèques ou scripts vulnérables ou obsolètes, les implémentations de ces composants ne doivent pas créer de vulnérabilité, et l'application doit être correctement corrigée lorsqu'une vulnérabilité est identifiée. Les algorithmes cryptographiques et les nombres d'itérations doivent être actuellement non identifiés comme vulnérables, testés par l'industrie et acceptés par des institutions telles que le FFIEC, l'ANSI et le NIST. Selon les directives sur le risque technologique, les vulnérabilités identifiées lors des évaluations doivent être corrigées dans un délai approuvé par l'ISC.

   Source :Guidelines on Minimum Compliance Standard for Payment Related Mobile Applications No. 1 of 2020, sections 11 et 16 ; Banking Act Directions No. 16 of 2021, 5.8.2

   Ce que cela implique pour votre application mobile

   Les SDK et bibliothèques natives d'une application bancaire sont des logiciels que vous livrez. Chacun doit avoir une version connue, une gravité lorsqu'une vulnérabilité apparaît, et un délai de correction dont vous pouvez apporter la preuve.

   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. Leur résolution est suivie sous forme de tickets dans la plateforme ou dans Jira et ServiceNow, et les résultats sont classés critiques, élevés, moyens ou faibles.

   Ce qui reste de votre ressort

   Les décisions de correctifs, les contrats de maintenance des fournisseurs, la planification des mises à niveau et l'acceptation des risques.

8. 08

   Banking Act Directions No. 16 of 2021, 5.5.1 ; Guidelines No. 1 of 2020, sections 9.3, 11.2 et 11.3 ; Personal Data Protection Act No. 9 of 2022, article 10

   Protéger les données clients sur l'appareil et en transit

   Ce que dit le texte

   Selon les directives sur le risque technologique, les données clients sont protégées par chiffrement : chiffrement au repos au niveau de la base de données ou des fichiers, chiffrement des données en transit, et chiffrement intégral du disque pour les appareils endpoints et les supports amovibles qui stockent des données clients. Lorsque le chiffrement n'est pas réalisable ou approprié, les dérogations nécessitent l'approbation du conseil, des contrôles compensatoires et une surveillance, ainsi qu'une revue au moins tous les deux ans. La ligne directrice de paiement ajoute que les informations sensibles telles que les numéros de compte et les identifiants clients dans le stockage temporaire de l'appareil doivent être sécurisées, que les données sensibles sont chiffrées en transit et au repos, que les clés de chiffrement ne sont pas stockées sur l'appareil mobile sans contrôles de sécurité appropriés, et que les données sensibles ne sont pas stockées sur l'appareil. La loi sur la protection des données personnelles impose aux responsables de traitement de garantir l'intégrité et la confidentialité des données personnelles par des mesures techniques et organisationnelles appropriées, dont le chiffrement, la pseudonymisation, l'anonymisation ou les contrôles d'accès.

   Source :Banking Act Directions No. 16 of 2021, 5.5.1 ; Guidelines No. 1 of 2020, sections 9.3, 11.2 et 11.3 ; Personal Data Protection Act No. 9 of 2022, article 10

   Ce que cela implique pour votre application mobile

   Les jetons, numéros de compte et identifiants ne devraient jamais se trouver en clair dans le stockage, les caches, les journaux ou les rapports de crash de l'application, ni transiter sans protection vers le backend.

   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, et détecte les erreurs de configuration qui affaiblissent la protection du transport et des sessions.

   Ce qui reste de votre ressort

   La classification des données, la gestion des clés, les sauvegardes et le processus de dérogation avec le conseil.

9. 09

   Payment and Settlement Systems Circulars No. 01 of 2024, No. 02 of 2024 et No. 01 of 2026

   Appliquer le seuil d'OTP JustPay et les contrôles d'enregistrement des applications de paiement

   Ce que dit le texte

   Pour les transactions JustPay de 10 000 roupies ou plus, l'application mobile de paiement qui initie la transaction doit demander un code à usage unique à l'émetteur du compte rattaché, envoyé au numéro de mobile enregistré auprès de l'émetteur. Cette règle s'applique depuis le 1er avril 2024. Depuis le 31 mars 2025, les fournisseurs doivent identifier les utilisateurs avec un document d'identité acceptable, vérifier cette identité avant d'autoriser des transactions ou de rattacher un compte et, pour JustPay, vérifier que l'utilisateur de l'application et le titulaire du compte sont la même personne en faisant correspondre le numéro de mobile de l'appareil avec celui enregistré pour le compte. La circulaire n° 01 de 2026 plafonne les transactions JustPay à 150 000 roupies à compter du 2 février 2026 et exige de tous les fournisseurs d'applications mobiles de paiement des contrôles et procédures de sécurité adéquats lors de l'enregistrement des clients et du rattachement des comptes.

   Source :Payment and Settlement Systems Circulars No. 01 of 2024, No. 02 of 2024 et No. 01 of 2026

   Ce que cela implique pour votre application mobile

   L'application effective de l'OTP et les contrôles d'identité sont des comportements backend. Testez-les en tentant de finaliser une transaction ou de rattacher un compte sans le facteur requis ou depuis le mauvais appareil.

   Comment Ostorlab vous aide

   Ostorlab saisit les codes à usage unique reçus par SMS, e-mail ou TOTP avec vos comptes de test et teste l'application effective de l'OTP, de la MFA et des parcours d'authentification renforcée, ainsi que les appels d'API derrière le rattachement de comptes et les paiements.

   Ce qui reste de votre ressort

   Le processus de vérification d'identité, les registres d'enregistrement des appareils et la configuration des limites de transaction.

10. 10

    Guidelines on Minimum Compliance Standard for Payment Related Mobile Applications No. 1 of 2020, section 25

    Auditer avant le lancement et faire rapport chaque année

    Ce que dit le texte

    Chaque prestataire de services de paiement doit soumettre un rapport de conformité, approuvé par son conseil d'administration, au Director of the Payments and Settlements Department avant le lancement commercial de chaque application mobile de paiement, ainsi qu'un rapport pour l'année précédente avant le 31 janvier de chaque année, couvrant les nouvelles versions, correctifs et mises à jour. Un audit du système d'information et un audit de sécurité de l'information de tout l'écosystème sont fortement recommandés, réalisés par un auditeur tiers indépendant, avec un périmètre incluant l'analyse de sécurité statique et dynamique, la revue du code source pour les contrôles de sécurité, les portes dérobées et les informations sensibles codées en dur, la revue des environnements de production et de test, et la revue des évaluations de vulnérabilité et des tests d'intrusion.

    Source :Guidelines on Minimum Compliance Standard for Payment Related Mobile Applications No. 1 of 2020, section 25

    Ce que cela implique pour votre application mobile

    Le dossier de conformité a besoin de preuves, pas seulement d'affirmations, et chaque nouvelle version relance le cycle en pratique.

    Comment Ostorlab vous aide

    Ostorlab produit des résultats de scan, des requêtes et réponses à l'appui, des exploits rejouables et des résultats de retest pour chaque version, que vous pouvez joindre au dossier d'audit. Ostorlab ne soumet pas de rapports au CBSL et n'est pas un cabinet d'audit.

    Ce qui reste de votre ressort

    L'approbation du rapport de conformité par le conseil, les envois au CBSL et toute opinion que vous demandez à un cabinet d'audit agréé.

Synthèse des textes publics du CBSL et de la loi sur la protection des données, vérifiés le 27 septembre 2026. Les points de la ligne directrice de paiement sont résumés d'après le texte anglais. Cette page ne constitue pas un avis juridique.