APRA et ASIC : testez votre application bancaire mobile comme le décrivent les textes.

1. 01

   CPS 234, paragraphes 27 à 31 ; CPG 234, Testing control effectiveness

   Tester systématiquement les contrôles de sécurité de l'information

   Ce que dit le texte

   Une entité régulée par l'APRA doit tester l'efficacité de ses contrôles de sécurité de l'information au moyen d'un programme de tests systématiques. La nature et la fréquence doivent être proportionnées à la vitesse de changement des vulnérabilités et des menaces, à la criticité et à la sensibilité de l'actif, aux conséquences d'un incident, aux risques liés à l'exposition à des environnements où l'entité ne peut pas faire appliquer ses politiques, ainsi qu'à l'importance et à la fréquence des changements des actifs informationnels. Les tests doivent être menés par des spécialistes compétents et fonctionnellement indépendants, et la suffisance du programme doit être revue au moins une fois par an ou en cas de changement important. CPG 234 ajoute que la fréquence et la portée devraient couvrir un ensemble suffisant de contrôles au moins une fois par an, et que les contrôles protégeant des actifs exposés à des environnements non maîtrisés, dont l'internet, devraient être testés tout au long de l'année.

   Source :CPS 234, paragraphes 27 à 31 ; CPG 234, Testing control effectiveness

   Ce que cela implique pour votre application mobile

   Une application bancaire mobile et ses API sont des actifs informationnels exposés à l'internet qui changent à chaque release. Ils font partie du programme de tests systématiques, et le rythme des releases devrait déterminer la fréquence des tests, pas seulement la revue annuelle.

   Comment Ostorlab vous aide

   Ostorlab exécute des scans automatisés depuis votre pipeline CI/CD à chaque build et surveille les versions publiées sur les stores sans déclenchement manuel. Un pentest par agents IA teste l'application et ses API après authentification, et chaque résultat d'un agent IA est accompagné d'un exploit fonctionnel que vous pouvez rejouer.

   Ce qui reste de votre ressort

   Le programme de tests lui-même, les décisions sur l'indépendance des testeurs, l'escalade des déficiences de contrôle qui ne peuvent pas être corrigées à temps et l'audit interne.

2. 02

   CPS 234, paragraphe 21 ; CPG 234, Implementation of controls

   Gérer les vulnérabilités avec des délais de réponse

   Ce que dit le texte

   Les contrôles de sécurité de l'information doivent être proportionnés aux vulnérabilités et aux menaces pesant sur les actifs informationnels. CPG 234 attend des contrôles de gestion des vulnérabilités qui identifient et traitent les vulnérabilités en temps utile, et des contrôles de gestion des correctifs qui gèrent l'évaluation et l'application des correctifs et autres mises à jour qui traitent les vulnérabilités connues en temps utile. Ces attentes couvrent les actifs informationnels gérés par des tiers et des parties liées, et alimentent l'assurance que le conseil reçoit sur l'environnement de contrôle.

   Source :CPS 234, paragraphe 21 ; CPG 234, Implementation of controls

   Ce que cela implique pour votre application mobile

   Les SDK et les bibliothèques natives intégrés à votre application sont des logiciels que vous livrez. Chacun a besoin d'une version connue, d'une sévérité lorsqu'une vulnérabilité apparaît et d'un délai de correction que vous pouvez prouver. Il en va de même pour les composants backend dont dépend l'application.

   Comment Ostorlab vous aide

   SCA identifie les bibliothèques compilées statiquement et les associe aux vulnérabilités connues, release après release. Les résultats sont notés critique, élevé, moyen ou faible, suivis comme tickets dans la plateforme ou dans Jira et ServiceNow, et retestés une fois le correctif livré.

   Ce qui reste de votre ressort

   Le patchage des serveurs et de l'infrastructure, les contrats de maintenance des fournisseurs, les décisions d'acceptation du risque et le reporting au conseil.

3. 03

   CPG 234, Attachment D (Software security) et Security in change management

   Intégrer la sécurité et tester chaque changement

   Ce que dit le texte

   L'APRA attend que les considérations de sécurité de l'information soient présentes tout au long du cycle de vie de livraison logicielle, y compris lorsque des méthodes agiles sont utilisées : exigences, conception, sélection et configuration, tests et mise en œuvre. La sécurité dans la gestion des changements comprend des tests et des revues de sécurité pour identifier les vulnérabilités et confirmer que les exigences de sécurité ont été satisfaites, la nature des tests étant proportionnée à la portée du changement et à la sensibilité de l'actif concerné, avec une approbation des changements avant le déploiement en production. Les standards logiciels devraient couvrir des domaines comme l'authentification, l'autorisation, la gestion de session, la validation des données, la cryptographie, la journalisation et la gestion sécurisée des entrées et sorties.

   Source :CPG 234, Attachment D (Software security) et Security in change management

   Ce que cela implique pour votre application mobile

   Chaque release de l'application est un changement apporté à un actif exposé à l'internet. Les tests automatisés ont leur place dans le pipeline avant que le build n'atteigne le store, et les SDK intégrés à l'application font partie du changement.

   Comment Ostorlab vous aide

   Mobile SAST analyse directement l'APK, l'AAB ou l'IPA, sans code source, avec une analyse de propagation (taint) sur les SDK intégrés. Mobile DAST exécute l'application et capture le trafic, les traces de pile et les captures d'écran. Les deux s'exécutent depuis votre pipeline CI/CD à chaque build.

   Ce qui reste de votre ressort

   Les standards de codage sécurisé, la formation des développeurs, la revue manuelle du code et la décision d'approbation avant la production.

4. 04

   CPS 234, paragraphes 16, 20, 22 et 28 ; CPG 234, Information asset identification and classification

   Connaître vos actifs informationnels et vos tiers

   Ce que dit le texte

   Une entité régulée par l'APRA doit classer ses actifs informationnels, y compris ceux gérés par des parties liées et des tiers, par criticité et sensibilité. Lorsque des actifs informationnels sont gérés par une partie liée ou un tiers, l'entité doit évaluer la capacité de sécurité de l'information de cette partie, évaluer la conception de ses contrôles de sécurité, et, lorsqu'elle s'appuie sur les tests de contrôle de cette partie, déterminer si la nature et la fréquence de ces tests sont proportionnées aux facteurs de la norme.

   Source :CPS 234, paragraphes 16, 20, 22 et 28 ; CPG 234, Information asset identification and classification

   Ce que cela implique pour votre application mobile

   Votre inventaire d'actifs devrait inclure l'application mobile, les API qu'elle appelle et les SDK qu'elle intègre. Une application en marque blanche ou une version développée par un prestataire reste soumise à vos obligations.

   Comment Ostorlab vous aide

   Ostorlab liste les SDK et les bibliothèques natives de chaque release avec leurs versions et leur emplacement dans le bundle de l'application, et montre ce que l'application et ses SDK échangent avec les backends sur le réseau. Ostorlab est audité SOC 2 Type II, et le rapport est disponible sur demande.

   Ce qui reste de votre ressort

   Le registre des actifs, la diligence raisonnable sur les tiers, les contrats et les décisions de s'appuyer sur les tests d'un fournisseur.

5. 05

   CPG 235, Data life-cycle management, Retention, Desensitisation et Outsourcing/offshoring ; CPS 230, paragraphe 23

   Gérer le risque lié aux données sur tout leur cycle de vie

   Ce que dit le texte

   CPG 235 attend que le risque lié aux données soit pris en compte à chaque étape de leur cycle de vie : capture, traitement, conservation, publication et élimination. Il attend des contrôles de conservation et une stratégie formelle de conservation, une désensibilisation telle que le chiffrement ou la dé-identification lorsque les données passent dans un environnement moins fiable, l'auditabilité des données et de leurs modifications, et une évaluation prudente de l'externalisation et de la délocalisation, y compris la capacité à poursuivre les opérations, à respecter les exigences prudentielles et à donner à l'APRA un accès rapide aux données sous une forme utilisable. CPS 230 cite le risque lié aux données parmi les risques opérationnels que l'entité doit gérer.

   Source :CPG 235, Data life-cycle management, Retention, Desensitisation et Outsourcing/offshoring ; CPS 230, paragraphe 23

   Ce que cela implique pour votre application mobile

   Les données de compte, les jetons et les informations personnelles présents sur le téléphone font partie du cycle de vie des données. Les décisions de conservation et de désensibilisation s'appliquent aux caches, aux journaux, aux captures d'écran et au stockage local, pas seulement aux bases de données.

   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 vérifie les erreurs de configuration qui affaiblissent les protections du transport et des sessions.

   Ce qui reste de votre ressort

   La classification des données, les calendriers de conservation, la politique de désensibilisation, la gouvernance des données et les évaluations de délocalisation.

6. 06

   CPG 234, Attachment F (Customer security)

   Protéger les clients sur les canaux numériques

   Ce que dit le texte

   CPG 234 décrit des contrôles pour les produits et services fournis via des canaux numériques : une authentification proportionnée aux menaces ; une notification ou confirmation par second canal pour des événements comme les virements, les nouveaux bénéficiaires, un changement d'adresse ou un accès depuis un appareil non reconnu ; des limites telles que des plafonds de virement et de transaction quotidiens ; la surveillance de l'activité transactionnelle ; des procédures documentées pour la fraude, les fuites de données et l'usurpation d'identité ; et la minimisation de la collecte d'informations client sensibles utilisées pour l'authentification, comme les mots de passe et les codes PIN.

   Source :CPG 234, Attachment F (Customer security)

   Ce que cela implique pour votre application mobile

   La MFA, les contrôles renforcés, les notifications et les limites doivent être appliqués par le backend à chaque opération clé, y compris lorsque l'application ou un attaquant tente de sauter une étape.

   Comment Ostorlab vous aide

   Ostorlab se connecte avec vos comptes de test, complète les codes à usage unique SMS, e-mail ou TOTP, et teste l'application de la MFA et les parcours d'authentification renforcée, y compris la manière dont les attaquants tentent de les manipuler, ainsi que les appels API derrière les changements de compte, les bénéficiaires et les virements.

   Ce qui reste de votre ressort

   Le choix des méthodes d'authentification, les limites de transaction, la surveillance de la fraude et la sensibilisation des clients.

7. 07

   CPS 230, paragraphes 29, 48 à 50 et 60

   Traiter le risque opérationnel et les prestataires comme un seul système

   Ce que dit le texte

   CPS 230 exige qu'une entité surveille, revoie et teste régulièrement ses contrôles quant à leur conception et à leur efficacité opérationnelle, à une fréquence proportionnée à l'importance des risques contrôlés, qu'elle rapporte les résultats à la direction générale et corrige les lacunes ou déficiences en temps utile. Elle doit identifier et tenir un registre de ses prestataires importants, transmettre ce registre à l'APRA chaque année, notifier l'APRA dans les 20 jours ouvrables suivant la conclusion ou la modification importante d'un accord pour un service dont elle dépend pour une opération critique, et notifier l'APRA avant tout accord important de délocalisation. La gestion des risques, les services technologiques essentiels et l'audit interne doivent être classés comme prestataires importants, sauf justification contraire.

   Source :CPS 230, paragraphes 29, 48 à 50 et 60

   Ce que cela implique pour votre application mobile

   L'application dépend de services technologiques essentiels et de fournisseurs de SDK et d'API. Les contrôles qui la maintiennent en service font partie du profil de risque opérationnel, et les preuves que vous conservez devraient correspondre au registre et au reporting au conseil.

   Comment Ostorlab vous aide

   Les scans automatisés à chaque build donnent un résultat daté par release, et le pentest par agents IA couvre l'application et ses API après authentification. Avec l'offre Enterprise, vous pouvez choisir la résidence des données en Asie-Pacifique ou exécuter les scans on-premises, et Ostorlab est audité SOC 2 Type II.

   Ce qui reste de votre ressort

   Le registre des prestataires, les contrats, le reporting au conseil, les notifications à l'APRA et la continuité d'activité.

8. 08

   Scams Prevention Framework Act 2025, sections 58BD, 58BE, 58BJ, 58BM, 58BN, 58BO, 58BX, 58BZC, 58BZD et 58BZG ; Designation 2026, sections 11, 12 et 101

   Préparer l'application au cadre de prévention des arnaques

   Ce que dit le texte

   Le Scams Prevention Framework Act 2025 a ajouté le cadre au Competition and Consumer Act 2010. Les entités régulées doivent documenter et mettre en œuvre des politiques et procédures de gouvernance pour prévenir, détecter et perturber les arnaques, y répondre et les signaler, avec des métriques de performance et une certification écrite annuelle par un dirigeant. Elles doivent prendre des mesures raisonnables pour empêcher une autre personne de commettre une arnaque, pour détecter une arnaque pendant et après sa survenance, enquêter sur les renseignements exploitables dans les 28 jours, identifier les consommateurs touchés, prendre des mesures raisonnables dans un délai raisonnable pour perturber l'activité ou prévenir les pertes ou dommages, fournir un mécanisme accessible pour signaler les arnaques, gérer un processus interne de règlement des litiges accessible et transparent, et adhérer à un dispositif externe de règlement des litiges. La désignation de 2026 intègre les services bancaires couverts au cadre, avec l'ASIC comme régulateur sectoriel. La plupart des obligations s'appliquent à partir du 31 mars 2027, et l'adhésion à l'AFCA est exigée à partir du 1er septembre 2026.

   Source :Scams Prevention Framework Act 2025, sections 58BD, 58BE, 58BJ, 58BM, 58BN, 58BO, 58BX, 58BZC, 58BZD et 58BZG ; Designation 2026, sections 11, 12 et 101

   Ce que cela implique pour votre application mobile

   Plusieurs de ces obligations se retrouvent dans l'application : la perturbation des paiements, les avertissements dans l'application, le mécanisme de signalement et le parcours de réclamation. Si un contrôle peut être contourné via l'application ou ses API, l'argument des mesures raisonnables s'affaiblit.

   Comment Ostorlab vous aide

   Le pentest par agents IA teste la logique métier des paiements et des flux de compte, et les tests d'API vérifient l'autorisation et la relecture sur les appels derrière les paiements et les changements de compte, ce qui montre si les protections côté application tiennent au niveau du backend.

   Ce qui reste de votre ressort

   Les politiques et métriques de gouvernance, la certification annuelle, la surveillance des arnaques et le signalement à l'ASIC, le traitement des réclamations et l'adhésion à l'AFCA.

9. 09

   Consumer Data Right Rules 2020, règles 1.15, 4.25 et 4.27 et Schedule 2 ; Consumer Data Standards 1.36.0, Security Profile (Authentication Flows) ; Competition and Consumer Act 2010, section 56ES

   Respecter le profil de sécurité des API du Consumer Data Right

   Ce que dit le texte

   Au titre du Consumer Data Right de la partie IVD du Competition and Consumer Act 2010, les banques sont des détenteurs de données qui doivent divulguer les données CDR via des API CDR lorsqu'un consommateur le demande ou qu'une personne accréditée le demande pour lui, et fournir un tableau de bord consommateur permettant de gérer et de retirer les autorisations de divulguer des données CDR. Les Consumer Data Standards fixent le socle technique. Dans le profil de sécurité, les détenteurs de données doivent prendre en charge FAPI 1.0 Advanced, ainsi que JARM et PKCE ; les logiciels des destinataires de données doivent utiliser PAR avec PKCE et la méthode de défi S256. Les règles définissent les étapes et les contrôles de sécurité minimaux pour les destinataires de données accrédités et les passerelles désignées, et les violations de données admissibles impliquant des données CDR relèvent du régime de notification des violations de données.

   Source :Consumer Data Right Rules 2020, règles 1.15, 4.25 et 4.27 et Schedule 2 ; Consumer Data Standards 1.36.0, Security Profile (Authentication Flows) ; Competition and Consumer Act 2010, section 56ES

   Ce que cela implique pour votre application mobile

   Si votre application mobile sert de tableau de bord consommateur, les écrans d'autorisation et le parcours de retrait font partie de la surface CDR. Les points de terminaison des API CDR doivent être testés comme le reste de votre parc d'API, avec les exigences FAPI en plus.

   Comment Ostorlab vous aide

   Ostorlab intercepte le trafic de l'application, même avec TLS pinning, et teste l'authentification et l'autorisation sur les API, y compris les flux OIDC, la gestion des jetons, les appels de retrait d'autorisation et l'accès aux données d'autres clients.

   Ce qui reste de votre ressort

   Les questions d'accréditation et de politique CDR, la conception du consentement et du tableau de bord, la gouvernance des données CDR et la notification des violations.

10. 10

    Privacy Act 1988, Schedule 1, APP 11 et Part IIIC ; OAIC APP Guidelines, Chapter 11 (mis à jour le 3 octobre 2025) ; Privacy Amendment (Personal Data Protection) Bill 2026 (projet)

    Sécuriser les informations personnelles au titre du Privacy Act

    Ce que dit le texte

    Le Privacy Act 1988 exige des entités APP qu'elles prennent des mesures raisonnables pour protéger les informations personnelles contre l'usage abusif, l'ingérence et la perte, ainsi que contre l'accès, la modification ou la divulgation non autorisés, et qu'elles détruisent ou dé-identifient les informations qui ne sont plus nécessaires. Depuis le 11 décembre 2024, l'APP 11.3 précise que les mesures raisonnables incluent des mesures techniques et organisationnelles. Au titre du régime de notification des violations de données de la partie IIIC, une entité doit notifier l'OAIC et les personnes concernées lorsqu'une violation de données est susceptible d'entraîner un préjudice grave. Les orientations de l'OAIC sur l'APP 11, mises à jour en octobre 2025, citent notamment la sécurité des TIC, la sécurité des accès et les fournisseurs tiers parmi les domaines à couvrir. Une deuxième tranche de réformes de la vie privée a été publiée sous forme de projet en août 2026 et n'est pas encore en vigueur.

    Source :Privacy Act 1988, Schedule 1, APP 11 et Part IIIC ; OAIC APP Guidelines, Chapter 11 (mis à jour le 3 octobre 2025) ; Privacy Amendment (Personal Data Protection) Bill 2026 (projet)

    Ce que cela implique pour votre application mobile

    Les mots de passe, les jetons, les numéros de compte et les données personnelles ne devraient pas rester en clair sur le téléphone ni circuler sans protection vers le backend. Ce que l'application écrit dans les journaux, les caches et les captures d'écran compte.

    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 vérifie les erreurs de configuration qui affaiblissent les protections du transport et des sessions.

    Ce qui reste de votre ressort

    Le programme de protection de la vie privée, les décisions de conservation et de destruction, l'évaluation et la notification des violations, et votre politique de confidentialité.

Synthèse de textes publics de l'APRA, du gouvernement australien et de l'OAIC, vérifiés le 27 septembre 2026. CPS 234 et CPS 230 sont des normes prudentielles prises en application du Banking Act 1959 ; CPG 234 et CPG 235 sont des guides. Les codes et règles du cadre de prévention des arnaques pour le secteur bancaire étaient encore à l'état de projet lors de la vérification de cette page. Cette page ne constitue pas un avis juridique.