IP Due Diligence Checklist: Protecting Patents, Code and Tech Files in a Secure Data Room

Buyers and their IP counsel focus on four questions. Is every important asset owned by the company, with a clean chain of title from every employee and contractor who built it? Are the registrations valid, maintained and in the company's name? What third-party rights flow in through licenses and software components, and what rights flow out to customers and partners? And is the technology documented well enough to be run and developed after closing?

The most common problems are not exotic. A founder who wrote early code before the company existed and never assigned it. A contractor agreement with no IP assignment clause. A trademark registered in an owner's personal name. A key library used under license terms that conflict with how the product is distributed. Each of these is fixable before a sale, and much harder to fix during one.

Start with an internal IP audit three to six months before launch. It is far cheaper to collect missing assignments and correct registrations on your own timetable than under a buyer's deadline.

Licenses matter in two directions. Inbound licenses tell the buyer what the business depends on and whether those rights survive a change of control. Outbound licenses tell the buyer what rights customers and partners already hold, including any exclusivity that could limit the buyer's plans for the product.

Technical documentation should be written for an informed outsider. The buyer's technical advisors need to understand how the system fits together, where it runs and how changes are made, without reading the code. A clear architecture summary and a short description of the development process answer most first-round questions.

Separate the IP section into ownership records, which most bidders can see, and technical material, which should be released in stages. The table below sets out a structure many technology sellers use.

Give technical folders their own permission group so the buyer's technical advisors can be added without opening legal or financial folders to them. Papermark supports granular folder and file permissions, NDA gating before first access, dynamic watermarking with the viewer's email on each page, and page-level analytics that show which architecture documents a bidder actually read.

Source code does not belong in a due diligence data room. Even with watermarking and view-only access, a code repository is too valuable and too easy to misuse. Buyers who need assurance about code quality and licensing can get it in other ways that keep the code under your control.

Lumen Robotics is a hypothetical warehouse automation startup in talks with a larger industrial equipment maker. Its patents and navigation software are the core of the valuation, and the buyer also makes competing products.

Lumen's internal IP audit turns up two gaps. One of the co-founders wrote the first version of the navigation software before the company was incorporated, and an early contract developer signed an agreement with no IP assignment clause. Counsel obtains a founder assignment and a confirmatory assignment from the developer before the process launches, and files both in the ownership folder.

Next, Lumen runs a software composition scan. It finds a component licensed on terms that require attention given how Lumen distributes its controller software. The engineering team replaces it, and the clean scan report goes into the licenses folder with a short note explaining the change.

Because the buyer competes in the same market, Lumen shares the patent schedule and architecture summary with the buyer's deal team, but the detailed roadmap and the description of its proprietary mapping method go into a clean-team folder visible only to the buyer's outside technical advisors. No source code is uploaded. When the buyer asks about code quality, Lumen arranges an independent review instead, and its summary findings are added to the room.