From LinkedIn · · 1 min
The sixth category
Five categories had nowhere to file the same recurring risk. The sixth asks a different question: can the company transfer what it says it owns, and what makes it worth owning once it does?
By Olha Shevchenko. Audits production systems on AWS and Node.js.
The sixth category was the one my technical due diligence checklist had nowhere to put.
I started with five:
- Product
- Architecture
- Operational
- Security
- Team
The checklist grew to 37 questions. The same underlying risk had surfaced in three different categories.
- Licence obligations sat under Architecture.
- Missing IP assignments sat under Team.
- Vendor terms that may not survive a change of control sat under Product.
At that point, the checklist had an ownership problem of its own.
Different folders. Same question:
Can the company transfer what it says it owns, and what makes it worth owning once it does?
None of the five categories answered that cleanly.
So I added a sixth: Rights and defensibility.
Rights is the transfer half. Who owns the code, data, accounts, licences, and contracts? What still works when control changes?
Defensibility is the other half. Once everything transfers, what prevents someone else from rebuilding the same product?
Defensibility does not automatically live in the repository.
It may live in a customer's workflow. Proprietary data. Distribution. Switching costs. Integrations that took years to establish.
That changes the review.
A clean codebase with good tests can still be a weak asset. The company may not fully control it. Or the code may transfer perfectly while the thing creating the value does not.
Technical due diligence is not only about finding what can break.
It also has to establish what is actually being bought.