Privacy Policy Checklist For Healthtech Startups In NZ

Launching a healthtech product is exciting, but privacy can feel like one of the heavier parts of getting ready. If your app, platform or device collects symptoms, medication details, test results, appointment notes or wellbeing data, you're handling information people care about deeply.

The good news is that you don't need to make your privacy setup complicated. You do need to be clear, careful and specific about what data you collect, why you collect it, who can access it and what happens if something goes wrong.

A strong health app privacy policy in NZ should connect your legal obligations with the real user journey - from sign-up screens and consent ticks through to cloud hosting, analytics tools, overseas transfers and breach response.

Do I Need A Privacy Policy For A Healthtech App In NZ?

Yes, if your healthtech product collects personal information, you need privacy notices that clearly explain what you're doing with that information.

Under the Privacy Act 2020, any business that collects personal information must tell people key details at or before collection where practicable. If you collect health information, the Health Information Privacy Code 2020 also matters. It adapts the Privacy Act's privacy principles for health information and health agencies.

Your privacy policy is usually the main public document users can read. But for healthtech, it's rarely enough on its own. You'll often need shorter privacy notices and consent prompts inside the app too, especially at points where you collect sensitive information or connect to another provider.

For example, if your onboarding asks a user for their date of birth, medications, allergies and symptoms, your screen shouldn't just say, I agree to the Privacy Policy. It should also explain, in plain English:

• why you need those details
• whether the user has to provide them
• who can see them
• whether you share them with clinicians, labs, insurers or cloud providers
• how the user can access or correct their information

New Zealand businesses also need a privacy officer. This can be someone inside your business who understands your data practices, information security policy and breach response process. In an early-stage startup, that might be a founder, operations lead or compliance manager.

What Counts As Health Information In New Zealand?

Health information is broader than many founders first realise, and it can include information that only becomes health-related once you connect it with your product.

Under the Health Information Privacy Code 2020, health information can include information about a person's health, disabilities, health services provided to them, donations of body parts or substances, and information collected in providing health services. It can also include details that identify a person's health provider or health services.

In a healthtech product, this might include:

• symptom checklists and pain scores
• mental health check-ins, mood scores or sleep data
• medication lists, allergies and treatment plans
• test results, images, scans or measurements
• appointment notes and chat messages with clinicians
• wearable device data, such as heart rate or blood glucose readings
• NHI numbers or other identifiers used in a health setting
• location data that reveals attendance at a clinic or service

Say Maia launches a diabetes management app in Auckland. Users enter glucose readings twice a day, list their medication and invite their GP to view progress reports. Maia's app isn't just collecting ordinary account data. It's collecting health information, and the GP-sharing feature adds an extra disclosure step that needs to be explained clearly.

Even de-identified data needs careful handling. If your dataset can reasonably be linked back to a person, directly or indirectly, you should treat it as personal information. This is especially relevant where you have small patient groups, rare conditions or detailed timestamps.

What Should Your Healthtech Privacy Policy Include?

Your privacy policy should explain your actual data practices, not just describe privacy law in general terms.

Templates can be a helpful starting point, but healthtech privacy documents often need tailoring because the data is sensitive and the user journey can be complex. A lawyer should tailor your privacy policy before you use it, especially if you share data with clinicians, overseas providers or AI tools.

Privacy Policy Outline

1. Who You Are: State your legal business name, trading name, NZBN if relevant and contact details for privacy questions.
2. What Information You Collect: List account details, health information, device data, payment-related data, support messages and technical data.
3. How You Collect It: Explain collection through app forms, connected devices, clinicians, integrations, cookies, analytics, customer support and other third parties.
4. Indirect Collection: Explain when you collect information from clinicians, devices, integrations, referrers, labs, practice management systems or other providers, and how users will be told about this.
5. Why You Use It: Describe purposes such as providing the service, personalising features, clinical workflows, support, security, analytics and legal compliance.
6. Who You Share It With: Name categories of recipients, such as cloud hosts, analytics providers, health practitioners, payment processors and support tools.
7. Overseas Disclosures: Identify where data may go and how you assess whether overseas recipients have acceptable privacy protections.
8. Security Measures: Summarise practical safeguards, such as access controls, encryption, logging, backups and staff permissions.
9. Retention And Deletion: Explain how long you keep different categories of information and how users can request deletion where available.
10. Access And Correction: Tell users how they can request access to their personal information or ask you to correct it.
11. Privacy Complaints: Explain how users can contact you and that they can complain to the Office of the Privacy Commissioner if concerns aren't resolved.

Your policy should match your product. If you don't sell data, say that. If you use aggregated analytics, explain what that means. If you use a third-party chatbot, symptom checker or AI model, don't hide that in vague wording.

What If You Collect Information Indirectly?

Healthtech products often collect information from someone other than the user. For example, you might receive appointment notes from a clinician, readings from a connected device, referral details from a health provider, lab results through an integration or profile data from another platform.

Since 1 May 2026, Information Privacy Principle 3A requires organisations to consider notification when they collect personal information indirectly, meaning from someone other than the individual concerned. If you're a health agency collecting health information indirectly, the corresponding Health Information Privacy Code Rule 3A is especially important.

In practical terms, if your startup collects personal information from a third party, you generally need to make the user aware of the required matters as soon as reasonably practicable after collection. This can include what you've collected, why, who it may be shared with, whether collection is required or optional, and how the user can access and correct it. You may not need to notify again if an exception applies or the user has already been properly informed.

This matters because many healthtech data flows sit behind the scenes. If Maia's diabetes app pulls glucose readings from a wearable and medication updates from a clinic system, Maia shouldn't rely only on the clinic's paperwork unless it has checked that the user has already been properly told. The app's privacy policy, onboarding screens and integration notices should work together.

How Should Consent Work In App Onboarding?

Consent should be clear, specific and tied to what the user is actually agreeing to, rather than buried in one large checkbox.

New Zealand privacy law doesn't require consent for every use of personal information. Often, you can collect and use information because it's necessary to provide the service the user asked for. But health data is sensitive, and consent is usually the best way to manage higher-risk features, optional sharing and unexpected uses.

A practical onboarding flow might include:

• Account Creation: Link to your privacy policy and explain the basic information needed to create an account.
• Health Data Collection: Give a short notice before asking for symptoms, medications or measurements.
• Clinical Sharing: Ask for separate consent, using clear health data sharing wording, before sending reports to a GP, specialist or health service.
• Device Integrations: Explain what data will be pulled from a wearable or connected device, including where information is coming from.
• Marketing: Keep marketing consent separate from service consent, especially for email and in-app promotions.
• Research Or Product Improvement: Use separate wording if you want to use health data for research, model training or product analytics beyond core service delivery.

For example, Maia's diabetes app asks users to agree to the privacy policy at sign-up. Later, when a user wants to connect their GP, the app displays a separate screen: We'll share your glucose readings, medication list and weekly progress report with Dr Patel at Green Street Medical. You can turn this off at any time. That's much clearer than a broad consent hidden in the original terms.

Your records matter too, and a data retention policy can help. Keep a timestamped record of what each user agreed to, the version of the wording they saw and when consent was changed or withdrawn.

What Should Your Cloud And Supplier Agreements Say?

Your supplier agreements should clearly control how each provider can access, store, secure and use health information.

Most healthtech startups rely on third parties. You might use a cloud host, app developer, analytics platform, support desk, SMS provider, payment processor and AI vendor. Each one can create privacy risk if the contract is vague.

New Zealand privacy law doesn't use the exact same controller and processor language as the GDPR, but the idea is still useful. If a supplier handles data for you, your agreement should say they can only process it for your business purposes and must protect it properly.

Data Processing Agreement Outline

1. Parties And Roles: Identify your business and the supplier, and describe the supplier's role in handling personal information.
2. Types Of Data: List the categories of data involved, including health information, account data and technical logs.
3. Permitted Purposes: State exactly what the supplier can do with the data and ban unrelated use, sale or training unless agreed.
4. Security Requirements: Set minimum standards for access controls, encryption, backups, vulnerability management and staff access.
5. Subcontractors: Require approval or notice before the supplier uses subcontractors who can access the data.
6. Overseas Storage And Access: Identify countries where data may be stored or accessed and require safeguards for overseas disclosure.
7. Breach Notification: Require fast notice if the supplier suspects unauthorised access, loss, disclosure or security compromise.
8. Assistance With Requests: Require help with access, correction, deletion and privacy complaints.
9. Return Or Deletion: Say what happens to data when the contract ends.
10. Audit And Evidence: Require enough reporting, certificates or audit rights to check the supplier is following the agreement.

A lawyer should tailor this before you sign it or give it to a supplier. In practice, the hardest clauses are usually breach notification timing, overseas storage, AI training rights and subcontractor control.

What If Health Data Is Stored Or Accessed Overseas?

You can send or store health data overseas in some situations, but you need to check Privacy Act rules before you do it.

Information Privacy Principle 12 of the Privacy Act 2020 deals with overseas disclosure. In simple terms, if you disclose personal information to an overseas recipient, you usually need to be satisfied that the recipient is subject to privacy protections comparable to New Zealand's, or use another permitted pathway such as informed authorisation from the individual.

This can come up more often than you think. Your users may be in New Zealand, but your:

• cloud servers may be in Australia or Singapore
• customer support platform may allow staff in the United States to access tickets
• analytics provider may process event data offshore
• AI tool may send prompts and outputs to overseas systems
• software developer may access production data from another country

Don't assume that a big-name provider automatically solves this. You still need to understand where data is stored, who can access it and what contractual terms apply.

Your privacy policy should explain overseas disclosures in plain language. Your supplier agreement should back that up with controls. For higher-risk health data, you may also need a privacy impact assessment that records the decision-making behind your setup.

If your product uses overseas AI tools, be extra careful and consider an AI governance policy. Prompts can include health information, and outputs can reveal it. Your supplier terms should say whether the tool can use your data to train models, whether humans can review it and how long it is retained.

What Should You Do If There Is A Privacy Breach?

If there's a privacy breach, your first job is to contain it, assess the risk and decide whether it's notifiable under the Privacy Act 2020.

A privacy breach can include unauthorised access, accidental disclosure, loss of information, ransomware, misdirected emails, exposed cloud storage or a supplier incident. Health information can increase the chance of serious harm because it's sensitive and hard to change once exposed.

Breach Response Steps

1. Contain The Issue: Disable access, rotate keys, revoke tokens, pause affected integrations or take the exposed system offline if needed.
2. Preserve Evidence: Keep logs, screenshots, supplier notices, affected user counts, timelines and internal decisions.
3. Assess Serious Harm: Look at the sensitivity of the information, who has it, whether it was encrypted and what harm could follow.
4. Notify If Required: If the breach is likely to cause serious harm, notify the Office of the Privacy Commissioner and affected individuals as soon as practicable.
5. Support Users: Give practical steps, such as changing passwords, watching for scams or contacting their health provider if clinical care could be affected.
6. Fix The Root Cause: Patch systems, update supplier terms, retrain staff and improve access controls.

New Zealand doesn't set a fixed 72-hour notification deadline like some overseas regimes. The rule is to notify as soon as practicable once you believe a breach is notifiable.

Your privacy policy doesn't need to describe every breach step in detail, but your internal breach response plan should.

Key Takeaways

• A healthtech privacy policy in NZ needs to reflect the Privacy Act 2020 and, where health information is involved, the Health Information Privacy Code 2020.
• If you collect information from clinicians, devices, integrations or other third parties, consider IPP3A and, for health agencies, HIPC Rule 3A.
• Your app should use clear privacy notices and consent flows at the points where users share sensitive information or choose optional data sharing.
• Cloud providers, analytics tools, developers and AI vendors should be covered by written supplier or data processing terms.
• Overseas storage or access needs careful checking under Information Privacy Principle 12, not just a line in your privacy policy.
• You should have a breach response plan that helps you contain incidents, keep records and notify the Office of the Privacy Commissioner and users where required.

If you'd like help with your healthtech privacy policy, app consent flows, supplier data processing terms or breach response documents, you can reach us at 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.