NZ Privacy Act 2020 and custom business software: what you're responsible for

When a NZ business subscribes to a SaaS platform, the software vendor carries much of the privacy architecture: their servers, their access controls, their breach notification procedures, their data processing agreements. The business's obligations are real, but they sit on top of an existing privacy framework the vendor maintains.

When a business commissions custom software — a purpose-built ERP, a B2B ordering platform, an AI agent that operates on customer data — none of that infrastructure exists until someone builds it. The business is not inheriting a privacy model. It is creating one. That is a different category of responsibility under the NZ Privacy Act 2020, and one that is consistently underestimated in project briefs.

This guide covers what that responsibility looks like in practice, what has changed since May 2026 with the addition of IPP 3A, and what to include in the design brief when commissioning custom business software to avoid costly retrofitting later.

What the Privacy Act covers in a B2B context

The Privacy Act 2020 applies to "personal information" — information about identifiable individuals. It does not apply to company-level data such as a trading name, an NZBN, or an organisation's credit rating. This leads some B2B businesses to assume the Act is largely irrelevant to them. In practice, it rarely is.

Most B2B customer databases contain individual contact records: the purchasing manager at a customer account, the accounts payable contact, the delivery receiver, the individual director listed as a personal guarantor on a credit application. The order history linked to those contacts, the credit notes, the account notes from sales calls — all of this is personal information once it is linked to an identifiable person. Any ERP, B2B portal, or CRM that holds this data is in scope.

The 13 Information Privacy Principles (IPPs) set out the rules: collect only what you need, tell people what you're collecting and why, keep it secure, don't use it for purposes beyond what was disclosed, and respond to requests for access or correction. None of these are unusual obligations — but they require deliberate implementation. In custom software, that implementation is your responsibility, not a vendor's.

IPP 3A: the indirect-collection rule that came into force in May 2026

The Privacy Amendment Act 2025 added IPP 3A to the existing set of principles, with the new principle coming into force on 1 May 2026. It addresses a common gap: indirect collection of personal information.

IPP 3A applies when your business obtains personal information about an individual from a third party — a source other than the individual themselves. When this happens, you must take reasonable steps to ensure the individual knows you hold information about them, where it came from, and what you intend to do with it.

For businesses running custom software and system integrations, this has direct practical implications. Three common scenarios:

• Contact sync via ERP integration. A B2B ordering portal that pulls customer and contact records from Accredo, MYOB Acumatica, or MYOB Exo via an API integration is collecting personal information indirectly — from the accounting system, not from the individual. The contacts loaded via that sync need to be covered by your privacy notice as a source of indirect collection, not just the contacts who register directly on the portal.
• Data enrichment via third-party sources. If your custom platform or CRM is enriched with data from business directories, credit bureaus, or data providers — adding phone numbers or email addresses to existing records — each of those data points is an indirect collection under IPP 3A.
• Migration from a legacy system. When a new custom ERP imports ten years of customer contact records from an old system, those individuals gave their details to the old system under its privacy notice. The new system's collection of that same data is indirect and requires notification — or at minimum a privacy notice that explicitly covers historically migrated records.

The practical step is to review your privacy notice and ensure it describes every source from which you collect personal information, including integrations and data imports. A notice that only describes information "you provide when you create an account" is no longer adequate once your system is pulling contacts via API.

The IRD record-keeping tension

Under the Privacy Act, individuals have the right to request that personal information about them be deleted. Under Inland Revenue requirements, businesses must retain financial records — GST returns, invoices, payment records — for at least seven years.

These two obligations create a real tension that custom software needs to handle at the data model level. The answer is not to choose one over the other — it is to separate financial facts from personal identifiers.

A transaction record must be retained: invoice number, date, line items, amounts, GST, payment received. This is financial data, not personal data, and it satisfies the IRD requirement. The personal data embedded in that record — the name and contact details of the individual who placed the order — can be anonymised or removed on a valid deletion request without destroying the financial record.

Custom ERP systems that conflate these two concerns — storing the individual's full name and contact details in the same record as the transaction, with no way to separate them — make IRD-compliant deletion requests impossible. The consequence is either a Privacy Act breach (refusing a valid deletion request) or an IRD compliance risk (deleting records you were required to keep). A well-designed data model separates them from the start.

AI agents and the data purpose question

The rise of AI agents in business operations creates a specific privacy consideration that most software briefs do not address.

IPP 2 and IPP 8 require that personal information only be used for the purpose for which it was collected, or a directly related purpose. If your privacy notice described collecting customer contact details and order history "to process your orders and manage your account", then using that same data to feed an AI agent that predicts customer churn, analyses buying patterns, or generates demand forecasts is likely a new purpose — one that may not be covered by the original notice.

This is not a reason to avoid AI agents in business operations. It is a reason to update the privacy notice when AI functions are introduced. The notice should accurately describe what data the AI uses, what it infers from that data, and how those inferences are used. For NZ wholesale and distribution businesses, this typically means updating the B2B portal's privacy policy to reflect AI demand forecasting, customer buying pattern analysis, or automated exception handling — functions that use historical order data in ways beyond simple order processing.

Breach notification: your responsibility, not a vendor's

Under the Privacy Act 2020, when a privacy breach occurs that has caused or is likely to cause serious harm, the responsible organisation must notify both the Privacy Commissioner and the affected individuals as soon as practicable. Failing to notify a notifiable breach is an offence under the Act.

When you use SaaS, a breach at the vendor level is the vendor's notification responsibility (though you remain responsible for ensuring your vendor has appropriate agreements in place). When you operate custom software on infrastructure you control — your own servers, cloud infrastructure in your account, or a managed hosting environment — the breach notification obligation falls on your organisation.

Custom software needs to be built with breach detection and notification readiness in mind. The minimum requirements are:

• Audit logging. Sufficient logging to establish, after the fact, what data was accessed or modified and by whom. Without this, a breach investigation cannot determine the scope of what was exposed.
• Access monitoring. Anomaly detection for unusual data access patterns — bulk exports, access outside normal hours, access to data outside a user's normal role. These are indicators of both external breaches and insider threats.
• An incident response procedure. A documented process that does not rely on a SaaS vendor to initiate. Who is notified internally when a breach is suspected, who assesses whether notification is required, and who actually notifies the Commissioner and affected individuals.

What to put in the design brief

Privacy compliance is significantly cheaper to build in than to retrofit. A subject access request capability added to a system designed without it can require rearchitecting entire data stores. Access controls added after go-live require careful mapping of what every user role can see and systematic verification that the controls actually work. These are expensive, disruptive, and avoidable.

If your organisation is commissioning custom ERP, a B2B platform, or AI agents, include the following in the design brief:

• Role-based access controls. Define which user roles can see which categories of data before build starts. A warehouse picker does not need customer credit terms; a sales rep does not need detailed payment history. These distinctions need to be in the data access design, not added as an afterthought.
• Data minimisation. Collect the minimum personal data necessary for the business purpose. Default to not collecting data "we might need later" — each additional data point is an additional obligation to protect, secure, and disclose on request.
• Retention and deletion design. Specify how long different categories of data are kept, how deletion is handled, and how the system separates personal identifiers from financial records for IRD-compliant anonymisation.
• Subject access request support. The system should be able to extract all personal information held about a named individual on request. If it cannot, that is a compliance gap. For systems with large numbers of data tables and integration logs, this often requires deliberate design rather than ad hoc SQL queries.
• IPP 3A compliance. For any system that imports or syncs contact data via integrations, document where the data comes from and ensure the privacy notice covers indirect collection from those sources.
• AI purpose disclosure. For any system that uses personal data in AI or analytics functions, ensure those functions are accurately described in the privacy notice, not buried under generic "we may use data for business purposes" language.

Compliance is easier when it is designed in

The businesses that find privacy compliance hardest are usually not the ones with bad intentions. They are the ones that built systems quickly without privacy design, now hold data they cannot fully account for, cannot respond to deletion requests without manual effort, and have privacy notices that describe a simpler system than the one they actually run.

Custom software built with privacy in mind — data minimisation, access controls, clear retention policies, accurate privacy notices — is not substantially more expensive to build. It is substantially cheaper than retrofitting the same capabilities after a complaint or a breach.

If your business is building or extending a custom ERP or B2B ordering platform, or deploying AI agents that operate on customer data, the Zeabyte team can discuss how privacy design fits into the build. For businesses with existing system integrations that sync contact data via Accredo, MYOB, or other sources, the IPP 3A indirect-collection requirement in force since May 2026 is worth reviewing against your current privacy notice. The discovery phase guide covers what else to include in the brief before build starts.