What Data Processing Clauses Do SaaS Customers Need?

What should you put in your SaaS customer contract when your product handles customer data?

The reassuring answer is that you don't need to turn your agreement into a privacy textbook. You do need clear, practical data processing clauses that explain what you can do with customer data, how you'll protect it, and what happens if something goes wrong.

If you sell SaaS to business customers, these clauses can help you close deals faster. They also make privacy expectations much clearer from day one, especially if your platform stores personal information, uses overseas cloud hosting, or relies on other software providers behind the scenes.

If a customer asks for a data processing clause for New Zealand, they usually mean a set of processor-style obligations in your SaaS agreement or privacy schedule. New Zealand privacy law doesn't use exactly the same controller and processor language as the GDPR, but the commercial expectation is often very similar.

Do You Need A Data Processing Agreement For SaaS Customers?

Yes, if your SaaS product handles personal information for business customers, you should usually have data processing clauses in your customer contract.

This might be a standalone data processing agreement, often called a DPA, or a privacy policy schedule attached to your main SaaS terms. For many New Zealand SaaS companies, a well-drafted privacy and data security schedule is enough.

Your customers will want comfort that you won't misuse their data. You'll want clear limits on your responsibilities so you don't accidentally promise more than your product, team or infrastructure can deliver.

Good data processing clauses usually cover:

• what customer data you can access, store, use and disclose
• the purpose you can process that data for
• your security measures and minimum standards
• how you use cloud hosting and other subprocessors
• what happens if there's a privacy or security incident
• data return, deletion and retention when the contract ends
• audit rights, reports and customer compliance requests

Say you run a Wellington-based HR SaaS platform that helps employers manage leave requests and staff records. Your customer uploads names, contact details, role information, leave history and sometimes medical certificates. Even if the customer controls most of what goes into the platform, you still need clear rules about how your business handles that information while providing the service.

How Does The Privacy Act 2020 Apply To Cloud Software?

The Privacy Act 2020 can apply where your SaaS platform collects, holds, uses or discloses personal information.

Personal information means information about an identifiable individual. It can include obvious details like a name, email address or phone number, but it can also include user IDs, IP addresses, employee records, customer notes and support tickets if a person can be identified from them.

New Zealand's Privacy Act is built around the Information Privacy Principles, often called the IPPs. These cover things like collection, storage, access, correction, accuracy, use, disclosure and overseas disclosure of personal information.

For SaaS businesses, the most relevant themes are usually:

• purpose limitation: you should only use customer data for agreed purposes, such as providing support, hosting the platform, maintaining security and improving the service where permitted
• security: you need reasonable safeguards against loss, unauthorised access, misuse or disclosure
• transparency: your customer should understand how data moves through your platform
• overseas handling: you need to understand whether personal information is being disclosed overseas for a foreign recipient's own use, or stored or processed offshore on your behalf
• breach response: serious privacy breaches can trigger notification obligations

New Zealand law doesn't label one party as a controller and the other as a processor in the same way some overseas privacy laws do. Instead, the Act uses the concept of an agency. In some SaaS arrangements, both you and your customer may have Privacy Act responsibilities for the same information, depending on who controls what and how the data is used.

Your contract can't remove legal obligations under the Privacy Act 2020. What it can do is set practical boundaries between you and your customer so each side knows its role.

What Should A Customer Data Clause In A SaaS Contract Say?

A customer data clause should say who owns or controls the customer data, how you can use it, and what you won't do with it.

For most SaaS providers, the clause should make it clear that the customer keeps control of the data it uploads into the platform. Your business receives a limited right to use that data so you can provide, secure, support and improve the service.

A good customer data clause often deals with:

• ownership: the customer owns or controls the customer data, subject to any rights you need to operate the platform
• permitted use: you can use customer data to provide the SaaS, fix bugs, respond to support requests, maintain security, back up data and meet legal obligations
• restricted use: you won't sell customer data, use it for unrelated advertising, or access it for reasons outside the contract
• aggregated data: you may use de-identified or aggregated data for analytics or product improvement, if the wording is clear and the data can't reasonably identify individuals
• customer responsibilities: the customer is responsible for having the right notices, consents and lawful basis to upload personal information into your platform
• admin access: the customer controls its user accounts, permissions and internal access settings

Be careful with phrases like we'll comply with all privacy laws worldwide. That may sound helpful, but it can create a promise you can't realistically meet, especially if customers use your SaaS in several countries. It's usually better to name the laws that matter to the deal and include a process for handling extra requirements.

A data processing agreement template can be a useful starting point, but data clauses work best when they match how your product actually works. If your platform uses AI features, analytics, third-party integrations or customer-configured workflows, generic wording can miss the parts your customers care about most.

How Should You Deal With Overseas Hosting?

You should tell customers where their data may be hosted or accessed from, and you should include practical safeguards for overseas handling of personal information.

Many New Zealand SaaS businesses use cloud infrastructure or support teams outside New Zealand. That isn't automatically a problem. The key is to understand the difference between an overseas disclosure and overseas processing on your behalf.

Under Information Privacy Principle 12 in the Privacy Act 2020, an agency disclosing personal information to a foreign person or entity must generally take reasonable steps to make sure the overseas recipient is subject to privacy safeguards comparable to the New Zealand Privacy Act, unless an exception applies. This is most relevant where the overseas recipient receives the information for its own use, or for a purpose that isn't simply providing services to you.

However, IPP 12 doesn't apply to every overseas cloud or service provider arrangement in the same way. If an overseas cloud provider only stores or processes personal information on your behalf and doesn't use it for its own purposes, section 11 of the Privacy Act may mean the information is treated as held by you rather than disclosed to that provider for IPP 12 purposes. That doesn't remove the need for strong contracts, security controls and transparency with customers.

In SaaS contracts, overseas hosting can still get tricky because data may move through several providers. For example, your app might be built in New Zealand, hosted on cloud servers in Australia, backed up in Singapore, monitored using a US-based security tool, and supported by a contractor in the Philippines.

Your data processing clauses should usually cover:

• the countries or regions where customer data may be hosted, stored, accessed or backed up
• whether providers are using data only to provide services to you, or for their own purposes
• what notices, authorisations or customer contract permissions are needed for the way data is handled
• the safeguards you use with overseas providers, such as written contracts, an information security policy, security standards and confidentiality obligations
• how you assess whether a provider has appropriate privacy and security controls
• whether you'll notify customers before changing key hosting locations

You don't have to list every small operational detail, but your customers shouldn't be surprised to learn that their data is stored overseas. If your sales team says all data stays in New Zealand, your legal terms and actual setup need to match that promise.

What Should A Subprocessor Clause Say?

A subprocessor clause should explain when you can use third-party providers to process customer data, and what responsibilities you keep if you do.

A subprocessor is usually another service provider that helps you deliver your SaaS and may handle customer data. Common examples include cloud hosting providers, email delivery tools, helpdesk platforms, analytics providers, payment tools, monitoring software and outsourced support providers.

Customers often ask for approval rights over subprocessors because they want to know who else can access their data. You can handle this in a few ways.

Option 1: General Permission

You can ask the customer to give general permission for you to use subprocessors, as long as you meet agreed conditions. This is practical for standard SaaS because your stack may change over time.

The conditions might include using reputable providers, having written contracts or a data sharing agreement where needed, flowing down privacy and security obligations, and staying responsible for the subprocessor's work.

Option 2: A Current Subprocessor List

You can maintain a list of current subprocessors and tell customers where to find it. Your contract can say you may update the list, with advance notice for material changes.

This approach works well when enterprise customers want transparency, but you can't ask every customer to approve every routine vendor change.

Option 3: Customer Objection Rights

You can give customers a right to object to a new subprocessor for reasonable privacy or security reasons. Your contract should explain what happens if you can't resolve the objection.

Without a clear process, a customer objection can leave you stuck between your product roadmap and a contract promise that's too strict.

A practical subprocessor clause usually says:

• you can appoint subprocessors to help provide the service
• you'll require subprocessors to protect customer data to a suitable standard
• you remain responsible to the customer for your subprocessors' acts and omissions, within the limits of your contract
• you'll keep a current list or provide details on request
• you'll give notice of material changes where appropriate
• the customer has a reasonable objection process, if that suits your sales model

How Fast Do You Need To Give Notice Of A Data Breach?

Under the Privacy Act 2020, a notifiable privacy breach must be reported to the Privacy Commissioner and affected individuals as soon as practicable after you become aware that the breach is notifiable.

The Act doesn't set a fixed number of hours for every breach. A privacy breach is notifiable if it has caused, or is likely to cause, serious harm. Serious harm depends on factors such as the sensitivity of the information, the actions taken to reduce harm, who obtained the information, and the nature of the harm that may result.

Your SaaS contract should deal with two different notice pathways:

• legal notification: notices to the Privacy Commissioner and affected individuals where the Privacy Act requires it
• contractual notification: notices between you and your customer so both sides can investigate, contain and respond to the incident

For business customers, it's common to agree a faster contractual notice period than the legal test requires. For example, you might agree to notify the customer without undue delay after confirming a security incident affecting their customer data, or within a set period such as 48 or 72 hours. The right timeframe depends on your team, your monitoring setup and the type of data you hold.

Try not to promise notice immediately if your team can't realistically investigate outside business hours. You can still be responsive without setting yourself up to breach the contract.

Your breach clause should usually cover:

• what counts as a security incident or privacy breach
• when the notice clock starts
• who receives notices
• what information you'll include if known, such as the type of data affected, dates, likely impact and steps taken
• how you and the customer will cooperate
• who decides whether regulators or individuals must be notified
• any limits on public statements, unless the law requires disclosure

For example, if an employee's laptop is stolen but the device is encrypted and remote-wiped, the incident may not be notifiable. If an unauthorised person downloads payroll information from your platform, the response will be very different. Your contract should give you enough flexibility to assess the facts properly.

What Should Happen To Data When The SaaS Contract Ends?

Your contract should say whether customer data will be returned, exported, deleted, retained or anonymised when the SaaS relationship ends.

This is one of the most practical data processing clauses, because customers often ask about it during procurement. They want to know they won't lose access to business-critical information if they cancel the service.

Your clause should deal with:

• how long the customer can access or export data after termination
• the format of any export, such as CSV or another standard format
• whether you charge for custom export work
• when you'll delete customer data from active systems
• how long backups are retained before normal deletion cycles remove the data
• whether you may keep records required for legal, accounting, security or audit purposes
• whether de-identified analytics can be retained

Be realistic about backups. Many SaaS businesses can't delete a single customer's data from every backup instantly without affecting the integrity of the backup system. It's usually better to explain that data in backups will be protected and deleted or overwritten through the normal backup cycle.

You should also think about suspended accounts. If a customer doesn't pay, can you suspend access? How long do you keep their data before deleting it? Without a written process, you may end up storing data for far longer than needed, which can increase privacy and security risk.

How Do You Balance Customer Demands With Your Own Risk?

You balance customer demands by accepting privacy obligations you can meet, and pushing back on terms that don't match your product, pricing or security model.

Enterprise customers sometimes send supplier privacy terms, data processing addenda or security terms that are written for large vendors or heavily regulated environments. Some will be fine. Others may ask you to accept unlimited liability, on-site audits, strict data localisation, very short breach reporting timeframes, or approval rights over every subprocessor.

Before you sign, check whether the clause is commercially workable. Ask yourself:

• Can we actually meet this security standard today?
• Do we know where all customer data is hosted, accessed and backed up?
• Can we give breach notices within the timeframe requested?
• Do we have contracts in place with our key subprocessors?
• Would this clause stop us from changing hosting provider or support tools?
• Does our liability cap cover privacy, security and confidentiality claims in a way that makes sense?

It's often better to offer a clear, sensible privacy schedule than to negotiate from scratch every time. That way, your sales team has a consistent position and your customers see that you've thought through the issues.

If you sell into regulated sectors like health, finance, education or government, you may need extra clauses. These customers may have their own security, retention, audit and procurement requirements. The right wording depends on the sector, the data and the way your product is used.

Key Takeaways

• New Zealand SaaS contracts should include practical data processing clauses if your platform handles personal information for customers.
• The Privacy Act 2020 doesn't use GDPR-style controller and processor labels, but processor-style obligations are still very useful in customer contracts.
• Your clauses should cover customer data use, security, overseas hosting, subprocessors, breach notice, deletion and retention.
• Overseas hosting isn't automatically an IPP 12 overseas disclosure if a cloud or service provider only stores or processes data on your behalf, but you still need strong contracts, security controls and transparency.
• Breach notice clauses should be fast enough to help customers respond, but realistic for your team and systems.
• A tailored privacy schedule can make sales conversations easier and reduce messy negotiations later.

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