SaaS Contract: How to Draft and Negotiate in New Zealand

A SaaS contract can look deceptively simple, especially when a provider sends over standard terms and says everyone signs the same document. The problem is that small wording choices can shift major risk onto your business.

Founders often miss three things: service levels that are too vague to enforce, data clauses that do not match how the software actually handles customer information, and liability caps that leave them exposed when the platform fails at the worst possible time.

If you are buying, selling or partnering around software as a service in New Zealand, the contract matters long before there is a dispute. It affects who owns the data, what happens at renewal, whether you can leave cleanly, and who carries the cost of downtime, security issues or customer complaints. This guide explains what a SaaS contract should cover, what New Zealand businesses should negotiate before they sign, and where founders commonly get caught by standard terms.

Overview

A SaaS contract sets the legal and commercial rules for delivering software over the cloud. In New Zealand, the right contract should deal clearly with service scope, pricing, data use, privacy, intellectual property, liability, and how the relationship ends.

The best time to fix a risky SaaS agreement is before you sign, not after your team has migrated systems and become dependent on the platform.

• Define the services, features, users and support included.
• Set measurable uptime, response times and service credits if performance drops.
• Confirm who owns customer data, usage data and any custom developments.
• Check privacy obligations, cross border data handling and security commitments.
• Review payment terms, renewals, price increase rights and termination rights.
• Limit liability in a fair way and test any broad indemnities.
• Include a practical exit process, data export rights and transition support.

What SaaS Contract Means For New Zealand Businesses

A SaaS contract is not just a software order form. It is the agreement that controls access to the platform, the service standards you receive or promise, and the legal risk attached to your use of cloud software.

For a customer, the contract is often the only place you can lock in support levels, security standards and a realistic exit route. For a provider, it is the main document that protects your intellectual property, limits open ended liability and sets clear rules for acceptable use and payment.

What a SaaS agreement usually covers

Most SaaS arrangements combine a few legal ideas into one contract. Instead of buying a copy of software outright, the customer usually receives a limited right to access and use the platform during the subscription term.

A typical agreement should include:

• the subscription scope, including user limits, modules and environments
• implementation or onboarding services, if any
• service levels and support arrangements
• fees, invoicing and renewal mechanics
• privacy, security and data management terms
• intellectual property ownership and licence terms
• warranties, disclaimers and liability limits
• suspension, termination and post termination obligations

Why New Zealand legal context matters

New Zealand businesses should not assume an overseas template works locally without changes. The contract should align with New Zealand law, your actual business model, and the regulatory position created by your customers, sector and data practices.

Depending on the arrangement, a SaaS provider or customer may need to think about the Privacy Act 2020, fair trading rules around sales claims, and the extent to which business to business contracting can modify or contract out of certain statutory protections. If your software serves consumers indirectly, or your customer base includes smaller businesses, marketing statements and service promises need to match what the platform can genuinely deliver.

This matters in practical founder moments. If your sales team promises enterprise grade uptime, instant support and secure hosting, but your standard SaaS contract says the service is provided as is and support is only reasonable endeavours, that gap can create legal and commercial trouble quickly.

Customer side versus provider side priorities

The same SaaS contract looks very different depending on which side of the deal you are on. Customers usually focus on continuity, security and leverage if the service underperforms. Providers usually focus on limiting misuse, preserving ownership and preventing unlimited claims.

If you are the customer, key concerns often include:

• whether the platform is fit for your intended business use
• what downtime rights you have if the system is unavailable
• how your business data can be accessed, stored and returned
• whether the provider can change pricing or features mid term
• how hard it will be to switch providers later

If you are the provider, key concerns often include:

• keeping ownership of the software, code and documentation
• restricting use to permitted users and purposes
• excluding liability for customer misuse, third party systems and internet outages
• making sure payment, suspension and renewal rights are workable
• avoiding broad warranties that overpromise performance or legal compliance

Legal Issues To Check Before You Sign

The biggest legal risks in a SaaS contract usually sit in the clauses people skim. Before you accept the provider's standard terms or send your own template, make sure the contract matches how the software will actually be sold, deployed and used.

1. Service description and scope

If the scope is vague, arguments start early. The contract should say exactly what the customer is getting, including plan level, features, implementation work, support hours, user limits, storage allowances and any excluded functionality.

Founders often rely on demos, proposal decks or verbal promises. That is risky. If a feature is business critical, put it in the contract or a detailed schedule before you sign.

2. Service levels and support

Uptime language is only useful if it can be measured. A clause that promises commercially reasonable availability may sound reassuring, but it does not tell you what happens after repeated outages.

Service levels should deal with:

• target uptime and how it is measured
• planned maintenance windows
• severity levels for incidents
• response and resolution targets
• service credits or other remedies if standards are missed
• escalation paths for prolonged outages

If your business depends on the system to process orders, deliver customer services or manage regulated information, weak support wording can become an operational crisis very quickly.

3. Data ownership, access and use

Data terms often decide whether the relationship remains manageable. The customer should usually retain ownership of its business data, while the provider may need limited rights to host, process, back up and secure that data to deliver the service.

The contract should separately address:

• customer uploaded data
• personal information
• system generated usage data and analytics
• aggregated or de identified data
• custom reports, templates or outputs created during the subscription

This is where founders often get caught. A provider may claim broad rights to use customer data for product improvement, benchmarking or AI model training. That may be acceptable, or it may be completely inconsistent with your customer promises, privacy notice or industry expectations.

4. Privacy and security obligations

If the platform handles personal information, privacy terms should not be generic filler. New Zealand businesses need to understand who is collecting, storing and processing personal information, where that information goes, and what security commitments actually apply.

Useful contract points include:

• the purpose for which personal information is processed
• minimum security standards and access controls
• subprocessors or third party hosting providers
• cross border data storage or access
• incident notification timeframes
• cooperation if an access request, correction request or privacy complaint arises

Do not rely on a broad statement that the provider uses industry standard security. Ask what that means in practice before you sign.

5. Intellectual property and custom work

Most SaaS providers keep ownership of the platform and license access to customers. That is normal. Problems arise when the deal includes custom integrations, bespoke workflows, commissioned features or customer supplied materials.

The contract should clearly state who owns:

• the underlying software and codebase
• configuration work and implementation materials
• custom developments funded by the customer
• customer branding, content and uploaded materials
• feedback and suggested improvements

If the customer is paying significant money for custom work, a blanket provider ownership clause may not reflect the commercial deal.

6. Fees, renewals and price changes

Auto renewal terms are one of the most common sources of avoidable frustration. A SaaS contract should say when renewals happen, how much notice is needed to opt out, and whether the provider can raise prices during the term or only on renewal.

Check the detail around:

• billing cycles and payment timing
• fees for implementation, migration or training
• usage based charges and overage rates
• annual uplifts or discretionary price changes
• what happens if the service scope changes mid term
• suspension rights for late payment

For providers, clear payment mechanics reduce disputes. For customers, the goal is to avoid getting locked into a tool that becomes much more expensive than planned.

7. Liability, warranties and indemnities

This section decides who carries the financial consequences when things go wrong. Many standard SaaS terms cap the provider's liability at a very low level and exclude most indirect loss.

That can be reasonable in some deals, but you should still test whether the cap matches the real risk. A customer using the system for core revenue operations may need stronger protection than a low value internal tool would justify.

Look closely at:

• the amount of any liability cap and whether it is tied to fees paid
• whether the cap applies per claim or in aggregate
• carve outs for confidentiality breaches, privacy incidents, fraud or wilful misconduct
• any indemnity for third party intellectual property infringement
• warranties around service performance, legal compliance and authority to contract

Customers should also be cautious about broad indemnities for all use of the software. Providers should be cautious about promising that the service will be uninterrupted, error free or suitable for every purpose.

8. Termination and exit planning

The right to leave is easy to ignore until you need it. Every SaaS contract should spell out how a party can terminate, what notice is required, and what happens to data and access afterwards.

A practical exit clause should cover:

• termination for convenience, if any
• termination for material breach and cure periods
• termination for insolvency or prolonged force majeure events
• data export formats and timing
• transition assistance and any extra charges for it
• deletion or retention rules after termination

If your business would struggle to move quickly, negotiate the exit process before you become dependent on the platform.

Common Mistakes With SaaS Contract

Most SaaS contract mistakes happen because the legal document is treated as admin after the commercial deal is already done. The result is a signed agreement that does not reflect what the parties actually expect.

Accepting standard terms without matching them to the real deal

A provider's standard form may be perfectly workable for a basic subscription, but not for enterprise onboarding, data migration, or sector specific needs. Customers often assume a signed order form is enough. It usually is not.

If implementation, integrations or security commitments matter, those details need to be written in. Otherwise, the provider may only be legally promising access to the standard platform.

Relying on sales promises that never make it into the contract

Founders often hear statements such as we can integrate with your stack in two weeks, your data will stay in a certain region, or support is available any time. If those points matter, record them clearly in the agreement or schedules.

Before you rely on a verbal promise, ask whether the contract confirms:

• delivery dates and milestones
• specific integrations or compatibility requirements
• security features and hosting arrangements
• named support channels and hours
• any promised roadmap items

Ignoring the renewal and notice trap

Auto renewals can roll over for another full term if notice is missed by a narrow window. That is a common problem for busy SMEs that signed the contract months earlier and never diarised the deadline.

Customers should track renewal dates internally. Providers should use renewal wording that is clear, visible and commercially fair, because surprise renewals can damage the relationship even if the clause is technically enforceable.

Using unclear data clauses

Data disputes often stem from one sentence trying to cover too much. Ownership, processing rights, analytics use, backup rights and deletion should not all be collapsed into a vague statement about provider use of customer data.

This matters even more where the software handles sensitive customer records, employee information or commercially valuable analytics.

Leaving liability caps untouched in high risk deals

A very low liability cap may be acceptable for a low fee tool with limited business impact. It may be uncommercial for software that runs payroll interfaces, customer transactions, logistics or compliance workflows.

The key question is simple: if the platform fails badly, who bears the financial cost? If the answer does not match the commercial reality, negotiate the clause before you sign.

Forgetting the exit plan

A strong SaaS contract does not only cover the happy path. It also deals with the last day of the relationship.

Customers often focus on onboarding and pricing, then realise too late that there is no guaranteed export format, no migration assistance and only a short window to retrieve data. Providers can also create avoidable disputes if offboarding steps are not clear and consistent.

FAQs

What is the difference between a SaaS contract and a software licence?

A SaaS contract usually gives access to cloud hosted software for a subscription period, rather than transferring a copy of software for the customer to install and use permanently. It also tends to include service, support, hosting and data terms that a traditional software licence may not cover.

Can a New Zealand business just use overseas SaaS terms?

Sometimes, but it is risky to assume they fit without a contract review. Overseas templates may not line up well with New Zealand privacy expectations, local contracting practices, or your actual commercial arrangement.

Who owns the data in a SaaS arrangement?

That depends on the contract. Usually, the customer should retain ownership of its business data, while the provider receives limited rights to host and process it. The agreement should also address usage analytics, aggregated data and any custom outputs.

What should a customer negotiate first in a SaaS contract?

Start with service scope, uptime and support, data rights, privacy and security, liability caps, renewals and exit rights. Those issues usually affect business risk far more than minor drafting points.

Do SaaS contracts need a privacy clause?

Yes, if personal information is involved, and many SaaS products process personal information in some way. The clause should reflect what data is handled, where it is stored or accessed, what security applies, and what happens if there is a privacy incident.

Key Takeaways

• A SaaS contract should reflect the real service, not just the provider's standard form wording.
• Before you sign, check service scope, support levels, renewals, pricing mechanics and termination rights.
• Data ownership, privacy obligations and security commitments need clear drafting, especially where personal information is involved.
• Liability caps and indemnities should match the commercial and operational risk of the platform.
• An exit plan matters, including data export, transition support and deletion rules after termination.
• Verbal promises, demos and sales materials should be captured in the contract if they are important to the deal.

If you want help with service levels, data and privacy clauses, liability caps, termination rights, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.