Privacy Clauses For SaaS Customer Contracts

Enterprise customers can ask tough privacy questions before they sign your SaaS contract. Where is the data hosted? Who can access it? What happens if there's a breach? Can you use subcontractors?

If you're growing a SaaS business in New Zealand, these questions are a good sign. They usually mean your customer is taking you seriously. The key is to turn your Privacy Act 2020 obligations and your actual data practices into clear, practical contract clauses.

A well-drafted privacy clause doesn't need to promise the impossible. It should explain what you do, who is responsible for what, and how you'll work with the customer if something goes wrong.

What Should A SaaS Privacy Clause Cover?

A SaaS privacy clause should cover the full customer data lifecycle, from collection and hosting through to access, security, breach notification, subcontractors, return and deletion.

For most SaaS contracts, your privacy wording should deal with:

• What data is covered: for example, customer data, personal information, usage data, support data and account administration data.
• Each party's role: who collects the information, who decides how it's used, and who handles access and correction requests.
• Permitted use: what you can and can't do with the customer's data.
• Security: the practical safeguards you use to protect the data.
• Breach notification: when and how you'll tell the customer about a privacy or security incident.
• Hosting and overseas access: where data may be stored or accessed from.
• Subprocessors and suppliers: which third parties help you provide the service.
• Data return and deletion: what happens when the contract ends.

Say Ava runs a New Zealand HR software platform. Her enterprise customer uploads employee names, contact details, payroll IDs, leave records and performance notes. Ava's contract shouldn't just say she will comply with privacy laws. It should say what Ava can use that data for, who at Ava's company can access it, what happens if AWS or another hosting provider is involved, and how quickly Ava will notify the customer if an incident affects employee information.

This level of detail helps you answer procurement questions faster and reduces the back-and-forth that can slow down deals.

Are You The Agency, Processor Or Something Else?

It depends, because New Zealand privacy law doesn't use the exact same controller and processor labels as the GDPR, but your contract still needs to clearly describe your role.

Under the Privacy Act 2020, an organisation that handles personal information can be an agency. The Information Privacy Principles, often called IPPs, then set out rules about collection, storage, access, correction, use and disclosure of personal information.

In a SaaS arrangement, your role may vary depending on the data and what you're doing with it. For example:

• Your customer may be the main decision-maker for personal information they upload into your platform, such as their employee or client records.
• You may handle that information mainly to provide the service, such as hosting it, backing it up, providing support and keeping the platform secure.
• You may also use some information for your own business purposes, such as billing contacts, administrator account details, product analytics, fraud prevention and service improvement.

That means a neat overseas-style clause saying customer is controller and supplier is processor may not be enough on its own in New Zealand. It can still be useful language for enterprise customers, especially if they deal with global privacy teams, but your contract should also fit the Privacy Act 2020.

Practical Role Wording

Your contract can say that, for customer data uploaded to the platform, you'll only use and disclose that data to provide the services, meet your legal obligations, protect the platform, and do anything else the customer has authorised.

For account, billing and support information, you may need a separate clause saying you handle that information for your own business operations and will do so under your privacy policy, any privacy collection notice and applicable privacy laws.

This distinction matters. If your contract says you never use customer data for anything except hosting, but your product team uses identifiable records to train features or build benchmarks, your wording won't match reality.

Do You Need A Data Processing Agreement In New Zealand?

You don't always need a standalone data processing agreement in New Zealand, but many SaaS businesses use one because enterprise customers expect it and it makes privacy responsibilities much clearer.

A data processing agreement, sometimes called a DPA or data processing addendum, is usually an attachment to your SaaS terms. It focuses on how personal information is handled. It can be especially helpful where:

• your customer is an enterprise, government-related organisation or regulated business
• you handle employee, health, financial, education or other sensitive information
• you use offshore hosting or support teams
• your customer needs to complete supplier risk checks
• your customer has overseas privacy obligations, such as the GDPR or Australian Privacy Act requirements

In New Zealand, a DPA should usually cover:

• the categories of personal information processed through the platform
• the purposes for which you can use the information
• security measures and access controls
• subprocessors and how they're approved
• overseas storage, access and transfers
• privacy breach notification and cooperation
• help with access, correction and deletion requests
• return or deletion of customer data at the end of the contract

You can include these points in your main SaaS terms instead of a separate DPA. The right format depends on your sales process. If your customers often send you procurement questionnaires, a separate addendum can make reviews easier because all the privacy answers sit in one place.

Templates often miss the operational details that enterprise customers care about, such as who your actual subprocessors are and what happens to backups after deletion. Your document will work best when it matches how your platform really operates.

What Should Your Security And Access Controls Say?

Your security clause should promise sensible, specific safeguards rather than an absolute guarantee that data will never be compromised.

Privacy Act 2020 IPP 5 requires agencies to protect personal information with safeguards that are reasonable in the circumstances. For a SaaS platform, what is reasonable will depend on the type of data, the size of your business, your technical setup and the risk if something goes wrong.

Good SaaS security clauses often refer to:

• access controls, such as role-based access and least privilege permissions
• multi-factor authentication for internal systems where appropriate
• encryption in transit and, where appropriate, at rest
• logging and monitoring of system access
• secure development practices and vulnerability management
• staff confidentiality obligations and training
• backups, business continuity and disaster recovery processes
• regular review of security controls

Be careful with wording like we guarantee complete security or we'll prevent all unauthorised access. No SaaS provider can honestly promise that. A better approach is to commit to maintaining administrative, technical and organisational safeguards that are appropriate for the nature of the data and the services.

What About Security Standards?

If you have ISO 27001, SOC 2 or another certification, your contract can refer to it. If you don't, don't pretend that you do. Instead, describe the controls you actually have and avoid locking yourself into a standard you can't meet.

Enterprise customers may also ask for audit rights. You can offer a practical alternative, such as providing current security documentation, your information security policy, summaries of penetration testing, or responses to security questionnaires. Unlimited on-site audit rights can be hard for a small SaaS business to manage, especially if you have many customers.

How Should Breach Notification Work?

Your breach notification clause should require prompt notice to the customer, but it should also leave room to investigate and avoid premature or inaccurate statements.

Under the Privacy Act 2020, a notifiable privacy breach generally needs to be reported to the Privacy Commissioner and affected individuals if it's reasonable to believe the breach has caused, or is likely to cause, serious harm. Notification must happen as soon as practicable after you become aware of the notifiable privacy breach.

Your SaaS contract can sit alongside this legal requirement by setting out a practical process. For example, it can say you will:

• notify the customer without undue delay after becoming aware of a confirmed or reasonably suspected privacy breach affecting their data
• provide the information you reasonably have at the time, such as the nature of the incident, affected systems and steps being taken
• keep the customer updated as your investigation continues
• take reasonable steps to contain, investigate and remedy the incident
• cooperate with the customer so they can assess any data breach notification obligations they may have

Some customers will ask for notification within 24 or 48 hours. That can be workable if the clause only requires an initial notice based on available information. It may be risky if it requires a full root cause report or final impact assessment within that timeframe.

It also helps to define the difference between a security incident and a privacy breach. Not every attempted login, spam email or blocked attack is a privacy breach. Your contract should focus urgent reporting on incidents that actually affect, or are reasonably likely to affect, customer data.

Can You Use Overseas Hosting And Subprocessors?

Yes, you can usually use overseas hosting and subprocessors, but your contract needs to be transparent and your privacy settings need to meet New Zealand requirements.

Many New Zealand SaaS businesses use offshore providers for hosting, email delivery, analytics, support tickets, payments and infrastructure monitoring. That's normal. The privacy issue is how you manage those providers and what your customer has agreed to.

Under IPP 12 of the Privacy Act 2020, overseas disclosures of personal information can require reasonable steps to make sure the information will be protected by comparable privacy safeguards, unless an exception applies. Where an overseas provider is simply storing or processing information for you and not using it for its own purposes, the legal analysis can be more nuanced. Either way, your customer will want comfort that offshore access is controlled.

Your SaaS contract should usually say:

• where customer data may be hosted or accessed from, or how you'll make that information available
• that you may use subprocessors to provide the service
• that subprocessors must meet privacy, confidentiality and security obligations under appropriate subprocessor terms
• that you remain responsible to the customer for the parts of the service performed by your subprocessors
• how you'll notify customers about material changes to subprocessors

Subprocessor Approval Options

There are a few ways to handle subprocessor approval in your contract:

• General authorisation: the customer agrees you can use subprocessors, and you maintain an up-to-date list.
• Notice and objection: you notify the customer of new material subprocessors and give them a reasonable period to object on privacy or security grounds.
• Specific approval: you need written approval before adding each subprocessor. This is more common for high-risk or heavily negotiated contracts.

For many SaaS startups, general authorisation with a clear subprocessor list is the most practical. If you're selling into larger enterprises, a notice and objection process may be a better middle ground.

What Happens To Customer Data At The End?

Your contract should say how the customer can export their data, when you'll delete it, and what happens to backups and legally retained records.

This is one of the areas customers often ask about late in the sales process. If your contract is silent, they may worry about lock-in, data loss or lingering copies after termination.

A practical data return and deletion clause should cover:

• how long the customer can access or export data after termination
• whether you'll provide data in a standard format, such as CSV or another available export format
• when you'll delete or de-identify customer data from active systems
• how backups are handled and when they're overwritten or deleted in the ordinary backup cycle
• whether you can retain limited records for legal, security, billing or compliance purposes
• whether you can keep aggregated or de-identified analytics that no longer identify individuals or the customer

Try to avoid promising immediate deletion from every system if your backups don't work that way. A more accurate clause might say active data will be deleted within a set period, while backup copies will be protected from normal use and deleted or overwritten on the normal backup cycle.

If your platform is mission-critical, customers may also ask for migration assistance. You can include this, but be clear about what is included in the subscription fee and what is chargeable professional services work.

Common Mistakes To Avoid

The biggest mistake is using privacy wording that sounds impressive but doesn't match your product, systems or team practices.

Watch out for these common issues:

• Copying GDPR wording without adapting it for New Zealand: controller and processor language can help, but it shouldn't replace Privacy Act 2020 concepts.
• Forgetting support and admin data: your platform data clause may not cover billing contacts, helpdesk tickets, call recordings or admin users.
• Promising all data stays in New Zealand: only say this if it's true for hosting, backups, support access and subprocessors.
• Leaving subprocessors unnamed: enterprise customers usually expect to know the main providers involved in hosting, support, analytics and communications.
• Using vague breach wording: a clause that just says you'll comply with privacy laws doesn't tell the customer when you'll notify them.
• Overpromising deletion: your contract should reflect how backups, logs and legally retained records actually work.
• Letting the contract and privacy policy conflict: make sure your public privacy policy, SaaS terms and DPA tell a consistent story.

Your privacy clauses should also line up with your operational documents. If your contract says access is limited to authorised personnel, your internal permissions should support that. If it says you keep a subprocessor list, someone needs to own updating it.

Key Takeaways

• New Zealand SaaS privacy clauses should turn Privacy Act 2020 obligations into clear contract promises about data use, security, breaches, hosting, subprocessors and deletion.
• A standalone data processing addendum isn't always required, but it can make enterprise sales much easier.
• Your contract should describe your actual role and data practices, rather than copying overseas wording that doesn't fit.
• Breach clauses should require prompt notice and cooperation, while allowing time to investigate properly.
• Be transparent about overseas hosting and subprocessors, and make sure your customer data clause matches your technical setup.
• Data return and deletion wording should cover exports, active systems, backups, retained records and de-identified analytics.

If you'd like help with your SaaS customer contracts, privacy clauses, data processing addendums and subprocessor wording, you can reach us at 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.