Confidentiality Clauses for Cybersecurity Service Agreements in New Zealand

If you are hiring a cybersecurity provider, or providing cybersecurity services to clients, the confidentiality clause is usually where the real commercial risk sits. Many New Zealand businesses sign standard terms that define confidential information too narrowly, let the provider reuse incident data too freely, or stay silent on what happens when an employee, contractor, or offshore subcontractor gets access. Those gaps often only become obvious after a security event, a client complaint, or an awkward dispute about who can keep logs, threat intelligence, and system data.

A good confidentiality clause does more than say, “keep this secret”. It should match the way cybersecurity work actually happens, including access to networks, credentials, personal information, vulnerability reports, source code, customer databases, and internal security processes. It also needs to work alongside privacy obligations, data breach response steps, and limits on disclosure during audits, insurance claims, and legal requests.

This guide explains what confidentiality clauses for cybersecurity company agreements should cover in New Zealand, what to check before you sign, and the mistakes that regularly catch founders and SMEs off guard.

Overview

Confidentiality terms in cybersecurity service agreements need to be specific, practical, and broad enough to cover the data and systems a provider will actually touch. In New Zealand, these clauses often sit alongside privacy obligations, service levels, subcontracting terms, and incident response provisions, so they should not be treated as a throwaway boilerplate section.

• How confidential information is defined, including technical data, credentials, reports, and business information
• Who can access that information, including employees, contractors, related companies, and subcontractors
• What uses are permitted, including service delivery, threat analysis, testing, and internal quality control
• What security standards apply when handling confidential material
• How the clause deals with personal information and the Privacy Act 2020
• When disclosure is allowed, such as by law, court order, insurer request, or urgent incident response
• How long confidentiality obligations continue after the agreement ends
• What happens to data, logs, reports, and copies on termination
• What remedies apply if confidential information is misused or disclosed

What Service Agreements Cover

A cybersecurity service agreement should clearly set out what the provider is doing, what information it can access, and what legal duties apply to that access. The confidentiality clause is only one part of that picture, but it needs to line up with the rest of the contract.

Cybersecurity services often involve a deeper level of access than ordinary IT support. A provider may monitor systems continuously, investigate incidents, test vulnerabilities, handle credentials, review employee conduct data, or receive copies of sensitive reports. That means the contract needs to reflect both the sensitivity of the work and the practical reality of how data moves through the engagement.

Core terms usually covered

Before you accept the provider's standard terms, make sure the agreement deals with the full service relationship, not just price and scope.

• The services being delivered, such as penetration testing, managed detection and response, incident response, security consulting, awareness training, or virtual CISO support
• Service levels and response times, especially for critical incidents and notifications
• Access rights to systems, premises, devices, and cloud environments
• Confidentiality and non-disclosure obligations
• Privacy and data handling obligations, where personal information is involved
• Subcontracting rights and any approval process for third parties
• Intellectual property ownership in reports, playbooks, scripts, tooling, and deliverables
• Liability caps, indemnities, and exclusions
• Audit rights, compliance support, and cooperation during security incidents
• Termination rights and post-termination return or deletion of information

What counts as confidential information in cybersecurity work

The definition should be broad enough to cover information that may not look commercially sensitive at first glance, but could create serious risk if exposed. This is where founders often get caught, especially when the clause only protects material marked confidential in writing.

In a cybersecurity engagement, confidential information may include:

• Usernames, passwords, keys, tokens, certificates, and other credentials
• Network diagrams, architecture maps, cloud configurations, and asset inventories
• Security policies, access control settings, and internal escalation paths
• Penetration testing findings, vulnerability scans, remediation plans, and threat intelligence
• Customer lists, contracts, pricing, financial data, and internal strategy
• Source code, scripts, APIs, proprietary tools, and system integrations
• Logs, telemetry, alerts, and forensic artefacts
• Personal information held in systems the provider accesses
• Information disclosed orally during incident calls or workshops, even if it is not later labelled confidential

It is also worth stating that information derived from confidential information is covered. For example, a report summarising weaknesses in your environment can be as sensitive as the raw system data itself.

How confidentiality interacts with privacy

Confidentiality and privacy are not the same thing. Confidentiality is a contractual promise about how information can be used and disclosed. Privacy law applies to personal information and may impose separate duties about collection, storage, access, correction, disclosure, and breach notification.

If a cybersecurity provider will handle personal information, the agreement should align with the Privacy Act 2020. In many cases, the customer will remain responsible for the personal information it holds, but the provider will need clear contractual obligations about:

• Using personal information only for the agreed services
• Applying appropriate safeguards against loss, misuse, and unauthorised access
• Helping the customer respond to privacy requests or incidents where relevant
• Not disclosing personal information to third parties except as permitted
• Managing offshore access or storage arrangements carefully

If overseas staff, cloud tools, or subcontractors are involved, this should be addressed explicitly before you sign. A vague confidentiality clause will not fix a weak data-handling model.

Legal Issues To Check Before You Sign

Before you sign a contract, the key question is whether the confidentiality clause reflects the actual risk of the services, not just a generic non-disclosure promise. Standard wording often misses operational points that matter most in cybersecurity.

1. Is the definition of confidential information wide enough?

A narrow definition creates avoidable arguments later. If the clause only covers information labelled confidential, or excludes oral disclosures, incident calls, screenshots, and machine-generated data, protection may fall away when you need it most.

The clause should cover confidential information regardless of format, including written, verbal, digital, visual, and observed information. It should also protect information accessed through systems, not just information formally handed over.

2. Are permitted uses drafted too broadly?

The provider should be allowed to use confidential information only to deliver the agreed services and meet related legal obligations. Wording that allows use for “business purposes”, “service improvement”, or “internal analytics” without limits can be too broad.

That matters in cybersecurity because providers often want to:

• Use anonymised or aggregated threat data to improve services
• Share learnings across teams
• Benchmark incidents and remediation trends
• Train internal staff or AI-enabled tools on client materials

Some of these uses may be commercially reasonable, but they should be described carefully. If data is to be anonymised, the contract should say that. If reports may be used for training or product development, that should be stated clearly and limited appropriately.

3. Who can receive the information?

A confidentiality clause is only as strong as its rules on onward disclosure. Many agreements let the provider disclose information to any employee, contractor, affiliate, or subcontractor who “needs to know”, without requiring meaningful controls.

Before you rely on a verbal promise, check whether the agreement requires recipients to be bound by confidentiality obligations at least as strict as the main contract. Also check whether subcontracting is unrestricted, or whether client consent is needed for high-risk third parties.

For higher-risk engagements, businesses often ask for:

• Advance notice of subcontractors who will handle sensitive data
• Restrictions on offshore access
• Minimum security standards for third parties
• Provider responsibility for acts and omissions of personnel and subcontractors

4. Does the contract deal properly with compelled disclosure?

Most confidentiality clauses allow disclosure where required by law, regulation, or court order. That is sensible, but the wording should still protect the disclosing party as far as possible.

The agreement should usually require the receiving party to:

• Notify the other party promptly, unless legally prohibited
• Disclose only what is legally required
• Cooperate with efforts to seek suppression, protective orders, or confidential treatment where appropriate

This becomes especially relevant if there is a regulatory inquiry, a discovery request, or an insurer asks for information after an incident.

5. Are security obligations clear enough?

A confidentiality promise is stronger when backed by practical security obligations. If the contract says the provider must keep information confidential but says nothing about access controls, encryption, logging, device security, or retention, there may be a gap between the promise and the real-world handling of data.

You do not always need a long technical schedule, but the agreement should at least set a measurable standard. For example, it may require the provider to take reasonable security measures consistent with good industry practice, the nature of the information, and any specific client policies agreed in writing.

6. What happens at the end of the engagement?

Termination is a common weak point. After a project finishes, providers may still hold copies of reports, extracts, screenshots, logs, backups, or forensic artefacts. If the contract is silent, the parties may have very different expectations about deletion and retention.

Before you sign, the agreement should address:

• What must be returned on termination
• What must be deleted and within what timeframe
• Whether backups are excluded, and if so, how they remain protected
• Whether the provider can keep one archival copy for legal, insurance, or compliance reasons
• How long confidentiality obligations continue after termination

In many cases, confidentiality obligations should survive for several years, and some highly sensitive information may need protection indefinitely.

7. Are remedies realistic?

If confidential information is disclosed, damages may not be enough. The agreement should preserve the right to seek urgent relief where misuse would cause immediate harm, especially where credentials, vulnerabilities, or customer data are involved.

At the same time, the broader liability clauses should be checked carefully. A provider may accept a confidentiality obligation in one clause, then try to cap all liability for breach at a very low amount elsewhere. That can undermine the protection you thought you had negotiated.

Common Service Agreement Mistakes

The most common mistake is treating the confidentiality clause as standard boilerplate when the service itself is highly sensitive. Cybersecurity agreements need careful contract drafting that reflects access to live systems, incident data, and personal information.

Relying on a one-line NDA style clause

A short clause may be fine for a basic introductory discussion, but it is rarely enough for managed security services, incident response, or penetration testing. These engagements involve ongoing access, multiple recipients, and technical outputs that create their own confidentiality risks.

If your contract says little more than “each party must keep confidential information secret”, that is usually too thin.

Ignoring metadata, logs, and derived materials

Businesses often focus on obvious confidential material such as reports and passwords, but forget about logs, screenshots, packet captures, case notes, alerting data, and internal analysis created during the work. Those materials can reveal just as much about your systems and vulnerabilities as the original source data.

The clause should make clear whether these materials are confidential, who owns them, and whether the provider can retain or reuse them.

Not matching the confidentiality clause to the scope of services

A penetration test, security audit, and 24/7 managed detection service involve different risk profiles. Founders sometimes sign a provider's standard terms without proper contract review or tailoring the confidentiality language to the actual engagement.

For example:

• An incident response retainer may need urgent disclosure rules, access protocols, and cooperation obligations
• A managed SOC arrangement may need ongoing controls for alerts, logs, and analyst access
• A consulting engagement may need tighter ownership and use restrictions for reports and recommendations

The clause should fit the service, not the other way around.

Assuming privacy wording solves everything

Privacy clauses help where personal information is involved, but they do not replace confidentiality drafting. A cybersecurity provider may access confidential commercial information that is not personal information at all, such as network maps, pricing models, unreleased product plans, or source code.

You need both concepts covered properly.

Leaving subcontracting too open

This is a frequent issue in modern service delivery. Providers may use offshore analysts, cloud tooling vendors, niche specialists, or white-label partners. If the contract gives unrestricted subcontracting rights and only vague confidentiality protections, your information may travel further than you expected.

Before you sign, ask who will actually have access and on what terms. If the answer is vague, the contract probably is too.

Forgetting about marketing and case study use

Some providers want to mention clients in pitches, capability statements, or case studies. Others want to publish anonymised examples of attack patterns or remediation work. If that is not acceptable, the agreement should say so clearly.

Even where a use is anonymised, context can sometimes identify the client. This is especially true in niche sectors or after a public incident.

Accepting weak survival clauses

Some contracts end confidentiality obligations when the service agreement ends, or after an unrealistically short period. That can be a problem where the information remains sensitive long after the work is done.

Credentials, architectural details, and vulnerability findings do not suddenly stop mattering once the invoice is paid. Survival periods should reflect the nature of the information.

FAQs

Do cybersecurity service agreements in New Zealand need a separate confidentiality clause?

Usually, yes. General service terms may include a confidentiality section, but cybersecurity work often needs more detail because the provider may access highly sensitive technical and personal information.

Is confidential information the same as personal information?

No. Personal information is information about an identifiable individual and is covered by privacy law. Confidential information is broader and can include commercial, technical, operational, and security material that is not personal information.

Can a cybersecurity provider use our data to improve its services?

Only if the contract allows it, or you agree later. If reuse, aggregation, anonymisation, training, or product improvement is permitted, the clause should describe that clearly and set limits.

Should confidentiality obligations continue after the agreement ends?

Yes, in most cases. The survival period should reflect how sensitive the information is, and some categories may need ongoing protection for much longer.

What should we ask for before accepting a provider's standard terms?

Ask for a wider confidential information definition, tighter controls on subcontractors and permitted use, clear return and deletion obligations, and confidentiality liability clauses that are not undermined by a low general liability cap.

Key Takeaways

• Confidentiality clauses for cybersecurity company agreements should be tailored to the actual services, data flows, and access levels involved.
• The definition of confidential information should cover technical data, credentials, reports, logs, oral disclosures, and information derived from system access.
• Permitted use wording matters, especially where the provider wants to reuse anonymised, aggregated, or training-related data.
• Subcontractor access, offshore handling, security controls, compelled disclosure, and post-termination deletion should all be addressed before you sign.
• Privacy obligations under the Privacy Act 2020 may apply alongside confidentiality promises, but they do not replace them.
• Liability caps and remedy clauses should be checked carefully so the confidentiality clause has real practical value if something goes wrong.

If you want help with service agreement drafting, privacy notice and data handling terms, subcontractor access rules, or liability caps, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.