NZ Privacy Act 2020: What Software Teams Need

New Zealand’s Privacy Act 2020 has seen significant changes over the past year, with new rules already in force and more taking effect through 2026. If your product processes personal information about people in New Zealand, grasp both the current foundation and what has recently changed, rather than working from an understanding of the Act that is a couple of years out of date.

The Act is structured around thirteen Information Privacy Principles, enforced by the Office of the Privacy Commissioner, addressing how personal information is collected, used, stored and disclosed. One of the key features introduced by the 2020 Act itself was mandatory breach notification: organisations must report a notifiable privacy breach, one likely to cause serious harm, to the Privacy Commissioner and generally to affected individuals as well.

What is new, and worth building around

Two recent developments matter more than general Privacy Act background:

• A new indirect collection principle, IPP 3A. Under the Privacy Amendment Act 2025, agencies that collect personal information about someone from a source other than that person, rather than directly from them, must take reasonable steps to inform the individual of specified matters about that collection, including what was collected, where it came from, and why. This comes into force on 1 May 2026 and is directly relevant to any product that enriches user profiles from third party data sources, buys or licenses data, or otherwise builds records about people without collecting the data from them directly, which is a common pattern in analytics, fraud detection, and B2B enrichment tooling.
• A specialized Biometric Data Privacy Code. Effective from late 2025, this code dictates how organizations manage biometric information like fingerprints, facial recognition, and voiceprints. Businesses operating biometric systems have until August 2026 to comply, so if your product includes facial recognition, fingerprint authentication, or voice verification, this code is now the definitive guideline.

On breach notification specifically, the statutory standard is to notify as soon as feasible once you become aware a breach is reportable, and OPC guidance points to around 72 hours as a practical benchmark for that, though treat that figure as guidance on reasonable speed rather than a hard legal deadline written into the Act itself. Failing to notify when required carries its own penalty, so a breach response plan ready before you need one costs relatively little upfront and pays for itself the first time you use it. A workable plan does not need to be overly complex: know who on your team gets notified first, know how you will assess whether a breach meets the reportable threshold, and know who is responsible for actually contacting the OPC and affected individuals once that assessment is made.

For an engineering team, the practical lessons are quite tangible. If your product extracts personal data from external sources, whether that is a data enhancement service, a public registry, or a partner integration, IPP 3A requires a strategy for informing affected individuals, not just a plan for utilizing the data post-collection. This could involve revising a privacy notice, sending a one-time disclosure when a profile is enriched, or creating a self-service page where users can view external data your system holds about them. If your product handles biometric data in any form, treat the Biometric Code as a distinct compliance requirement to review directly rather than assuming your general privacy policy covers it. Either way, having an actual breach response playbook, even a brief one, positions you ahead of many smaller New Zealand products.