Technology Due Diligence Checklist for M&A (2026)

Short answer: Technology due diligence checks whether the technology behind a business actually works, is legally the seller's to sell, is secure enough, can be run without its current builders, and will support your plan for the next few years. The practical method is to work through nine areas (code, IP and licences, infrastructure, security, data protection, people, third-party dependencies, scalability and integration), ask for specific documents in each, and bring in a code reviewer when the product itself is what you are buying.

If you are buying a small or lower-middle-market company that depends on software, you do not need to read code yourself. You need to know what to ask for, what a worrying answer sounds like, and when a specialist is worth paying. This guide is broader than a SaaS review: it covers any tech-dependent or tech-enabled business, including companies whose "technology" is an ERP, a booking system and a handful of spreadsheets. For recurring-revenue metrics such as churn and net revenue retention, see our SaaS due diligence checklist. For the wider process, see the M&A due diligence checklist.

The checklist at a glance

1. Code and architecture

You are checking whether the software can be maintained by someone other than its author.

• ✓Ask for an architecture overview: what the main components are, where they run, and how data flows between them. A one-page diagram is enough to start. If none exists, that is itself a finding.
• ✓Ask how a change goes from a developer's machine to production. Look for version control, a release process, and more than one person able to do it.
• ✓Ask about automated tests and how bugs are tracked. You are not judging coverage numbers; you are judging whether changes are made with a safety net.
• ✓Ask which parts of the system the team is afraid to touch. Honest teams can answer immediately.
• ✓Look at the age of the main frameworks and languages. Software built on versions that no longer receive security updates carries a rebuild cost you should price in.

2. IP ownership and open-source licences

The question is simple: does the company own, or have the right to use, everything it sells?

• ✓Ask for the employment and contractor agreements of everyone who wrote code. You are looking for written assignment of intellectual property to the company. Freelancers and early co-founders are the usual gaps.
• ✓Ask for a list of open-source components and their licences. Many licences are permissive. Some, often called copyleft licences, can impose conditions on how the software built with them is distributed. Whether a given use is a problem is a legal question, so confirm with counsel.
• ✓Check whether any customer contract grants a licence to source code, escrow rights, or exclusivity.
• ✓Confirm trademarks, domain names and app store accounts are registered to the company, not to an individual.
• ✓If the product uses AI models, ask which providers, under what terms, and what happens to the product if a provider changes pricing or terms.

3. Infrastructure and hosting

• ✓Ask for a list of cloud, hosting and domain accounts, and who is the registered owner and administrator of each. Accounts tied to a founder's personal email are common and fixable, but only if found before closing.
• ✓Ask for a monthly cost breakdown for hosting and compare it with the financials. A large gap suggests unrecorded spend or credits that will end.
• ✓Ask how backups are made and when a restore was last tested. A backup that has never been restored is a hope, not a control.

4. Security and incident history

• ✓Ask for the security policies that exist in writing, how staff access is granted and removed, and whether multi-factor authentication is used on core systems.
• ✓Ask for a list of security incidents, near misses and customer security questionnaires from the last few years. Past incidents are not disqualifying; hiding them is.
• ✓Ask whether any penetration test or external assessment has been done, and read the findings and what was fixed.
• ✓Ask whether the company holds, or has been asked for, any security certification, and verify the certificate and its scope rather than the claim.

5. Data protection and GDPR

If the company holds personal data about people in the EU or UK, data protection is part of technology diligence.

• ✓Ask for a record of what personal data is held, where, and why. A company that cannot describe its data has not controlled it.
• ✓Ask for processor agreements with the vendors that handle personal data, and for any record of transfers outside the EU or UK.
• ✓Ask for any regulator correspondence, complaints or breach notifications.
• ✓Treat compliance conclusions as a question for your lawyer, not something this checklist can settle.

6. Key people and documentation

In small companies, the largest technology risk is often a person.

• ✓Identify who built the system, who runs it day to day, and who has the credentials. If that is one person, you are buying a dependency.
• ✓Ask for the contracts, notice periods and tenure of the engineers.
• ✓Check whether runbooks, onboarding notes and system documentation exist and are current. Ask a team member to explain a deployment out loud; you will learn quickly how much is written down.
• ✓Plan retention and a structured handover (for example through an earn-out or a consulting period) while the seller still has leverage to agree to one.

7. Technical debt

Every system has technical debt. What matters is whether the seller knows about it.

• ✓Ask for a list of known shortcuts, workarounds and postponed upgrades, with rough sizes.
• ✓Ask how much engineering time goes to new features versus keeping things running. A team that only firefights cannot deliver your growth plan.

8. Third-party vendors and SaaS spend

• ✓Ask for a complete list of software subscriptions and vendors, with owner, cost, renewal date and notice period. This also exposes costs that are missing from the adjusted earnings.
• ✓Identify which vendors are critical: payments, hosting, email delivery, identity, key APIs. For each, ask what happens if it fails or raises prices.
• ✓Read vendor contracts for change of control, assignment and termination clauses. Some terminate or reprice when ownership changes.

9. Scalability and performance

• ✓Ask which part breaks first if volume doubles, and what that costs to fix.
• ✓Compare your growth plan against those answers. If the plan needs ten times the load and nobody has measured the current limit, put a cost on finding out.

10. IT in businesses that are not software companies

Many acquisitions are ordinary businesses (a distributor, a clinic network, a manufacturer) where technology is an operating system, not a product.

• ✓Ask for an inventory of core systems: ERP or accounting, line-of-business applications, point of sale, scheduling, device fleet and networks.
• ✓Check support status and licensing. Software past end of support, or licences that are not transferable to a new owner, are real costs.
• ✓Ask who provides IT support, under what contract, and whether the managed service provider holds the administrator credentials.
• ✓Check spreadsheets and macros that carry real business logic. They are often the least documented critical system in the company.

11. Integration and the day-one plan

• ✓List what must work on day one: logins, payroll, customer-facing systems, billing. Everything else can wait.
• ✓Plan the credential handover: who receives administrator rights, how they are changed, and how former staff are removed.

What to request in the data room

• ✓Architecture diagram and system inventory
• ✓Repository access (read-only) and release process description
• ✓List of open-source and third-party components with licences
• ✓IP assignment agreements for employees and contractors
• ✓Cloud, hosting and domain account list with owners
• ✓Monthly hosting and software subscription costs
• ✓Security policies, incident log, and any test reports
• ✓Data map, processor agreements, and any regulator correspondence
• ✓Vendor contracts with renewal and change of control terms
• ✓Engineering team contracts and organisation chart
• ✓Backup and disaster recovery documentation

Who to hire for a code review, and when

Hire a specialist when custom software is a material part of what you are paying for, when the seller's claims about the product cannot be tested from documents alone, or when the founder-developer is leaving. Look for an independent senior engineer or a firm that does technical assessments and has no stake in the outcome. Agree scope, access and a written deliverable up front, and ask for findings sorted by what changes the price or the structure of the deal. Do the document side first so the expert's hours go to the questions that remain. For what advisers typically charge in general, see what due diligence costs, and for the full small-business process, our small business acquisition checklist.

Frequently asked questions

How long does technology due diligence take?

It depends on the size of the codebase, how organised the seller is, and how deep you go. A document-only review of the data room can be done in days; a hands-on code and infrastructure review by an outside specialist usually takes longer and needs the seller's cooperation. Ask the specialist for a time estimate against your exclusivity window before you engage them.

Do I need a code review for a small acquisition?

Not always. If the business is a services company that uses off-the-shelf tools, an IT and vendor review is usually enough. If the product is custom software and it drives revenue, a code review is worth considering, scaled to the price you are paying. The cost of a review is small next to rebuilding a product you did not understand.

What is the biggest technology risk in a small acquisition?

Very often it is a person, not a system: one developer or one owner who holds the only working knowledge of how the software is built, deployed and fixed. Close behind are undocumented systems, accounts held in someone's personal name, and unpatched or unsupported software. Confirm access, documentation and handover terms before closing.

What should be in a tech due diligence request list?

At minimum: an architecture overview, repository and cloud account access (read-only), a list of third-party and open-source components, vendor contracts and monthly costs, security and incident history, data protection documents, an inventory of systems and who administers them, and the engineering team's contracts and tenure. The checklist above maps each item to a red flag.

Can AI do technology due diligence for me?

AI can read the documents you have and surface claims and gaps quickly, with each finding tied to its source page, but it cannot inspect a live system or replace an engineer reading the code. Use it to organise the document side and to decide where an expert's hours are best spent.

A cited first pass on the documents

Deal OS reads the deal documents you already have, such as the CIM, and returns a diligence brief in which every claim is cited to its source page, so you can see what the seller says about technology, what is missing, and what to ask next. It does not replace a code review or your advisers, and it cannot inspect a live system. Your first CIM is free: try Deal OS. To learn more, see Deal OS.