What is IT due diligence in M&A?

IT due diligence (IT DD) is a structured assessment of a target company's technology assets, risks, and capabilities conducted during the M&A process, typically between term sheet and closing. It evaluates: the architecture and scalability of core software systems; the technical debt and remediation costs that will be inherited; the security posture and any known or undiscovered vulnerabilities; the IP ownership and licensing cleanliness of the codebase; the engineering team's structure, capabilities, and retention risk; and the integration complexity of connecting the target's systems to the acquirer's. IT DD findings inform the purchase price, representations and warranties, integration planning, and go/no-go decisions on the transaction.

What are the biggest red flags in IT due diligence?

Deal-threatening red flags in IT DD: (1) undisclosed data breaches or ongoing security incidents; (2) IP ownership disputes — code built by contractors without IP assignment clauses, or open-source components used in violation of licence terms (GPL in a proprietary product); (3) single points of failure in the engineering team (the entire system documented only in one person's head); (4) critical systems running on unsupported infrastructure (EOL operating systems, databases out of support contracts); (5) material misrepresentation of the technology in the sales process — systems described as cloud-native that are actually bare-metal; (6) customer data stored insecurely or in violation of contractual obligations; and (7) fundamental architectural scalability limits that would require a full rewrite to support 2× current load.

Who should conduct IT due diligence?

IT DD requires a combination of: a technical architect or principal engineer to assess system architecture and scalability; a security specialist to assess the security posture and run a vulnerability scan; an IP and licensing specialist (often a lawyer, sometimes a technical consultant) to review open-source licence compliance and IP ownership; an engineering management specialist to assess team structure, processes, and retention risk; and optionally a data specialist for data architecture, data quality, and privacy compliance if data assets are central to the deal thesis. For most M&A transactions, this is assembled as a dedicated IT DD team — either from the acquirer's internal team, an independent advisory firm, or a combination.

How long does IT due diligence take?

IT DD typically runs 3–6 weeks in a standard M&A process, with compressed timelines (2–3 weeks) for competitive processes. The work phases: week 1 — document request list response, initial architecture and team interviews, security scan initiation; weeks 2–3 — deep technical assessment of core systems, security review, IP review, team interviews; week 4 — findings synthesis, risk quantification, integration planning input; week 5–6 — report production, management Q&A, deal team briefing. Compressed timelines are feasible but increase the risk of missing material issues. Critical security and IP assessments should not be compressed below 2 weeks regardless of process timeline.

How do you quantify technical debt in IT due diligence?

Technical debt quantification in IT DD translates code-level findings into remediation cost estimates that the deal team can model. Approach: categorise technical debt by type (code quality, architecture, security, dependency, infrastructure); estimate remediation effort in engineering weeks per category; apply a loaded engineering cost rate ($150–$300/hour depending on market); sum to a total remediation cost estimate; and present as a range (low/base/high) given uncertainty. This becomes an input to purchase price negotiation — a $2M architectural remediation cost in the base case supports a corresponding price adjustment. Be conservative: IT DD time constraints mean some debt is discovered post-close.

What IP issues commonly arise in IT due diligence?

IP issues that arise frequently: (1) contractor work without written IP assignment agreements — code built by freelancers or agencies before formal IP assignment clauses were standard may legally belong to the contractor; (2) open-source licence violations — GPL or LGPL licensed code embedded in a proprietary product creates an obligation to open-source the proprietary code if the product is distributed; (3) employee agreements without work-for-hire clauses — engineers hired in jurisdictions where work-for-hire is not automatic without a contract; (4) third-party software licences not transferable in an asset acquisition — enterprise software licences may need re-negotiation post-close; and (5) patent or trade secret claims from former employers of key engineers.

What is the IT integration complexity assessment?

Integration complexity assessment evaluates how difficult it will be to connect the target's systems to the acquirer's post-close. Key dimensions: data model compatibility (are customer, product, and transaction records mappable between systems?); API availability (does the target have APIs that allow integration, or is point-to-point database access required?); identity and access management (can users be federated into the acquirer's IdP?); infrastructure compatibility (same cloud provider? Same containerisation approach?); and ERP/CRM integration (how does the target's revenue recognition, billing, and CRM connect to the acquirer's?). Integration complexity directly determines the integration timeline and cost, which affects synergy realisation timing — a 24-month integration instead of a 12-month integration can materially change deal economics.

What representations and warranties should the acquirer require based on IT DD findings?

Based on IT DD findings, the acquirer should negotiate representations and warranties covering: no undisclosed data breaches or security incidents in the last N years; all material software is owned by the company or properly licensed; no open-source licences that would require disclosure or distribution of the company's proprietary code; all contractor and employee IP is assigned to the company; no material security vulnerabilities known to management; systems are compliant with applicable data protection regulations (GDPR, CCPA); and no pending or threatened IP claims. Representations are negotiated based on DD findings — issues discovered in DD become specific carve-outs or adjusted representations. Representations and Warranties insurance (RWI) can cover residual IP and security risk.

2026-08-18 · Updated 2026-08-18

IT Due Diligence for M&A: What to Assess, What Kills Deals, and How to Structure the Review (2026)

The most expensive M&A mistakes are not bad deals on the surface. They are deals that looked right until the integration exposed a $10M remediation programme that was invisible in the financial model because nobody looked at the code.

IT due diligence exists to find those risks before they are locked into the purchase price. Done well, it quantifies technical debt into deal model inputs, identifies security issues that require representations and warranties, surfaces IP risks that require structural fixes, and gives the integration team a realistic cost and timeline before close.

Done poorly — or skipped — the acquirer inherits the risk without the discount.

What IT Due Diligence Covers

A complete IT DD engagement has five primary workstreams:

Workstream	Key questions	Primary risk
Architecture and scalability	Can the system handle 2–5× current load? What would break?	Rewrite risk, scaling cost
Security	Are there undisclosed vulnerabilities or breaches?	Regulatory, reputational, financial liability
IP and licensing	Who owns the code? Are OSS licences clean?	Deal structure risk, litigation exposure
Engineering team	Who are the key people? What is the retention risk?	Knowledge loss, integration delay
Integration complexity	How hard is it to connect to acquirer systems?	Synergy timeline, integration cost

Architecture Assessment: Questions That Reveal Real Risk

The architecture interview with the CTO and lead engineers produces the most valuable signals when you ask questions that reveal the gap between the pitch and reality:

"Walk me through what happens when 10× your current load hits the system — 
what breaks first?"

"What is the one architectural decision you would undo if you could?"

"If a senior engineer leaves tomorrow, which parts of the system would become 
unmaintainable?"

"What is the oldest part of the codebase that nobody has touched in two years?"

"Have you had to turn away customers or deals because the system couldn't 
handle their requirements?"

The answers calibrate the distance between the management presentation and the engineering reality.

Security Assessment: What to Scan and What to Check

External attack surface scan

# Tools commonly used in IT DD security assessment:
# - Tenable.io or Qualys: authenticated vulnerability scanning
# - Shodan/Censys: exposed services and infrastructure discovery  
# - truffleHog / gitleaks: secrets in Git history
# - FOSSA / Snyk: OSS licence and CVE scanning in codebase
# - Wiz / Prisma Cloud: cloud configuration against CIS Benchmarks

Security posture checklist

Control	Green	Yellow	Red
MFA on production systems	MFA enforced via SSO	MFA optional	No MFA
Data encryption at rest	All data encrypted, KMS managed	Partial encryption	Unencrypted production data
Last penetration test	< 12 months, critical findings closed	12–24 months	> 24 months or never
Known critical CVEs	None open	< 30 days open	Critical CVEs open > 30 days
Secrets in codebase	None found	Rotated since exposure	Active credentials in code
Incident history	No material incidents	Incidents disclosed and closed	Undisclosed incidents

A single Red in the incident history row — an undisclosed material breach — is typically a deal-stopper or requires significant structural mitigation.

IP and Open-Source Licence Risk Matrix

Licence type	Risk level	Issue
MIT, Apache 2.0, BSD	Low	Attribution required only
LGPL (linked)	Medium	Must allow relinking; disclose LGPL dependency
GPL v2/v3 (embedded)	High	Forces proprietary code to be open-sourced if distributed
AGPL	Very high	Triggers copyleft on network use (SaaS)
Commercial licence not transferable	High	Must re-negotiate post-close
No IP assignment (contractor)	High	Contractor may own the code

GPL-licensed code embedded in a commercial product is the most common material IP finding in IT DD. Remediation requires removing or replacing the GPL component — which can take weeks to months depending on how deeply it is embedded.

Technical Debt Quantification Template

Debt category	Findings	Severity	Effort (eng-weeks)	Cost at $200/hr
Architecture	Monolith requiring decomposition for scale	High	40	$320,000
Security	12 critical CVEs in dependencies	Critical	4	$32,000
Infrastructure	3 servers on EOL OS (unsupported)	High	6	$48,000
Code quality	No automated tests (0% coverage)	Medium	20	$160,000
Dependencies	8 major outdated frameworks	Medium	12	$96,000
Total base case			82 weeks	$656,000

Present as a range: low case (50% of base, assuming some debt is less severe than assessed), base case, and high case (150% of base, accounting for discovery risk post-close).

Deal Structure Implications of IT DD Findings

Finding	Deal implication
Material technical debt	Purchase price reduction or escrow holdback
Critical unpatched vulnerabilities	Representation and warranty; indemnification clause
GPL licensing issue	Remedy required pre-close or structural risk allocation
No contractor IP assignments	Specific rep/warranty with indemnification
Undisclosed security incident	Material adverse change trigger or deal-stopper
Key person concentration	Retention packages (bonuses, vesting) as closing condition
High integration complexity	Adjust synergy timeline in deal model; increase integration budget

Technology risk in M&A is quantifiable risk, not subjective risk. IT due diligence converts what looks like engineering opinion into deal-model inputs: remediation costs, integration timelines, and the specific representations and warranties that allocate residual risk between buyer and seller. The cost of a thorough IT DD engagement is measured in tens of thousands of dollars; the cost of a material IT issue discovered post-close is measured in millions.

For help structuring an IT due diligence engagement or assessing the technical readiness of an acquisition target, see our Enterprise Software Development capabilities or get in touch. Our guide on Technical Debt covers the underlying measurement and prioritisation frameworks used in technology debt quantification.

Related Insights

Technical Debt: How to Identify, Measure, and Reduce It Before It Kills Your Roadmap

Technical debt slows every feature, multiplies every bug, and burns out every team — and most organisations only measure it when delivery has already collapsed. This guide gives you a taxonomy, a quantification method, a prioritisation matrix, and a remediation roadmap you can start using this week.

Legacy System Modernization: When and How to Migrate Off Old Software

Legacy systems slow businesses down, increase risk, and block growth. This guide explains how to recognize when your system is a liability, which modernization approach to use, and how to plan a migration that actually works.

How to Choose a Software Development Partner: Agency vs Freelancers vs In-House (2026)

Choosing between a software agency, freelancers, and building in-house is a decision that shapes your product's velocity, quality, and cost for years. This guide covers the real trade-offs of each model, a vendor evaluation framework, and the red flags that separate good partners from expensive mistakes.

Need Expert Guidance?

Planning custom software for your business?

Book a free consultation with our team to discuss architecture, product strategy, and the right build approach for your goals.

Book Free Consultation

LLM Integration in Enterprise Applications: Patterns, Risks, and Production Checklist (2026)

Integrating LLMs into enterprise software is not the same as calling a REST API. Latency, cost per token, hallucination, prompt injection, data residency, and vendor lock-in require patterns that most API tutorials skip entirely. This guide covers the production architecture decisions, risk controls, and evaluation frameworks that separate a reliable enterprise LLM integration from an expensive demo.

Disaster Recovery Planning for Cloud Workloads: RTO, RPO, and the Architecture Decisions That Actually Matter (2026)

Most disaster recovery plans fail their first real test — not because the architecture was wrong, but because the plan was never tested. This guide covers the RTO/RPO framework for setting recovery targets that business requirements actually justify, the four cloud DR patterns (backup/restore, pilot light, warm standby, multi-site active/active), what each costs, and the testing cadence that separates a working DR plan from a document that creates false confidence.

Back to Insights