IP Assignment Clauses for Cybersecurity Companies in New Zealand

If you run a cybersecurity business in New Zealand, your real value often sits in code, detection rules, scripts, architecture, playbooks, threat intelligence processes and internal tools. The problem is that many founders assume they automatically own everything their team or contractors create. That assumption is often wrong. Common mistakes include using contractor agreements that only mention confidentiality, relying on verbal promises about ownership, or signing client contracts that quietly transfer more intellectual property than intended.

An IP assignment clause for cybersecurity company arrangements needs careful drafting because cybersecurity work rarely fits into a simple bucket. You might create bespoke code for a client, improve your own platform while delivering services, or reuse threat detection templates across multiple engagements. The clause has to say who owns what, when ownership transfers, what licences still apply, and how background IP is treated. If you are reviewing an employment agreement, contractor agreement, software development contract or client services agreement, this guide explains what the assignment wording should cover before you sign.

Overview

An IP assignment clause sets out whether intellectual property created during a business relationship is transferred to someone else, and on what terms. For New Zealand cybersecurity companies, the wording matters because the same engagement can produce new code, client-specific materials, and improvements to your core systems all at once.

A workable clause should separate pre-existing IP from newly created deliverables, match the commercial deal, and avoid giving away reusable know-how by accident.

• Define exactly what intellectual property is covered, including source code, scripts, documentation, playbooks, workflows, data models and inventions.
• Separate background IP, being what each party already owned before the deal, from project IP created during the engagement.
• State when assignment happens, such as on creation, on payment, or on signing a further deed.
• Confirm whether the client receives ownership, an exclusive licence, or a limited non-exclusive licence.
• Deal with improvements, derivative works and tools built from lessons learned during the project.
• Cover contractor-created IP, because independent contractors do not automatically transfer ownership the same way founders often assume.
• Address moral rights consents where relevant, especially for documentation, reports and other authored materials.
• Include further assurance obligations, so parties must sign extra documents if needed to perfect ownership.

What IP Assignment Clause for Cybersecurity Company Means For New Zealand Businesses

An IP assignment clause decides who owns the commercially valuable outputs of your cybersecurity work. For a New Zealand business, that can affect valuation, client relationships, future product development and your ability to raise capital.

Cybersecurity companies often sit across several models at once. Some sell managed security services. Some license SaaS tools. Some do incident response, penetration testing, compliance advisory, or bespoke secure software work. Each model creates different ownership risks.

For example, a client may assume it owns everything produced in a security assessment because it paid for the work. You may assume your business keeps ownership of your testing methodology, scripts and templates because they are part of your standard toolkit. Both views can sound reasonable until the contract forces a clear answer.

Why ownership gets messy in cybersecurity work

The work product is rarely just one final document. A single project might include:

• a written report for the client
• custom integrations with the client’s systems
• changes to your internal detection logic
• automation scripts written by a contractor
• new threat hunting processes your team intends to reuse
• configuration standards derived from your existing know-how

If the contract says all IP created “in connection with the services” is assigned to the client, that wording may catch more than you intended. It can reach internal tools, upgrades, reusable frameworks, and modifications to your own platform. This is where founders often get caught, especially before they accept the provider's standard terms or sign a large enterprise client contract.

New Zealand legal context

In New Zealand, intellectual property ownership is shaped by contract terms, the nature of the relationship, and the type of IP involved. Copyright commonly protects source code, reports, diagrams and written materials. Confidential information and trade secrets can protect know-how and methods if you manage them properly. Patent rights may be relevant in narrower cases, although many cybersecurity businesses rely more heavily on copyright, confidentiality and contractual control.

Employment and contractor status also matter. Employees may create IP for the employer in circumstances where the employer has stronger ownership rights, but that does not mean every issue is automatically solved. Contractors are different. If a contractor writes scripts, develops software modules or prepares technical materials without a clear assignment clause, ownership may stay with the contractor unless the agreement says otherwise.

Why investors and buyers care

If you plan to grow, raise funding or sell the business, your IP chain of title matters. A buyer or investor will want to know that your company actually owns the core codebase, templates, detection content and service materials it depends on. Missing assignments from founders, early developers or specialist contractors can become a due diligence problem.

That is why this issue is not just legal housekeeping. A weak ownership position can reduce the value of your business, slow a transaction, or force urgent document clean-up later when leverage is against you.

Assignment versus licence

Full assignment is not always the right answer. Sometimes the better commercial arrangement is an IP licence.

For example:

• a client may own a bespoke deliverable created solely for its environment
• your company may keep ownership of pre-existing tools and grant the client a licence to use them as part of the service
• a report may be owned by your company, with the client licensed to use it internally
• your platform may remain yours, while client-specific configurations are licensed or assigned under narrower terms

The main point is that “we paid for it” does not automatically tell you what the ownership model should be. The contract needs to do that work.

Legal Issues To Check Before You Sign

The right IP assignment clause should follow the actual deal, not a generic template. Before you sign a contract, check what is being transferred, what is being retained, and whether the wording lines up with how your cybersecurity company operates.

1. Define the IP with enough precision

Vague wording creates expensive arguments later. “All intellectual property” sounds broad, but it can hide uncertainty about whether it includes data sets, configurations, reusable detection rules, standard operating procedures or machine-readable documentation.

The clause should identify the relevant categories, such as:

• source code and object code
• scripts, APIs and integrations
• security rules, signatures and detection content
• technical reports and remediation plans
• playbooks, workflows and methodologies
• design documents, diagrams and specifications
• database structures and training materials

2. Carve out background IP

Your background IP is what you owned, developed or licensed before the engagement, plus anything you build independently outside the scope of the project. If the agreement does not clearly ringfence this material, a broad assignment clause may accidentally sweep it into the transfer.

This carve-out is especially important where your business uses standard internal tools across multiple clients. Before you sign, make sure the contract says your pre-existing software, templates, know-how and frameworks remain yours.

3. Deal with project IP and improvements separately

Not every output should be treated the same way. The contract may need one rule for bespoke client deliverables and another for improvements to your platform or service methodology.

You may want the agreement to distinguish between:

• client-specific deliverables created solely for the engagement
• your own tools, systems and libraries used to deliver the services
• general know-how, skills and experience gained by your team
• improvements or derivative works that build on your existing IP

Without this split, the other side may argue that any improvement made during the project belongs to it.

4. Check when assignment takes effect

Timing matters. Some clauses say IP assigns on creation. Others say assignment happens only once all fees are paid. Some require a future deed or extra paperwork.

If you are the supplier, you may want ownership to transfer only after payment. If you are acquiring IP from a contractor, you may want assignment to happen automatically on creation, backed by a further assurances clause. The wording should avoid gaps where ownership is uncertain for months.

5. Cover moral rights and further assurances

Even if ownership is assigned, other steps may still be needed. Moral rights issues can arise in authored works such as reports, diagrams, technical manuals and documentation. Further assurances clauses require a person to sign extra forms or help register rights later if needed.

This matters when a contractor disappears, a founder leaves, or a client asks for formal proof of ownership after the work is finished.

6. Make contractor and subcontractor arrangements consistent

Your client contract may promise that the client gets ownership of certain deliverables. That promise is risky if your own contractor agreements do not pass the same IP rights to your company first.

Before you rely on a verbal promise from a developer, analyst or specialist consultant, check that your written terms cover:

• assignment of project IP to your company
• waivers or consents relating to moral rights where appropriate
• confidentiality obligations
• warranties that their work does not infringe third party rights
• an obligation to help sign further documents later

7. Watch for confidentiality and privacy overlap

Cybersecurity work often involves sensitive client information, logs, network diagrams and incident details. Ownership clauses are only part of the picture. Your contract also needs strong confidentiality wording, and in some cases a privacy notice or other privacy obligations under the Privacy Act 2020 if personal information is involved.

Ownership of a report does not automatically allow broad use of the confidential information inside it. Likewise, keeping ownership of your methodology does not mean you can reuse client-sensitive data or disclose findings elsewhere.

8. Match the clause to your business model

A managed service provider, a penetration testing firm and a product-led security company often need different clauses. A business built around recurring software revenue generally needs tighter protection around platform IP than a pure consulting business delivering one-off bespoke outputs.

Founders should ask a practical question before they sign: if this clause worked exactly as written, could we still serve other clients, improve our product and prove ownership of our core assets later? If the answer is no, the clause needs work.

Common Mistakes With IP Assignment Clause for Cybersecurity Company

The most common mistake is treating IP ownership as an admin issue instead of a commercial one. Once a bad clause is signed, fixing it often depends on the other party agreeing to change terms after leverage has shifted.

Using one template for every engagement

A generic services template can be too broad or too thin. Cybersecurity work ranges from advisory reports to ongoing detection engineering. One form of assignment language may be fine for a one-off deliverable and completely wrong for a long-term platform-enabled service.

This often shows up when a startup reuses an early client contract across enterprise projects without revisiting what is actually being created.

Assuming payment equals ownership clarity

Businesses often think that because a client paid for work, ownership is settled. It is not. Payment and ownership are different issues. The contract needs to state whether payment triggers assignment, merely grants a licence, or has no bearing on ownership of background tools.

Ignoring founder and early contractor paperwork

Many cybersecurity companies build their first prototypes with help from friends, freelancers or part-time technical advisers. If those people created code or key materials without a proper written assignment, your company may not own important assets cleanly.

This becomes a serious issue before an investment round, a sale, or a major customer procurement process.

Giving away reusable know-how

Founders sometimes agree that the client owns all materials developed “directly or indirectly” through the services. Wording like this can be much wider than expected. It may hand over reusable playbooks, threat models, automation components or internal frameworks that your business intended to deploy elsewhere.

The main risk is not just losing one deliverable. It is losing the ability to scale what you learned across future work.

Leaving improvement rights unclear

If your team improves a detection rule set, software module or workflow while serving one client, who owns the improved version? If the contract is silent or vague, disputes can arise later, especially when similar functionality appears in later customer projects.

Improvement language should reflect whether the change is a client-specific customisation or an enhancement to your general product or service capability.

Forgetting third party and open source components

Your deliverables may include components you cannot assign freely because they are licensed from someone else or subject to open source licence conditions. A contract that promises complete ownership of everything can create a warranty problem if parts of the stack are not actually assignable.

That does not mean open source is a problem by itself. It means the contract should be honest about what is owned, what is licensed, and what third party terms still apply.

Not lining up sales promises with legal terms

A sales conversation might promise “full ownership”, while the draft contract preserves supplier ownership and gives only a limited licence, or the reverse. That mismatch creates trust issues and negotiation blow-ups.

Before you sign, make sure the deal your team described commercially is the same deal the legal drafting delivers.

Relying on confidentiality alone

Confidentiality clauses are useful, but they do not replace assignment wording. Keeping source code or scripts confidential does not tell you who owns them. You need both protection tools working together.

FAQs

Do cybersecurity companies in New Zealand automatically own IP created by contractors?

No. Contractor-created IP is a common risk area. You should use a written agreement that clearly assigns relevant IP to your business and covers confidentiality, moral rights issues where relevant, and further assurances.

Should a client always own the deliverables in a cybersecurity engagement?

No. It depends on the deal. A client may own bespoke outputs created only for that client, but your company may retain ownership of pre-existing tools, methodologies and platform components, with the client receiving a licence instead.

What is the difference between background IP and project IP?

Background IP is what a party already owned or developed independently before the engagement. Project IP is new material created under the contract. Good drafting separates the two so pre-existing assets are not transferred by accident.

Can an IP assignment clause cover reports, scripts and security playbooks as well as software?

Yes. The clause can and usually should define IP broadly enough to cover technical documents, code, diagrams, procedures, playbooks and other work product relevant to the services.

What if our existing contracts are unclear about ownership?

You may need a contract review and, in some cases, follow-up deeds of assignment or variation agreements. It is much easier to fix ownership gaps before a dispute, investment process or customer audit than in the middle of one.

Key Takeaways

• An IP assignment clause for cybersecurity company contracts should clearly state who owns bespoke deliverables, who keeps background IP, and what licence rights apply.
• Cybersecurity engagements often produce mixed outputs, so one broad ownership sentence is rarely enough.
• Contractor agreements matter because your company may not automatically own IP created by independent developers, analysts or consultants.
• Improvement rights, derivative works, confidentiality and privacy issues should be addressed alongside assignment wording.
• Before you sign, check that the legal drafting matches the commercial deal and does not give away reusable tools, methods or platform IP by accident.

If you want help with contractor agreements, client contract terms, software IP ownership, or confidentiality provisions, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.