Most technology due diligence in M&A fails for one reason: it happens too late, and it asks the wrong questions. By the time the IT team is brought in, the deal is priced, the LOI is signed, and the red flags have already become somebody else’s problem, which is exactly when they become expensive.
This checklist is built to change that. It breaks technology due diligence into seven risk areas, each with concrete items you can run against a target in days, not weeks. Whether you are buying a growth company or a distressed asset, the goal is the same: find the technology risks before they find their way onto your integration plan.
The numbers that justify it: 47% of deal teams now prioritise technology due diligence, yet 51% still name it the single most burdensome diligence area (SRS Acquiom 2026). 74% of acquired codebases contain high-risk vulnerabilities (Human Renaissance). And in distressed deals, undiscovered technical debt is routinely the difference between a turnaround thesis that works and one that unravels in the first 100 days.
The 7 Risk Areas of Technology Due Diligence
Run the target against these seven lenses. Each has its own checklist below.
- Infrastructure and Architecture what is it running on, and will it scale
- Technical Debt and Code Quality how costly is the code to maintain and change
- Cybersecurity and Data what is exposed, and who has access
- IP and Licensing do they actually own what they sell
- Vendor and Third-Party Dependency what breaks if a supplier disappears
- Team and Talent who knows the systems, and will they stay
- AI and Data Readiness is the data clean enough to build on
1. Infrastructure and Architecture Checklist
- Complete infrastructure inventory servers, cloud accounts, network topology, storage
- Cloud spend and commitment analysis AWS, Azure, or GCP run rate versus committed spend
- On-premise hardware age and warranty status with replacement cost estimate
- Single points of failure identified what takes the whole business down if it fails
- Disaster recovery and backup verified with the most recent restore test results, not just the policy
- Scalability assessment can the architecture support the projected growth, or is a re-platform coming
- Monitoring and alerting coverage are production failures detected before customers notice
2. Technical Debt and Code Quality Checklist
- Codebase inventory and language breakdown what is proprietary versus off-the-shelf
- Automated code analysis run static analysis to detect latent vulnerabilities and complexity
- Test coverage measured is there an automated test suite, or does every release rely on manual QA
- Deployment frequency and cycle time how fast can the team actually ship changes
- Documentation quality assessed do the people who built it have to explain it, or is it written down
- Technical debt quantified as a cost translate deferred fixes into a remediation estimate, not a vague “some debt”
- End-of-life and unsupported components flagged deprecations that become a forced rewrite after close
3. Cybersecurity and Data Checklist
- Latest penetration test reviewed within the last 12 months, with remediation status
- Vulnerability scan results examined current exposure, not historical posture
- MFA deployment coverage percentage of users and systems, especially privileged accounts
- Endpoint detection and response (EDR) coverage confirmed
- Incident response plan tested with a recent tabletop exercise, not just a policy document
- Data classification and flow mapped where sensitive data lives and where it moves
- Compliance posture verified SOC 2, ISO 27001, GDPR, and any industry-specific obligations
- Known breach or incident history reviewed with disclosure quality and remediation evidence
4. IP and Licensing Checklist
- IP ownership documentation verified assignment agreements for all code contributors
- Open-source license compliance reviewed with a software bill of materials (SBOM)
- Commercial licence compliance audited to avoid post-close true-ups and audits
- Patent and trademark status confirmed with filings current and ownership clean
- Third-party code provenance traced is any core IP actually borrowed without a licence
5. Vendor and Third-Party Dependency Checklist
- Vendor contract register assembled with change-of-control provisions flagged
- Critical and single-source vendors identified concentration risk mapped
- API and external service dependencies mapped what the product silently depends on
- SLA and support agreements reviewed for production-critical systems
- Cloud provider lock-in assessed migration cost if you need to move off a platform
6. Team and Talent Checklist
- Key-person dependency mapped who knows what, and what breaks if they leave
- Retention risk assessed for the technical staff critical to the product
- Documentation and runbooks verified so knowledge does not walk out the door
- Succession plan confirmed for CTO, chief architect, and critical engineering roles
- Contractor and offshore dependency understood who is actually doing the work
7. AI and Data Readiness Checklist
- Data quality and completeness assessed is the data clean enough to build AI on
- Data governance and lineage documented where did the training data come from
- AI and ML assets inventoried models, pipelines, and their dependencies
- Regulatory exposure flagged AI Act, data privacy, and sector-specific rules
- Model risk and bias reviewed with documented evaluation, not just claims
How to Build Remediation Costs Into Your Bid
Every red flag above has a price. Rather than treating findings as a pass or fail score, translate them into remediation line items and fold them into the deal model. A missing MFA rollout is a five-figure, weeks-long project. A forced rewrite of an end-of-life ERP is a seven-figure, multi-quarter programme. The discipline is to attach a number and a timeline to each finding before close, so the risk is priced, not inherited.
How AssetMax Supports Technology Due Diligence
Diligize automates the heavy lifting of technology due diligence: scanning application portfolios, mapping dependencies, quantifying technical debt, and surfacing the issues a buyer will flag, before the buyer gets access. For distressed and carve-out situations where speed matters, it compresses a multi-week manual review into days.
Pair it with Praetorian for the cybersecurity posture assessment and CarveX for the separation and integration planning that findings feed into.
Frequently Asked Questions
What is technology due diligence?
Technology due diligence is the structured review of a target company’s technology assets, code, infrastructure, security, and team before an acquisition, to surface risks and quantify the cost to remediate them. It answers what you are actually buying and what it will cost to maintain and integrate.
What should an IT due diligence checklist include?
A complete IT due diligence checklist covers seven areas: infrastructure and architecture, technical debt and code quality, cybersecurity and data, IP and licensing, vendor and third-party dependencies, team and talent, and AI and data readiness. Each area should produce documented findings, not verbal assurances.
How long does technology due diligence take?
A focused technology due diligence can be completed in 5 to 10 days using automated scanning and a structured checklist, with deep-dive reviews on high-risk areas extending to several weeks. Starting during the LOI phase, rather than after signing, is what separates deals that price risk from deals that inherit it.
What are the most common technology due diligence findings?
The most common findings are undocumented application inventories, missing MFA deployment, high-risk vulnerabilities in the codebase, unremediated penetration test findings, and single-source vendor dependencies. Each translates directly into a remediation cost that should be priced into the deal.
Why does technology due diligence matter in distressed M&A?
In distressed deals, the timeline is compressed and the seller’s documentation is often incomplete, so hidden technical debt and security gaps are more likely to surface after close, when there is no capacity to deal with them. Technology due diligence is how you find those risks before the turnaround budget is spent.
For the full framework behind this checklist, including the three-phase diligence process and cost benchmarks, see our guide to the technology risks special situations investors miss.