Cyberrésilience RBNZ : évaluez votre application bancaire mobile avant et après chaque version.
La Guidance on Cyber Resilience de la RBNZ demande aux entités de mener des tests de sécurité sur leurs systèmes et réseaux, de façon régulière et à chaque changement majeur. La Deposit Takers (Operational Resilience) Standard 2027, soumise à consultation en 2026 et applicable au 1er décembre 2028, ajoute la gestion des vulnérabilités et des correctifs, l'assurance sur les systèmes TIC et la notification sous 72 heures des incidents TIC importants. Ostorlab teste votre application et les API qui la sous-tendent, derrière la connexion, à chaque version.
- Teste l'application et les API qu'elle appelle, sur le build que téléchargent vos clients
- Se connecte avec vos comptes de test et complète les codes à usage unique pour tester les paiements, les modifications de bénéficiaires et les sessions
- 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é
- Banques enregistrées, dépositaires non bancaires agréés et assureurs pour les textes de la RBNZ sur la cyberrésilience ; dépositaires agréés pour les normes de la DTA
- Dates clés
- Déclaration des incidents cyber importants depuis le 8 avril 2024 ; norme sur la résilience opérationnelle applicable au 1er décembre 2028
- Objet
- Tests de sécurité, gestion des vulnérabilités et des correctifs, assurance TIC, risque lié aux tiers et déclaration des incidents
- Texte de référence
- Guidance on Cyber Resilience de la RBNZ, avril 2021
Les textes néo-zélandais qui encadrent votre canal mobile
Les lignes directrices et la collecte de données sur la cyberrésilience sont venues d'abord, puis la Deposit Takers Act 2023 et ses normes, et les règles de confidentialité qui s'appliquent aux données des clients. Les dates ci-dessous concernent les textes cités sur cette page.
- Avril 2021
Guidance on Cyber Resilience
La RBNZ publie des lignes directrices pour toutes les entités qu'elle régule : des pratiques de base et avancées en matière de gouvernance, de renforcement des capacités, de partage d'information et de gestion des tiers, y compris des tests de sécurité des systèmes et réseaux.
- Juillet 2023
Deposit Takers Act 2023
Le Parlement adopte la loi qui crée un régime prudentiel unique pour les banques et les dépositaires non bancaires, avec des normes prises en tant que législation secondaire. Le Depositor Compensation Scheme entre en vigueur le 1er juillet 2025.
- 8 avril 2024
Déclaration des incidents cyber importants
Les banques enregistrées, les dépositaires non bancaires et les assureurs doivent déclarer à la RBNZ les incidents cyber importants dès que possible et dans les 72 heures suivant leur détection, au moyen d'un modèle partagé avec la FMA.
- 1er octobre 2024
Déclaration périodique et enquête sur les capacités
La déclaration périodique de tous les incidents cyber et l'auto-évaluation au regard de la Guidance on Cyber Resilience commencent. Les grandes entités déclarent les incidents tous les six mois et s'auto-évaluent chaque année ; les autres, annuellement et tous les deux ans. L'enquête de déclaration des incidents est suspendue à la date de mai 2026.
- 18 juin 2026
Projet de norme sur la résilience opérationnelle
La RBNZ ouvre la consultation sur la Deposit Takers (Operational Resilience) Standard 2027 et son projet de guide, l'une des six normes de la dernière tranche. Les contributions sont closes le 11 septembre 2026.
- 1er décembre 2028
Entrée en vigueur des normes de la DTA
Toutes les normes de la DTA doivent être publiées d'ici le 31 mai 2027 et entrer en vigueur le 1er décembre 2028, y compris la norme sur la résilience opérationnelle et ses exigences pour les systèmes TIC, les fournisseurs de services importants et la continuité d'activité.
- Tous les 12 mois
Tests de continuité d'activité
Selon le projet de norme, un dépositaire doit tester son plan de continuité d'activité au moins une fois par période de 12 mois, sur une série de scénarios graves mais plausibles, et documenter les résultats.
Les règles néo-zélandaises, appliquées à votre application mobile
Pour chaque règle : ce que dit le texte, ce que cela implique pour une application bancaire mobile, comment Ostorlab vous aide et ce qui reste du ressort de votre équipe. La norme sur la résilience opérationnelle est un projet soumis à consultation du 18 juin au 11 septembre 2026.
- Guidance on Cyber Resilience de la RBNZ, avril 2021, A1 ; Deposit Takers (Operational Resilience) Standard 2027, projet, clauses 13 et 33
Porter la cyberrésilience au niveau du conseil
Ce que dit le texte
Le conseil devrait être ultimement responsable de la cyberrésilience de l'entité, avec un dirigeant responsable de la stratégie et du cadre de cyberrésilience. Il devrait comprendre l'environnement de risque cyber, déterminer la tolérance et l'appétit pour le risque cyber, approuver la stratégie et le cadre, et suivre leur mise en œuvre. Le projet de norme sur la résilience opérationnelle rend le conseil responsable de l'approbation des niveaux de tolérance des opérations critiques et des systèmes TIC, du cadre de gestion du risque opérationnel, de la politique relative aux systèmes TIC et des plans de continuité d'activité.
Ce que cela implique pour votre application mobile
La gouvernance se situe au-dessus de l'application, mais c'est elle qui décide si le canal mobile est testé selon un calendrier et si les résultats remontent au conseil.
Comment Ostorlab vous aide
Ostorlab fournit aux équipes sécurité et à la direction des preuves par version : ce qui a été testé, ce qui a été trouvé, ce qui a été corrigé et ce qui a été retesté.
Ce qui reste de votre ressort
Les approbations du conseil, l'appétit pour le risque, la responsabilité, l'audit interne et les ressources du programme de tests.
- Guidance on Cyber Resilience de la RBNZ, B3.7 à B3.7.2 ; projet de guide de la norme sur la résilience opérationnelle, juin 2026, paragraphes 71.3 et 97.3
Mener des tests de sécurité régulièrement et après tout changement majeur
Ce que dit le texte
L'entité devrait mener des tests de sécurité sur ses systèmes et réseaux afin de détecter les faiblesses exploitables par une cyberattaque ou susceptibles de l'exposer à un incident. Les tests devraient être menés régulièrement, ainsi qu'à chaque changement majeur de la situation des menaces, par exemple lors de la mise en œuvre de nouveaux systèmes ou technologies, et impliquer les équipes internes et les tiers concernés si nécessaire. Le projet de guide de la norme sur la résilience opérationnelle attend des évaluations des vulnérabilités des systèmes TIC, y compris des tests d'efficacité des contrôles de sécurité et des assurances, ainsi que des tests adversariaux comme des exercices de red team pour valider les contrôles face à des scénarios d'attaque plausibles.
Ce que cela implique pour votre application mobile
Chaque version mobile est un changement majeur apporté à un canal exposé à Internet. L'application et les API qu'elle appelle devraient être testées avant la mise à jour en store et à intervalles réguliers entre les versions.
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. Des scans automatisés s'exécutent depuis votre pipeline CI/CD à chaque build.
Ce qui reste de votre ressort
Le cadrage, les exercices de red team ou de TLPT, et la manière dont les résultats de test alimentent le cadre de risque.
- Projet de guide de la norme sur la résilience opérationnelle, juin 2026, tableau 6 ; projet de norme, clause 21(4)
Gérer les vulnérabilités et les correctifs selon des délais documentés
Ce que dit le texte
Le projet de guide énumère les contrôles de sécurité de l'information attendus : des processus de gestion des vulnérabilités pour identifier, évaluer, hiérarchiser et traiter les vulnérabilités en temps utile, y compris lorsque de nouvelles vulnérabilités et menaces sont découvertes, et des processus de gestion des correctifs pour évaluer, tester lorsque c'est approprié et appliquer les correctifs et autres mises à jour sur les actifs matériels et logiciels, y compris les composants fournis par des tiers. Lorsqu'une faiblesse de contrôle importante pourrait mener à un incident TIC important et qu'elle ne sera probablement pas corrigée à temps, le projet de norme exige que la RBNZ en soit informée dans les 10 jours ouvrables.
Ce que cela implique pour votre application mobile
Les SDK et bibliothèques natives de votre application sont des logiciels livrés, avec des versions et des correctifs. Une vulnérabilité que vous ne voyez pas est une vulnérabilité sans délai de correction.
Comment Ostorlab vous aide
SCA identifie les bibliothèques compilées statiquement et les rapproche des vulnérabilités connues, version après version. Les résultats sont classés critiques, élevés, moyens ou faibles, suivis sous forme de tickets dans la plateforme ou dans Jira et ServiceNow, et retestés une fois le correctif publié.
Ce qui reste de votre ressort
L'application des correctifs sur les serveurs et l'infrastructure, les décisions de calendrier, les contrats de maintenance et l'acceptation des risques.
- Deposit Takers (Operational Resilience) Standard 2027, projet, clause 20 ; projet de guide, paragraphes 99 à 102
Fournir l'assurance que les contrôles fonctionnent, y compris pour les TIC de tiers
Ce que dit le texte
Un dépositaire doit maintenir des contrôles de sécurité de l'information qui limitent l'accès à l'information aux personnes autorisées, ainsi que des processus d'assurance confirmant l'efficacité de ces contrôles et de ses processus de partage d'information. L'assurance doit être suffisante pour confirmer que les contrôles répondent aux menaces et vulnérabilités en évolution, et doit s'étendre aux systèmes TIC fournis ou maintenus par un tiers. Le projet de guide attend un processus d'assurance documenté, mené périodiquement et selon les risques, et répété après des changements ou incidents importants.
Ce que cela implique pour votre application mobile
L'application, son backend et les services qui la sous-tendent forment un seul système. L'assurance doit couvrir les parties exploitées par d'autres, y compris les services d'identité, de fraude et de cloud dont dépend l'application.
Comment Ostorlab vous aide
Ostorlab teste les contrôles de l'application et de ses API et produit des preuves pour chaque résultat, qui peuvent alimenter le dossier d'assurance aux côtés du reste de l'environnement de contrôle.
Ce qui reste de votre ressort
Le cadre d'assurance lui-même, la conception des contrôles et la décision sur ce qui constitue une preuve suffisante.
- Guidance on Cyber Resilience de la RBNZ, B1.4.1, B2.5 et B2.8 ; projet de guide de la norme sur la résilience opérationnelle, tableau 6
Intégrer la sécurité et tester chaque changement
Ce que dit le texte
L'entité devrait disposer de politiques, procédures et contrôles de gestion du changement, la cybersécurité étant prise en compte tout au long du cycle de vie du changement. À titre de pratique avancée, elle devrait adopter une approche de « résilience dès la conception », en intégrant les mesures de résilience dès la première étape de conception et de développement, et mener des évaluations du risque cyber avant l'introduction de technologies, produits, services ou processus nouveaux ou modifiés. Les domaines de contrôle du projet de guide incluent la gestion du changement, la gestion de la configuration, ainsi que les environnements de déploiement et de test sécurisés des nouvelles fonctionnalités.
Ce que cela implique pour votre application mobile
Chaque version de l'application modifie un canal exposé à Internet. Les tests automatisés dans le pipeline couvrent l'avant ; les scans des versions publiées sur les stores couvrent l'après.
Comment Ostorlab vous aide
Mobile SAST analyse directement l'APK, l'AAB ou l'IPA, sans code source, y compris l'analyse de propagation (taint) dans les SDK intégrés. Mobile DAST exécute l'application et capture le trafic, les traces d'exécution et les captures d'écran. Les deux s'exécutent depuis votre pipeline CI/CD à chaque build, et les versions publiées sur les stores sont surveillées sans déclenchement manuel.
Ce qui reste de votre ressort
Les normes de développement sécurisé, les revues de conception, la formation des développeurs et l'approbation des mises en production.
- Guidance on Cyber Resilience de la RBNZ, D1.1, D2.1, D4.1 et D5.1 ; Deposit Takers (Operational Resilience) Standard 2027, projet, clauses 12 et 22 à 26
Évaluer les tiers et les fournisseurs de services importants
Ce que dit le texte
L'entité devrait évaluer la criticité et la sensibilité des activités avant toute externalisation, réaliser et documenter une diligence raisonnable avant la signature, concevoir et vérifier des contrôles pour détecter et empêcher les intrusions venant des connexions tierces, intégrer les tiers critiques dans son plan de réponse et évaluer régulièrement leurs capacités de cybersécurité. Selon le projet de norme, un fournisseur de services important est un tiers qui fournit une opération critique ; le dépositaire doit enquêter sur sa capacité avant de conclure l'accord, documenter et suivre les termes, tenir un registre et disposer d'une politique de gestion de ces fournisseurs.
Ce que cela implique pour votre application mobile
Une application bancaire mobile embarque des SDK tiers qui communiquent avec leurs propres backends, et elle peut dépendre d'un fournisseur de fraude ou d'identité. Ils ont leur place dans votre inventaire et votre vision du risque lié aux tiers.
Comment Ostorlab vous aide
Ostorlab recense les SDK et bibliothèques natives de chaque version avec leurs versions et leur emplacement dans le bundle, montre ce que l'application et ses SDK échangent avec les backends sur le réseau, et peut tester les API qu'un fournisseur expose à l'application.
Ce qui reste de votre ressort
Les contrats, le registre des fournisseurs de services importants, les dossiers de diligence raisonnable, la surveillance et les plans de sortie.
- Cyber resilience for regulated entities de la RBNZ, collecte de données, mise à jour du 6 mai 2026 ; Material Cyber Incident Notification FAQs ; Deposit Takers (Operational Resilience) Standard 2027, projet, clause 21
Déclarer les incidents importants et s'auto-évaluer selon le calendrier
Ce que dit le texte
Les incidents cyber importants doivent être déclarés à la RBNZ dès que possible et dans les 72 heures suivant leur détection, au moyen d'un modèle qui peut aussi servir à la FMA. La déclaration périodique de tous les incidents cyber est suspendue à la date de mai 2026. Les entités déclarent aussi une auto-évaluation au regard de la Guidance on Cyber Resilience : les grandes entités chaque année, les autres tous les deux ans. Le projet de norme ajoute l'obligation d'informer la RBNZ d'un incident TIC important au plus tard 72 heures après en avoir pris connaissance, avec la gravité, l'impact et toute solution viable.
Ce que cela implique pour votre application mobile
Le compte à rebours commence à la détection de l'incident. Les informations de triage sur l'application et ses API doivent être reconstituables, et un problème d'application ou d'API peut en être le déclencheur.
Comment Ostorlab vous aide
Ostorlab ne gère pas la réponse aux incidents et ne dépose pas de déclarations. Il fournit des résultats sur l'application et les API avec des étapes de reproduction, les versions concernées et des preuves de requêtes et réponses que votre équipe peut utiliser pendant une investigation, puis reteste la correction.
Ce qui reste de votre ressort
La détection, le triage, la notification à la RBNZ et à la FMA, la réponse aux incidents et le récit de l'auto-évaluation.
- Deposit Takers (Operational Resilience) Standard 2027, projet, clauses 8, 27 et 29
Tester le plan de continuité d'activité
Ce que dit le texte
Un dépositaire doit disposer d'un plan de continuité d'activité documenté pour ses opérations critiques, revu régulièrement et testé régulièrement. Le programme de tests doit couvrir chaque opération critique du registre, porter sur les risques importants auxquels le dépositaire fait face et tester l'efficacité du plan dans une série de scénarios graves mais plausibles. Un test doit être mené au moins une fois par période de 12 mois. Les revues et les tests doivent être documentés, et les faiblesses traitées en temps utile.
Source :Deposit Takers (Operational Resilience) Standard 2027, projet, clauses 8, 27 et 29
Ce que cela implique pour votre application mobile
Les paiements, les dépôts et les règlements inscrits au registre passent par le canal mobile. Le plan détermine comment les clients sont servis lorsque l'application ou ses API tombent en panne.
Comment Ostorlab vous aide
Ostorlab n'est pas un outil de continuité d'activité. Il maintient la partie application et API du plan testée entre les exercices, avec des résultats, des tickets et des retests sur lesquels vos scénarios peuvent s'appuyer.
Ce qui reste de votre ressort
Le plan lui-même, la conception des scénarios, la conduite des tests, l'assurance au conseil et la déclaration à la RBNZ lors de l'activation du plan.
- Privacy Act 2020, article 22, IPP 5 et 12, et partie 6 ; Office of the Privacy Commissioner, Principle 5 ; Privacy Amendment Act 2025
Protéger les informations personnelles et notifier les violations graves
Ce que dit le texte
Selon la Privacy Act 2020, une agence qui détient des informations personnelles doit les protéger par des garanties raisonnables dans les circonstances contre la perte, l'accès, l'utilisation, la modification ou la divulgation non autorisés, et tout autre usage abusif. Les divulgations hors de Nouvelle-Zélande ne sont permises que si le destinataire est soumis à la loi, est soumis à des garanties comparables, ou si la personne autorise la divulgation après avoir été informée que les protections peuvent différer. Une violation susceptible de causer un préjudice grave doit être notifiée au Commissaire à la protection de la vie privée et aux personnes concernées dès que possible ; le Commissaire attend une notification dans les 72 heures. La Privacy Amendment Act 2025 a ajouté la règle IPP 3A sur la collecte indirecte, en vigueur depuis le 1er mai 2026.
Ce que cela implique pour votre application mobile
Les numéros de compte, les données d'identité et les jetons de session ne devraient pas rester sans protection sur le téléphone ni transiter sans protection vers le backend, et un traitement à l'étranger exige une vérification des garanties comparables.
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 montre vers quels services tiers et quels emplacements l'application envoie des données.
Ce qui reste de votre ressort
Les analyses d'impact sur la vie privée, les mentions et le consentement, les contrats avec les fournisseurs à l'étranger et la notification des violations.
Synthèse de textes publics néo-zélandais, vérifiés le 27 septembre 2026. La Deposit Takers (Operational Resilience) Standard 2027 est un projet soumis à consultation du 18 juin au 11 septembre 2026, susceptible d'évoluer avant sa publication et son entrée en vigueur le 1er décembre 2028. La Guidance on Cyber Resilience de la RBNZ est un guide, pas un règlement. Cette page ne constitue pas un avis juridique.
Les règles néo-zélandaises, contrôle par contrôle
Les contrôles visés par les textes néo-zélandais, 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 |
|---|---|---|
| Tests de sécurité réguliers des systèmes et réseauxLD cyberrésilience B3.7 | 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 |
| Tests après un changement majeur et les nouvelles technologiesLD cyberrésilience B3.7.1 ; guide RO 71.3 | Mobile SAST et DAST dans la CI/CD à chaque build, et surveillance des versions publiées sur les stores. Détails | Résultats de scan par build et par version publiée sur les stores |
| Gestion des vulnérabilités et des correctifs pour les actifs logicielsGuide RO, tableau 6 | Identifie par empreinte les bibliothèques compilées statiquement et les associe aux vulnérabilités connues, d'une version à l'autre. Détails | Vulnérabilités identifiées avec recommandations de mise à niveau ou de remplacement, et résolution suivie d'une version à l'autre |
| SDK, bibliothèques natives et inventaire des composantsGuide RO, paragraphe 96 | 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 |
| Assurance que les contrôles de sécurité de l'information fonctionnentProjet de norme RO, clause 20 | Teste les contrôles de l'application et de ses API et produit une preuve par résultat pour le dossier d'assurance. Détails | Résultats avec étapes de reproduction et preuves, par contrôle |
| Gestion du changement et déploiement sécuriséLD cyberrésilience B2.5 et B2.8 | Mobile SAST sur le binaire et Mobile DAST sur l'application en cours d'exécution, avant la mise en production. Détails | Résultats avec contexte du code décompilé, trafic, traces d'appels et captures d'écran |
| Connexions tierces et fournisseurs de services importantsLD cyberrésilience D4.1 ; projet de norme RO, clauses 22 à 26 | Recense les SDK et backends avec lesquels l'application communique et teste les API exposées par ces services. Détails | Preuves sur les composants et le réseau pour la diligence raisonnable et la surveillance |
| Notification des incidents importants dans les 72 heuresFAQ MCIN ; projet de norme RO, clause 21 | Ostorlab ne déclare pas les incidents ; les résultats incluent les étapes de reproduction, les versions concernées et les preuves de requêtes et réponses pour votre investigation. | Résultats de retest montrant que la correction a clos le résultat |
| Tests du plan de continuité d'activité tous les 12 moisProjet de norme RO, clauses 8 et 29 | Maintient la partie application et API du plan testée entre les exercices, avec des tickets et des retests. Détails | Historique des tickets et issue du retest pour chaque résultat |
| Informations personnelles sur l'appareil et en transitPrivacy Act 2020, IPP 5 et 12 | 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 |
Ostorlab teste les contrôles de l'application et de ses API. La réponse aux incidents et leur déclaration, la continuité d'activité, la gouvernance du conseil, la surveillance SOC, les exercices de red team ou de TLPT et les décisions en matière de vie privée restent du ressort de vos équipes.
Les contrôles néo-zélandais à tester dans votre application mobile
Une liste pratique pour les équipes sécurité et risque opérationnel, fondée sur les textes de la RBNZ sur la cyberrésilience, le projet de norme sur la résilience opérationnelle et la Privacy Act 2020.
Application mobile dans le périmètre
Intégrez l'application mobile au périmètre de votre programme de tests de sécurité, avec une fréquence et une étape préalable à la mise en production.
Tests à chaque changement
Déclenchez des tests de l'application et des API à chaque version, pas seulement lors de la revue annuelle, et conservez les résultats.
Vulnérabilités et délais
Tenez une liste versionnée des SDK et bibliothèques de chaque version, et fixez des délais de correction selon la gravité.
Assurance sur les tiers
Vérifiez que l'assurance de l'application et de ses API couvre les services fournis par d'autres, y compris les backends des SDK et le cloud.
Résultats qui remontent au conseil
Alimentez le reporting à la direction et au conseil attendu par le guide avec les résultats de chaque version.
Préparation aux incidents
Testez ce que l'application et les API journalisent et exposent, pour que la notification sous 72 heures et celle sous 10 jours ouvrables reposent sur des faits.
Continuité d'activité
Incluez un scénario de canal mobile dans les scénarios graves mais plausibles testés au moins une fois tous les 12 mois.
Vie privée sur l'appareil
Recherchez les jetons et les données personnelles dans le stockage, les caches, les journaux et les captures d'écran, et vérifiez où l'application envoie les données.
Une liste indicative, et non un modèle de la RBNZ. 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.
- Guidance on Cyber ResilienceRBNZ, avril 2021. Pratiques de base et avancées pour les banques enregistrées, les dépositaires non bancaires agréés, les assureurs agréés et les infrastructures de marché financier désignées, y compris les tests de sécurité des systèmes et réseaux (B3.7) et la gestion des tiers (partie D)
- Cyber resilience for regulated entities et collecte de données sur la cyberrésilienceRBNZ, page publiée le 28 février 2022, mise à jour le 6 mai 2026. Déclaration des incidents cyber importants dans les 72 heures, déclaration périodique de tous les incidents cyber (enquête suspendue) et auto-évaluation au regard du guide
- Material Cyber Incident Notification FAQsRBNZ, guide du modèle. L'obligation de déclaration des incidents cyber importants a commencé le 8 avril 2024 et les incidents doivent être déclarés dans les 72 heures suivant leur détection ; le modèle peut aussi servir à la FMA
- Deposit Takers (Operational Resilience) Standard 2027, projetRBNZ, juin 2026. Prise en application de l'article 72 de la Deposit Takers Act 2023, soumise à consultation du 18 juin au 11 septembre 2026 et applicable au 1er décembre 2028. Clauses 8, 12, 13, 18 à 21, 22 à 26, 27 à 29 et 33
- Guidance Note : Operational Resilience Standard (projet de guide)RBNZ, juin 2026. Guide d'accompagnement du projet, incluant les contrôles de gestion des vulnérabilités et des correctifs (tableau 6), les attentes en matière d'assurance (paragraphes 99 à 102) et les tests adversariaux (paragraphe 97.3)
- Deposit Takers Act 2023 (2023 No 35)New Zealand Legislation. Crée le régime prudentiel unique des dépositaires et le pouvoir d'édicter des normes en tant que législation secondaire. Toutes les normes de la DTA doivent être publiées d'ici le 31 mai 2027 et entrer en vigueur le 1er décembre 2028
- Privacy Act 2020 (2020 No 31)New Zealand Legislation. Principes de confidentialité 5 et 12, et dispositions sur les violations notifiables de la partie 6. Modifiée par la Privacy Amendment Act 2025 (2025 No 53), qui a ajouté l'IPP 3A sur la collecte indirecte, en vigueur le 1er mai 2026
- New Zealand Anti-Scam Alliance Work Programme 2026Ministry of Business, Innovation and Employment, actions de juin à décembre 2026. Comprend l'extension du système Confirmation of Payee des banques, un service sectoriel qui vérifie si le nom d'un titulaire correspond au numéro de compte
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 au regard des attentes de la RBNZ
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.