Service Agreements for New Zealand Healthtech Startups

Healthtech founders often move fast on product, pilots and procurement, then sign a provider's standard contract without fully checking the legal risk. That is where problems start. Common mistakes include accepting vague service levels for business-critical software, overlooking privacy and health information clauses, and agreeing to broad liability exclusions that leave your startup carrying the loss if something goes wrong.

A good service agreement does more than record price and scope. For a New Zealand healthtech business, it needs to deal with uptime, implementation, data handling, security obligations, subcontractors, intellectual property, regulatory responsibilities and what happens when the relationship ends. If you are about to engage a software developer, cloud provider, clinical services partner, device maintenance supplier or outsourced support team, this guide explains what a service agreement for healthtech startups in New Zealand should cover, what to check before you sign, and where founders most often get caught by standard terms.

Overview

A service agreement for a healthtech startup should clearly allocate operational risk, privacy responsibilities and commercial expectations before work begins. In New Zealand, that usually means looking beyond the headline fee and checking whether the contract actually fits your product, your data flows and your customer promises.

The strongest agreements are specific about who does what, when they must do it, what standards apply, and who is responsible if a failure affects patients, clinicians, customers or your business.

• Define the services in practical detail, including deliverables, timelines, support hours and implementation responsibilities.
• Check service levels, response times, outage handling and any service credits or termination rights.
• Confirm who owns intellectual property in new work, integrations, custom code and data outputs.
• Review privacy, confidentiality and health information handling obligations carefully.
• Test liability caps, indemnities and exclusions against the real risk if the service fails.
• Look at subcontracting, offshore hosting and security standards before you accept the provider's standard terms.
• Make sure exit, transition and data return or deletion clauses are workable.
• Match the contract to your own obligations under customer agreements, procurement terms and New Zealand law.

What Service Agreements Cover

A service agreement sets the rules for how a provider delivers services to your business and what happens if the arrangement does not go to plan. For healthtech startups, the detail matters because the service often supports sensitive data, clinical workflows or core platform functionality.

Scope of services

The scope should say exactly what the provider is doing, not just describe the service at a high level. If you rely on a verbal promise or sales presentation, you may find it is not legally binding unless it is built into the agreement.

The scope should usually cover:

• what services are included and excluded
• deliverables, milestones and acceptance criteria
• implementation tasks and who is responsible for each step
• ongoing support, maintenance and update obligations
• training, onboarding or migration services
• dependencies on your team, your systems or third parties

This is especially important where the supplier is providing software-as-a-service, clinical workflow tools, integrations with practice management systems, remote monitoring support, AI-enabled functionality or managed IT services. A vague scope often leads to disputes about whether a failed integration, a delayed rollout or a missing feature is included in the fee.

Fees and payment structure

The price clause should do more than state the monthly or project fee. It should explain when invoices are issued, whether implementation costs are fixed, when price increases can happen, and whether there are additional charges for support, overages, change requests or urgent work.

Founders are often caught by clauses that allow the provider to increase fees on short notice, bill for all out-of-scope work at high hourly rates, or suspend services quickly for payment disputes. If the service is mission-critical, those clauses need careful attention before you sign.

Service levels and performance standards

If the provider supports a core healthtech function, your agreement should include measurable standards, not broad promises to use reasonable efforts. Uptime, support response times and fix times should reflect the actual impact of downtime on your business and users.

Depending on the service, you may need terms dealing with:

• system availability targets
• scheduled maintenance windows
• incident severity levels
• response and resolution timeframes
• escalation procedures
• reporting obligations
• service credits or termination rights for repeated failures

If your startup has committed service levels to hospitals, clinics, insurers or enterprise customers, your supplier agreement should not be weaker than the promises you are making downstream.

Privacy, confidentiality and health information

Privacy clauses are central in healthtech contracts because the service may involve personal information, health information or commercially sensitive data. A basic confidentiality clause is rarely enough.

In New Zealand, privacy obligations can arise under the Privacy Act 2020, and health information handling may also engage the Health Information Privacy Code. Your contract should align with how data is actually collected, stored, accessed, processed and deleted. If the provider hosts data offshore or uses subprocessors, that should be transparent in the agreement.

Key privacy and data handling clauses often deal with:

• what categories of information the provider can access
• whether the provider is acting only on your instructions
• minimum security requirements and incident notification obligations
• who can use de-identified or aggregated data, and for what purpose
• cross-border disclosures or overseas hosting
• audit rights or evidence of compliance
• return, export or deletion of data at the end of the contract

This is where healthtech startups need to be realistic. If a provider stores backup data in multiple regions, uses analytics tools, or reserves broad rights to use customer data for product improvement, the contract needs scrutiny before you accept the standard terms.

Intellectual property and ownership

The intellectual property clause should say who owns pre-existing materials, custom developments and outputs created during the engagement. Many founders assume they will own all work paid for under the contract, but standard terms often say the opposite.

That matters if you are paying for custom integrations, workflow templates, algorithms, reporting dashboards or branded patient communications. The agreement should clearly separate:

• your existing intellectual property
• the provider's existing tools, software and know-how
• new developments created specifically for your business
• licence rights to use any provider-owned components

Without a clear clause, you may end up unable to switch vendors, modify your product, or continue using deliverables after the relationship ends.

Term, termination and exit

The end of the relationship needs just as much attention as the start. Healthtech businesses can be badly disrupted if a provider can terminate quickly, lock access to data, or charge excessive transition fees.

Your service agreement should deal with fixed term versus rolling term arrangements, early termination rights, termination for breach, cure periods and what support must be provided during exit. If continuity matters, include transition assistance, data export formats and a reasonable handover period.

Legal Issues To Check Before You Sign

The main legal question is whether the contract puts risk on the party best able to manage it. Before you sign a contract, test each clause against a real failure scenario, not just the supplier's sales pitch.

Does the contract fit your regulatory position?

A service provider may describe itself as only a technology supplier, but the legal and practical position can be more complicated. If the service touches patient records, appointment flows, care coordination, remote monitoring or clinical decision support, you need to understand where responsibility sits.

Your agreement should make clear:

• whether the provider is processing information only on your instructions
• whether it has independent compliance obligations
• who is responsible for consents, notices and user-facing disclosures, including any privacy notice
• who handles privacy complaints, data access requests and security incidents
• what cooperation is required if a regulator, customer or enterprise client raises an issue

Even where there is no specific health sector approval built into the service arrangement, healthtech contracts still need to reflect the operational reality of handling sensitive information and supporting healthcare delivery.

Are liability caps realistic?

Liability clauses often decide who bears the cost of a serious failure. A provider's standard terms may cap liability at a very low amount, sometimes just the fees paid in the last month or quarter, even if your losses would be much higher.

That may not work for a healthtech startup where a service outage could trigger customer refunds, remediation costs, incident response expenses, reputational damage and urgent migration work. You should also look at exclusions for indirect loss carefully. Some losses that matter commercially may fall into excluded categories if the clause is drafted broadly.

Before you sign, compare the liability cap with realistic risks such as:

• extended downtime affecting customers or patients
• loss or corruption of records
• security incidents and breach response costs
• IP infringement claims
• regulatory investigations or contractual claims from your customers

You may also want certain obligations carved out of the cap, such as confidentiality breaches, privacy breaches, wilful misconduct or IP infringement.

What indemnities are you giving?

Indemnities shift risk in a stronger way than ordinary breach clauses. Founders often accept broad indemnities without noticing that they go beyond reasonable responsibility.

For example, a customer or provider may ask your startup to indemnify it for any claim connected with your platform, your data, your users or your use of the service. That can be too broad if the other party controls part of the risk.

Check whether each indemnity is limited by fault, breach, negligence or specific subject matter. Unlimited indemnities, especially those paired with a low liability cap for the other side, are a common red flag.

Can the supplier subcontract or host offshore?

If the provider can freely subcontract, migrate hosting, or use overseas subprocessors without notice, your risk profile may change after you sign. In healthtech, that can affect security, privacy, uptime and your ability to answer enterprise procurement questions.

The contract should state whether subcontracting is allowed, whether approval or notice is required, and whether the provider remains fully responsible for subcontractor performance. Offshore hosting and overseas access to information should also be clearly addressed.

Do the marketing and performance statements line up with the contract?

The Fair Trading Act 1986 matters here because business marketing claims still need to be accurate. If a provider has promised enterprise-grade security, New Zealand hosting, compliance support or integration capability, the contract should reflect those promises.

This is where founders often get caught. The sales process sounds tailored, but the final paper says the service is provided as-is, with no warranty that it will meet your needs. Before you rely on a verbal promise, ask for the material commitments to be inserted into the signed agreement or attached statement of work.

Common Service Agreement Mistakes

Most service agreement problems are not caused by obscure legal technicalities. They happen because the contract does not match the way the startup will actually use the service.

Signing standard terms too quickly

A standard form agreement is usually written to protect the supplier. That does not make it unacceptable, but it does mean you should expect imbalances around liability, termination, IP ownership and data use.

Before you accept the provider's standard terms, identify what is truly critical to your business. If the supplier supports patient communications, clinical workflow, records access, billing or your core product stack, the contract deserves more than a quick commercial review or contract review.

Leaving the scope too vague

If the statement of work is unclear, the provider may argue that key tasks are out of scope. Your team may assume the fee includes migration, training, testing, integrations or post-go-live support, while the supplier assumes those are change requests.

Clear contract drafting saves time and money later. It also makes it easier to manage underperformance without arguing about what was promised in the first place.

Ignoring privacy operational detail

Many agreements say the provider will comply with applicable privacy law, then say very little else. That is not enough where your business handles sensitive health information.

You should ask practical questions such as:

• who can access the data internally
• where the data is stored and backed up
• how incidents are detected and reported
• how quickly you will be notified of a breach or suspected breach
• what happens to test data, logs and backups at termination

If the contract does not answer those questions, the startup may discover the operational limits too late.

Missing downstream obligations

Your customer agreements may contain service levels, security standards, audit rights or privacy commitments that your supplier contract does not match. When that happens, your startup sits in the middle and absorbs the gap.

This is a frequent issue for healthtech businesses selling to clinics, insurers, larger healthcare groups and government-linked organisations. Procurement terms can be demanding, so your supplier agreements need to support those commitments rather than undermine them.

Failing to plan the exit

Founders often focus on getting the service live and overlook how they will leave if things change. That can become expensive if the provider controls key integrations, data structures or access credentials.

An exit plan should cover timing, cost, cooperation, data format and continuity support. If the provider charges for extraction or transition assistance, the agreement should make that clear upfront.

Assuming all business-to-business protections are negotiable later

In New Zealand, some statutory protections can apply to services, and business contracts can also limit or contract out of certain rights in some circumstances. The legal position depends on the relationship and the drafting.

For example, service quality expectations may interact with legislation such as the Consumer Guarantees Act 1993 in some settings, but business-to-business arrangements often contain clauses addressing that position directly. Founders should not assume the law will automatically fix a weak contract. It is better to negotiate the key protections before you sign.

FAQs

Do healthtech startups in New Zealand need a written service agreement?

Yes, in practice they usually do. A written agreement reduces disputes about scope, privacy, security, IP ownership, fees and liability, especially where the service supports sensitive information or critical platform functions.

Who should own data under a healthtech service agreement?

The contract should clearly state that your business retains ownership or control of its data, subject to any lawful rights needed by the provider to deliver the service. It should also limit any wider provider use of that data, especially for analytics, training or product improvement.

Can a provider exclude all liability in its standard terms?

It can try to draft broad limits and exclusions, but that does not mean you should accept them. The right position depends on the service, the bargaining context and the real commercial risk if the provider fails.

What if the provider stores information outside New Zealand?

You should check where information is stored, who can access it, what safeguards apply and how this fits your privacy obligations and customer commitments. Offshore hosting is not automatically prohibited, but it should be addressed clearly before you sign.

Should service levels sit in the main contract or a schedule?

Either can work, as long as they are legally binding and detailed enough to enforce. Many startups use a schedule for service levels so they can set out uptime, support tiers, response times and credits more clearly.

Key Takeaways

• A service agreement for a New Zealand healthtech startup should do more than record price and scope, it should allocate privacy, operational and commercial risk clearly.
• Founders should pay close attention to service levels, downtime consequences, data handling, subcontracting, offshore hosting and exit support.
• Intellectual property ownership needs to be explicit, especially for custom code, integrations, workflows and deliverables created during the engagement.
• Liability caps, indemnities and exclusions should be tested against real outage, privacy and customer claim scenarios before you sign.
• Standard supplier terms often leave important gaps, particularly where your startup has strong promises to enterprise or healthcare customers.
• A well-drafted agreement should match the service's actual role in your product, customer commitments and compliance position.

If you want help with privacy clauses, liability caps, IP ownership, supplier contract negotiation, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.