Joint standards de la FSCA et de la PA : évaluez votre application bancaire mobile avant et après chaque version.

1. 01

   Joint Standard 1 de 2023, paragraphes 7.3(e) et 9.3(a) ; Joint Standard 2 de 2024, paragraphes 7.1.1(d), 7.1.2 et 7.7.5(c)

   Tenez un inventaire de ce que vous exploitez, y compris les tiers

   Ce que dit le texte

   Le Joint Standard 1 de 2023 exige que le cadre de gestion des risques informatiques identifie et hiérarchise les actifs informatiques et les protège contre les accès non autorisés, les usages abusifs ou les modifications frauduleuses, et qu'il maintienne un inventaire à jour des actifs informatiques. Le Joint Standard 2 de 2024 exige un inventaire de tous les actifs informationnels, avec leur emplacement et leur propriétaire, revu régulièrement et au moins tous les deux ans, ainsi qu'une politique sur l'utilisation et la mise à jour des codes tiers et open source, afin qu'ils soient examinés et testés avant leur intégration.

   Source :Joint Standard 1 de 2023, paragraphes 7.3(e) et 9.3(a) ; Joint Standard 2 de 2024, paragraphes 7.1.1(d), 7.1.2 et 7.7.5(c)

   Ce que cela implique pour votre application mobile

   Une application bancaire mobile est un actif informationnel qui embarque des SDK tiers et des bibliothèques natives. Chacun doit figurer dans l'inventaire, avec une version et un responsable.

   Comment Ostorlab vous aide

   Ostorlab recense les SDK et bibliothèques natives de chaque version avec leurs versions et leur emplacement dans le bundle de l'application, et montre avec quels backends l'application et ses SDK communiquent.

   Ce qui reste de votre ressort

   L'inventaire des actifs lui-même, les vérifications préalables sur les tiers et les contrats.

2. 02

   Joint Standard 2 de 2024, paragraphes 7.7.2 et 7.7.3

   Évaluez et testez régulièrement l'application et ses API

   Ce que dit le texte

   Les institutions financières doivent réaliser régulièrement des évaluations de vulnérabilité des systèmes et actifs informationnels, à une fréquence proportionnée à leur criticité et au risque de sécurité auquel ils sont exposés. Elles doivent réaliser des tests d'intrusion sur les systèmes et actifs informationnels critiques afin d'obtenir une évaluation approfondie de leurs défenses, selon le mode black box, grey box ou white box, ou une combinaison, que l'autorité responsable peut préciser. Pour les systèmes et actifs directement accessibles depuis Internet, les tests d'intrusion doivent être réalisés à chaque changement ou mise à jour majeure, et au moins une fois par an en l'absence de changement.

   Source :Joint Standard 2 de 2024, paragraphes 7.7.2 et 7.7.3

   Ce que cela implique pour votre application mobile

   Votre application bancaire mobile et les API qu'elle appelle sont directement accessibles depuis Internet. Prévoyez des tests à chaque version majeure et au moins une fois par an, y compris après connexion.

   Comment Ostorlab vous aide

   Le 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. Les résultats sont notés, suivis sous forme de tickets et retestés après correction.

   Ce qui reste de votre ressort

   Le choix du prestataire des tests d'intrusion annuels, les décisions black ou grey box, les tests en production et le reporting à l'organe de gouvernance.

3. 03

   Joint Standard 2 de 2024, paragraphes 7.2.4 et 7.7.5

   Intégrez la sécurité et testez les applications pendant le développement

   Ce que dit le texte

   Le standard exige une approche de sécurité dès la conception, intégrée à chaque phase du développement logiciel pour minimiser les vulnérabilités et réduire la surface d'attaque. Les exigences de sécurité relatives au contrôle d'accès, à l'authentification, à l'autorisation des transactions, à l'intégrité des données, à la journalisation, aux pistes d'audit, au suivi des événements de sécurité et au traitement des exceptions doivent être précisées dès les premières étapes du développement ou de l'acquisition, et les changements apportés aux applications critiques doivent être examinés et testés. Des normes de codage sécurisé, de revue de code source et de tests de sécurité applicative doivent être adoptées, et la sécurité fonctionnelle des applications web et critiques testée pendant le développement et la mise en œuvre.

   Source :Joint Standard 2 de 2024, paragraphes 7.2.4 et 7.7.5

   Ce que cela implique pour votre application mobile

   Chaque version de l'application modifie un canal exposé à Internet et devrait passer des tests de sécurité automatisés avant d'atteindre le store, y compris les SDK et bibliothèques qu'elle embarque.

   Comment Ostorlab vous aide

   Mobile SAST analyse directement l'APK, l'AAB ou l'IPA, sans besoin du code source, y compris l'analyse de propagation dans les SDK intégrés. Mobile DAST exécute l'application, et les deux s'exécutent depuis votre pipeline CI/CD à chaque build.

   Ce qui reste de votre ressort

   Les normes de codage sécurisé, la formation des développeurs, la revue de code manuelle et l'approbation des versions.

4. 04

   Joint Standard 2 de 2024, paragraphes 7.7.6 et 8.5

   Corrigez selon la gravité, la priorité et des délais de correctif

   Ce que dit le texte

   Le processus de remédiation doit comprendre l'évaluation de la gravité et la classification des problèmes, leur priorisation selon le risque encouru, des délais de correction selon la gravité, ainsi que des évaluations de risque et des stratégies d'atténuation le cas échéant. Tous les problèmes issus des tests de cybersécurité, ainsi que les défauts logiciels découverts lors de la revue de code ou des tests de sécurité applicative, doivent être suivis, et les problèmes majeurs et failles connus doivent être corrigés avant le déploiement en production. Les correctifs de sécurité doivent être appliqués dans un délai proportionné aux risques, avec des mesures compensatoires en l'absence de correctif, des tests avant la production et un plan de remédiation assorti de délais lorsqu'un correctif ne peut pas être appliqué.

   Source :Joint Standard 2 de 2024, paragraphes 7.7.6 et 8.5

   Ce que cela implique pour votre application mobile

   Chaque résultat dans l'application ou une API a besoin d'une gravité, d'un délai de correction et d'une trace. Les bibliothèques tierces sont les plus faciles à oublier.

   Comment Ostorlab vous aide

   Ostorlab classe chaque résultat en critique, élevé, moyen ou faible, le suit sous forme de ticket dans la plateforme ou dans Jira et ServiceNow, et le reteste après correction. Les résultats sur les composants incluent des recommandations de mise à niveau ou de remplacement.

   Ce qui reste de votre ressort

   Les fenêtres de correctifs, l'application des correctifs sur les serveurs et l'infrastructure, l'acceptation des risques et les décisions de mise en production.

5. 05

   Joint Standard 2 de 2024, paragraphes 7.2.2, 8.2 et 8.3

   Identité, accès et MFA pour les comptes exposés à Internet

   Ce que dit le texte

   L'accès aux actifs informationnels doit être limité aux utilisateurs, processus et appareils autorisés, géré en fonction du risque d'accès non autorisé évalué, avec des mécanismes de gestion des identités et de contrôle d'accès, des politiques de sécurité et de contrôle d'accès, un accès distant uniquement depuis des appareils et connexions sécurisés, et une authentification forte pour l'accès distant. Chaque compte d'administration doit être sécurisé contre tout accès ou usage non autorisé, et l'accès privilégié accordé selon le besoin d'utilisation, avec journalisation des activités. L'authentification multifacteur est requise pour les utilisateurs ayant accès à des fonctions critiques, pour tous les comptes d'administration et privilégiés, et pour tous les comptes utilisateurs servant à accéder via Internet à des applications contenant des informations sensibles.

   Source :Joint Standard 2 de 2024, paragraphes 7.2.2, 8.2 et 8.3

   Ce que cela implique pour votre application mobile

   L'application mobile correspond exactement au type d'application visé par la règle MFA. Le second facteur doit être imposé par le serveur, quoi que l'application envoie.

   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, ainsi que les appels d'API qui les sous-tendent.

   Ce qui reste de votre ressort

   Le choix des méthodes d'authentification, la gestion des accès privilégiés, les revues d'accès et la politique des appareils.

6. 06

   Joint Standard 2 de 2024, paragraphe 7.2.3 ; Joint Standard 1 de 2023, paragraphe 10

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

   Ce que dit le texte

   Le Joint Standard 2 de 2024 exige des politiques de prévention des fuites de données pour les informations sensibles, qu'elles soient en mouvement, au repos ou en cours d'utilisation, des mesures pour prévenir et détecter les accès non autorisés aux données, leur modification, copie, transmission et vol dans les systèmes et les appareils, le chiffrement ou un contrôle d'accès proportionné au risque pour les informations sensibles stockées dans les systèmes et appareils, et l'utilisation exclusive de systèmes et appareils autorisés. Le Joint Standard 1 de 2023 exige des mesures pour protéger les données de compte et de transaction des clients, un contrôle d'accès logique avec surveillance des anomalies, et des mesures contre le vol, la perte et la fuite de données depuis les appareils.

   Source :Joint Standard 2 de 2024, paragraphe 7.2.3 ; Joint Standard 1 de 2023, paragraphe 10

   Ce que cela implique pour votre application mobile

   Les mots de passe, jetons et données clients ne devraient pas rester en clair sur le téléphone ni transiter sans protection vers le backend. Les appareils rootés ou jailbreakés affaiblissent chacun de ces contrôles.

   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 teste le comportement de l'application dans des environnements rootés et jailbreakés.

   Ce qui reste de votre ressort

   La classification des données, les outils DLP, la gestion des appareils mobiles et la gestion des clés.

7. 07

   Joint Standard 2 de 2024, paragraphe 7.2.6

   Gérez la cryptographie et protégez les clés

   Ce que dit le texte

   Lorsqu'elle utilise la cryptographie, l'institution doit disposer de politiques, normes et procédures couvrant la génération, la distribution, l'installation, le renouvellement, la révocation, la récupération et l'expiration des clés. Les algorithmes cryptographiques doivent provenir de normes internationales reconnues, les clés doivent être générées de manière sûre et protégées contre toute divulgation non autorisée dans des systèmes durcis et résistants à l'altération, les clés expirées ou révoquées doivent être détruites de façon irrécupérable, et tous les algorithmes doivent être rigoureusement testés ou vérifiés au regard des objectifs de sécurité identifiés.

   Source :Joint Standard 2 de 2024, paragraphe 7.2.6

   Ce que cela implique pour votre application mobile

   Le pinning de certificats, la signature de code et l'usage du keystore sont de la cryptographie dans l'application. Ce qui se trouve dans le package ou le keystore peut être attaqué sur un appareil modifié.

   Comment Ostorlab vous aide

   Mobile Shielding Scan tente de contourner à l'exécution la détection du root et du jailbreak, l'anti-altération et le TLS pinning, et montre quelles protections ont tenu et lesquelles ont été contournées. Ostorlab détecte aussi les clés et secrets dans le package de l'application.

   Ce qui reste de votre ressort

   Les systèmes de gestion des clés, les HSM, le cycle de vie des certificats et le choix des algorithmes.

8. 08

   Protection of Personal Information Act 4 of 2013, articles 19, 21, 22 et 72

   Respectez les garanties et les obligations de notification de la POPIA

   Ce que dit le texte

   La POPIA impose au responsable du traitement de sécuriser l'intégrité et la confidentialité des données à caractère personnel par des mesures techniques et organisationnelles appropriées et raisonnables. Il doit identifier les risques internes et externes raisonnablement prévisibles, mettre en place et maintenir des garanties contre ces risques, vérifier régulièrement que ces garanties sont effectivement mises en œuvre et les actualiser face aux nouveaux risques ou aux défaillances constatées. Un contrat écrit doit exiger de l'opérateur qu'il maintienne les mêmes mesures de sécurité, et l'opérateur doit informer immédiatement le responsable lorsqu'il existe des motifs raisonnables de croire que des données personnelles ont été consultées par une personne non autorisée. Lorsqu'il existe des motifs raisonnables de croire que des données personnelles ont été consultées ou acquises par une personne non autorisée, le responsable doit notifier le Information Regulator et, sous réserve des exceptions, la personne concernée, dès que raisonnablement possible. Les transferts de données personnelles hors du territoire exigent un niveau de protection adéquat ou un autre motif prévu à l'article 72.

   Source :Protection of Personal Information Act 4 of 2013, articles 19, 21, 22 et 72

   Ce que cela implique pour votre application mobile

   Les tests d'application sont un moyen de vérifier les garanties de l'article 19 sur l'appareil et dans l'API. Le Information Regulator indique qu'il n'existe aucun seuil de risque : tout compromis de sécurité doit être signalé, et il n'a pas besoin d'être confirmé au préalable.

   Comment Ostorlab vous aide

   Ostorlab teste les contrôles techniques de l'application et de ses API et vous fournit des preuves pour chaque résultat. La qualification du compromis de sécurité et les notifications restent du ressort de votre information officer.

   Ce qui reste de votre ressort

   Les obligations de l'information officer, l'évaluation des violations, la notification au Regulator et aux personnes concernées, et les décisions de transfert transfrontalier.

9. 09

   Joint Standard 1 de 2023, paragraphe 15.1 ; Joint Standard 2 de 2024, paragraphe 9.1 ; Joint Notice 2 de 2026

   Notifiez les incidents importants dans la forme déterminée

   Ce que dit le texte

   Les deux joint standards exigent qu'une institution financière notifie à l'autorité responsable, dans la forme et de la manière déterminées par les autorités, tout dysfonctionnement, incident cyber ou compromis de sécurité de l'information qu'elle a classé comme incident important. Le Joint Notice 2 de 2026, publié avec la Joint Communication 5 de 2026, détermine le Reporting of Material IT and Cyber Incident Template et prend effet le 1er septembre 2026. Les banques, banques mutualistes, assureurs et leurs sociétés de contrôle le transmettent via le portail Umoja ; les autres institutions financières concernées utilisent le Joint Standards Submission Portal de la FSCA.

   Source :Joint Standard 1 de 2023, paragraphe 15.1 ; Joint Standard 2 de 2024, paragraphe 9.1 ; Joint Notice 2 de 2026

   Ce que cela implique pour votre application mobile

   Votre procédure de classification et de notification des incidents doit prévoir le modèle, le portail et le délai indiqué sur la page de couverture du modèle. Les preuves de scan aident à établir le périmètre.

   Comment Ostorlab vous aide

   Ostorlab ne classe ni ne notifie les incidents. Il vous fournit des preuves de la vulnérabilité ou de la défaillance de contrôle à l'origine d'un incident et reteste les correctifs ensuite.

   Ce qui reste de votre ressort

   La classification, la notification, la communication avec le régulateur et les clients, et l'investigation technique.

10. 10

    Joint Communication 2 de 2025, section 4 ; Directive 3 de 2018 de la PA ; Joint Standard 1 de 2023, paragraphe 7.3(i)

    Encadrez le cloud et l'offshoring des données

    Ce que dit le texte

    La Joint Communication 2 de 2025, publiée le 25 juillet 2025, rappelle la Directive 3 de 2018 et la Guidance Note 5 de 2018 de la PA pour les banques et expose les pratiques recommandées en matière de cloud computing et d'offshoring des données : une approche fondée sur les risques alignée sur l'appétit pour le risque, une gouvernance couvrant une politique définie et une stratégie de données approuvée par le conseil, une attention aux exigences contractuelles et juridiques, et une diligence raisonnable avant tout investissement stratégique. L'offshoring désigne le stockage ou le traitement de données hors des frontières de l'Afrique du Sud. Les autorités indiquent qu'un joint standard sur le cloud et l'offshoring des données est en préparation. Le Joint Standard 1 de 2023 exige également une sélection rigoureuse des prestataires et sous-traitants, et des obligations contractuelles de protection des informations sensibles ou confidentielles.

    Source :Joint Communication 2 de 2025, section 4 ; Directive 3 de 2018 de la PA ; Joint Standard 1 de 2023, paragraphe 7.3(i)

    Ce que cela implique pour votre application mobile

    Si le backend de l'application ou ses SDK envoient des données personnelles vers des services hors d'Afrique du Sud, l'article 72 de la POPIA et les attentes sur le cloud s'appliquent tous les deux. L'application peut tout de même être scannée là où vivent les données.

    Comment Ostorlab vous aide

    Le scan on-premises s'exécute sur une infrastructure que vous contrôlez, dans votre réseau. Il scanne les applications de préproduction, les API et les dépôts derrière votre pare-feu ou VPN.

    Ce qui reste de votre ressort

    La stratégie cloud, la diligence raisonnable, les contrats, les décisions de localisation des données et le futur joint standard.

Synthèse des joint standards publics, des communications de la Prudential Authority et du texte de la POPIA, vérifiés le 27 septembre 2026. Les joint standards ne nomment pas les applications mobiles : ils s'appliquent aux systèmes informatiques, aux actifs informationnels et aux applications en général, et cette page les applique au canal mobile. Cette page ne constitue pas un avis juridique.