GDPR Data Processing Agreements For NZ SaaS Companies

Mia runs a Wellington SaaS platform that helps marketing teams manage customer campaigns. A German prospect is ready to sign, but procurement sends through a privacy questionnaire and asks for a GDPR data processing agreement before they can approve the deal.

If that sounds familiar, you're not alone. NZ SaaS businesses often first meet the GDPR through customer procurement, not a regulator letter. It can feel like a lot when you're already managing your Privacy Act 2020 obligations at home.

The good news is that a DPA doesn't have to derail the sale. With the right clauses, it can sit neatly alongside your SaaS terms, privacy policy, data sharing agreement and internal privacy processes.

Do NZ SaaS Companies Need To Comply With GDPR?

It depends, but many NZ SaaS companies do need to think about the GDPR when they sell to EU or UK customers.

The EU General Data Protection Regulation can apply outside Europe if your business offers goods or services to people in the EU, or monitors their behaviour. The UK GDPR has a similar approach for the UK.

For a New Zealand SaaS business, that usually matters in two common situations:

• You sell directly to EU or UK customers, such as a French retailer or a UK accounting firm.
• Your customer is based in New Zealand or Australia, but they use your platform to handle personal information about EU or UK users.
• You track EU or UK users through analytics, profiling, cookies or behavioural tools in a way that brings you within GDPR rules.

Not every overseas sale automatically makes the GDPR apply. For example, if an EU person happens to find and use a NZ-only service that isn't aimed at the EU market, the analysis may be different.

In practice, the procurement team on the customer side often won't want to debate all of that. If they're subject to the GDPR, they'll usually require a privacy contract with each software provider that handles personal data for them. That's where a GDPR data processing agreement comes in.

Why Are EU And UK Customers Asking For A DPA?

EU and UK customers ask for a DPA because the GDPR requires controllers to use written contracts with processors.

In SaaS, your customer is often the controller because they decide why and how personal data is used. Your business is often the processor because you host, store, analyse or otherwise handle that data for the customer through your platform.

Article 28 of the EU GDPR sets out what must be in the contract between a controller and processor. UK GDPR has similar requirements. A procurement team asking for a SaaS data processing agreement is usually trying to tick off those Article 28 obligations.

A DPA can also help your customer answer practical questions, such as:

• Where will personal data be hosted?
• Can you use subprocessors, such as cloud hosting providers?
• How quickly will you tell them about a data breach?
• Will you help them respond to access, correction or deletion requests?
• What happens to personal data when the contract ends?

For a GDPR data processing agreement, NZ SaaS companies usually need more than a short privacy paragraph in their standard terms. A few privacy clauses may help, but they often won't cover the specific items EU and UK customers need for procurement approval.

What Should A GDPR Data Processing Agreement Include?

A GDPR DPA should include the mandatory processor terms, plus enough operational detail to match how your SaaS product actually works.

Templates can be useful for spotting common clauses, but they often miss the product-specific details that matter most. A lawyer should tailor the document before you use it with customers, especially if you process sensitive data, use AI features or rely on several third-party tools.

A Practical DPA Outline

A sensible fill-in outline for your DPA might look like this:

1. Parties And Roles: State who is the controller, who is the processor, and whether any group companies are covered.
2. Processing Details: Describe the categories of personal data, data subjects, processing activities, purpose and contract duration.
3. Customer Instructions: Confirm that you process personal data only on the customer's documented instructions, unless law requires otherwise.
4. Confidentiality: Require your staff and approved contractors to keep personal data confidential.
5. Security Measures: Set out technical and organisational measures, such as access controls, encryption, backups, logging and staff training.
6. Subprocessors: Explain when you can use third-party providers, how customers are notified and how objections are handled.
7. International Transfers: State where data is processed and what transfer safeguards apply if data leaves the EU, UK or New Zealand.
8. Data Subject Requests: Explain how you'll help the customer deal with access, correction, deletion and portability requests.
9. Breach Notification: Set out how quickly you'll notify the customer and what information you'll provide.
10. Deletion Or Return: Say what happens to personal data when the services end, including backups and retention periods.
11. Audit And Information Rights: Give the customer enough information to show compliance without opening your systems in an unworkable way.
12. Liability And Order Of Documents: Align the DPA with your SaaS terms, including liability caps, indemnities and which document wins if there's a conflict.

The breach notification clause deserves careful drafting. Under the GDPR, a controller generally has 72 hours to notify the relevant supervisory authority after becoming aware of a personal data breach, unless the breach is unlikely to risk people's rights and freedoms. Because your customer may be on that clock, your processor notice to them usually needs to be very prompt.

How Does A DPA Work With Your NZ Privacy Documents?

A DPA doesn't replace your New Zealand privacy documents. It works alongside them.

Your NZ privacy framework usually starts with the Privacy Act 2020 and the Information Privacy Principles. If your business collects, stores or uses personal information, you should have privacy practices that match those principles.

For a SaaS company, your privacy documents may include:

• Privacy Policy: Explains to users and customers what personal information you collect, why you collect it, who you share it with and how people can contact you.
• SaaS Terms Or Customer Agreement: Covers the commercial deal, payment, access rights, acceptable use policy, IP ownership, service levels, liability and termination.
• Data Processing Agreement: Covers controller and processor obligations for customer personal data, especially under the GDPR or UK GDPR.
• Internal Privacy And Security Procedures: Sets out who can access data, what to do if something goes wrong, and how staff handle requests.

These documents should speak to each other. If your privacy policy says customer data may be stored in New Zealand, Australia and the United States, your DPA shouldn't say it's stored only in New Zealand. If your SaaS terms cap liability, your DPA should be clear on whether that cap applies to privacy claims.

You should also think about New Zealand's notifiable privacy breach rules. Under the Privacy Act 2020, you must notify the Office of the Privacy Commissioner as soon as practicable if a privacy breach has caused, or is likely to cause, serious harm. You'll also usually need to notify affected individuals as soon as practicable, unless an exception applies or public notice is permitted instead. Your DPA should fit with that process, rather than creating a separate promise your team can't meet.

What Happens With Overseas Transfers And Subprocessors?

Overseas transfers and subprocessors need special attention because this is where many SaaS DPAs become messy.

New Zealand has an EU adequacy decision, which means the EU recognises New Zealand as providing an adequate level of data protection for personal data transferred from the EU. The UK also treats New Zealand as adequate for UK transfer purposes. That helps, but it doesn't solve every transfer question.

The issue is that many NZ SaaS businesses don't process data only in New Zealand. You may use cloud hosting, analytics, customer support tools, error monitoring, email providers or AI tools based in other countries.

Worked Example: A Kiwi CRM Selling To A German Customer

Say Mia's CRM platform signs a German customer for 120 users. The customer uploads contact names, email addresses, phone numbers and sales notes about EU prospects.

Mia's company is based in New Zealand. The production database is hosted in Sydney. Support tickets are handled through a US-based helpdesk tool, and product analytics are processed by a provider with servers in the United States.

The DPA shouldn't simply say that all data is stored in New Zealand. A better approach is to clearly list:

• New Zealand as the SaaS company's location.
• Australia as the hosting region for the main database.
• The US helpdesk provider as a subprocessor that may receive limited customer support data.
• The US analytics provider as a subprocessor, if personal data is sent to that tool.
• The transfer mechanism used for any restricted EU or UK transfers, such as the relevant Standard Contractual Clauses or UK transfer documents where needed.

This level of detail helps your customer's privacy and procurement teams sign off the deal. It also protects your business because you're not promising a data flow that your product can't actually deliver.

Your subprocessor clause should also say how you'll notify customers about new subprocessors. Some customers expect 30 days' notice before a new subprocessor is engaged, but the right timeframe depends on your sales model, product risk and customer base.

How Can You Put A DPA In Place Without Slowing Down Sales?

You can keep sales moving by preparing a practical DPA and a clear privacy pack before procurement asks for it.

The aim isn't to over-engineer the process. It's to avoid a last-minute scramble when a promising EU or UK customer is ready to buy.

Start With Your Data Map

Write down what customer personal data your platform handles. You don't need a perfect enterprise diagram, but you should know:

• What data you collect or receive.
• Whose data it is, such as customer staff, end users, patients, students or prospects.
• Where the data is hosted.
• Which third-party tools receive it.
• How long you keep it after the customer leaves.

This makes the DPA much easier to complete and reduces the risk of giving inconsistent answers in privacy questionnaires.

Build A Customer-Ready Privacy Pack

For EU and UK sales, it helps to have a neat pack you can send to procurement. That might include:

• Your standard DPA or data processing schedule.
• Your privacy policy.
• A subprocessor list and records of processing activities.
• A short security summary.
• Your breach response process.
• A contact email for privacy questions.

If you serve larger customers, you may also need to negotiate their DPA. Try to keep a clear internal position on clauses you can accept, clauses you can accept with changes, and clauses that don't work for your product.

Watch out for DPAs that create obligations you can't meet, such as 24/7 phone support for every breach, unlimited audit rights, data localisation promises or uncapped liability for any privacy issue. These clauses may look like standard procurement wording, but they can create real commercial risk for a growing SaaS business.

Key Takeaways

• NZ SaaS companies often need a GDPR DPA when they sell to EU or UK customers, even if the business is based in New Zealand.
• A DPA is usually needed because your customer must have Article 28 processor terms in place under the EU GDPR or UK GDPR.
• Your DPA should cover processing details, security, subprocessors, international transfers, breach notice, data subject requests and deletion or return of data.
• A DPA doesn't replace your Privacy Act 2020 documents. It should work with your privacy policy, SaaS terms and internal privacy processes.
• Be accurate about where data goes. Hosting regions, support tools, analytics providers and AI tools can all affect your transfer and subprocessor clauses.
• Having a customer-ready privacy pack can make procurement smoother and help you close EU and UK SaaS deals with more confidence.

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