An acquisition can look financially sound while its M&A transaction assumptions overlook inherited technology costs. IT due diligence examines the target’s systems, security, software, suppliers and operating capability before those commitments become yours.
The review should identify what could interrupt trading, restrict growth or increase integration costs, then connect each finding to a decision. Start with the acquisition plan, because technology that supports the target today may not support the combined business.
Key Takeaways
- IT due diligence assesses whether the target’s technology can support the acquisition’s commercial assumptions and identifies what the buyer will inherit, need to invest in and integrate.
- Review systems, software, cyber security, data protection, infrastructure, recovery, suppliers, contracts, staffing and operating costs against the deal plan.
- Base findings on evidence and record each issue’s business impact, supporting evidence, owner, proposed treatment and estimated cost.
- Resolve material issues before signing where access permits. Carry any remaining uncertainty and remediation work into the acquisition terms, budget and integration plan.
Establish what IT due diligence must answer
IT due diligence assesses whether the target’s technology can support the acquisition’s commercial assumptions. It should establish what the buyer will inherit, what needs investment and which dependencies could prevent the planned integration. A reliable inventory helps, but it doesn’t establish whether systems are secure, recoverable or suitable for expansion.
Separate the overlapping workstreams:
- IT due diligence examines infrastructure, applications, support, suppliers and operating costs.
- Technical due diligence examines software architecture, code quality, development practices and product scalability.
- Cyber due diligence examines exposure, access controls, incident handling and security operations.
For a software business, architecture and intellectual property may dominate. For a professional services acquisition, identity, Microsoft 365, document access and business continuity may matter more.
Base IT due diligence questions on the deal’s commercial assumptions. Cover expected user growth, international operations, planned integrations, data pipelines that support these plans and assumed cost savings.
Assign owners and sequence the review
Appoint a deal sponsor who can resolve commercial questions and a technical lead who can challenge the evidence. Involve legal, finance, security and operational owners where findings affect contracts, forecasts or continuity. Specialist advisers can provide independent scrutiny, but management still owns the acquisition decision.
Use a sequence that follows dependencies rather than treating each assessment as an isolated exercise:
- Define the IT due diligence scope, material systems, business assumptions and access arrangements.
- Request evidence through a controlled data room against the agreed scope and deal assumptions, with named owners for missing information.
- Review architecture and software components, then commission appropriate code analysis.
- Assess cyber security, data management, infrastructure and recovery capability.
- Review contracts, staffing, operating costs and integration dependencies.
- Produce a prioritised report with commercial implications, remediation owners and estimated effort.
Request architecture diagrams, asset registers, supplier contracts, security reports, recovery records and annual expenditure early. Missing evidence should remain an explicit limitation, rather than becoming an assumption that controls exist.
Resolve material issues before signing where access permits. If an assessment must wait, document the uncertainty and its proposed treatment with the deal team.
Review software architecture and code
Examine design before relying on scan results
During technical due diligence, review the software architecture. Check how applications exchange data, authenticate users, separate customers and handle increased demand. Establish which systems depend on unsupported frameworks, undocumented interfaces or manual intervention.
Code scanning can identify security vulnerabilities and code quality issues, but it can’t establish whether the architecture supports the acquisition plan. Ask developers to explain deployment, testing, rollback and the effort required for planned changes.
Technical debt is future work created by expedient implementation choices or deferred improvements. Record the affected components and business consequences. A backlog count alone doesn’t show whether delivery is constrained.
Request an SBOM and establish ownership
A software bill of materials, or SBOM, inventories open source components and their dependencies. It’s a starting point for identifying third-party licences and known vulnerabilities, not proof that every component is acceptable. Black Duck’s explanation of an SBOM describes its role in documenting open-source and third-party components.
Compare the inventory with deployed versions, dependency records and supplier information. Review open source licence obligations with legal advisers, including distribution conditions and restrictions relevant to the intended use.
Establish who owns custom code and whether employee, contractor and supplier agreements support that ownership.
Assess infrastructure, cloud and recovery
Request IT infrastructure inventories, including servers and hardware, network topology, cloud architecture, administration procedures and annual IT spend. Reconcile recorded IT infrastructure assets with management tools, invoices and support arrangements.
Technical due diligence should examine cloud ownership, privileged access, resource configuration, billing commitments, capacity and recovery evidence. Separate current expenditure from costs that will change when contracts end or workloads move.
Recovery evidence needs particular attention. Compare business recovery requirements with recorded restore tests, backup coverage and dependencies such as identity, connectivity and encryption keys. A successful file restore doesn’t demonstrate recovery of an entire application.
Microsoft 365 also needs its own review. Tenant configuration, licences, permissions and retention settings can affect both security and migration effort. Our Office 365 assessment guide describes the relevant review areas.
Where tenant consolidation is planned, involve Microsoft 365 migration support before agreeing dates. Existing email, Teams and SharePoint arrangements influence the work required.
Examine cyber security and data protection
Assess controls through evidence
Use cyber due diligence to assess controls against evidence. Request privileged-account records, multi-factor authentication coverage, endpoint protection reports, patching evidence, penetration-test findings and incident response procedures. Identify unresolved security vulnerabilities and record who accepted each risk.
Legal Edge reports that Intechnica found security issues in 1 in 5 businesses across more than 250 engagements in its technology due diligence overview. This finding from those engagements should not be treated as an industry-wide prevalence estimate.
Assess authentication methods as well as coverage. The NCSC’s corporate MFA guidance recommends stronger protection against phishing. An enabled setting doesn’t prove that every privileged access route is protected.
Review incidents and data obligations
Map personal data, processing purposes, processor relationships, retention and international transfers. Review compliance with UK GDPR and other applicable data protection laws, contractual obligations and relevant industry standards.
Examine breach history, investigation records and completed corrective actions. The ICO’s personal data breach guidance says reportable breaches require notification without undue delay and, where feasible, within 72 hours of awareness.
Establish who monitors alerts and who can contain an incident. Our managed SOC services can support monitoring and investigation, but the acquisition review must still identify coverage gaps and escalation responsibilities.
Review suppliers, people and data readiness
Examine contracts and operating commitments
Review SaaS subscriptions, third-party licences, service-level agreements, renewal dates, termination rights and change-of-control provisions. Identify contracts that require consent, restrict transfer or impose exit costs.
Reconcile purchased licences with actual use. Separate recurring operating expenditure, committed spending and outstanding projects so that proposed savings are not counted before they are achievable.
Review planned software contracts as well as current agreements. A purchase agreed shortly before completion can create a commitment that is absent from the latest accounts or supplier register.
Document the supplier’s role in recovery and migration. A service-level agreement may cover availability without providing the assistance needed to exit.
Assess delivery capability and data dependencies
Review skill diversification, process maturity, documentation and key person dependencies. Establish whether a CTO or another senior technical leader owns architecture, investment priorities and technical risk.
Ask who can deploy software, restore systems and administer critical platforms when the usual owner is unavailable. A capable individual does not replace repeatable procedures or shared access to operational knowledge.
For data pipelines, check source data, access permissions and processing rights. For AI services that support the business plan, document model dependencies, operating costs and human oversight.
For Microsoft Copilot or other assistants, existing permissions deserve attention. Introducing an AI tool doesn’t correct excessive access to the underlying information.
Turn red flags into deal decisions
IT due diligence uses evidence to prioritise findings that could affect the acquisition decision, valuation, terms or integration timetable. Each finding needs supporting evidence, a business consequence, a responsible owner and a proposed treatment. Technical severity alone is insufficient: an issue affecting a critical revenue system deserves different treatment from the same weakness in an unused application.
Use a rating scheme agreed with the deal team.
| Priority | Decision test | Proposed treatment |
|---|---|---|
| Critical | Could prevent lawful or safe operation | Resolve before completion or reconsider proceeding |
| High | Material exposure or integration dependency | Agree funded remediation and contractual treatment |
| Medium | Manageable within the operating plan | Assign an owner, budget and completion date |
| Low | Limited immediate business impact | Include in routine improvement work |
The rating should reflect business impact and available evidence, not simply a scanner’s score.
Estimate remediation costs using supplier quotations, internal effort, dependencies and delivery capacity. Separate one-off implementation costs from recurring support, licensing and hosting costs. Record assumptions and confidence alongside each estimate.
For Microsoft 365 consolidation, licence savings may depend on completing migration and ending overlapping commitments. Model the overlap before including savings in the acquisition forecast.
Discuss price adjustments, seller remediation, warranties, indemnities or retention arrangements with legal and financial advisers. These mechanisms allocate exposure; they don’t repair systems.
Build integration into the acquisition plan
Define what must work on completion day before planning wider post-merger integration. Identity, payroll, finance, communications, security monitoring and support need accountable owners.
Separate immediate control changes from platform migrations. Combining networks or identity environments before understanding access and security can expose the buyer to inherited weaknesses.
Build an integration register covering dependencies, downtime, data pipelines, supplier consent and rollback. Our M&A technology integration plan provides a practical structure for post-close work.
For international acquisitions, establish support hours, escalation routes and local responsibilities through global IT support. A combined service desk still needs clear authority over accounts, devices and suppliers.
Carry unresolved IT due diligence findings into an owned remediation programme. Report integration problems against their operational and financial effects, not just technical completion.
Frequently Asked Questions
What is IT due diligence?
IT due diligence assesses whether a target’s technology can support the acquisition’s commercial assumptions. It identifies inherited systems, costs, investment needs and dependencies that could affect the deal or integration.
How does IT due diligence differ from technical and cyber due diligence?
IT due diligence examines infrastructure, applications, support, suppliers and operating costs. Technical due diligence focuses on software architecture, code and development practices, while cyber due diligence assesses security exposure, access controls, incident handling and security operations.
What evidence should a buyer request?
Request architecture diagrams, asset registers, supplier contracts, security reports, recovery records and annual IT expenditure. The review may also need software component inventories, access records, penetration-test findings and incident records.
How should a buyer handle material findings?
Record the evidence, business consequence, responsible owner and proposed treatment for each finding, then estimate remediation costs and delivery effort. Resolve material issues before signing where possible, and document any remaining uncertainty and its treatment with the deal team.
Make the offer reflect the technology commitments
IT due diligence is useful when evidence informs a decision, the offer’s valuation, budget or contractual commitments. A report without funded actions leaves the buyer carrying the same unresolved exposure.
Agree what must happen before completion and what the combined business can deliver afterwards. Keep ownership explicit.
Speak to our team about IT consulting and integration planning to connect infrastructure, security and supplier findings with a practical acquisition plan.
