When you buy an IT company, you may acquire not only the team and the product but also obligations to third parties, demands to disclose source code, technical debt and seven-figure penalties. These risks don't show up on a conventional balance sheet, yet their consequences can exceed the deal value many times over. In this article we break down which hidden IT liabilities you can actually encounter during due diligence, how to detect them and how to properly shift them onto the seller.
Which IT liabilities don't make it onto a conventional balance sheet
Licensing risks and "viral" open source
Using open-source components is cheap and convenient, but without control it turns into a risk. Copyleft licenses (GPL) require you to disclose the source code of the entire product, which devalues your main asset. In addition, you need to verify whether the software is recorded in the relevant intellectual property and software registries.
It is also important to verify the scope of rights: does the licensor hold the full scope of rights. Without such verification, the actual rights holder may prohibit the use of the software. Reviewing agreements with authors deserves separate attention: there are frequent cases where the software is registered to an individual (the CEO) rather than to the company - a direct path to claims from the tax authorities and former developers.
Contractual obligations under development and support agreements
Even if the code has been purchased and paid for, the following often remain:
- Unfulfilled contractor obligations (documentation not handed over, source code held by a third party, the final stage of work unpaid).
- Claims for remuneration owed to authors.
- Terms that oblige you to finance further development.
Vendor lock-in and non-obvious payments
Vendor lock-in is when, due to technological, financial or organizational costs, switching to another supplier becomes practically impossible. This is especially relevant for cloud services: the platform itself is cheap, but proprietary data formats and the absence of export mechanisms help "tie" the client in. In a deal, this means that future cost growth is entirely in the vendor's hands.
Cybersecurity and regulatory risks
Hidden security incidents, unpatched vulnerabilities, attacks through contractors - all of this is "security debt" that will pass to you. You also cannot ignore regulatory requirements: for example, the banking sector typically requires a compliance assessment against financial regulator requirements. Your assessment should include an analysis of access levels, incidents, compliance and any sanctions in force.
Technology due diligence: how to find hidden liabilities
When acquiring an IT company, buying the asset is only half the job. It is essential to properly check its technological health.
Static and dynamic analysis: security review, search for critical vulnerabilities and backdoors, analysis of code quality and structure, verification that the documentation matches the actual code.
High coupling between components, lack of documentation, dependency on specific employees, outdated libraries.
Reviewing component licenses and identifying "viral" restrictions.
You need to understand where and under what terms all assets are used: software, libraries, databases, hardware, specialized software.
Tools for shifting risks onto the seller
The main goal of legal protection is to ensure that none of the risks found land on your shoulders after the deal.
Representations & Warranties
In the purchase agreement, the seller warrants in writing that:
- all rights to the software held by the seller are "clean";
- there are no undisclosed claims or sanctions;
- all open source is compatible with the commercial model.
A breach of warranty is a direct basis for recovering damages.
Indemnity
An indemnity is an agreement under which the seller undertakes to compensate the buyer for specific losses upon the occurrence of certain circumstances. A common practice is to include in the contract a list of "indemnifiable risks" (licensing claims, tax claims, author claims).
Software Escrow (source code deposit)
The buyer can require the source code and documentation to be placed with an independent escrow agent. This guarantees that even if the vendor goes bankrupt or discontinues support, you will have all the materials needed to keep working. In cross-border deals, this is critical when foreign vendors may withdraw from a market.
Holdback and limitation of liability mechanisms
An effective approach is to hold back part of the purchase price (a cash escrow) for 12-24 months to cover identified risks. At the same time, it is important to reasonably limit the seller's liability and define exactly what counts as an "indemnifiable event," as well as set a deductible and a liability cap.
| Tool | What it covers | When it triggers |
|---|---|---|
| Representations & warranties | Clean title, absence of claims, open source compatibility | Breach - grounds to recover damages |
| Indemnity | List of specific risks: licenses, taxes, authors | Upon the occurrence of the agreed circumstance |
| Software Escrow | Access to code and documentation | Vendor bankruptcy, discontinuation of support |
| Price holdback | Covering identified risks from the seller's money | Within 12-24 months after the deal |
Conclusion
Hidden debts in the areas of licensing, open source, cloud dependency, security and technical debt can not only destroy the business model but also lead to multimillion-dollar claims. To protect yourself, you need to identify these risks and, using sound legal structures (warranties, indemnities, escrow and holdbacks), shift them onto the seller.
Technology due diligence to protect your deal
G-Invest audits licenses, source code, open source and technical debt, uncovers hidden IT liabilities outside the financial statements, and builds warranties, indemnities and escrow into the contract to shift the risks onto the seller - with deal support all the way to closing.
Frequently asked questions
What is technology due diligence in M&A deals?
Technology due diligence (Tech DD) is an in-depth review of the target company's IT assets, code, architecture, licensing cleanliness, open-source components, security and infrastructure. Unlike financial or legal DD, technology DD focuses on uncovering hidden technical risks that are not reflected on the balance sheet but can lead to multimillion-dollar losses after the deal.
Why does ordinary due diligence miss hidden IT liabilities?
Classic due diligence (financial, legal, tax) operates on statements, contracts, lawsuits and registries. IT liabilities, however, often have no material form and are not recorded in the books:
- use of open source without an agreement;
- undisclosed claims from code authors;
- technical debt embedded in the architecture;
- vendor dependency that is not formalized as a financial obligation.
Without analyzing the source code, library licenses and IP rights, such risks remain "invisible."
How do you verify clean title to code when buying an IT company?
Verification involves several stages:
- Inventory of the code - all repositories, libraries, frameworks, scripts.
- Analysis of each component's license (including transitive dependencies) for compatibility with the buyer's commercial model.
- Analysis of the commit history - who made changes, when and under what terms.
- Review of agreements with developers (employment, contractor, work-for-hire) - whether exclusive rights were transferred to the company.
- Reconciliation with intellectual property and software registries (for accredited IT companies and tax incentives).
Such an audit should be carried out by an independent technologist together with an IP lawyer.
Is it mandatory to check IP and software registries before a purchase?
Yes, especially if you are buying an accredited IT company that claims tax incentives (for example, reduced social-security contribution rates or a 0% profit tax for special economic zone or government-grant residents). The registries contain records of registered software, databases and integrated-circuit topographies. A mismatch between the software actually used and what is registered is grounds for additional tax assessments and penalties. Moreover, if rights to the software are registered to an individual (even the CEO), the company cannot be considered the rights holder - a direct obstacle to obtaining incentives.
What documents are needed to review software when buying a business?
Minimum checklist:
- An inventory of all intellectual property (software, databases, know-how).
- Software registration certificates (if any).
- Agreements with authors (employment, contractor, work-for-hire) with acceptance acts transferring exclusive rights.
- License agreements for third-party software (commercial and open source, with license versions specified).
- An open-source component scan report (SBOM - Software Bill of Materials).
- Technical documentation (architectural, API, user and administrator).
- Security policies and penetration-test reports for the last 2 years.
- Agreements with contractors for development and support.
- Access to repositories, CI/CD, monitoring systems and incident databases.
Important: all documents must allow you to trace the chain of rights from the author to the seller and from the seller to you.