SaaS Legal Checklist in New Zealand: Contracts, IP and Privacy

SaaS can look simple on paper. You compare features, accept standard terms, connect your data, and get on with business. The legal risk usually shows up later, when the provider changes pricing, your customer data sits offshore, the contract auto-renews, or your team assumes you own more intellectual property rights than you actually do.

Founders and SMEs often make the same mistakes. They rely on a sales call instead of the written contract, they skip the privacy review because the provider is well known, or they only look at price and miss liability caps, termination rights, and data use clauses. Those issues matter whether you are buying software for your business or offering a SaaS product to customers in New Zealand.

This guide answers the practical questions that come up before you sign. It covers the key legal points in a SaaS agreement, what to check about ownership of software and data, how the Privacy Act 2020 affects SaaS arrangements, and where New Zealand businesses most often get caught.

Overview

A SaaS deal is usually a bundle of legal promises about access, service levels, data handling, fees, ownership, and risk allocation. In New Zealand, the right checklist depends on whether you are the customer using a SaaS platform, the provider selling software subscriptions, or both.

The contract should match how the software will actually be used, where data will sit, who can access it, and what happens if the relationship ends. Privacy obligations, consumer law risks, and IP ownership points should be clear before you accept the provider's standard terms.

• Confirm exactly what is being supplied, including users, modules, support, uptime commitments, and usage limits.
• Check fees, price changes, automatic renewals, minimum terms, and how extra usage is billed.
• Review termination rights, suspension rights, data export options, and what happens to your information at the end.
• Identify who owns the software, customer data, custom developments, feedback, and any generated outputs.
• Assess privacy compliance, including collection notices, offshore disclosures, subcontractors, and security commitments.
• Review liability caps, exclusions, indemnities, and whether the risk split is realistic for the value of the deal.
• Make sure service descriptions, sales promises, and implementation commitments are reflected in writing.
• Check whether the arrangement could trigger Fair Trading Act concerns if performance claims or security claims are overstated.

What SaaS Means For New Zealand Businesses

SaaS usually means you are paying for access to software hosted by someone else, not buying the software itself. That distinction matters because your rights often depend less on ownership and more on the licence, service terms, and privacy arrangements in the contract.

For New Zealand businesses, SaaS can sit in a few different legal positions. You might be:

• a business subscribing to accounting, CRM, HR, project management, e-commerce, or AI software
• a founder building a SaaS product and contracting directly with customers
• a company reselling, integrating, or embedding third party software into your own service
• an employer using SaaS tools that process staff information as well as customer data

Each position changes the legal issues. A customer will focus on service levels, data access, exit rights, and privacy. A provider also needs customer terms that deal with acceptable use, payment, IP, disclaimers, support scope, and misuse of the platform.

Why SaaS contracts need closer review

The main reason is that standard SaaS terms are usually written to protect the provider. That is not unusual, but it does mean key commercial points can be buried in legal clauses that are easy to miss before you sign a contract.

This is where founders often get caught:

• the provider can change the service or terms on notice
• the service can be suspended for broad reasons
• all warranties are heavily limited
• the provider's liability cap is far lower than the potential loss if the platform fails
• you have limited time to export your data after termination
• disputes must be handled under overseas law or in a foreign jurisdiction

If you are providing SaaS to others, the reverse is also true. Your customer terms need to be commercially workable, but they also need to reflect New Zealand legal expectations around fair dealing, accurate representations, and privacy transparency.

New Zealand laws that commonly affect SaaS

SaaS is mostly governed by contract, but several New Zealand legal frameworks still matter.

• The Contract and Commercial Law Act 2017 affects general contract principles, including how terms are formed and interpreted.
• The Privacy Act 2020 applies where personal information is collected, held, used, disclosed, or stored. This often matters even when a software provider says it is only a processor.
• The Fair Trading Act 1986 can apply to marketing claims, pricing claims, security statements, uptime promises, and statements made during negotiations.
• The Consumer Guarantees Act 1993 may be relevant in some cases involving consumer customers, although many B2B SaaS relationships try to contract out where legally permitted.
• Intellectual property law matters for copyright, trade marks, confidential information, database use, branding, and custom code.

If your SaaS model serves regulated sectors such as health, finance, or education, there may be sector specific requirements layered on top. That is especially relevant where sensitive information is involved.

Legal Issues To Check Before You Sign

Before you accept the provider's standard terms, check whether the contract actually matches the operational reality of your business. The legal drafting needs to reflect how you will use the service, what data will go into it, and how damaging downtime or data loss would be.

1. Scope of service and service levels

The contract should say what the SaaS product includes and what it does not. If implementation, migration, integration work, onboarding, support hours, training, or response times matter to you, they should be written down.

Look closely at:

• what modules and features are included in the subscription
• how many users, entities, or locations are covered
• whether there are usage thresholds or fair use limits
• support channels and support times
• service availability commitments and exclusions from uptime calculations
• planned maintenance windows and emergency outage rights

Sales conversations often create expectations that never make it into the agreement. Before you rely on a verbal promise, ask for the commitment to be included in the contract or order form.

2. Fees, renewals, and price changes

Pricing disputes are common because SaaS charging models can be layered. The agreement should make clear what you pay now, what can change later, and what triggers extra charges.

Check:

• whether fees are per user, by usage volume, by feature tier, or by transaction
• when renewal happens and whether it is automatic
• how much notice is required to avoid renewal
• whether the provider can change fees during the term
• whether implementation or migration fees are refundable
• what happens if you dispute an invoice

If you are the provider, your pricing clauses need to work operationally. If overage fees, suspension rights, or annual increases are part of the commercial model, the contract should say so clearly.

3. Data ownership, access, and exit rights

You should not assume that owning your business data automatically means easy access to it at the end of the contract. The practical issue is not just legal ownership, but whether the agreement gives you timely export rights in a usable format.

The contract should address:

• whether customer data remains your property
• what rights the provider has to use that data for service delivery, analytics, training, or product improvement
• how you can access and export data during the term and after termination
• how long the provider keeps data after the contract ends
• whether backups are included and how restoration works
• whether there are fees for extraction, migration assistance, or extended access

If the software handles critical records, ask what format export will be in and whether metadata, attachments, and audit logs are included. A simple promise that data is exportable may not be enough.

4. Intellectual property and customisation

In most SaaS deals, the provider keeps ownership of the platform and grants the customer a limited right to use it. That part is standard. The harder questions arise around customer content, custom development, integrations, feedback, and AI generated outputs.

Before you sign, clarify:

• who owns pre-existing software, templates, documentation, and APIs
• who owns customisations paid for by the customer
• whether the provider can reuse custom development for other clients
• whether customer feedback can be used without restriction
• who owns reports, generated content, and outputs created through the platform
• whether your branding, trade marks, or logos can be used in case studies or marketing

If you are building SaaS in New Zealand, protect your own IP early. That may involve contractor IP assignment clauses, confidentiality terms, trade mark strategy for your brand, and clear ownership of source code and product documentation before you invest in branding.

5. Privacy and security

Privacy is not just a technical issue. If personal information flows through the platform, the contract and your privacy notice both need to line up with the Privacy Act 2020.

Questions to answer before you sign include:

• what categories of personal information will be processed
• whether any information is sensitive or high risk
• where the data is stored and whether it is disclosed overseas
• what subcontractors or sub-processors are involved
• what security measures are promised in the contract
• how privacy incidents and data breaches are notified and managed
• whether the provider can use data for training models, benchmarking, or analytics

Under the Privacy Act, overseas disclosure can require extra care. If a SaaS provider stores or accesses personal information outside New Zealand, you should understand what safeguards are in place and whether your own privacy statement needs to say more about it.

If you are the provider, your customer contract should accurately describe your role and your security commitments. Your external privacy statement and your internal practices should match what the contract says.

6. Liability, indemnities, and risk allocation

The risk split in a SaaS contract is often where the real negotiation happens. The provider will usually try to cap liability and exclude indirect loss. The customer will want stronger protection, especially where business critical systems or large data sets are involved.

Review:

• the amount of any liability cap and whether it is tied to fees paid
• which claims are carved out of the cap, such as confidentiality or IP infringement
• whether data loss, privacy breaches, or security failures are excluded from liability
• what indemnities apply, and who gives them
• whether the contract excludes loss of profit, revenue, goodwill, or data
• whether the risk position still makes sense if the service goes down at a critical time

There is no single right answer here. A low cost tool used for non-essential admin will justify a different risk profile from a platform that stores customer records or powers your sales pipeline.

7. Termination and transition

Exit rights matter more than many businesses expect. A SaaS relationship often ends when things are already strained, such as after outages, poor support, budget pressure, or a change of systems.

Before you sign, check:

• whether you can terminate for convenience or only for breach
• how long a material breach must continue before termination is allowed
• whether auto-renewal limits your exit timing
• whether the provider can suspend service before terminating
• what assistance is available on transition out
• what happens to stored data, user accounts, and integrations after termination

If migration away from the system would be expensive, that should affect how you assess term length, renewal mechanics, and data export rights.

Common Mistakes With SaaS

The most common SaaS mistake is treating the contract as a routine procurement document when it is really a core risk document. Small wording points can decide who carries the loss when service quality drops, data is mishandled, or the vendor relationship breaks down.

Accepting standard terms without comparing them to real usage

A founder might accept a click-through agreement for a tool that later becomes central to operations. Once the platform holds customer records, staff information, or billing history, broad provider protections become more significant.

Match the legal review to the role the software will play in your business. A low risk internal tool is different from a platform tied to revenue, compliance, or sensitive information.

Assuming the privacy position is covered by the provider's reputation

A well known provider is not a substitute for a privacy review. You still need to know what personal information is going in, where it goes, and whether your own customer facing privacy wording is accurate.

This is especially important if:

• the SaaS product stores customer identities, payment related information, or behavioural data
• staff information is uploaded into the platform
• the provider uses subcontractors in multiple countries
• AI functionality is enabled on customer content or internal documents

Relying on sales statements that never appear in the contract

If uptime, integration, implementation timing, or security standards are central to your decision, they should appear in the legal documents. Verbal assurances are hard to enforce if the written terms say something narrower.

Ask for important promises to be included in the order form, statement of work, service level schedule, or main agreement.

Not checking who owns custom work

Businesses often pay for configuration or development and assume that payment equals ownership. That is not always the case. The agreement may say the provider keeps ownership and grants only a licence.

If you are paying for tailored features, reports, templates, integrations, or implementation assets, check the ownership and reuse clause before you spend money on setup.

Ignoring the end of the relationship

Many SaaS disputes happen on exit. Data access gets restricted, support becomes slower, and migration costs rise just as you are trying to move quickly.

Founders often focus on onboarding and skip the offboarding terms. That is a mistake. Data export, deletion timing, handover support, and transition fees should be reviewed before you sign.

Using weak customer terms when selling SaaS

If you are the provider, weak terms can cause just as much trouble. New Zealand SaaS businesses often launch with copied terms that do not fit their product, pricing, or support model.

Your customer contract should clearly address:

• subscription structure and payment
• acceptable use and account security
• service limits and support scope
• customer data rights and privacy position
• IP ownership and licence boundaries
• warranties, disclaimers, liability caps, and termination rights

It should also line up with your sales process, your product claims, and your operational reality. If the contract promises more than the product team can deliver, the legal risk increases.

FAQs

Do New Zealand businesses need a written SaaS agreement?

Yes, in practice they usually do. Even if the arrangement starts with online standard terms, the key rights and obligations should be in writing so scope, pricing, privacy, IP, and liability are clear.

Who owns data in a SaaS platform?

That depends on the contract. Many agreements say the customer owns its data, but the provider may still have rights to host, process, analyse, or de-identify it. The real question is what uses are allowed and how easily the data can be retrieved.

Can a SaaS provider store personal information overseas?

Often yes, but the privacy position needs checking. If personal information is disclosed or stored offshore, New Zealand businesses should understand what safeguards apply and whether their privacy notice and contracts properly address that arrangement.

Are standard overseas SaaS terms suitable for New Zealand customers?

Sometimes, but not always. Overseas terms may rely on foreign law, overseas dispute forums, or consumer law assumptions that do not fit the New Zealand context. They also may not reflect local privacy expectations or your commercial risk position.

What should a New Zealand SaaS provider have in place?

At a minimum, clear customer terms, a privacy statement, internal data handling processes, contractor and developer IP protections, and sales material that accurately reflects what the platform does. If enterprise customers are involved, a negotiable master agreement and data handling schedule are often helpful.

Key Takeaways

• SaaS contracts are not just about price, they control service levels, data rights, privacy handling, liability, and exit options.
• Before you sign a contract, check scope, renewals, fees, export rights, offshore data use, IP ownership, and termination mechanics.
• Do not rely on verbal promises about uptime, security, implementation, or custom features unless they are written into the agreement.
• If personal information is involved, the contract and your privacy disclosures should align with the Privacy Act 2020.
• If you are selling SaaS, your customer terms should fit your product, support model, pricing, and New Zealand legal context.

If you want help with customer contracts, privacy compliance, IP ownership, and software terms, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.