Last Updated: October 23, 2026
Quick Summary
Mobile app security compliance in New Zealand comes from overlapping sources rather than one app-specific law: the Privacy Act 2020, the NCSC’s Minimum Cyber Security Standards, and app-store security requirements. The Privacy Act 2020 is the core statute and applies to any organisation that collects personal information through an app, regardless of size.
- Map Privacy Act principles to app features: collection, awareness at collection, use limits, and disclosure.
- Biometric templates kept on-device remove an entire category of risk.
- Encrypt data at rest with AES-256 and enforce TLS with no cleartext fallback.
- Maintain a software bill of materials for third-party SDKs, generated automatically in CI.
- Both app stores require in-app account deletion for apps that support account creation.
Table of Contents
- What Mobile App Security Compliance Requirements Apply in New Zealand
- Mapping the Privacy Act 2020 to Your App’s Features
- Your Mobile App Privacy Requirements: What Users Must Be Told
- The Mobile App Security Checklist for Build and Release
- Mobile App Security Testing Before and After Launch
- App-Store and NCSC Minimum Standards: The Overlapping Obligations
- Mobile App Data Breach Response: What to Do and Who to Tell
- Frequently Asked Questions
What Mobile App Security Compliance Requirements Apply in New Zealand
Mobile app security compliance in New Zealand is not governed by one app-specific law. Obligations come from overlapping sources: the Privacy Act 2020, the National Cyber Security Centre’s Minimum Cyber Security Standards, and app-store security requirements.
The Privacy Act 2020 is the core statute. Alongside it, the NCSC’s Minimum Cyber Security Standards set a baseline of foundational practices for organisations within the Government Chief Information Security Officer’s mandate, and the standards are explicitly intended to drive sector-wide uplift.
Below, we break down what each obligation actually requires, map the privacy principles to specific app features, and give you a checklist you can work through before release.
Mapping the Privacy Act 2020 to Your App’s Features
The Privacy Act 2020 is built around the New Zealand Privacy Principles, each attaching to something your app does or fails to do. Mapping principles to features turns abstract legal text into a concrete build list.
The Information Privacy Principles That Bite on Apps
Four principles do most of the work on mobile. Principle 1 governs collection: you may only collect personal information where it is necessary for a lawful purpose connected to your functions. Principle 3 requires that, where information is collected directly from the individual, you take reasonable steps to make them aware of the collection, the purpose, the recipients, and their access and correction rights. Principle 5 limits use and disclosure to the purpose collected. Principle 11 governs disclosure to third parties.
Your onboarding screens, permission prompts, and privacy notice are compliance artefacts, not marketing copy. A common mistake is burying the privacy notice in settings when Principle 3 expects awareness at the point of collection.
Sensitive Data, Biometrics and Children’s Information
Sensitive information attracts a higher standard. Biometric data, health data, and children’s information warrant explicit justification, tighter retention, and clear consent mechanics. If your app uses face or fingerprint unlock, decide early whether biometric templates stay on-device or reach your servers; on-device processing removes an entire category of risk. For children’s apps, apply stricter defaults: minimal collection, no behavioural advertising, and parental consent flows.
Your Mobile App Privacy Requirements: What Users Must Be Told
Mobile app privacy requirements come down to transparency at the point of collection. Users must be told what personal information is collected, why, who it may be shared with, and how to access or correct it, before or at the moment of collection, not after. This obligation extends to the processing of sensitive data within on-device models, where the nuances of local AI privacy determine whether the promise of data sovereignty holds up under modern regulatory scrutiny.
The practical build list looks like this:
- A layered privacy notice. Short in-app summary plus a full notice on your website.
- Purpose-specific permission prompts. Explain why the camera, contacts, or location is needed at the moment you request it.
- An access and correction route. A real, working way for users to request their data.
- A complaints process. Named contact, stated response expectations, and a path to the Privacy Commissioner if unresolved.
- Plain-language consent. No pre-ticked boxes, no bundled consent for unrelated purposes.
If a user cannot find or exercise their rights, the notice fails its purpose.
Bundling consent for analytics, marketing, and core app functionality into a single “I agree” button is a common compliance failure. It removes the user’s ability to consent to one purpose without the others, and it undermines the lawful basis for all of them.
The Mobile App Security Checklist for Build and Release
A mobile app security checklist converts policy into release gates. The controls below are the ones we insist on before any build ships, and they align with recognised frameworks such as the Mobile Application Security Verification Standard, which defines security requirements for mobile applications.
Controls to Build In From the Start
- Encrypt data at rest using platform-standard encryption (AES-256 where applicable)
- Enforce TLS for all network traffic; no cleartext fallback
- Store secrets in the platform keystore, never in source or config files
For a deeper walkthrough of these controls, our guide to mobile app security best practices for businesses covers implementation detail.
The control most teams skip is the software bill of materials. Third-party SDKs are where a large share of mobile vulnerabilities enter, and you cannot patch what you have not inventoried. Generating the list automatically in CI rather than maintaining it by hand is recommended.
Mobile App Security Testing Before and After Launch
Mobile app security testing is the evidence layer of compliance: it proves your controls work and produces the artefacts auditors, app stores, and regulators expect.
Test on three cadences. Before release, run static analysis, dependency scanning, and a penetration test against the build you intend to ship. At release, verify signing, obfuscation, and that debug flags are off. After launch, schedule recurring dynamic testing and re-test whenever you add an SDK or change authentication.
App-Store and NCSC Minimum Standards: The Overlapping Obligations
App-store requirements and the NCSC Minimum Cyber Security Standards overlap more than most teams expect, and satisfying one does not satisfy the other. The risk is treating app-store submission as the finish line when it is a declaration layer on top of ongoing operational practice.
What the app stores actually require
Apple’s App Store Review Guidelines and Google Play’s Developer Program Policies impose security and privacy conditions that map loosely onto the Privacy Act. Recurring themes:
- Data minimisation and purpose limitation. Apple’s guideline 5.1.1 requires apps to request only the data they need and obtain consent before collecting or transmitting personal data. Google Play’s User Data policy requires prominent in-app disclosure and affirmative consent before collecting sensitive data or data unrelated to core functionality.
- Privacy nutrition labels and the Data safety section. Apple requires App Privacy details in App Store Connect; Google requires a Data safety form in Play Console. Both declare what you collect, how it is used, whether it is shared, and whether it is encrypted in transit. Inaccurate declarations are a removal risk, not a warning.
- Account deletion. Both platforms now require apps that support account creation to offer in-app account deletion. This is a direct operational expression of Privacy Principle 7 (access and correction) and Principle 9 (retention limits).
What the NCSC Minimum Standards add
The NCSC’s Minimum Cyber Security Standards are organised around foundational control areas rather than app features, requiring evidence of:
- Governance and ownership, a named accountable person for cyber security, and a documented risk management approach.
- Identity and access management, multi-factor authentication for privileged access, least-privilege accounts, and a joiner/mover/leaver process.
- Patch management, a defined cadence and a supported-version policy for systems and dependencies.
Where the two regimes diverge
App stores want a declaration at submission; the NCSC standards want ongoing, evidenced practice. When you engage developers to implement these obligations, it helps to know the mobile app development contract pitfalls to avoid.
A worked example: your Data safety form declares that location data is collected and encrypted in transit. The evidence artefact is the network security configuration plus the TLS test result from your release pipeline.
Treat the app-store privacy declaration as a compliance artefact with a version history, not a one-off form. Diff it against your data map at every release, and assign a named owner for the Data safety and App Privacy sections specifically.
The two regimes overlap but demand different things, so here is how their obligations line up side by side. Once the compliance picture is clear, see how to prepare your business for mobile app launch.
| Obligation | App-store requirement | NCSC Minimum Standards |
|---|---|---|
| Data minimisation and purpose limitation | Apple 5.1.1 and Google Play User Data policy require consent | Not specified as an app feature |
| Privacy declarations | App Privacy details and Data safety form required | Not specified as an app feature |
| Account deletion | In-app account deletion required by both platforms | Not specified as an app feature |
| Secure transmission | Google prohibits cleartext; Apple enforces TLS by default | Not specified as an app feature |
| Patch cadence | Annual target API levels and recent SDK required | Defined cadence and supported-version policy |
| Third-party SDKs | Disclosure required; developer responsible for behaviour | Due diligence and contractual security expectations |
| Governance and ownership | Not specified as an app feature | Named accountable person and documented risk approach |
| Incident response | Not specified as an app feature | Documented plan, defined roles, tested capability |
Mobile App Data Breach Response: What to Do and Who to Tell
Mobile app data breach response follows the Privacy Act’s mandatory notification regime, but the mechanics are app-specific. If a breach has caused or is likely to cause serious harm, notify the Privacy Commissioner as soon as practicable and notify affected individuals (Office of the Privacy Commissioner). Contain first, assess harm, then notify, but in mobile, containment and assessment run in parallel because the attack surface spans devices you do not control.
The app-specific containment actions
A mobile breach is rarely contained by taking a server offline. The actions that actually stop the bleeding are:
- Revoke and rotate. Invalidate refresh tokens, rotate API keys and signing secrets, and force re-authentication. If you use short-lived access tokens with refresh rotation, this is a configuration change; if you use long-lived tokens, it is a scramble.
- Force a minimum app version. Use your remote configuration or app-update mechanism to block older builds that contain the vulnerability. Both major platforms support forced-update patterns, and this is the fastest way to remove a vulnerable client from your population.
- Disable the affected feature server-side. Feature flags are a containment tool. If a third-party SDK is exfiltrating data, you can often disable its initialisation remotely without shipping a new build.
The harm assessment questions
The Privacy Commissioner’s guidance frames serious harm around the likelihood and severity of harm to affected individuals. For an app breach, the questions that move the assessment are:
- What categories of data were exposed, credentials, contact details, location history, health data, biometric templates, identity documents?
- Was the data encrypted at rest and in transit at the time of exposure, and were the keys also exposed?
- How many individuals are affected, and are any of them children or otherwise vulnerable?
- Is the data sufficient to enable identity theft, account takeover, or physical harm?
- Is the exposure ongoing, or has it been contained?
- Has the data already appeared elsewhere, or is there evidence of misuse?
Document the answers at the time of assessment. The Commissioner expects a record of how you reached your conclusion, whether or not you notified.
Who to tell, and in what order
- The Privacy Commissioner, as soon as practicable after you form the view that notification is required. The notification form asks for the nature of the breach, the data involved, the number of affected individuals, the harm assessment, and the steps taken.
- Affected individuals, with a clear description of what happened, what data was involved, what you have done, and what they should do. Avoid speculative reassurance; state what you know and what you do not.
- Other regulators or agencies where sector rules apply, for example, financial-services obligations may require parallel notification.
Build the playbook before you need it
Define who can declare an incident, who owns the harm assessment, who drafts the notification, and who speaks to the Commissioner. Run a tabletop exercise at least annually, including a scenario where the breach originates in a third-party SDK rather than your own code, the scenario most teams are least prepared for.
A common failure is not technical containment; it is decision paralysis over whether harm is “serious.” Setting a decision deadline in the playbook, for example, a documented assessment within 24 hours of containment, can help ensure the regulatory clock does not run while the team debates.
Pre-draft the notification template and the harm-assessment questions now. Writing them during an incident costs hours you do not have, and the regulatory clock is already running.
Frequently Asked Questions
What are the security requirements for a mobile app in New Zealand?
There is no single mobile app security law. Instead, obligations come from several places: the Privacy Act 2020 governs how you collect, store, use and disclose personal information; the National Cyber Security Centre’s Minimum Cyber Security Standards set a baseline of foundational practices; and app stores impose their own platform requirements. On top of these, frameworks such as the OWASP Mobile Application Security Verification Standard (MASVS) are commonly used as a reference for defining and testing app security requirements. Treat compliance as a combination of legal duties, platform rules and recognised technical standards.
Do mobile apps need a privacy policy?
Under the Privacy Act 2020, you must tell users what personal information you collect, why you collect it, who you share it with, and how they can access or correct it. A privacy policy is the standard way to meet that requirement. It should be written in plain language, be easy to find before a user creates an account, and accurately reflect what the app actually does, including any third-party SDKs, analytics or advertising tools that receive data. If your app collects location, biometrics or children’s data, spell that out explicitly.
How can I check whether a mobile app is secure?
Ask for evidence rather than assurances. A credible app team can show a completed mobile app security checklist, results from static and dynamic testing, confirmation that data is encrypted in transit and at rest, and a record of how vulnerabilities were remediated. Check whether the app uses secure sign-in such as passkeys or multi-factor authentication, whether it requests only the permissions it needs, and whether a privacy policy is available before sign-up. For higher-assurance work, look for testing aligned to MASVS or a recognised international standard such as ISO 27001 at the organisation level.
What security testing should be completed before launching a mobile app?
At minimum, run static analysis on the codebase, dynamic testing on a running build, and a review of how the app stores credentials and tokens. Test authentication and session handling, check that data is encrypted in transit and at rest, and confirm the app requests only permissions it genuinely uses. Review third-party libraries and SDKs for known vulnerabilities. Before release, repeat the critical tests on the production build and again after any significant update, because a clean pre-launch test says nothing about the version users are running six months later.
How should a business respond to a mobile app data breach?
Contain the issue first: revoke compromised keys, force sign-outs, and patch the vulnerable component. Then assess what personal information was affected and whether it has caused or is likely to cause serious harm. The Privacy Act 2020 requires you to notify the Office of the Privacy Commissioner as soon as practicable if a breach is likely to cause serious harm, and to tell affected users. Keep a written record of the incident, the assessment and the steps taken. After containment, review how the vulnerability entered the build so the same gap does not return.
What is the mobile app security checklist for a new build?
A workable checklist covers encryption of data in transit and at rest, secure authentication with passkeys or multi-factor options, least-privilege permissions, secure storage of tokens rather than plain text, input validation, and dependency scanning for known vulnerabilities. Add a privacy policy linked before sign-up, a documented data retention and deletion process, and a tested breach response plan. Record who owns each item and when it was last verified. The checklist is only useful if it produces evidence you can hand to a client, auditor or regulator.
Compliance is not a launch checkbox; it is a set of controls you maintain for the life of the app. If your team needs help building security and privacy into the product from the first sprint, Web Maniacs delivers personalised app development, custom software suited to your business, and intuitive app design that keeps compliance and user experience aligned. Get started with Web Maniacs and ship an app you can defend.
