Tech IT Due Diligence: Key Challenges and Typical Red Flags

Author: David Wang

Wang Advisory GmbH (June 2026)

Why technology has become a core M&A value driver

Tech IT Due Diligence is no longer a narrow IT workstream. In many transactions, technology is the product, the operating model, the customer interface, the scalability engine, the compliance layer, and the risk surface at the same time.

Bain defines Tech Due Diligence as an assessment of a company’s software or ecommerce platform across product functionality, infrastructure, and security to identify opportunities, avoid risk, and determine the target’s full potential. Bain also states that cybersecurity is central to 80 percent of its tech due diligence assessments. [1]

BCG Platinion similarly emphasizes that robust Tech Due Diligence helps acquirers understand investment value, evaluate existing technology structures, identify growth opportunities, and assess potential risks. [2]

The message is clear. Technology is not only an IT cost topic. It is a valuation topic, a risk topic, and a post closing value creation topic.

A strong Tech IT Due Diligence should answer five executive questions.

• Can the technology support the deal thesis?

• Can the platform scale without disproportionate investment?

• Are ERP, non ERP applications, infrastructure, data, cyber, and licenses under control?

• What technical debt, compliance risk, or hidden capex will the buyer inherit?

• What must be fixed in the first 100 to 180 days after closing?

The goal is not to produce a long technical report.

The goal is to translate technology facts into deal implications.

The Tech IT Due Diligence value equation

Technology risk becomes deal risk when it affects one of five areas.

• Valuation

• Synergy case

• Integration cost

• Business continuity

• Regulatory or contractual exposure

Deloitte describes Software, Product and Tech Due Diligence as an assessment of product capabilities, future development, structure, design, technology stack, technical debt, and the effectiveness of the product development team in relation to the investment thesis. [3]

A weak ERP setup can delay integration. A fragmented application landscape can increase cost. An outdated infrastructure can create resilience risk. Unclear software licenses can create legal and financial exposure. Weak cybersecurity can become a material liability. Poor data quality can weaken the value creation plan.

Tech IT Due Diligence should therefore assess the full technology stack, not only the software product.

Eight diligence lenses that matter

1. IT application landscape

The application landscape shows how the business really works.

Key diligence questions:

• Which applications are business critical?

• Which systems support sales, finance, operations, HR, logistics, customer service, and reporting?

• Which applications are custom built, standard software, SaaS, or outsourced?

• Which systems are integrated and which rely on manual workarounds?

• Which applications are end of life, unsupported, or technically obsolete?

• Which applications are in scope for Day 1, integration, carve out, or TSA planning?

Typical red flags:

• No complete application inventory

• Unknown system ownership

• Duplicated tools across functions

• Heavy use of shadow IT

• Manual interfaces between critical systems

• High number of local tools without central governance

• Business critical applications without support model

• No target application roadmap

Deal implication: A fragmented application landscape creates integration cost, business continuity risk, and hidden modernization capex.

2. ERP and core enterprise systems

ERP is often the operational backbone of a company. It connects finance, controlling, procurement, inventory, production, sales, logistics, and reporting.

Key diligence questions:

• Which ERP system is used and how heavily is it customized?

• Are finance, procurement, production, inventory, and order to cash processes standardized?

• Is the ERP setup scalable across countries, entities, and business units?

• Are there upcoming ERP migrations, upgrades, or end of support issues?

• Is the target dependent on the seller’s ERP after closing?

• Are ERP costs, licenses, interfaces, and support contracts transparent?

Typical red flags:

• Highly customized ERP core

• Outdated ERP release or approaching end of support

• Weak master data quality

• Manual month end closing workarounds

• Poor integration between ERP and CRM, warehouse, ecommerce, or billing systems

• Key users maintaining critical logic outside the system

• ERP separation or migration not reflected in the business plan

• No clear Day 1 ERP access model in carve outs

Deal implication: ERP issues can directly affect finance reporting, working capital, operational continuity, TSA needs, and integration cost.

3. Non ERP applications and business platforms

Non ERP applications often carry the real business differentiation.

These include CRM, ecommerce, POS, payment systems, warehouse management, transport management, customer portals, billing, data platforms, workflow tools, product platforms, and industry specific software.

Key diligence questions:

• Which non ERP systems are mission critical?

• Which applications are customer facing?

• Which platforms generate revenue or enable service delivery?

• Which systems are internally developed versus vendor based?

• Are interfaces documented?

• Are system owners and vendor contracts clear?

• Are there change of control, assignment, or termination clauses?

Typical red flags:

• Customer facing platform with weak resilience

• POS, payment, ecommerce, or billing systems with undocumented dependencies

• CRM data quality issues

• Unsupported warehouse or logistics systems

• High operational reliance on Excel, email, or manual approvals

• Vendor contracts not transferable after closing

• No application rationalization logic

• Product roadmap disconnected from system reality

Deal implication: Non ERP application risk can affect revenue continuity, customer experience, synergy capture, and post closing transformation speed.

4. Infrastructure, cloud, and resilience

Infrastructure determines whether technology can scale, recover, and operate reliably.

Key diligence questions:

• Is infrastructure cloud based, on premise, hybrid, or outsourced?

• Are hosting, network, workplace, identity, backup, and disaster recovery documented?

• Are service levels, uptime, and incidents measured?

• Are cloud costs transparent and linked to business usage?

• Are critical workloads dependent on one vendor or one data center?

• Are disaster recovery tests performed and documented?

Typical red flags:

• No infrastructure inventory

• Unknown cloud cost drivers

• No FinOps or cloud cost governance

• Missing backup or restore testing

• No tested disaster recovery plan

• Single points of failure

• Unsupported servers or operating systems

• Poor monitoring and observability

• Critical infrastructure operated by small external providers without exit plan

Deal implication: Infrastructure risk can create hidden capex, resilience exposure, cybersecurity risk, and Day 1 disruption.

5. Software licenses, contracts, and open source risk

Software licenses are often underestimated in M&A. They can create cost leakage, compliance risk, and post closing disruption.

Key diligence questions:

• Are software assets and licenses inventoried?

• Are license entitlements aligned with actual usage?

• Are there under licensing or over licensing risks?

• Are SaaS, cloud, ERP, database, and infrastructure contracts transferable?

• Do contracts include change of control clauses?

• Are open source components tracked?

• Are copyleft, GPL, AGPL, or other license obligations understood?

• Is there a software bill of materials where relevant?

Typical red flags:

• No software asset management process

• No clear license ownership

• Material under licensing exposure

• Duplicated tools and unused subscriptions

• Non transferable vendor agreements

• Open source components without license review

• No Software Composition Analysis

• Reliance on automated scans without legal or technical interpretation

• Missing software bill of materials for critical products

Automated software composition scans are useful, but they do not guarantee open source license compliance without legal and technical interpretation. [9]

Deal implication: License issues can trigger audit exposure, unexpected cost, legal remediation, delayed integration, and customer contract risk.

6. Cybersecurity and operational resilience

Cybersecurity is one of the most important Tech IT Due Diligence areas because buyers can inherit hidden liabilities.

IBM’s Cost of a Data Breach Report 2025 states that the global average cost of a data breach was approximately USD 4.4 million. IBM also highlights that AI adoption is outpacing AI security and governance. [8]

NIST Cybersecurity Framework 2.0 provides a recognized structure for managing cybersecurity outcomes across governance, identification, protection, detection, response, and recovery. [4]

Key diligence questions:

• Is cybersecurity governed at management level?

• Are identity, access, and privileged accounts controlled?

• Is multi factor authentication enforced?

• Are vulnerabilities identified and remediated within clear timelines?

• Are backups tested?

• Is incident response documented and exercised?

• Are third party and cloud risks governed?

• Are cyber metrics reported to leadership?

Typical red flags:

• No CISO or clear security owner

• Weak identity and access controls

• No privileged access management

• No vulnerability management process

• No recent penetration test

• No incident response playbook

• No tested backup and recovery process

• Unknown internet facing assets

• Weak supplier security governance

• Cyber risk not reflected in the investment case

Deal implication: Cybersecurity weaknesses can affect valuation, deal protection, remediation cost, customer trust, and regulatory compliance.

7. Secure software development, data, AI, and compliance readiness

Security should not be tested only at the end of development. It should be embedded into the software development lifecycle.

NIST’s Secure Software Development Framework provides a core set of high level secure software development practices that can be integrated into software development processes. OWASP Top Ten is a standard awareness document for developers and web application security, and the current released version is OWASP Top Ten 2025. [5] [7]

Data and AI are increasingly central to technology valuation. But many companies lack the governance foundation required to scale data products or AI enabled workflows.

Key diligence questions:

• Who owns the data?

• Are data lineage, quality, and access rights documented?

• Are GDPR and privacy obligations managed?

• Are reporting and analytics reliable?

• Are secure software development practices embedded?

• Are third party libraries and open source components tracked?

• Are AI use cases governed?

• Are model outputs monitored and reviewed?

• Are third party AI dependencies transparent?

Typical red flags:

• Unclear data ownership

• Weak master data quality

• No data lineage

• Customer data stored across uncontrolled tools

• No secure development lifecycle

• No automated security scanning

• Hard coded credentials or secrets

• Shadow AI usage without governance

• Overstated AI capability

• No AI risk management approach

• No human review for critical AI outputs

• Compliance requirements not reflected in the roadmap

Deal implication:Weak secure development, data, and AI governance can reduce scalability, create compliance exposure, and weaken the commercial value story.

8. Technology organization and delivery capability

Technology quality depends on people, governance, and delivery discipline.

Google Cloud’s DORA metrics, from DevOps Research and Assessment, have become an industry standard for measuring software delivery performance. [6]

Key diligence questions:

• Is the CTO or CIO organization strong enough for the next growth phase?

• Are product, engineering, data, security, and operations roles clear?

• Is knowledge concentrated in a few individuals?

• Are release cycles predictable?

• Are incidents tracked and resolved systematically?

• Is technical debt actively managed?

Typical red flags:

• Key person dependency

• High engineering attrition

• No clear product ownership

• Weak documentation

• Low test automation

• Manual deployment process

• Frequent production incidents

• No roadmap discipline

• Outsourced development without knowledge transfer

Deal implication: People and delivery risks can quickly become product risk, integration risk, customer risk, and value creation risk.

The ten red flags investors should not ignore

A Tech IT Due Diligence should escalate when it identifies one or more of the following red flags.

• No reliable application inventory

• ERP heavily customized, outdated, or not separation ready

• Critical non ERP systems with undocumented dependencies

• Infrastructure without tested disaster recovery

• Cloud costs growing without ownership or transparency

• Software licenses not inventoried or not transferable

• Open source usage without license and security review

• Cybersecurity controls immature or undocumented

• Product roadmap disconnected from technical reality

• Material technology capex missing from the business plan

Not every red flag is a deal breaker.

But every red flag should become a deal question.

Should the buyer adjust valuation?

Should the SPA include specific representations and warranties?

Should there be a holdback or remediation covenant?

Should closing conditions be added?

Should Day 1 or Day 100 technology stabilization be required?

Should integration cost assumptions be increased?

A practical Tech IT Due Diligence playbook

Phase 1: Deal thesis alignment

• Clarify the role of technology in the investment case

• Identify value drivers and risk drivers

• Define diligence scope and priority questions

• Align with commercial, financial, legal, tax, and operational diligence

Phase 2: Technology baseline

• Build the IT application inventory

• Separate ERP and non ERP landscape

• Map infrastructure, cloud, workplace, network, and security setup

• Review product architecture, data flows, and interfaces

• Assess software licenses, SaaS contracts, and open source components

• Identify critical systems, vendors, and dependencies

Phase 3: Red flag analysis

• Identify risks affecting valuation, timing, integration, or deal structure

• Quantify remediation cost where possible

• Separate critical risks from normal improvement topics

• Validate findings with data room evidence and management interviews

Phase 4: Deal implications

• Translate findings into valuation impact

• Define Day 1 and Day 100 priorities

• Identify SPA implications

• Estimate post closing investment needs

• Define TSA or integration requirements where relevant

Phase 5: Value creation roadmap

• Build the first 100 to 180 day technology roadmap

• Prioritize cyber remediation, ERP stabilization, application rationalization, and infrastructure resilience

• Assign owners, budgets, milestones, and governance

• Move from diligence findings to execution

Success story: Confidential payment service provider and POS M&A initiative

Wang Advisory supported a confidential payment service provider in Germany as external consultant. The mandate focused on enhancing product strategy across the payments and checkout ecosystem and leading a confidential M&A initiative in POS systems, including commercial and Tech IT Due Diligence.

Key contributions included:

• Enhanced product strategy across payments, checkout, and POS related capabilities

• Supported strategic assessment of the payment and POS ecosystem

• Led a confidential M&A initiative in POS systems

• Combined commercial and technology due diligence perspectives

• Assessed strategic fit, product logic, application landscape, infrastructure, cyber, license, and integration implications

• Identified potential transaction risks and value creation opportunities

• Translated commercial and technology findings into executive decision support

The case illustrates an important lesson. In payment and POS transactions, technology due diligence cannot be separated from commercial logic. Product strategy, platform architecture, transaction flows, regulatory readiness, vendor dependencies, customer experience, and post closing scalability must be assessed together.

Sector specific focus: Payments, POS, and regulated technology

In payment, POS, checkout, fintech, and financial services transactions, Tech IT Due Diligence requires additional depth.

The diligence should cover:

• PCI DSS readiness and card data environment scope

• Payment transaction flows

• POS architecture and device dependencies

• Acquirer, issuer, gateway, processor, and PSP integration logic

• Fraud prevention and risk monitoring

• Settlement, reconciliation, and reporting processes

• Data privacy and customer consent

• Operational resilience and incident response

• Third party ICT service providers

• Regulatory requirements such as the EU Digital Operational Resilience Act where applicable

PCI DSS v4.0.1 was published in June 2024, and the PCI Security Standards Council stated that the 31 March 2025 effective date for the new requirements was not changed by this revision. [10]

The EU Digital Operational Resilience Act, DORA, entered into application on 17 January 2025 and strengthens digital operational resilience requirements for banks, insurance companies, investment firms, and other financial entities in the EU. [11]

Typical red flags in payment and POS transactions:

• Unclear PCI DSS scope

• Cardholder data stored or transmitted outside controlled environments

• Weak POS device management

• Poor reconciliation between POS, payment processor, ERP, and finance systems

• High dependency on one payment provider or one acquirer

• No clear fraud monitoring process

• Weak incident response for payment outages

• Vendor contracts without transferability or resilience clauses

• Regulatory obligations not embedded in technology governance

Deal implication: In payments, technology failure is business failure. Platform resilience, security, compliance, and transaction integrity are directly linked to revenue continuity and customer trust.

Wang Advisory positioning

Wang Advisory supports clients across Tech IT Due Diligence, M&A, carve outs, Post Merger Integration, IT separation, digital transformation, PMO, and value creation.

Our approach combines:

• Senior M&A and technology transformation experience

• AI supported research and analytics

• Structured red flag assessment

• ERP, non ERP, infrastructure, license, cyber, and data diligence

• Clear translation of technology risks into deal implications

• Practical Day 1 and Day 100 execution planning

• Lean expert delivery without a large consulting pyramid

The objective is simple.

Identify the risks before closing.

Quantify the implications before signing. Build the execution roadmap before value is lost.

The leadership message

Tech IT Due Diligence is not about checking whether IT works today. It is about understanding whether technology can support the future value creation plan. The right question is not: Is the platform good enough for today? The better question is: Can this technology, application landscape, ERP setup, infrastructure, cyber posture, license base, data model, and team deliver the deal thesis after closing?

Wang Advisory - Tech IT Due Diligence Insights June 2026 v1.0.pdf

Download PDF • 563KB

Sources

[1] Bain & Company, Tech Due Diligence, n.d., accessed 19 June 2026.

[2] BCG Platinion, Navigating Pitfalls in Financial Institution Acquisitions, published 26 February 2024.

[3] Deloitte Germany, Software Due Diligence, n.d., accessed 19 June 2026.

[4] National Institute of Standards and Technology, The NIST Cybersecurity Framework CSF 2.0, published 26 February 2024.

[5] National Institute of Standards and Technology, Secure Software Development Framework SSDF Version 1.1, published February 2022.

[6] Google Cloud, Announcing the 2024 DORA Report, published 22 October 2024.

[7] OWASP Foundation, OWASP Top Ten Web Application Security Risks, current released version OWASP Top Ten 2025, accessed 19 June 2026.

[8] IBM, Cost of a Data Breach Report 2025, 2025, accessed 19 June 2026.

[9] Reuters, Why automated open source scans do not guarantee license compliance, published 18 June 2026.

[10] PCI Security Standards Council, Just Published: PCI DSS v4.0.1, published 11 June 2024.

[11] European Insurance and Occupational Pensions Authority, Digital Operational Resilience Act, n.d., accessed 19 June 2026.

[12] Wang Advisory internal project reference, confidential payment service provider and POS M&A initiative.