SaaS Security Terms in New Zealand: Legal Issues for Providers

If you provide software in New Zealand, security promises in your SaaS contract can create more legal exposure than many founders expect. A lot of providers copy overseas wording, promise “industry-standard security” without defining it, or accept customer security schedules that quietly shift too much risk onto the vendor. Another common mistake is treating privacy, uptime, and cyber security as separate issues when the contract ties them together.

The result is usually trouble at the worst time, after a breach, during enterprise procurement, or when a customer says your platform failed to meet promised controls. The right SaaS security terms and conditions do not just describe technical measures. They allocate responsibility, set realistic obligations, explain incident handling, and limit liability in a way that works under New Zealand law. This guide explains what New Zealand SaaS providers should look for before they sign, where the main legal pressure points sit, and which drafting mistakes most often lead to disputes.

Overview

SaaS security terms and conditions set the contract rules around cyber security, data handling, access controls, incident response, and each party’s responsibility if something goes wrong. For New Zealand providers, the key issue is making sure those promises match your actual systems, your privacy obligations, and the level of risk your business can realistically carry.

• Define what security standard you are actually promising, and what is only an aspiration or internal policy.
• Separate your obligations from the customer’s obligations, especially for user access, endpoint security, integrations, and configuration.
• Align security wording with your Privacy Act 2020 obligations, including breach response and any overseas data transfers.
• Check indemnities, liability caps, service credits, and exclusions carefully before you accept the provider’s standard terms or the customer’s paper.
• Make sure audit rights, penetration testing rights, and security questionnaires are practical for a startup or SME to meet.

What SaaS Security Terms and Conditions Means For New Zealand Businesses

SaaS security terms and conditions are the contract terms that say how secure your software and hosted environment must be, who does what to protect data, and what happens if there is an incident. For New Zealand businesses, those terms matter because they are often the first place a customer looks when deciding whether a security issue is a technical problem or a legal breach.

For a provider, security wording usually appears across several documents, not just one master agreement. You may see it in your SaaS agreement, order form, service levels, data processing schedule, privacy notice, acceptable use policy, or a customer procurement schedule. Before you sign a contract, read those pieces together. A promise buried in one schedule can expand your obligations far beyond the headline deal terms.

Why providers need precise security language

Founders often use broad phrases because they sound reassuring. The trouble is that phrases like “best practice security”, “state of the art protection”, or “fully secure platform” can be hard to prove and easy for a customer to rely on. If your contract says more than your systems, resourcing, and internal processes can support, the legal risk sits with you.

A better approach is to describe security commitments in plain, verifiable terms. That might include matters such as:

• encryption standards for data at rest and in transit
• multi-factor authentication requirements
• role-based access controls
• logging and monitoring practices
• backup frequency and retention periods
• incident notification timeframes
• subprocessor approval or disclosure rules

These details help both sides understand what is promised and what is not. They also reduce the chance that a customer reads a sales statement as a binding warranty.

How security terms interact with privacy law

Security promises are closely tied to privacy law when your platform handles personal information. In New Zealand, the Privacy Act 2020 requires agencies to protect personal information by reasonable security safeguards. If you hold customer personal information as part of your SaaS offering, your contract should not undercut that legal standard.

This does not mean every SaaS provider needs the same security stack. “Reasonable” depends on the nature of the information, the harm that could result from misuse, and the scale of your operations. A healthcare software provider storing sensitive patient information will usually need stronger controls and more detailed contractual commitments than a low-risk workflow tool with limited personal data.

If personal information is stored or accessed overseas, that should also be addressed clearly. Cross-border hosting and support are common in SaaS, but the contract needs to describe this accurately. Customers often ask where data is stored, who can access it, and whether subcontractors in other countries are involved.

Consumer and fair trading risks

Most SaaS deals for startups and SMEs are business-to-business, but legal risk can still arise from how services are marketed and described. If your website, proposal, sales deck, or security questionnaire says one thing and your contract says another, the inconsistency can create a dispute under contract law and may also raise fair trading concerns if the statements are misleading.

This is where founders often get caught. A salesperson says the platform is “ISO-aligned”, “penetration tested every month”, or “guaranteed compliant” without legal review. Later, the customer points to that statement after an incident. Your written terms should make clear which documents form the agreement and should avoid vague marketing claims that cannot be supported.

Enterprise procurement pressure

As soon as you start selling to larger New Zealand businesses, government agencies, or regulated sectors, security terms become more detailed and less negotiable. Customers may send a long security schedule that includes strict audit rights, broad indemnities, mandatory certifications, short incident notice periods, and unlimited liability for security breaches.

That does not mean you must accept all of it. It means you need to identify which obligations are workable, which need qualification, and which create a disproportionate risk for your business. Before you rely on a verbal promise that “legal never enforces that clause”, get the contract wording fixed.

Legal Issues To Check Before You Sign

The main legal task before you sign is to match the contract to your actual technical and operational reality. If the paper promises more than your business can deliver, the deal may be worth less than it looks.

1. Security commitments and warranties

Check exactly what level of security you are warranting. Some clauses promise that services “will be secure” or “free from vulnerabilities”. Those statements are risky because no SaaS environment can realistically guarantee perfect security.

Safer wording usually focuses on reasonable measures and ongoing processes rather than absolute outcomes. Review terms that cover:

• minimum security controls
• secure development practices
• patching and vulnerability management
• employee access restrictions
• background checks where relevant
• business continuity and disaster recovery

Make sure any warranty is qualified by what is within your control. For example, a provider should not be responsible for a customer’s weak passwords, unsecured devices, or unsafe third-party integrations unless the provider has expressly taken that responsibility on.

2. Incident response and notification obligations

Security incidents create legal stress quickly, so the contract needs a practical response framework. Customers often ask for notice “immediately” or within a very short time after any suspected incident. That can be unrealistic, especially when the facts are still developing.

Your contract should distinguish between:

• a general security event
• an incident affecting the services
• a personal data breach
• a notifiable privacy breach under the Privacy Act 2020

Those categories should not all trigger the same response. You may need time to investigate, contain, and verify what happened before giving a complete report. The wording should allow prompt notification once you become aware of a qualifying incident, while also recognising that early information may be incomplete.

3. Customer obligations and shared responsibility

A good SaaS contract makes it clear that security is shared. The provider protects the hosted application and core environment, but the customer is often responsible for user devices, internal access approvals, password management, endpoint protection, and how its staff use the service.

If you offer configurable security settings, the contract should say who is responsible for choosing and maintaining them. This is especially important where customers can turn off multi-factor authentication, set weak permissions, or connect risky third-party tools.

Include customer obligations such as:

• maintaining secure credentials
• promptly removing former staff access
• using supported browsers or devices where relevant
• keeping connected systems secure
• reporting suspected unauthorised access without delay

Without these clauses, the provider can end up blamed for failures outside its control.

4. Privacy, data use, and subcontractors

Security terms should line up with your data handling model. If you use cloud infrastructure vendors, support providers, analytics tools, or other subprocessors, customers may want approval rights or at least disclosure rights. Be careful not to promise advance consent for every supplier change unless your team can actually manage that process.

You should also check whether the contract says anything about:

• who owns customer data
• whether you can use service data for analytics or product improvement
• retention periods after termination
• deletion and return obligations
• cross-border transfers and remote access

These points often sit between the privacy schedule and the security schedule. If they are inconsistent, disputes are more likely after termination or after an incident.

5. Audit rights, testing rights, and compliance requests

Audit clauses can become a major operational burden for smaller providers. Some customers ask for on-site audits, unrestricted access to systems, or the right to run penetration tests against production environments. Those rights need clear limits.

Before you sign, check:

• how often audits can occur
• whether reasonable notice is required
• who pays the audit costs
• whether the customer can use an independent assessor instead
• what systems and information are excluded for security or confidentiality reasons
• whether penetration testing needs your prior written approval

Many providers can meet customer assurance needs through security reports, certifications, policies, and questionnaire responses rather than open-ended direct audit rights.

6. Liability caps, indemnities, and exclusions

This is usually the most commercial clause, but it matters most when a security incident occurs. Customers often try to carve data breaches, confidentiality breaches, or privacy claims out of the liability cap entirely. For a startup or SME, unlimited exposure can be business-ending.

Look closely at:

• whether security and privacy claims sit inside or outside the general cap
• whether there is a separate higher cap for data incidents
• what losses are excluded, such as indirect loss, loss of profits, or loss of revenue
• whether service credits are the sole remedy for downtime issues
• whether indemnities are fault-based or effectively automatic

A balanced position may include a tailored cap for security-related claims, rather than no cap at all. The right answer depends on your customer profile, contract value, insurance position, and the sensitivity of the data involved.

7. Insurance and evidence of cover

Some customers require cyber insurance or professional indemnity insurance at specified levels. That can be manageable, but only if the cover exists and aligns with the contract risk. Do not agree to insurance obligations on assumptions. Check your policy wording, exclusions, notification obligations, and territorial scope.

If you are unsure whether insurance responds to a contractual indemnity or a privacy incident, speak with your broker or insurer. Your lawyer can then help align the agreement with that cover.

Common Mistakes With SaaS Security Terms and Conditions

The most common mistake is signing security wording that sounds standard but does not fit how your SaaS product actually works. Security schedules often look familiar across deals, yet small wording changes can shift a large amount of legal risk.

Using imported templates without local review

Many providers start with a US or UK template. That is understandable, but overseas templates often use different privacy terminology, different liability concepts, and different procurement assumptions. New Zealand law, market practice, and customer expectations are not identical.

A template can be a useful starting point, but it should be reviewed for New Zealand context, especially where it refers to privacy law, notices, enforceability, and consumer or fair trading issues.

Promising compliance you cannot verify

Founders sometimes agree that the service complies with a security framework, regulatory standard, or customer policy without checking whether that is actually true. If your platform is not certified, assessed, or internally mapped against that framework, the statement may be too broad.

This often happens during procurement questionnaires. The sales team wants to keep the deal moving and answers “yes” to controls that are only partly in place. Later, those responses are attached to the contract or treated as pre-contract representations. That can become a serious problem if an incident occurs.

Leaving customer-side security responsibilities unstated

If the contract does not spell out what the customer must do, the provider may inherit blame for weak internal practices at the customer’s end. Shared responsibility needs to be written down, not assumed.

This is especially relevant where the customer controls user permissions, exports data, connects other systems, or decides whether to enable optional security features.

Ignoring termination and data exit issues

Security obligations do not end neatly on the termination date. Customers often want data returned quickly, deleted fully, and kept accessible for migration. If your contract is silent, you may face arguments about retention, backups, or transitional access.

Your terms should explain what happens to customer data after termination, how long retrieval is available, when deletion occurs, and what is excluded from immediate deletion, such as archived backups that are overwritten in the ordinary course.

Treating sales statements as harmless

A casual statement in a demo or proposal can reshape the customer’s expectations. If your sales material says your service has features or controls that are not yet available, the contract should not quietly assume the customer understands that. New Zealand businesses should be careful not to overstate security capability in ways that could be misleading.

Internal alignment matters here. Legal, product, engineering, and sales should agree on the security claims the business is willing to make in writing.

Accepting unlimited audit and assistance obligations

Some customer contracts require the provider to help with every audit, investigation, regulator request, and remediation process at no extra charge. That can turn a single customer incident into a major drain on time and resources.

It is usually better to set boundaries around the level of included assistance, response times, and additional fees for intensive support outside ordinary service delivery.

FAQs

Do SaaS providers in New Zealand need a separate security schedule?

Not always, but many do. If your product handles valuable or sensitive data, a dedicated schedule can define security controls, incident response, audit limits, and data handling more clearly than a short general terms document.

Can I promise “industry-standard security” in my SaaS terms?

You can, but it is often too vague on its own. It is safer to pair general wording with specific controls, internal standards, or documented practices that you can actually demonstrate.

Who is responsible if a customer’s employee causes a security issue?

It depends on the contract and the facts. A well-drafted agreement usually says the customer is responsible for its users, credentials, devices, and internal access management, while the provider remains responsible for the hosted service and systems within its control.

Do security breaches need to be carved out of the liability cap?

Not necessarily. Customers often ask for that, but many providers negotiate a separate higher cap for security or privacy claims instead of unlimited liability. The right position depends on the risk profile of the deal.

Should security questionnaire responses form part of the contract?

Only if you are comfortable standing behind them contractually. Before you sign, check that questionnaire answers are accurate, qualified where needed, and consistent with the final agreement.

Key Takeaways

• SaaS security terms and conditions should reflect your real security practices, not idealised marketing language or copied overseas templates.
• New Zealand providers should align security promises with the Privacy Act 2020, cross-border data arrangements, and any customer-facing statements about the service.
• Before you sign, check security warranties, incident notice clauses, customer responsibilities, audit rights, subcontractor rules, liability caps, and indemnities.
• Shared responsibility is essential. Your contract should clearly separate provider obligations from customer-side security obligations.
• Enterprise customers often push broad security schedules, but those terms can usually be negotiated into something more practical and proportionate.
• Questionnaire answers, proposals, and sales statements can create legal risk if they overstate your security capability or conflict with the contract.

If you want help with contract drafting, privacy and data handling clauses, liability caps, and customer security schedules, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.