RBNZ cyber resilience: test your mobile banking app before and after every release.
The RBNZ's Guidance on Cyber Resilience expects entities to conduct security tests on their systems and networks, on a regular basis and whenever a major change occurs. The Deposit Takers (Operational Resilience) Standard 2027, consulted on in 2026 and due to commence on 1 December 2028, adds vulnerability and patch management, assurance over ICT systems, and 72-hour notification of material ICT incidents. Ostorlab tests your app and the APIs behind it, behind login, on every release.
- Tests the app and the APIs behind it on the build your customers download
- Logs in with your test accounts and completes one-time codes to test payments, payee changes and sessions
- Lists the SDKs and native libraries in each release and maps them to known vulnerabilities
- Proves each finding with a replayable exploit or request and response evidence
- Who it applies to
- Registered banks, licensed non-bank deposit takers and insurers for the RBNZ cyber resilience texts; licensed deposit takers for the DTA standards
- Key dates
- Material cyber incident reporting from 8 April 2024; Operational Resilience Standard due to commence on 1 December 2028
- Focus
- Security testing, vulnerability and patch management, ICT assurance, third-party risk and incident reporting
- Main reference
- RBNZ Guidance on Cyber Resilience, April 2021
The New Zealand texts behind your mobile channel
The cyber resilience guidance and data collection came first, followed by the Deposit Takers Act 2023 and its standards, and the privacy rules that apply to customer data. The dates below are for the texts cited on this page.
- April 2021
Guidance on Cyber Resilience
The RBNZ publishes guidance for all entities it regulates: baseline and enhanced practices in governance, capability building, information sharing and third-party management, including security testing of systems and networks.
- July 2023
Deposit Takers Act 2023
Parliament passes the Act that creates a single prudential regime for banks and non-bank deposit takers, with standards made as secondary legislation. The Depositor Compensation Scheme commences on 1 July 2025.
- 8 April 2024
Material cyber incident reporting
Registered banks, non-bank deposit takers and insurers must report material cyber incidents to the RBNZ as soon as practicable and within 72 hours of detection, using a template shared with the FMA.
- 1 October 2024
Periodic reporting and capability survey
Periodic reporting of all cyber incidents and the self-assessment survey against the Guidance on Cyber Resilience begin. Large entities report incidents every six months and self-assess every year; other entities annually and every two years. The incident reporting survey is paused as at May 2026.
- 18 June 2026
Operational Resilience Standard exposure draft
The RBNZ opens consultation on the Deposit Takers (Operational Resilience) Standard 2027 and its draft guidance, one of six draft standards in the final tranche. Submissions close on 11 September 2026.
- 1 December 2028
DTA standards commence
All DTA standards are due to be issued by 31 May 2027 and commence on 1 December 2028, including the Operational Resilience Standard with its requirements for ICT systems, material service providers and business continuity.
- Every 12 months
Business continuity testing
Under the exposure draft, a deposit taker must test its business continuity plan at least once in a 12-month period, across severe but plausible scenarios, and document the results.
The New Zealand rules, applied to your mobile app
For each rule: what the text says, what it means for a mobile banking app, how Ostorlab helps, and what stays with your team. The operational resilience standard is an exposure draft consulted on from 18 June to 11 September 2026.
- RBNZ Guidance on Cyber Resilience, April 2021, A1; Deposit Takers (Operational Resilience) Standard 2027 exposure draft, clauses 13 and 33
Own cyber resilience at board level
What the text says
The board should be ultimately responsible for the cyber resilience of an entity, with a senior executive accountable for the cyber resilience strategy and framework. It should understand the cyber risk environment, determine the entity's cyber risk tolerance and appetite, approve the strategy and framework, and monitor implementation. The draft Operational Resilience Standard makes the board responsible for approving the tolerance levels for critical operations and ICT systems, the operational risk management framework, the ICT systems policy and the business continuity plans.
What it means for your mobile app
Governance sits above the app, but it decides whether the mobile channel is tested on a schedule and whether findings reach the board.
How Ostorlab helps
Ostorlab gives security teams and senior management per-release evidence: what was tested, what was found, what was fixed and what was retested.
What stays with you
Board approvals, risk appetite, accountability, internal audit and the resourcing behind the testing programme.
- RBNZ Guidance on Cyber Resilience, B3.7 to B3.7.2; Operational Resilience Standard draft guidance, June 2026, paragraphs 71.3 and 97.3
Conduct security tests regularly and after major change
What the text says
The entity should conduct security tests on its systems and networks to detect weaknesses that could be exploited by a cyberattack or leave it exposed to a cyber incident. The tests should be conducted on a regular basis, as well as each time a major change occurs to the cyber threat status of the entity, such as when it implements new systems or technologies, and should involve internal teams and relevant third parties where necessary. The draft guidance for the Operational Resilience Standard expects ICT systems vulnerability assessments, including security controls effectiveness tests and assurances, and adversarial testing such as red team exercises to validate controls against plausible attack scenarios.
What it means for your mobile app
A mobile release is a major change to an internet-facing channel. The app and the APIs it calls should be tested before the store update and on a regular cadence between releases.
How Ostorlab helps
An AI-agent pentest tests the app and its APIs behind login, on the build you ship, with a working exploit you can replay for each AI-agent finding. Automated scans run from your CI/CD pipeline on every build.
What stays with you
Scoping, red team or TLPT exercises, and deciding how test results feed the risk framework.
- Operational Resilience Standard draft guidance, June 2026, Table 6; exposure draft, clause 21(4)
Manage vulnerabilities and patches on documented deadlines
What the text says
The draft guidance lists the information security controls it expects: vulnerability management processes for identifying, assessing, prioritising and addressing vulnerabilities in a timely manner, including where new vulnerabilities and threats are discovered, and patch management processes for assessing, testing where appropriate and applying patches and other updates across hardware and software assets, including vendor-provided components. Where a material control weakness could lead to a material ICT systems incident and is unlikely to be remediated in time, the exposure draft requires the RBNZ to be notified within 10 business days.
Source:Operational Resilience Standard draft guidance, June 2026, Table 6; exposure draft, clause 21(4)
What it means for your mobile app
The SDKs and native libraries in your app are software assets with versions and patches. A vulnerability you cannot see is a vulnerability you cannot put a deadline on.
How Ostorlab helps
SCA fingerprints statically compiled libraries and maps them to known vulnerabilities, release to release. Findings are rated critical, high, medium or low, tracked as tickets in the platform or in Jira and ServiceNow, and retested once the fix ships.
What stays with you
Patching servers and infrastructure, timing decisions, vendor maintenance contracts and risk acceptance.
- Deposit Takers (Operational Resilience) Standard 2027 exposure draft, clause 20; draft guidance, paragraphs 99 to 102
Give assurance that controls work, including for third-party ICT
What the text says
A deposit taker must maintain information security controls that restrict access to information to authorised persons, and assurance processes that confirm those controls and its information-sharing processes are effective. The assurance must be adequate to confirm the controls are responding to evolving threats and vulnerabilities, and must extend to ICT systems provided or maintained by another person. The draft guidance expects the assurance process to be documented, run periodically and on a risk basis, and repeated after material changes or incidents.
What it means for your mobile app
The app, its backend and the services behind it are one system. Assurance has to cover the parts run by others, including the identity, fraud and cloud services the app depends on.
How Ostorlab helps
Ostorlab tests the controls in the app and its APIs and produces evidence per finding, so the results can feed the assurance file alongside the rest of the control environment.
What stays with you
The assurance framework itself, control design, and deciding what evidence is sufficient.
- RBNZ Guidance on Cyber Resilience, B1.4.1, B2.5 and B2.8; Operational Resilience Standard draft guidance, Table 6
Build security in and test every change
What the text says
The entity should have policies, procedures and controls for change management, with cyber security considered throughout the change lifecycle. As an enhanced practice it should adopt a resilience by design approach, embedding resilience measures from the first stage of design and development, and conduct cyber risk assessments before new or updated technologies, products, services or processes are introduced. The draft guidance's control areas include change management, configuration management, and secure deployment and testing environments for new functionality.
What it means for your mobile app
Every app release is a change to an internet-facing channel. Automated testing in the pipeline covers the before; scans of store releases cover the after.
How Ostorlab helps
Mobile SAST analyses the APK, AAB or IPA directly, with no source code needed, including taint analysis across embedded SDKs. Mobile DAST runs the app and captures traffic, stack traces and screenshots. Both run from your CI/CD pipeline on every build, and store releases are monitored without manual triggers.
What stays with you
Secure coding standards, design reviews, developer training and release approval.
- RBNZ Guidance on Cyber Resilience, D1.1, D2.1, D4.1 and D5.1; Deposit Takers (Operational Resilience) Standard 2027 exposure draft, clauses 12 and 22 to 26
Assess third parties and material service providers
What the text says
The entity should assess the criticality and sensitivity of activities before outsourcing, perform and document due diligence before signing, design and verify controls to detect and prevent intrusions from third-party connections, integrate critical third parties into its response plan, and regularly assess their cybersecurity capabilities. Under the exposure draft, a material service provider is a third party that provides a critical operation; the deposit taker must inquire into its ability before entering the arrangement, document and monitor the terms, keep a register, and have a policy for managing these providers.
What it means for your mobile app
A mobile banking app bundles third-party SDKs that talk to their own backends, and the app may depend on a fraud or identity provider. They belong in your inventory and your third-party risk view.
How Ostorlab helps
Ostorlab lists the SDKs and native libraries in each release with their versions and location in the app bundle, shows what the app and its SDKs exchange with backends over the network, and can test the APIs a provider exposes to the app.
What stays with you
Contracts, the material service provider register, due diligence records, monitoring and exit plans.
- RBNZ cyber resilience for regulated entities, data collection, updated 6 May 2026; Material Cyber Incident Notification FAQs; Deposit Takers (Operational Resilience) Standard 2027 exposure draft, clause 21
Report material incidents and self-assess on schedule
What the text says
Material cyber incidents must be reported to the RBNZ as soon as practicable and within 72 hours of detection, using a template that can also serve the FMA. The periodic reporting of all cyber incidents is paused as at May 2026. Entities also report a self-assessment against the Guidance on Cyber Resilience: large entities every year, other entities every two years. The exposure draft adds a duty to notify the RBNZ of a material ICT systems incident no later than 72 hours after becoming aware of it, with details of severity, impact and any viable solution.
What it means for your mobile app
The clock starts when an incident is detected. Triage information about the app and its APIs has to be reconstructable, and an app or API issue can be the trigger.
How Ostorlab helps
Ostorlab does not run incident response or file reports. It gives you app and API findings with reproduction steps, affected versions and request and response evidence that your team can use during an investigation, and retests the fix.
What stays with you
Detection, triage, notification to the RBNZ and the FMA, incident response and the self-assessment narrative.
- Deposit Takers (Operational Resilience) Standard 2027 exposure draft, clauses 8, 27 and 29
Test the business continuity plan
What the text says
A deposit taker must have a documented business continuity plan for its critical operations, reviewed regularly and tested on a regular basis. The testing programme must cover every critical operation in the register, focus on the material risks facing the deposit taker, and test the effectiveness of the plan in a range of severe but plausible scenarios. A test must be conducted at least once in a 12-month period. Reviews and tests must be documented, and weaknesses addressed in a timely manner.
Source:Deposit Takers (Operational Resilience) Standard 2027 exposure draft, clauses 8, 27 and 29
What it means for your mobile app
Payments, deposits and settlements in the register run through the mobile channel. The plan decides how customers are served when the app or its APIs fail.
How Ostorlab helps
Ostorlab is not a business continuity tool. It keeps the app and API side of the plan tested between exercises, with findings, tickets and retest results your scenarios can rely on.
What stays with you
The plan itself, scenario design, running the tests, board assurance and reporting to the RBNZ when the plan is activated.
- Privacy Act 2020, section 22 IPPs 5 and 12, and Part 6; Office of the Privacy Commissioner, Principle 5; Privacy Amendment Act 2025
Protect personal information and notify serious breaches
What the text says
Under the Privacy Act 2020, an agency that holds personal information must protect it with security safeguards that are reasonable in the circumstances against loss, unauthorised access, use, modification or disclosure, and other misuse. Disclosures outside New Zealand are allowed only where the recipient is subject to the Act, is subject to comparable safeguards, or the individual authorises the disclosure after being told the protections may differ. A breach likely to cause serious harm must be notified to the Privacy Commissioner and affected individuals as soon as practicable; the Commissioner's expectation is notification within 72 hours. The Privacy Amendment Act 2025 added IPP 3A on indirect collection, in force since 1 May 2026.
What it means for your mobile app
Account numbers, identity data and session tokens should not sit unprotected on the phone or travel unprotected to the backend, and offshore processing needs a comparable safeguards check.
How Ostorlab helps
Ostorlab looks for session tokens and personal data in local storage, caches, logs and screenshots, checks transport protections, and shows which third-party services and locations the app sends data to.
What stays with you
Privacy impact assessments, notices and consent, contracts with offshore providers, and breach notification.
Summary of public New Zealand texts, checked on 27 September 2026. The Deposit Takers (Operational Resilience) Standard 2027 is an exposure draft consulted on from 18 June to 11 September 2026 and may change before it is issued and commences on 1 December 2028. The RBNZ Guidance on Cyber Resilience is guidance, not a rulebook. This page is not legal advice.
New Zealand rules, control by control
The controls the New Zealand texts point to, how Ostorlab tests them in your app and its APIs, and the evidence you can keep.
| Control | How Ostorlab helps | Evidence you keep |
|---|---|---|
| Regular security testing of systems and networksCyber Resilience Guidance B3.7 | AI-agent pentest of the app and its APIs, behind login, on the build you ship. Details | A working exploit you can replay for each AI-agent finding, and a coverage heatmap |
| Testing after major change and new technologiesCyber Resilience Guidance B3.7.1; OR guidance 71.3 | Mobile SAST and DAST in CI/CD on every build, and monitoring of store releases. Details | Scan results per build and per store release |
| Vulnerability and patch management for software assetsOR guidance, Table 6 | Fingerprints statically compiled libraries and maps them to known vulnerabilities, release to release. Details | Mapped vulnerabilities with upgrade or replace recommendations, and closure tracked across releases |
| SDKs, native libraries and component inventoryOR guidance, paragraph 96 | Lists the SDKs and native libraries in each release with their versions, and shows which backends the app and its SDKs talk to. Details | Component identity, version and location in the app bundle, per release |
| Assurance that information security controls workOR exposure draft, clause 20 | Tests the controls in the app and its APIs and produces evidence per finding for the assurance file. Details | Findings with reproduction steps and evidence, per control |
| Change management and secure deploymentCyber Resilience Guidance B2.5 and B2.8 | Mobile SAST on the binary and Mobile DAST on the running app, before release. Details | Findings with decompiled source context, traffic, stack traces and screenshots |
| Third-party connections and material service providersCyber Resilience Guidance D4.1; OR exposure draft, clauses 22 to 26 | Lists the SDKs and backends the app talks to and tests the APIs those services expose. Details | Component and network evidence for due diligence and monitoring |
| Material incident notification within 72 hoursMCIN FAQs; OR exposure draft, clause 21 | Ostorlab does not report incidents; findings come with reproduction steps, affected versions and request and response evidence for your investigation. | Retest results showing the fix closed the finding |
| Business continuity plan testing every 12 monthsOR exposure draft, clauses 8 and 29 | Keeps the app and API side of the plan tested between exercises, with tickets and retests. Details | Ticket history and retest result for each finding |
| Personal information on the device and in transitPrivacy Act 2020, IPPs 5 and 12 | Looks for tokens and personal data in storage, caches, logs and screenshots, and checks transport protections. Details | File system evidence showing what was written, where and when |
Ostorlab tests controls in the app and its APIs. Incident response and reporting, business continuity planning, board governance, SOC monitoring, red team or TLPT exercises and privacy decisions stay with your teams.
New Zealand controls to test in your mobile app
A practical list for security and operational risk teams, based on the RBNZ cyber resilience texts, the operational resilience exposure draft and the Privacy Act 2020.
Mobile app in scope
Put the mobile app in the scope of your security testing programme, with a frequency and a pre-release step.
Tests on change
Trigger app and API testing on every release, not only on the annual review cycle, and record the results.
Vulnerabilities and deadlines
Keep a versioned list of the SDKs and libraries in each release, and set fix deadlines by severity.
Assurance over third parties
Check that assurance for the app and its APIs reaches the services provided by others, including SDK backends and cloud.
Findings that reach the board
Feed per-release results into the management and board reporting the guidance expects.
Incident readiness
Test what the app and APIs log and expose, so the 72-hour notification and the 10 business day control weakness notice can be built on facts.
Business continuity
Include a mobile channel scenario in the severe but plausible scenarios tested at least once every 12 months.
Privacy on the device
Look for tokens and personal data in storage, caches, logs and screenshots, and check where the app sends data.
A suggested list, not an RBNZ template. This is not legal advice.
The capabilities behind this page
Each one has its own page with the details.
- Mobile Agentic Deep ScanAI agents pentest the store build on every release, with a working exploit you can replay for each AI-agent finding.Learn more
- Authenticated testingTest login, one-time codes and step-up flows with your test accounts.Learn more
- API and backend testingIntercept app traffic even with TLS pinning, then test the APIs and backends behind accounts and payments.Learn more
- Mobile SASTBinary-based static analysis of APK, AAB and IPA files, with taint analysis across the app and its embedded SDKs.Learn more
- SCA and SBOMFind vulnerable dependencies, including statically compiled native libraries, and track their closure release after release.Learn more
- Mobile Shielding ScanTest root and jailbreak detection, anti-tampering and pinning at runtime, and see which protections held and which were bypassed.Learn more
- Bring your own AI keyRun AI-agent scans on your own AI provider key with a spend cap per scan, so usage follows your internal policies.Learn more
- On-premises scanningScan staging apps, APIs and repositories behind your firewall or VPN, on infrastructure you control.Learn more
Trusted by banks and fintechs, including
Sources
The official texts this page is based on, checked on 27 September 2026.
- Guidance on Cyber ResilienceRBNZ, April 2021. Baseline and enhanced practices for registered banks, licensed non-bank deposit takers, licensed insurers and designated financial market infrastructures, including security testing of systems and networks (B3.7) and third-party management (Part D)
- Cyber resilience for regulated entities and cyber resilience data collectionRBNZ, page published 28 February 2022, last updated 6 May 2026. Material cyber incident reporting within 72 hours, periodic reporting of all cyber incidents (survey paused), and the self-assessment survey against the guidance
- Material Cyber Incident Notification FAQsRBNZ, template guidance. The material cyber incident reporting requirement commenced on 8 April 2024 and incidents must be reported within 72 hours of detection; the template can also be used for the FMA
- Deposit Takers (Operational Resilience) Standard 2027, exposure draftRBNZ, June 2026. Made under section 72 of the Deposit Takers Act 2023, consulted on from 18 June to 11 September 2026, and due to come into force on 1 December 2028. Clauses 8, 12, 13, 18 to 21, 22 to 26, 27 to 29 and 33
- Guidance Note: Operational Resilience Standard (consultation draft)RBNZ, June 2026. Draft guidance to the exposure draft, including vulnerability and patch management controls (Table 6), assurance expectations (paragraphs 99 to 102) and adversarial testing (paragraph 97.3)
- Deposit Takers Act 2023 (2023 No 35)New Zealand Legislation. Creates the single prudential regime for deposit takers and the power to make standards as secondary legislation. All DTA standards are due to be issued by 31 May 2027 and commence on 1 December 2028
- Privacy Act 2020 (2020 No 31)New Zealand Legislation. Information privacy principles 5 and 12, and the notifiable breach provisions in Part 6. Amended by the Privacy Amendment Act 2025 (2025 No 53), which added IPP 3A on indirect collection in force on 1 May 2026
- New Zealand Anti-Scam Alliance Work Programme 2026Ministry of Business, Innovation and Employment, actions for June to December 2026. Includes expansion of the banks' Confirmation of Payee system, an industry service that checks whether an account name matches the account number
Frequently asked questions
Straight answers on coverage, setup, and how results reach your team.
Can't find your answer? Book a demo or contact us.
Test your mobile banking app against the RBNZ expectations
Start with a free scan of your app from the store, or book a demo to run logged-in tests of your app and APIs with our team.