IP & Confidentiality


IP & confidentiality may not seem to be the most exciting topics to think about when you are at such an early stage, but you should stay mindful of how they play into your company’s growth. A lot of your IP & confidentiality needs will be dependent on your product, sector, and industry.

Intellectual Property

Many people in the tech industry think of “Intellectual Property” as only something that is potentially patentable. We’ve lost count of the number of times someone has said something like, “there’s no real IP in that” when talking about software. 

This is a misunderstanding about what IP actually encompasses. There are many forms of IP that can be valuable to your business. Copyright exists in any original work of authorship — which does include software code — but also includes process documents, company decks, sales proposals, architecture diagrams, QA tests, websites, etc. 

Unless you are in a very “IP heavy” industry such as medtech (where the consideration of patentable inventions will come a lot earlier), the focus on IP at early stages will revolve mostly around copyright and trademarks. Make sure that the company owns everything that has been developed by your employees, contractors, and advisers. In your contracts of employment, you should also ensure that you are free to use any material developed independently by employees, if that material is then included in any of your products or services.

As a tech company, the most important thing is obviously that you own all of the code that is written, as well as the architecture, documentation, etc. relevant to your business. However, non-technical advisers and employees also create IP that will be valuable to the company — such as investment desks, business plans, financial models, customer lists, value propositions, etc.

Although you should absolutely have written agreements with all employees to govern the ownership of work they do for the company, under common law (the law that exists even if you don’t have a written agreement), the IP rights of all work done by employees as a result of performing their employment duties is automatically owned by the company. Do not use this information to try and justify the lack of written agreement — it is just that you don’t have to enter into a panic if you do not have written agreements at the initial stage.

However, the above does NOT apply to work done by consultants and advisers. There are some corner-case exceptions to this general rule, but any transfer of intellectual property (including copyright) in work done by a non-employee must be in writing and signed by the person or entity agreeing to the transfer.

There is a template Contractor’s Agreement in the Downloads section.

If you do not already have written agreements in place, you can still ensure that all previously created IP is transferred to the company. Because you are addressing past work, in strict theory this must be done via a “Deed of Assignment.” 

This sounds complicated but it really isn’t; all you need is the right language and for the deed to be signed and witnessed. It can be witnessed by anyone — preferably someone not related to the company. In practice, a lot of people just back-date the relevant contract if they are putting it in place later. While that is not strictly effective, it is often enough to assuage a concerned investor (or their lawyers) and it is arguable that, even if a contractor objects to it after having signed it (which would be really poor form), they could be legally prevented from arguing that it did not apply from the date stated in the contract. However, if you really want to impress, including the Deed of Assignment language is the proper way to do things.

Here is a template Deed of Assignment. We also recommend the Intellectual Property Rights Assignment Agreement made available by Jonathan Lea. This includes his discussion of why and where one might be needed.


The emphasis on confidentiality can change as your company grows. For example, a startup’s budget is unlikely to be as sensitive as that of a much larger company that is profitable, growing, and basing budget decisions on strategic goals. 

There are elements of your business that should always be treated as confidential, such as:

  • customer communications, negotiations, and terms (if not standard)
  • pricing (if not standard or published)
  • salary details
  • source code (if you don’t normally release your source code)
  • unpublished patent information
  • unpublished accounts

One of the few instances where you will have to take a leap of faith will be when you are disclosing information to potential investors. Potential investors are unlikely to require disclosure of really sensitive information that can be classed as a trade secret, such as unpublished patent information or source code. In the unlikely event that an investor wishes to see or have someone examine that material, it is not unreasonable to require that an NDA be signed.

At early-stage, situations where an NDA should be signed are:

  • as part of customer negotiations if a non-standard deal is being discussed
  • if a prospective employee comes in for a day as part of the recruitment process
  • as part of an employee, intern, or contractor agreement
  • as part of strategic partnership talks or reseller discussions if you are disclosing sensitive information

Lawyers and accountants are bound by a common law obligation of confidentiality — requiring them to sign NDAs is overkill.

Balancing Paranoia and Pragmatism

In the vast majority of cases, an idea alone will not be protectable by any formal method of IP protection. 

“For the most part, … folks need to face a cold, hard truth- an idea in its purest form is not worth anything in the business world. It’s the execution that matters. Unless entrepreneurs have some intellectual property to protect or code already written, an NDA is usually a sign of amateurism.”

– Stella Garber in this great Forbes article

Here is another straight-talking blog post on “Why I Won’t Sign your NDA. Harsh, but fair:

“… I won’t sign your NDA. It’s not because I don’t like you, it’s not because I want to steal your ideas, it’s not because what you’re up to isn’t important.

It’s because the ideas you are likely to share with me over coffee or in a phone conversation are otherwise plentiful, worthless in isolation, and, to some degree, completely unoriginal and already known to the world.”

NDAs are considered the confetti of the tech industry. You will be sent and will send lots of NDAs over the course of your company’s growth. While the terms in many NDAs may seem totally innocuous, until you have someone in-house who can review them properly, you should ensure the following:

  • if both parties are disclosing information, the NDA should be mutual
  • if you have signed an NDA, make sure to follow up to get a countersigned copy
  • review NDAs for (i) non-solicitation and (ii) non-compete clauses. Under normal circumstances, neither of these elements is appropriate for an NDA.
  • an NDA should prohibit usage of confidential information for the receiving party’s own benefit as well as prohibiting disclosure to third parties
  • keep an eye out for onerous marking requirements or requirements that all disclosures be only in writing if your main method of communication is by call or meeting – if you’ve agreed to reduce everything to writing, even the results of a meeting or a call, make sure to follow up on this
  • review the termination section to ensure that you are happy with the length of time the agreement will remain active and also what happens to your documents when the agreement terminates
  • get in the habit of putting a “confidential” footer in your standard documents, like presentation decks, financial information, pricing & POs, etc.


An experienced developer worked for a company for a number of years. While developing a software product for the company, they realised that a piece of code which they had developed previously, on their own and not while they were employed somewhere else, would be suitable to use to solve a particular problem in the company’s code.

The developer included their personal copyright notice on this code and maintained, correctly, that because it had not been developed while they were working at the company, the company did not own the code. Luckily the company discovered the code and the accompanying notice.

Had the company not discovered this “third party” code and a potential acquirer had uncovered it during acquisition due diligence, that could have placed the entire acquisition in danger and the acquirer would have lost faith in the company’s ability to keep its own code under control, as well as risking the company being in breach of various IP warranties in the acquisition documents. As it was, the company and the employee entered into a broad-ranging license allowing the company unlimited rights to use the particular code.

Both the Employee Contract and Contractor Contract template downloads include language which addresses this potential issue at the start, granting the company broad rights to IP which is included in the company’s products, even if developed prior to the engagement with the company. If you do not have such a clause in your agreements and come across this problem, you can also use a broad-based open-source license to the company and the company may want to exclude the requirement to refer to the individual developer in the code. We have also provided a template broad license to use under these circumstances (Unlimited Employee License).


Contractor Agreement

Deed of Assignment

Unlimited Employee License