Customer Data Ownership in SaaS Agreements in NZ

Customer data is often the most sensitive asset in a SaaS deal, but the contract is where many founders and customers leave the biggest gaps. Common mistakes include saying the customer owns all data without defining what that means, letting the provider use data for vague product improvement, or promising deletion without checking backups, audit logs and legal retention needs.

For New Zealand SaaS businesses, the issue is not just who owns the data. A well drafted agreement also needs to deal with intellectual property, confidentiality, access rights, Privacy Act 2020 obligations, overseas hosting, security incidents and what happens when the subscription ends.

A clear customer data clause helps both sides decide who can use what, for what purpose, for how long, and under what controls. It also reduces friction in sales conversations, vendor due diligence and enterprise procurement.

Data Ownership Checklist for SaaS Contracts

A strong SaaS data position should separate ownership, licence rights, privacy obligations and operational access instead of trying to solve everything with one sentence.

When a customer uploads files, contact records, employee details, customer lists, images, prompts, analytics events or transaction data into a SaaS platform, several rights can overlap. The customer may own or control the underlying business information. The provider may own the software, database structure, APIs, analytics tools and system outputs. Individuals may have privacy rights in their personal information. The contract should make these layers clear.

For a SaaS founder, the goal is usually to reassure customers that their data will not be sold, exposed or misused, while still preserving enough rights to host, process, secure, support and improve the product. For a SaaS customer, the goal is usually to keep control over commercially sensitive information, ensure the provider only uses it for agreed purposes, and secure a practical exit path.

Your SaaS data ownership clause should usually deal with:

• Definitions: what counts as customer data, personal information, usage data, aggregated data, support data and provider data.
• Ownership: whether the customer retains ownership of customer data, and whether the provider retains ownership of the platform, documentation and system data.
• Licence to process: the limited permission the provider needs to host, copy, transmit, back up, display and otherwise process customer data to provide the service.
• Permitted use: whether the provider can use data for support, security, analytics, product improvement, benchmarking, artificial intelligence training or marketing insights.
• Confidentiality: how commercially sensitive customer data is protected, including access by staff, contractors and service providers.
• Privacy terms: who is responsible for Privacy Act 2020 compliance, collection notices, indirect collection notices, security measures, overseas disclosure and breach handling.
• Access and export: how customers can access, correct, export or retrieve their data during and after the subscription.
• Deletion and retention: when data will be deleted, anonymised or retained, including backups, legal obligations and audit logs.
• Subprocessors: whether cloud hosts, analytics tools, email providers, AI tools and support vendors can handle customer data.
• Liability: what happens if data is lost, corrupted, accessed without authority or used outside the contract.

A common founder moment is the first enterprise customer asking for a data processing agreement in New Zealand terms. If your standard SaaS terms only say the customer owns its data, that customer will often ask for more detail before signing. The better approach is to build data ownership, confidentiality and privacy commitments into the contracting pack from the start.

What Counts as Customer Data, Platform Data and Personal Information

Most SaaS data disputes come from unclear definitions, so the contract should divide data into practical categories that match how the product actually works.

Customer data usually means information, content and materials that the customer or its authorised users submit to, upload to, store in or generate through the SaaS platform. Depending on the product, this might include CRM records, invoices, project files, product catalogues, customer communications, employee profiles, medical appointment notes, training records or marketing lists.

A customer data clause in New Zealand SaaS terms often says that the customer retains all rights, title and interest in customer data. That is a useful starting point, but it should not be treated as the whole answer. The provider still needs a licence to use that data for limited operational purposes, otherwise basic activities like hosting, caching, transmitting or backing up the data could technically fall outside the contract.

Provider data or platform data usually means the SaaS provider's software, source code, object code, database schemas, UI design, documentation, workflows, configuration logic, templates, know-how and system infrastructure. The provider should make clear that the customer does not obtain ownership of these assets merely by using the platform.

Usage data can be more sensitive. It may include login times, feature usage, clickstream events, device data, error logs, API calls, performance metrics and admin activity. Providers often want to use usage data to improve reliability, measure adoption, develop features and identify security risks. Customers may be comfortable with that if the use is limited, but not if it reveals their business operations or user behaviour in identifiable form.

Aggregated or anonymised data is often treated separately. A SaaS provider might want to create industry benchmarks, usage statistics or product insights from many customers' data. The contract should say whether this is allowed, what safeguards apply, and whether the data must be de-identified so it cannot reasonably identify the customer, its users or individuals.

Personal information has its own rules under the Privacy Act 2020. It broadly covers information about an identifiable individual. In a SaaS setting, that can include names, email addresses, phone numbers, employment details, customer records, location data, IP addresses, user IDs and notes about individual people.

New Zealand privacy law does not work on a simple property ownership model. Individuals have rights and protections in relation to their personal information, but that does not mean every item of personal information is owned like a physical asset. The better drafting approach is to say who controls the data, who can process it, what privacy roles each party has, and how requests and incidents will be handled.

Some SaaS products also create outputs, such as reports, dashboards, recommendations, generated documents or AI-assisted summaries. The contract should say whether those outputs belong to the customer, the provider, or both. If outputs are generated using customer data, the customer will usually expect to use them freely for its business. The provider may still need to protect its underlying templates, models, calculations and system logic.

For example, a payroll SaaS provider may not own the employer's employee records, pay rates and leave information. However, it will own the payroll engine, report layouts and software code. It may also need to retain some logs for security, audit and compliance purposes after the customer's subscription ends.

How to Draft a SaaS Data Ownership Clause

A well drafted SaaS data ownership clause should give the customer control over its data while giving the provider a narrow, workable licence to operate the service.

The ownership wording is usually direct. It can state that, as between the parties, the customer retains all rights in customer data and the provider retains all rights in the SaaS platform, software, documentation, integrations and pre-existing intellectual property. That kind of split is commercially familiar and usually easy for customers to understand.

The more difficult drafting sits around the provider's licence. If the licence is too broad, customers may worry that the provider can monetise or repurpose their data. If the licence is too narrow, the provider may not be able to deliver support, troubleshoot issues, monitor security or make the platform function properly.

A practical provider licence usually allows the SaaS company to use, host, copy, transmit, store, display and process customer data only to:

• provide and maintain the SaaS services;
• perform support, onboarding, migration and account management;
• prevent or address security, fraud, abuse and technical issues;
• comply with law and enforce the agreement;
• create backups and disaster recovery copies; and
• carry out any additional uses the customer has expressly agreed to.

Product improvement needs more careful drafting. Many SaaS providers want to analyse customer data and usage patterns to improve features, train models, reduce bugs or build benchmarks. That may be reasonable, but the clause should not leave customers guessing.

If the provider wants to use customer data beyond delivering the service, the contract should say:

• which data categories may be used;
• whether data will be aggregated, anonymised or de-identified;
• whether personal information is included or excluded;
• whether confidential information is included or excluded;
• whether AI or machine learning systems will be trained on the data;
• whether human review is allowed; and
• whether the customer can opt out.

AI-related wording deserves special attention. A customer may accept that a SaaS provider uses anonymised usage metrics to improve performance, but reject use of its confidential documents to train a general model. If the platform includes AI features, the contract should distinguish between processing data to produce the customer's requested output and using data to train or improve models for other customers.

Access rights should also be precise. Provider personnel should only access customer data where required for support, security, maintenance, legal compliance or another agreed purpose. For higher risk products, the contract might require access controls, staff confidentiality obligations, audit logs and approval workflows for support access.

Deletion wording should match technical reality. Many SaaS contracts promise deletion on termination, but the product team may retain data in backups for a period, keep logs for security, or retain billing records. Overpromising on deletion can create trust and compliance issues, especially when customers rely on that promise for their own privacy obligations and data retention policy.

A balanced deletion clause can say that after termination the customer may export its data for a defined period, after which the provider will delete or de-identify customer data from active systems, except to the extent retention is required by law, legitimate business records, dispute management, security, backups or audit purposes. It should also state how backups are handled and whether restored backups may temporarily reintroduce deleted data.

Data return is a commercial issue as much as a legal issue. Customers should know whether export is self-service, what file formats are available, whether metadata is included, and whether assistance with migration attracts fees. Founders should avoid promising bespoke migrations for every customer unless the pricing and support model can sustain it.

For customers reviewing a SaaS agreement, a strong negotiation position is often not to demand unlimited rights over every data category. Instead, ask the provider to clarify what it will do with your data, what it will not do, how it will protect it, and what happens at exit.

Privacy, Confidentiality and Permitted Use Under New Zealand Law

Data ownership wording will not override the Privacy Act 2020, confidentiality obligations or consumer protection rules if the SaaS provider mishandles data or makes misleading promises.

The Privacy Act 2020 applies where a New Zealand agency collects, holds, uses or discloses personal information. Many SaaS providers and customers will be agencies under the Act, depending on their role and activities. The Act contains Information Privacy Principles covering matters such as collection, purpose, notification, security, access, correction, retention, use, disclosure and privacy policy wording.

In a typical B2B SaaS arrangement, the customer often decides what personal information is put into the platform and why. The provider processes that information to deliver the service. The contract should reflect that operational reality, even though New Zealand privacy law does not use exactly the same controller and processor language as some overseas regimes.

Since 1 May 2026, Information Privacy Principle 3A also affects indirect collection of personal information. In a SaaS context, a provider may receive personal information from the customer rather than directly from the individual, and a customer may also collect information indirectly before uploading it to the platform. Where either party collects personal information indirectly, it may need to take reasonable steps to ensure the individual is aware of the collection and related matters, unless an exception applies. The SaaS agreement or data processing agreement should allocate responsibility for direct and indirect collection notices, record any agreed notification process, and identify any exception the parties are relying on.

SaaS privacy terms in New Zealand should usually cover:

• the types of personal information the platform may handle;
• the purposes for which the provider may process it;
• each party's responsibility for collecting information lawfully and giving direct or indirect collection notices, including under Information Privacy Principle 3A where relevant;
• the provider's responsibility to keep information secure and only use it as agreed;
• how access and correction requests from individuals will be managed;
• how notifiable privacy breaches will be assessed and escalated;
• whether information may be disclosed or stored overseas; and
• which subcontractors or service providers may access the information.

A data processing agreement in New Zealand is often used as an addendum to SaaS terms, especially for enterprise, health, education, HR, finance and government-adjacent customers. It can set out processing instructions, security measures, subprocessors, breach notification processes, assistance with privacy requests and return or deletion obligations.

New Zealand's Privacy Act includes rules for disclosing personal information to foreign persons or entities. If a SaaS provider hosts data overseas or uses offshore support teams, cloud infrastructure, analytics tools or AI services, the privacy terms should be honest about that. Customers may need to know where information is stored or accessed so they can assess their own compliance position.

Security promises and any information security policy should be accurate. It is tempting for a startup to say it uses industry-leading security, military-grade encryption or guaranteed protection against unauthorised access. If those claims are not true or cannot be supported, they may create issues under the Fair Trading Act 1986, which prohibits misleading and deceptive conduct in trade. Plain, accurate security commitments are safer than exaggerated marketing statements.

Confidentiality is separate from privacy. Customer data may include trade secrets, pricing, business plans, internal documents, customer lists and commercially sensitive analytics that are not personal information. The SaaS agreement and any data sharing agreement should protect confidential information even where privacy law does not apply.

A useful confidentiality clause will restrict disclosure, require reasonable protection measures, bind personnel and contractors, and include exceptions for information that is public, independently developed, already known, required by law or disclosed with permission. It should also deal with residual knowledge carefully. Providers may want their staff to use general know-how gained from supporting customers, but customers will resist wording that allows use of their confidential data.

Permitted use is where many SaaS contracts become unclear. The provider may say it can use data to improve services, develop products or analyse trends. Those words sound harmless, but they can be broad enough to allow uses the customer did not expect. A more customer-friendly approach is to limit those activities to aggregated or de-identified data and prohibit use that identifies the customer, its users or its clients.

Founders should also check whether their own vendor stack supports the promises in the SaaS contract. If you use cloud hosting, error monitoring, CRM tools, payment processors, email platforms, support desks or AI plug-ins, your contract should allow necessary disclosures to those providers. Your own supplier agreements should also contain suitable confidentiality, security and privacy obligations.

Customers should ask for a list of material subprocessors where data sensitivity justifies it. The contract can allow the provider to update that list, but customers may want notice of significant changes and a right to object where a new subprocessor creates a genuine risk.

Data breach handling should not be left to informal goodwill. Under the Privacy Act 2020, a notifiable privacy breach may need to be notified to the Privacy Commissioner and affected individuals where it is likely to cause serious harm. The SaaS agreement or data processing agreement should set out the data breach notification process, including how quickly the provider must notify the customer, what information must be shared, who communicates with affected individuals, and how both parties will cooperate.

The same incident may also raise confidentiality, contract and operational issues. For example, unauthorised access to a project management SaaS platform might expose personal information, confidential customer plans and valuable IP. A good contract gives both parties a process for containment, investigation, notification and remediation.

FAQs

Who Usually Owns Customer Data in a SaaS Agreement?

The customer usually retains ownership or control of the information it uploads, submits or generates through use of the platform. The SaaS provider usually owns the software, platform IP, documentation, infrastructure and underlying technology. The agreement should also give the provider a limited licence to process customer data so it can deliver the service.

Can a SaaS Provider Use Customer Data to Improve Its Product?

Yes, but only if the contract allows it and the use complies with privacy, confidentiality and fair trading obligations. The safest approach is to state exactly what data can be used, whether it must be aggregated or de-identified, and whether personal information or confidential information is excluded.

Do New Zealand SaaS Businesses Need a Data Processing Agreement?

A separate data processing agreement is not mandatory for every SaaS deal, but it is often expected where the platform handles personal information at scale or sensitive commercial data. It can be especially useful for HR, health, education, finance, enterprise and overseas customers.

What Should Happen to Customer Data When the SaaS Subscription Ends?

The agreement should give the customer a practical way to export data, then explain when the provider will delete or de-identify it. It should also account for backups, logs, legal retention duties, billing records and security records, rather than promising immediate deletion that the provider cannot technically deliver.

Is Personal Information Owned by the Customer or the Individual?

Personal information is not best treated as a simple ownership question. Individuals have rights under the Privacy Act 2020, while the customer and provider may each have responsibilities depending on how they collect, use, hold and disclose the information. The contract should focus on control, permitted processing, security, access, correction and deletion.

Key Takeaways

• Customer data ownership in a SaaS agreement should be defined separately from platform IP, usage data, aggregated data, outputs and personal information.
• A SaaS data ownership clause should say the customer retains its data, while giving the provider a limited licence to host, process, secure, support and maintain the service.
• Privacy Act 2020 obligations need their own drafting, especially for personal information, IPP 3A indirect collection notices, overseas hosting, subprocessors, access requests and notifiable privacy breaches.
• Confidentiality clauses protect commercially sensitive data that may fall outside privacy law, such as pricing, business plans, customer lists and internal documents.
• Permitted use wording should be precise, particularly for product improvement, benchmarking, analytics and AI training.
• Deletion and export promises should match the provider's actual systems, including backups, logs, audit records and lawful retention needs.

If you need help reviewing or drafting your SaaS terms, customer data ownership clause, privacy notices or data processing agreement, Sprintlaw New Zealand can help you get the details right. Contact us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.