IT Due Diligence
Almost nothing IT due diligence finds is recoverable from the seller. Sellers fix what they can. Buyers budget for the rest.
Preparing for a review, or running one. Both jobs start here.
What IT Due Diligence Tests
Technical due diligence answers 4 questions. One is whether the technology works. It does, or there would be no deal.
Will it carry the plan?
The deal thesis assumes growth. Architecture either supports it or needs rebuilding first. Scalability limits are a schedule problem before they are a cost problem.
Matters most to: whoever underwrote the growth case
What has been deferred.
Technical debt, unsupported versions, absent tests, and undocumented systems. All of it is real spend, just not yet booked.
Matters most to: the buyer writing the 100-day plan
Who actually knows how it works.
Undocumented systems held together by 2 engineers. Key-person dependency is the risk nobody can indemnify.
Matters most to: anyone planning retention packages
What will it cost to join up.
Identity, email, finance systems and data models all have to converge. Integration cost is consistently underestimated.
Matters most to: corporate development on a strategic deal
These rarely become a claim. They become a line in next year’s budget. Price them before signing, not after.
IT Due Diligence Document Checklist
13 groups. Documentation about the system, not the system itself. Repository access sits outside the room, on its own terms.
Sellers: assemble this before anyone asks. Buyers: send it as the request list.
1.0 Strategy and roadmap
Current plus 2 years forward
- ✓ Technology strategy and how it maps to the business plan
- ✓ Product roadmap with committed dates
- ✓ Build versus buy decisions and their rationale
- ✓ Planned migrations and platform changes
- ✓ Prior year roadmap against what actually shipped
2.0 Architecture
Current state
- ✓ System and data flow diagrams
- ✓ Component inventory with versions and support status
- ✓ Data model and system of record for each entity
- ✓ Multi-tenancy and isolation design
- ✓ Documented constraints and known limits
3.0 Technical debt
Quantified where possible
- ✓ Known debt register with owner and estimated effort
- ✓ Unsupported or end-of-life components
- ✓ Test coverage by service and trend over time
- ✓ Code complexity and static analysis output
- ✓ Deferred dependency and framework upgrades
4.0 Code, licensing and dependencies
All shipped components
- ✓ Third-party and open-source dependency inventory
- ✓ License type for every dependency, including transitive
- ✓ Copyleft components in proprietary or distributed products
- ✓ Commercial software licenses and entitlement counts
- ✓ License compliance position and any audit history
5.0 Infrastructure and resilience
Current state plus 12 months history
- ✓ Deployment model, cloud, on-premises or hybrid
- ✓ Environment inventory and configuration management
- ✓ Single points of failure and documented workarounds
- ✓ Recovery objectives and the last tested restore
- ✓ Uptime history and major incident record
6.0 Technology cost
24 months of actuals
- ✓ Cloud and hosting spend by month and by service
- ✓ Software subscription and license spend
- ✓ Cost per customer or per transaction, and its direction
- ✓ Committed spend, reserved capacity and exit terms
- ✓ Known price increases or contract renewals ahead
7.0 Cybersecurity
Current state plus 3 years' history
- ✓ Security policies and control framework in use
- ✓ Penetration test and vulnerability scan reports
- ✓ Patch status and exception register
- ✓ Incident and breach history with root causes
- ✓ Access control, privileged access and offboarding evidence
8.0 Data and privacy controls
Current state
- ✓ Data inventory, classification and retention practice
- ✓ Encryption at rest and in transit
- ✓ Backup scope, frequency and restore testing
- ✓ Data residency and sub-processor list
- ✓ Technical controls behind privacy commitments
9.0 Engineering team
Current state
- ✓ Org chart with tenure and reporting lines
- ✓ Documented ownership per system or service
- ✓ Key-person dependency and bus factor per component
- ✓ Open roles, attrition history and contractor mix
- ✓ On-call arrangements and escalation paths
10.0 Delivery process
12 months of history
- ✓ Release cadence and deployment frequency
- ✓ Build pipeline and degree of automation
- ✓ Change failure rate and time to restore
- ✓ Code review and branching practice
- ✓ Defect backlog and its trend
11.0 Third parties and support
All material vendors
- ✓ Vendor inventory with dependency criticality
- ✓ Service level commitments given and received
- ✓ Concentration risk on any single provider
- ✓ Support ticketing volumes and resolution times
- ✓ Source code escrow arrangements where they exist
12.0 Separation and integration
Carve-outs and strategic deals
- ✓ Shared systems and services with the parent group
- ✓ Transition services required, by system and duration
- ✓ Licenses that do not transfer with the business
- ✓ Data extraction feasibility and format
- ✓ Target end-state architecture after integration
13.0 AI and model dependencies
Where the target ships AI features
- ✓ Inventory of models in use, built in-house or called from a vendor
- ✓ Training data sources with rights and license evidence
- ✓ Dependency on any single model provider and switching cost
- ✓ Inference cost per transaction and how it scales
- ✓ Evaluation methodology and whether results are reproducible
- ✓ Share of the codebase generated by AI tooling, and review practice around it
Who owns the code sits with the IP workstream. Contract and privacy liability sit with legal review. This list covers what the systems are and cost.
IT Due Diligence Asks for the System, Not the Code
Diagrams, cost reports, incident logs, test evidence. Indexed by system.
Technical Debt and the Post-Close Budget
Technical debt is not on the balance sheet. It shows up in the 1st budget cycle after closing, when the price is already fixed.
If you underwrote the growth case, this table is your capex risk.
3 places a finding can land
Only the 1st reduces what the seller receives.
Priced into the deal.
The remediation estimate comes off the offer, or becomes a holdback where the scope is still uncertain.
Moved into the 100-day plan.
Accepted as a known cost, sequenced after closing, funded by the buyer.
Made a condition.
Fixed before completion. Rare on technology, because most remediation takes longer than the deal timetable.
An estimate a seller can evidence gets negotiated. One a buyer has to guess gets padded, always in the buyer’s favor.
Red Flags in IT Due Diligence
9 findings that move a price or a timetable. Founders should read this list as a to-do. Buyers read it as a price.
Fix the top 3 before launch. The rest you disclose and explain.
Copyleft components in a shipped product
Obligations nobody assessed, and a rewrite to remove them.
More licensed seats in use than purchased
A true-up bill that arrives whether or not anyone audits.
Architecture nobody has documented
Knowledge lives in 2 heads. Both have other offers.
Cloud cost per customer rising
Unit economics moving the wrong way, quietly.
A single point of failure with no tested recovery
The restore has never been run. Assume it does not work.
Test coverage falling over 12 months
An engineering culture problem, not a backlog problem.
Training data with no rights evidence
A model cannot be untaught. Fixing it means retraining.
A breach history that surfaced from a search
The incident matters less than the omission.
Shared systems with a parent nobody mapped
On a carve-out, this is the largest unbudgeted line.
From IT Due Diligence to Deal Terms
On legal and tax review, most findings become the seller’s problem. Here, most do not.
Read the last column first. It decides who pays.
The report is what makes any of this negotiable. Findings, a risk matrix, remediation estimates, and a plan across 30, 60, and 90 days.
Their Engineers Are Reading Your Room
On a strategic deal, the technical reviewer works for a competitor. Stage what they see.
IT Due Diligence Scope and Timelines
Shorter than the other workstreams. Document quality decides how much shorter.
If you are buying
2 to 4 weeks for 1 product. Longer for a group or a multi-stack platform. Run it alongside financial review, not after.
If you are selling
Reviewing yourself turns surprises into decisions. What you document, you get credit for. What you cannot explain, a buyer discounts.
If it is a carve-out
Add time for separation mapping. Shared systems, non-transferable licenses, and transition services stay unbudgeted until someone lists them.
Independent specialists do this, not the buyer’s own IT team. Investment committees and lenders need a view that is not internal.
Frequently Asked Questions
The questions buyers ask their advisers, and the ones sellers ask too late.
A review of a target’s systems, technical debt, security posture, and technology costs before a transaction. IT due diligence prices what the buyer will need to spend after closing.
Buyers use them interchangeably. Practitioners increasingly do not. Technical review goes deep on the product when software is the asset. IT review covers the target's entire systems estate.
2 to 4 weeks for a single product. Longer for a group, a multi-stack platform, or a carve-out. Document quality drives the timeline more than company size.
Independent technology specialists, not the buyer’s internal IT team. Investment committees and lenders rely on the report, so the view has to be external.
By estimating the engineering effort to remediate, then converting it to cost and calendar time. An estimate the seller can evidence gets negotiated. What the buyer has to guess gets padded.
It should, on any strategic deal. Identity, email, finance systems, and data models all have to converge, and that cost is consistently underestimated at the offer stage.
Copyleft components inside a proprietary product create obligations the target may never have assessed. Removing or replacing them is engineering work, so it lands as a cost, not just a legal issue.
Findings by area, a risk matrix, remediation estimates with effort and cost, and a sequenced plan across 30, 60 and 90 days. It is written to be negotiated from.
IT Due Diligence Rewards Whoever Documented It
Diagrams, cost reports, and incident history in 1 indexed place. Access staged per reviewer.