What Happens in a Technical IP Audit — and How to Prepare

The scenario that derails deals isn't dramatic fraud — it's administrative neglect. A developer who joined early and never signed an IP assignment. A contractor who built the core data pipeline without a written agreement. An open source library that's GPL-licensed sitting inside a commercial product. None of these were intentional. All of them are material. And every one of them takes 10 minutes to prevent and potentially months to fix once a deal surfaces them.

Buyers and investors don't surface these issues to be difficult. They surface them because if your ownership chain has gaps, then their ownership chain after acquisition has the same gaps. A gap that's discoverable before closing is their leverage point. The conversation shifts from “here's the valuation” to “here's the valuation minus a holdback pending resolution of these IP items.” That holdback comes out of your pocket.

The founders who navigate technical due diligence cleanly aren't the ones with perfect IP from day one — they're the ones who ran their own audit six months before they needed to and fixed whatever they found. The audit itself isn't complicated. What's complicated is doing it reactively under deadline pressure when the other party already knows what they're looking for.

A technical IP audit has five main areas. First is the code ownership chain: who wrote what, and do you have signed documentation for every material contributor? This includes full-time employees, contractors, co-founders, advisors who wrote code, and anyone who contributed meaningfully to the codebase before the company was formally structured. Git history is usually the starting point — it's an honest record of who committed what and when.

Second is open source license compliance: are any dependencies in your codebase licensed in ways that are incompatible with your commercial product? This is a common problem not because engineers are careless but because license compatibility is genuinely confusing and the consequences aren't obvious when you're moving fast. Third is prior employer risk: did any of your engineers create IP at a previous employer on company time or equipment that resembles what they built for you? Prior employer IP agreements often include broad assignment language, and work created in the same domain can trigger a claim.

Fourth is contractor documentation: signed agreements, explicit IP assignment clauses, and NDA coverage for every external contributor. Fifth is employee onboarding documentation: IP assignment agreements for every full-time hire, signed at or before their start date. A buyer's technical team will walk all five areas. You should walk them first.

Start with the contributor list. Pull your git history and build a table of every email address that has ever committed to any repository you own. Cross-reference that against your HR records and contractor files. For every name, ask: is there a signed IP assignment agreement on file? If the answer is no or uncertain, that's a gap to close. The contractor who built your MVP three years ago and has since started their own company is the one you want to track down now, not six weeks before closing.

For open source license compliance, don't try to audit this manually — use a tool. FOSSA, Licensee, and Snyk all have license scanning capabilities. Run a scan across your dependency tree, not just your direct dependencies. GPL-licensed code buried three levels deep in a transitive dependency still counts. The scan will produce a list; filter for GPL, AGPL, and LGPL, and have your lawyer review anything that comes up. In most cases, there's a permissively licensed alternative you can swap in.

For prior employer risk, have a direct conversation with any engineer who joined from a company working in a closely adjacent space. Ask them whether they signed a broad IP assignment at their previous employer and whether anything they built for you could reasonably be argued to overlap with that assignment. If there's a plausible overlap, document the conversation and loop in a lawyer. The risk isn't that you'll always have exposure — it's that you want to know about it before someone else points it out.

Missing contractor IP assignments are the most common finding, particularly in companies that moved fast in the early days. The resolution is usually a retroactive assignment document — if you can find the contractor and they'll sign. Most will. Some won't, or won't without payment. The cost is typically legal fees plus whatever negotiation you end up doing, which is rarely enormous but always stressful under deal timeline pressure. If a contractor is unreachable or uncooperative, you may have to get an IP insurance policy to cover the gap, which costs more and leaves uncertainty on the table.

GPL-licensed open source in a commercial product is the second most common finding. The resolution options are: swap the dependency for a permissively licensed alternative, obtain a commercial license from the GPL library's owner if they offer one, or restructure the integration so the GPL code is isolated and not distributed with your product. None of these are impossible, but all of them require engineering time and should be done before a deal is live — not during it.

Missing employee IP assignment agreements are the third finding, particularly for early hires who may have started before formal onboarding processes were in place. These are usually the easiest to fix — most employees will sign a retroactive assignment without issue. The fourth finding, prior employer IP exposure, is the hardest to resolve because it may involve a third party (the prior employer) who you have no relationship with. In serious cases, buyers sometimes require representation and warranty insurance or a price reduction to absorb the risk. The lesson is: when hiring from direct competitors, get legal guidance on what the engineer's prior agreements say.