Financial due diligence has a playbook. Legal due diligence has a playbook.

IT due diligence, in mid-market deals, does not.

That is why it is the most consistently underexecuted piece of work in the acquisition process. Buyers close the deal, sign the wire, and then discover a technology environment that will not support the model they paid for. Or worse, one that carries compliance obligations, security exposure, and integration costs that nobody priced into the transaction.

After 40 years in technology and hundreds of environments reviewed, the pattern is the same. The IT review is treated as a formality, an equipment inventory, or a task the seller’s own IT team runs on itself. Then the real cost shows up in the twelve months after close.

This guide sets the standard. It walks through what IT due diligence actually is, why it gets skipped, the six domains it must cover, and how findings translate into real deal terms. If you are a private equity deal team, a strategic acquirer, an M&A advisor, or a CFO or COO looking at your first or second acquisition, this is the framework.

What IT Due Diligence Actually Is

IT due diligence is a risk assessment tied to valuation.

It is not a hardware inventory. It is not the seller telling you what they have. It is an independent review of the technology environment that answers three questions for the buyer.

Does the target’s infrastructure actually support the business the way the deal thesis assumes it does. Is there hidden liability in the environment that will transfer at close. Will the integration cost what the financial model says it will.

Six domains define the scope. Infrastructure health. Security posture. Compliance obligations. Documentation quality. Vendor and software contracts. Integration complexity. Each one carries direct financial consequences that show up in negotiation, in escrow, or in the twelve months after close.

Good IT due diligence produces a written deliverable. Not a verbal summary in a deal committee meeting. A document the buyer, the seller, and the lawyers can point to when the terms are being shaped.

Why It Gets Skipped and What That Costs

The reasons are consistent across deals.

Speed. Mid-market transactions move fast. The exclusivity window is 60 to 90 days. Legal and financial teams take priority. IT gets a two-page questionnaire and a phone call.

No IT advisor on the deal team. Financial advisors, lawyers, and quality of earnings providers show up on every deal. An independent IT expert rarely does. If nobody on the deal team can read a network diagram, nobody asks the right questions.

The seller’s IT team evaluates itself. This happens more often than buyers realize. The internal IT manager or the seller’s incumbent MSP fills out the buyer’s questionnaire and provides the answers. That is not diligence. That is a self-assessment by the party with the most incentive to present the environment favorably.

No standard playbook. Financial due diligence follows GAAP. Legal follows established templates. IT diligence in mid-market deals varies wildly by advisor, by industry, and by the buyer’s own maturity.

The cost of skipping shows up in four places.

Undisclosed IT debt. The target ran on infrastructure that was fine for the current business but cannot support the growth model the buyer paid for. Servers past end of life. Storage at capacity. Bandwidth that will not scale. The buyer inherits a capital plan nobody mentioned.

Compliance obligations that transfer. The target had client contracts that carried HIPAA, PCI, SOC 2, or CMMC obligations. Those requirements move with the customer relationship. If the target was not actually compliant, the buyer just bought the exposure.

Security incidents post-close. Attackers watch M&A activity. Announced transactions increase the target’s threat exposure in the 90 days after close. If the security posture is weak and nobody knew it, the first breach happens under the new owner’s name.

Integration surprises. The financial model assumed a 90-day integration at a specific cost. The reality is 18 months and three times the budget because nobody assessed what integration actually required.

None of this is theoretical. Each of these costs is a line item that shows up in almost every deal where IT diligence was rushed or skipped.

The Six Domains IT Due Diligence Must Cover

Infrastructure

The physical and logical foundation of the business. Servers, endpoints, networking equipment, storage, cloud footprint, and the documentation that describes how it all connects.

Age matters. Warranty status matters. Capacity utilization matters. A server room running at 85% capacity with three servers past end of life is a capital expenditure problem the buyer will own.

Documentation is where reality diverges from the seller’s story. Ask for network diagrams, asset inventories, backup schedules, and disaster recovery procedures. If the documentation is thin, out of date, or held in one person’s head, the buyer is inheriting operational risk that will surface the moment that person leaves.

Cloud footprint deserves specific attention. Which workloads are on AWS, Azure, GCP, or private cloud. What is the monthly spend. Are there reserved instances the buyer inherits. Is there shadow IT running on personal accounts.

Security Posture

Current controls, patch status, incident history, and access management.

Start with the basics. Is multi-factor authentication enforced across all systems. What is the endpoint detection and response stack. When was the last vulnerability scan. When was the last penetration test. What did those tests find and what got remediated.

Patch status tells the truth about operational discipline. If servers are running unsupported operating systems, if endpoints are two years behind on patches, if the firewall firmware has not been updated since installation, that pattern extends to every other operational control.

Incident history is often the hardest thing to extract. Sellers do not volunteer breach data. The right questions are direct. Has the target experienced a ransomware event, a data breach, a business email compromise, or any incident that triggered a legal or regulatory notification requirement in the past 36 months. If yes, what was the remediation and what obligations remain.

Access controls close the security domain. Who has administrative access to what systems. Are there former employees with active accounts. Are service accounts documented and rotated. Is privileged access managed or is everyone a local admin on their own machine. A proper cybersecurity assessment surfaces every one of these questions with evidence, not attestations.

Compliance Obligations

This domain is where the most expensive surprises live.

Compliance obligations flow from customer contracts. If the target sells services to healthcare organizations, HIPAA obligations attach. If it processes payment card data, PCI attaches. If it holds federal contracts touching Controlled Unclassified Information, NIST 800-171 and CMMC attach. If it provides services to publicly traded companies or financial institutions, SOC 2 is often contractually required.

Two questions matter for each obligation. Was the target actually compliant. Does the obligation transfer at close.

Actual compliance is different from claimed compliance. A SOC 2 report from three years ago is not evidence of current compliance. A HIPAA policy document with nobody trained on it is not compliance. CMMC self-attestations that were never independently validated are not compliance under the new certification regime.

Transfer is the second question. Most customer contracts include change of control provisions. Some require customer consent to assignment. Some allow the customer to terminate. If the target’s revenue depends on relationships that require compliance certifications the buyer cannot maintain, that is a revenue transfer risk, not just a compliance issue.

Software Licensing

Are the licenses legitimate, transferable, and current.

Software audits are the sleeper liability in acquisitions. Microsoft, Oracle, Adobe, Autodesk, and other major vendors have audit clauses in their enterprise agreements. If the target underlicensed, the true-up bill lands on the new owner. Six and seven figure retroactive license claims happen.

Transferability is the second issue. Many enterprise agreements do not transfer with a change of control without vendor consent. Some require repurchase. Some cannot be transferred at all. If the deal thesis assumed the buyer inherits the target’s Microsoft E5 pricing, but the agreement terminates at close, that is a real cost.

Currency is the third. Are maintenance contracts active. Are subscriptions paid. Are open source components in use that carry copyleft obligations the target never addressed.

Vendor and MSP Contracts

Terms, auto-renewal clauses, change of control provisions, and termination rights.

Every contract with an external technology provider becomes the buyer’s problem. Read the fine print. Auto-renewal clauses can lock the buyer into another 36 months of an incumbent MSP the buyer would rather replace. Change of control provisions can trigger renegotiation at exactly the moment the buyer has least leverage.

Termination rights are the practical concern. If the buyer plans to consolidate onto its own IT stack, what does it cost to exit the target’s contracts. Is there an early termination penalty. Is there a data extraction cost.

The MSP contract deserves the most attention because that is often the single largest ongoing technology commitment the target carries. Review the SLA. Review what is included versus billed separately. Review the transition assistance clause. Review whether the incumbent MSP will actually cooperate in a transition or whether they will slow-walk everything to protect the account.

Integration Complexity

The final domain and the one most tied to the financial model.

Integration is expensive. The buyer either integrates the target’s IT into its own environment, runs it as a standalone platform, or does some combination. Each choice has a cost, a timeline, and a risk profile.

Full integration means migrating identities, email, file storage, applications, and endpoints into the buyer’s stack. For a 100 employee target, plan on 6 to 12 months of active integration work and a budget that ranges from $150,000 to $500,000 depending on complexity, application count, and how much custom development the target carries.

Standalone operation is cheaper in the short term but creates permanent duplication. Two IT teams. Two support contracts. Two security stacks. Two compliance programs. That duplication carries an ongoing operational premium that must be reflected in the pro forma.

Hybrid approaches are common and are where cost estimation goes wrong most often. Keeping the target’s ERP but migrating everyone to the buyer’s email and identity system is a specific technical project with specific costs. Estimate it in the diligence phase, not after close.

What Good IT Due Diligence Produces

A written deliverable. Not a phone call. Not a summary slide.

The document should contain six components at minimum.

Infrastructure inventory. Every server, endpoint, network device, and cloud workload. Age, warranty status, and replacement priority.

Security gap assessment. Current controls mapped against a standard framework such as CIS Controls or NIST Cybersecurity Framework. Gaps identified with severity and remediation cost.

Compliance obligation map. Every regulatory or contractual compliance requirement the target carries, whether the target is currently compliant, and the estimated cost to close any gaps.

Vendor and license review. Every material contract summarized with term, renewal date, change of control provision, transferability, and estimated exit cost.

Integration complexity estimate. A specific dollar range and timeline for the integration approach the buyer intends to take, with the assumptions that drive the estimate documented.

Risk-ranked findings. Every finding ranked by financial impact and likelihood, with recommended deal term implications for each.

That final section is the one the deal team actually uses. It translates technical findings into the language of price, escrow, indemnification, and remediation timelines.

For the operational version of this document, the full IT due diligence checklist breaks each domain into specific request items and evidence standards.

How IT Findings Affect Deal Terms

This is where the CFOs and PE principals pay attention.

IT due diligence findings translate into five concrete negotiation levers.

Price adjustment. If the environment requires $400,000 of near-term capital expenditure to remain operational, that number comes off the purchase price or gets funded through a seller credit at close. This happens most often with infrastructure past end of life, storage at capacity, or licensing shortfalls the seller failed to disclose.

Escrow holdback. Compliance findings often move into escrow rather than price adjustment. If the target’s SOC 2 report is stale and remediation is 90 days out, an escrow of 12 to 24 months at 5 to 10 percent of purchase price protects the buyer against post-close claims from customers or auditors.

Seller indemnification. Undisclosed incidents get carved out into specific indemnification provisions with extended survival periods. Standard reps and warranties expire in 12 to 24 months. A specific indemnification for a known compliance exposure or a known undisclosed breach can survive for 6 years or longer, matching the statute of limitations for the underlying claim.

Remediation timeline requirements. Some findings get resolved between signing and close. The seller commits to specific remediation actions, with proof of completion required as a closing condition. This is common when the target is out of compliance with a required certification and the buyer wants the risk resolved before the wire hits.

Deal-stopper. Some findings kill the deal. Undisclosed breaches with active regulatory investigations. Compliance failures that would trigger customer termination on assignment. Licensing shortfalls large enough to eliminate the return on the deal. Ransomware history the target concealed. These are rare, but every practitioner has seen them.

The specific translation from finding to deal term depends on the transaction structure, the size of the deal, and the parties involved. What matters is that the findings arrive early enough to be negotiated, in writing, with financial impact quantified.

The Three Most Common IT Liabilities Found in Mid-Market Acquisitions

Three patterns show up across almost every transaction where diligence was thorough.

Undocumented systems. The target has a critical application, database, or automation running on a server that nobody remembers commissioning, maintained by a former employee, with no documentation. The system works. Nobody knows how. When it breaks, the recovery cost is measured in weeks of business disruption, not hours. This finding is nearly universal in mid-market businesses that grew organically without a mature IT function.

End of life infrastructure hidden in fixed assets. The balance sheet shows $600,000 in IT equipment. The reality is that half of it is past manufacturer support, running unsupported firmware, and one hardware failure away from an unrecoverable outage. Sellers do not write down IT equipment aggressively. Buyers inherit book value that does not match operational reality. A proper inventory with age and support status usually reveals a capital replacement obligation the buyer had not modeled. The hidden IT liabilities in small-cap acquisitions article expands on this pattern in detail.

Compliance obligations tied to the target’s client base that nobody mapped. The target sells services to hospitals, financial institutions, defense contractors, or retailers. The client contracts contain compliance flow-down clauses that most parties in the deal never read. The target has been technically noncompliant for years, and the clients have not audited. On change of control, some of those clients will audit. Some will terminate. Some will demand remediation on impossible timelines. This is the single largest source of post-close revenue attrition in acquisitions where IT and compliance diligence was thin.

Post-Close IT Integration Why Due Diligence and Integration Are Connected

Integration is the downstream consequence of diligence quality.

Companies that do thorough IT diligence integrate faster and cheaper. They know the environment they are inheriting. They have already priced the work. They have a plan that survives contact with reality because the reality was documented before close.

Companies that skip IT diligence pay for it during integration. Every finding that should have surfaced in diligence surfaces during integration instead, at the exact moment the buyer is trying to consolidate operations, keep the target’s employees, and reassure the target’s customers. The cost of a finding discovered during integration is typically 3 to 5 times the cost of the same finding addressed pre-close, because the buyer has already committed to the transaction and has less leverage to remediate.

Integration timelines that come in on budget almost always trace back to a diligence phase that was rigorous. Integration timelines that blow out almost always trace back to diligence that was rushed.

The connection is direct. Fund the diligence, save on the integration. The post-acquisition IT integration playbook walks through the operational steps that turn a good diligence deliverable into a successful integration.

When to Bring in an Outside IT Advisor

Practical thresholds, not a sales pitch.

Bring in an outside IT advisor on any deal that meets one of these criteria.

Deal size above $5 million where the buyer does not have an in-house IT infrastructure expert. The cost of a proper diligence engagement is a small fraction of the exposure it uncovers. On a $10 million deal, a $20,000 to $40,000 diligence engagement that uncovers a $200,000 infrastructure obligation pays for itself many times over.

Target company in a regulated industry. Healthcare, financial services, defense contracting, and any industry with CMMC, HIPAA, PCI, SOC 2, or state-level data privacy obligations. The compliance domain of IT diligence is specialized enough that a general operations advisor will miss things a compliance-experienced IT advisor catches immediately.

Any deal where the target’s IT team will be evaluating itself. This is disqualifying without an outside advisor. Not because the internal team is dishonest, but because the internal team lacks the perspective to identify what should be in a diligence deliverable versus what feels normal to them.

Below those thresholds, an experienced in-house team or a strong QoE provider with IT depth can carry the work. Above those thresholds, an independent advisor is the right call.

What to Expect from an IT Due Diligence Engagement

Scope, timeline, access, and deliverables.

Scope. All six domains covered above. Infrastructure, security, compliance, licensing, vendor contracts, integration complexity. Anything less is not a real diligence engagement.

Timeline. For a 50 to 200 employee target, plan on 2 to 4 weeks of active work. Week 1 is document request and initial review. Weeks 2 and 3 are technical assessment, interviews, and evidence gathering. Week 4 is analysis, findings documentation, and deliverable production. Complex environments or heavily regulated industries can extend to 5 to 6 weeks.

Access. The advisor needs read-only access to network monitoring tools, security consoles, licensing dashboards, and cloud management consoles. Interviews with the target’s IT lead, security lead, and compliance owner if separate. Access to contracts, incident reports, audit findings, and any prior IT assessments. If the target refuses access to any of these, that itself is a finding.

Deliverables. The written diligence deliverable described above, plus an executive briefing for the deal team, plus a follow-up call with the buyer’s counsel to translate findings into specific transaction language. The advisor should be available through signing and close to support the negotiation.

Presentation. Findings are presented to the full deal team, ranked by financial impact, with specific recommended deal term implications. Not a technical report handed to the CFO with no interpretation. A business document that the deal team can act on.

Ready to Have This Conversation

Strix Technology Group has run IT due diligence engagements across multiple acquisitions for strategic buyers, from lower middle market platform deals to add-on acquisitions in regulated industries. The framework in this article is the framework we use.

If you have a deal in your pipeline and you want to know whether the technology environment supports the deal thesis, whether there is hidden liability, and whether the integration will actually cost what your model says, here is how to start.

Contact us with the deal size, target industry, and expected timeline. We will scope the engagement and be in the diligence phase within a week.