When you finish a consulting project, who owns what you've created? That sounds like a simple question, but it's surprisingly complex. A strategy document you wrote, a software tool you built, a design you created — do you own it, does the client, or do you both? The answer depends entirely on what the contract says.
This guide walks through IP rights in consultancy agreements, what's standard, what's negotiable, and how to protect your interests.
Why IP ownership matters
IP ownership affects your future business. If a consultancy client owns the IP you create, you can't reuse elements of your work for other clients. You can't build a product based on tools you developed. You can't publish case studies or use the work as portfolio material without permission.
This matters more for some consultants than others. A management consultant might be less concerned because the deliverable is usually a written report that's unlikely to be reused. A software developer might be very concerned because code and tools have lasting value and reuse potential.
Also, clients care about ownership. They want to know they own the work they're paying for. These interests can conflict, which is why IP clauses are negotiated.
The two main approaches to IP ownership
Client owns all IP. "All intellectual property created during the engagement is the sole and exclusive property of the client." This is what most clients prefer. You create something, they own it, you walk away. In return, you charge more because they own the output.
Consultant retains ownership. "The consultant retains ownership of all intellectual property. The client receives a perpetual, royalty-free license to use the work for the purposes of this engagement." This is rarer but valuable if you're creating reusable tools or processes.
In practice, most contracts fall somewhere in between or have hybrid approaches. For example: "The client owns the deliverables and any customizations. The consultant retains ownership of underlying methodologies and tools."
Types of IP in consultancy
Deliverables. The main output: a report, a design, a strategy document, software. These are typically what the client pays for and expects to own.
Background IP. IP you already owned before the engagement: frameworks, processes, tools, templates. You usually retain this even if the client owns the deliverables.
Customizations. Modifications to your background IP specific to the client's needs. Who owns these? Often shared: the client owns the customization, you own the underlying tool.
Third-party IP. IP from other sources that you incorporate (open-source software, licensed content, etc.). Typically the original owner retains rights; the consultant and client have a license to use it.
A good IP clause should clearly distinguish these. For example: "The client owns the final deliverables and any customizations specific to this engagement. The consultant retains ownership of underlying frameworks and methodologies."
What's standard in the market?
It depends on the type of consulting. For pure advisory (strategy, management consulting), clients typically own the final report or recommendations. For implementation consulting (software development, infrastructure design), the split is murkier. Often the deliverable belongs to the client but the consultant retains underlying code and tools.
In software and product consulting, it's common for the client to own the customized work but the consultant to own the underlying platform or tool. For example: "The client owns the custom report generator we built for them, but we retain ownership of our broader analytics platform."
The market is moving towards more nuance. Clients are increasingly willing to let consultants retain background IP and tools, as long as the client gets full rights to the customized deliverables they're paying for.
Key clauses to look for
Pre-existing IP. The contract should clearly state that IP you brought into the engagement remains yours. This is usually non-controversial and protects both parties.
Client ownership of deliverables. Usually, the client will own the final deliverables. This is fair compensation for payment. But clarify what "deliverables" means: is it just the report, or does it include raw data, working papers, and presentations?
License grants. Even if the client owns IP, can you use it for case studies or portfolio purposes? Can you use anonymized versions to demonstrate your capabilities? Get explicit permission if this matters to you.
Residual knowledge. A "residual knowledge" clause says you can use general knowledge and experience gained during the engagement even if you don't own the specific deliverable. This protects you: you can apply lessons learned to future clients.
Third-party IP. If you're incorporating open-source software or licensed content, the contract should clarify that you're doing so and that the client understands the terms.
What to negotiate
If the client owns everything, push for permission to use anonymized case studies. "You own the work, but I'd like to publish a case study showing methodology and results with client names removed. Is that okay?" Most clients will agree.
Separate the deliverables from underlying tools. "I retain ownership of my underlying analytics framework. You own the customized version and the reports it generates for your business. You have a perpetual, royalty-free license to use the framework and any improvements for your own use, but you can't license it to competitors."
Include a residual knowledge clause. "The consultant may use general knowledge, skills, and experience gained during this engagement in future work, provided it doesn't directly copy the client's deliverables."
Clarify ownership of partial deliverables. If the project is cancelled mid-way, who owns the work-in-progress? It's worth specifying: "Work-in-progress at termination remains the consultant's property unless the client has paid for it, in which case ownership transfers."
Address software and code specifically if relevant. If you're a software consultant, clarify: "The client owns custom code and configurations specific to their requirements. The consultant retains ownership of all tools, libraries, and frameworks, which are licensed to the client under [license type]."
Red flags to watch for
"We own all IP created during the engagement, whether or not it relates to the project." This is too broad. If you happen to have an idea unrelated to the project during the engagement, does the client own it? Push back.
"We reserve the right to use your work for our own purposes, including selling it to other clients." If you're a software consultant, this is problematic. You're building something the client will resell, but you're not getting a share of the revenue. Negotiate better terms.
No residual knowledge clause. If the contract is silent on your right to use general knowledge gained during the engagement, you have no protection. Push for a residual knowledge clause.
Overly broad confidentiality + client owns IP. Sometimes, the combination of a very broad confidentiality clause and client IP ownership means you can't even talk about the type of work you did. Negotiate more specific confidentiality terms.
Getting clarity before you sign
IP terms matter for your future business, so take time to get them right. Before you sign a consultancy agreement, use QuickLegalCheck to review the IP clauses. We'll explain what you're agreeing to, what's standard, and what you should negotiate.
Or get started with a contract review today.