Penetration Testing Agreements in New Zealand

If you are hiring a cyber security provider to test your systems, the contract matters just as much as the technical work. New Zealand businesses often make the same mistakes before they sign: they accept a provider's standard terms without checking the testing scope, they overlook privacy and confidentiality issues where customer data may be exposed, or they assume insurance and liability will sort themselves out if something goes wrong. Those gaps can become expensive fast, especially where a test disrupts systems, triggers alerts, or uncovers serious vulnerabilities that need urgent action.

A penetration testing agreement should clearly say what the tester is allowed to do, what systems are in scope, who owns the results, how sensitive information will be handled, and what happens if the work causes loss or downtime. If you are comparing providers, negotiating enterprise customer requirements, or arranging testing before a procurement process or audit, this guide explains the legal points to sort out before you sign.

Overview

A penetration testing agreement is the contract between your business and the security provider performing authorised testing of your systems, applications, networks, or devices. In New Zealand, the legal risk usually sits less in the idea of testing itself and more in unclear permission, vague scope, weak confidentiality wording, and liability terms that do not match the real commercial exposure.

The agreement should be written so that both sides know exactly what is permitted, what is off limits, and what happens if the testing reveals a problem or causes disruption.

• Define the systems, environments, IP ranges, applications, and time windows that are in scope
• State the exact testing methods allowed, including whether social engineering, phishing, physical testing, or denial of service style techniques are prohibited or permitted
• Record express authorisation from the business for the tester to perform the agreed activities
• Set out confidentiality, data handling, and Privacy Act 2020 obligations where personal information may be accessed
• Clarify ownership and licence rights for reports, findings, scripts, and remediation materials
• Check liability caps, exclusions, indemnities, and insurance cover before you accept the provider's standard terms
• Deal with incident escalation, reporting deadlines, and emergency contact points if a critical vulnerability or outage occurs
• Confirm any subcontracting, offshore access, or use of third party tools

What Penetration Testing Agreement Means For New Zealand Businesses

A penetration testing agreement gives legal permission and practical boundaries for controlled cyber security testing. Without it, even well-intentioned security work can create disputes about access, damage, confidentiality, and responsibility.

For many founders and operations teams, the practical issue arises before they sign a contract with a specialist provider. The technical team may be focused on getting the work booked in, but the business still needs a written agreement that matches the systems being tested and the risks involved.

Why the written permission matters

Penetration testing usually involves deliberate attempts to identify and exploit weaknesses. That makes express authorisation essential. The provider needs clear written permission from the system owner or authorised business representative, and your business needs proof of what it authorised.

This is especially important if your systems are hosted by a cloud provider, integrated with customer platforms, or partly managed by another vendor. You may need to confirm that your existing supplier contracts allow testing, or that separate consent is obtained before any live environment work begins.

Scope is the heart of the agreement

The main legal and commercial protection in this kind of contract is a precise scope. If the scope is vague, arguments often follow about whether the tester exceeded authority or whether the client expected more than the provider actually delivered.

A useful scope clause usually covers:

• which systems or assets are in scope
• whether production, staging, or development systems are included
• what dates and testing windows apply
• what methods may be used
• what systems, users, suppliers, or locations are expressly excluded
• how severe findings will be categorised and reported

This is where founders often get caught. A proposal may say something broad such as "external penetration test" or "web application assessment", but that does not tell you enough about the actual work. Before you rely on a verbal promise, get the scope written into the agreement or attached statement of work.

Privacy and confidential information issues

A penetration test can expose personal information, commercially sensitive information, credentials, customer records, or internal business processes. In New Zealand, your Privacy Act 2020 obligations do not disappear just because a third party is doing the testing.

If the tester may access personal information, intentionally or incidentally, the contract should address:

• how data will be accessed, stored, copied, encrypted, and deleted
• whether any data leaves New Zealand or is accessed offshore
• who within the provider can access the material
• how long reports, logs, screenshots, and extracted data are kept
• what happens if a privacy incident or notifiable breach occurs

Confidentiality wording also matters beyond privacy law. Security reports often identify your weakest controls, software versions, exposed endpoints, and internal architecture. If that information leaks, the report itself can become a risk.

Consumer and commercial expectations

Most penetration testing for startups and SMEs is a business-to-business service. Even so, the quality and accuracy of the service still matter. If a provider markets expertise, certifications, or a particular testing standard, those representations should line up with the contract and the work actually delivered.

That is where fair trading concerns can arise. If the proposal promises one level of service and the terms quietly narrow it, the mismatch can create legal and commercial problems later. Before you sign, compare the quote, proposal, scope, and terms side by side.

Who relies on the report

Many businesses commission testing because a major customer, insurer, board, or procurement team expects it. The contract should deal with whether your business can share the final report with third parties and whether anyone else is entitled to rely on it.

Some providers try to prohibit any third party reliance at all. That may be fine in some cases, but not if you need to show the report to enterprise customers or investors as part of due diligence. This point is worth raising before you accept the provider's standard terms.

Legal Issues To Check Before You Sign

The right penetration testing agreement should allocate risk in a way that reflects the real testing activity, not just the provider's preferred boilerplate. Before you sign, focus on the clauses that affect authority, security, downtime, and use of the results.

Authority to test and third party consent

The contract should confirm that your business has authority over the target systems and will obtain any third party consents needed. That can include consent from:

• cloud hosting providers
• managed service providers
• software vendors
• customers whose environments are involved
• landlords or building managers for physical access testing, if relevant

If these approvals are missing, the testing may breach another contract even if your agreement with the tester looks fine.

Permitted and prohibited activities

A good contract says exactly what the tester may do, and what they must not do. This is more specific than simply saying "penetration testing services".

Examples of points to spell out include:

• whether phishing or social engineering is allowed
• whether credential stuffing or password spraying is allowed
• whether exploitation is limited to proof of concept or may proceed further
• whether destructive testing is prohibited
• whether denial of service style testing is excluded
• whether physical access attempts are part of the engagement

If your business has low tolerance for operational disruption, the agreement should say so clearly.

Testing windows, outages, and escalation procedures

The contract should say when testing can occur and who must be contacted if something unexpected happens. This is not just an operational detail. It helps limit disputes if a service interruption occurs.

Look for clauses covering:

• approved testing dates and times
• blackout periods such as peak trading times or release windows
• named contacts on both sides
• urgent escalation procedures
• pause rights if systems become unstable
• response expectations for critical findings

Deliverables and remediation support

The contract should clearly state what your business receives at the end of the work. A short executive summary may not be enough if you need detailed remediation planning or evidence for a customer audit.

The deliverables section should deal with:

• draft and final reports
• severity ratings and supporting evidence
• technical remediation recommendations
• retest services, if any
• presentation or workshop obligations
• timeframes for issuing reports after testing

If remediation support is important, make sure it is included expressly rather than assumed.

Liability, indemnities, and insurance

Liability clauses are often the hardest commercial point in a penetration testing agreement. The provider will usually try to cap its liability, exclude consequential loss, and avoid responsibility for indirect impacts such as lost revenue, customer claims, or downtime.

Your business should assess whether the proposed cap makes sense against the value of the engagement and the level of access being granted. A very low liability cap may be unrealistic where the provider is testing live systems or handling sensitive data.

Check the contract for:

• the dollar amount of any liability cap
• whether the cap applies once overall or per claim
• whether confidentiality breaches, privacy breaches, or wilful misconduct are carved out from the cap
• whether there is an indemnity for third party claims caused by the provider's breach
• what insurance the provider carries, such as professional indemnity or cyber liability cover

Insurance should not be treated as a substitute for clear contract drafting. It is still worth asking for evidence of cover where the engagement is sensitive.

Intellectual property and use of outputs

Most businesses assume they will own the final report, but contracts do not always say that clearly. The provider may retain ownership of methodologies, templates, tools, scripts, and working papers while giving your business a licence to use the report.

That can be workable, but the agreement should make sure you can use the deliverables for your internal security, governance, compliance, and customer assurance needs. If you need to share parts of the report with customers, auditors, insurers, or investors, that permission should be addressed expressly.

Subcontractors and offshore service delivery

Some testing firms use subcontractors or staff in other jurisdictions. That is not automatically a problem, but you should know about it before you sign.

The contract should address:

• whether subcontracting is allowed
• whether the provider remains fully responsible for subcontractors
• where data and reports are stored
• whether offshore access is permitted
• what security standards apply to all personnel involved

This matters even more where regulated data, health information, or customer confidential information may be visible during the engagement.

Termination and suspension rights

Your business should be able to pause or terminate testing if there is a material issue, such as system instability, unauthorised conduct, a privacy concern, or a disagreement about scope. The provider will also want clear termination rights to suspend work if access is not provided or invoices are unpaid.

Make sure the agreement explains what happens on termination, including handover of findings, return or deletion of data, and payment for work already done.

Common Mistakes With Penetration Testing Agreement

The most common mistakes happen when businesses treat the contract as a formality instead of a risk-control document. Small wording gaps can have outsized consequences once live testing starts.

Accepting a generic proposal as if it were a full contract

A quote or statement of work may describe the service, but it often does not cover authority, liability, confidentiality, privacy, or dispute points in enough detail. If there are separate standard terms, read them together with the proposal before you sign and consider a contract review.

Leaving the scope too broad or too narrow

Some businesses approve a broad test without checking what systems are connected behind the scenes. Others assume internal apps, APIs, mobile apps, and cloud environments are included when they are not.

If your environment is complex, list the in-scope assets specifically. Asset schedules, IP ranges, URLs, environments, and named applications can prevent later arguments.

Assuming confidentiality is enough without privacy wording

A basic confidentiality clause does not necessarily deal with personal information, security incidents, offshore access, or deletion obligations. If the engagement may expose employee, customer, or user data, add privacy-specific terms and appropriate data protection obligations.

Ignoring operational risk in live environments

Founders sometimes focus on the quality of the findings and forget to negotiate practical controls for uptime. Testing in production can be appropriate, but the agreement should reflect your business reality.

If downtime would be costly, build in approved windows, escalation contacts, stop-testing triggers, and limits on high-risk techniques.

Overlooking report use and reliance rights

This issue often appears later, when a customer or insurer asks to see the report. If the contract says the report is confidential to the client and cannot be shared, or that no third party can rely on it, you may need to renegotiate after the work is done.

Agreeing to a liability cap that does not match the risk

Some standard terms cap liability at the fees paid, even where the provider has access to sensitive systems and data. That may not be commercially reasonable in every case. The right position depends on the nature of the engagement, the systems involved, and the likely downside if something goes wrong.

Relying on verbal assurances from the sales process

Businesses are often told that the provider will work collaboratively, retest fixes, notify immediately about critical issues, or adapt methods to avoid disruption. If that matters to your business, put it in the contract. Verbal promises are difficult to enforce once there is a dispute about performance or scope.

FAQs

Does a penetration testing agreement need to be in writing?

It should be. A written contract is the clearest way to record permission, scope, exclusions, confidentiality, liability, and reporting obligations. This is particularly important before you allow testing on live systems.

Can a provider test our production environment?

Yes, if your business authorises it and the agreement manages the risk properly. The contract should specify timing, approved techniques, escalation procedures, and any restrictions designed to reduce disruption.

Who owns the penetration testing report?

That depends on the contract. Many providers keep ownership of their underlying methods and tools, while giving the client rights to use the final report. Before you sign, make sure your business can use and share the report as needed for compliance, customer assurance, or internal remediation.

What if personal information is exposed during the test?

The agreement should set out how personal information will be handled, secured, and deleted, and what happens if there is a privacy incident. Your business may still have obligations under the Privacy Act 2020, including possible breach assessment and notification steps.

Should we accept the provider's standard terms?

Not without review. Standard terms often favour the provider on scope, liability, subcontracting, and report use. Before you accept the provider's standard terms, check that they reflect the systems being tested and your commercial risk.

Key Takeaways

• A penetration testing agreement should do more than book the service, it should clearly authorise the testing and define the exact scope.
• New Zealand businesses should pay close attention to confidentiality, Privacy Act 2020 issues, incident handling, and any offshore access to data.
• Liability caps, exclusions, indemnities, and insurance need careful review before you sign, especially for live or sensitive environments.
• The contract should say what deliverables you will receive, whether retesting is included, and how reports can be used or shared.
• Common trouble spots include vague scope, missing third party consents, weak privacy wording, and relying on sales promises that never make it into the contract.
• If you are reviewing or negotiating a penetration testing agreement and want help with scope wording, privacy and confidentiality terms, liability caps, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.