⚠️ STAGING — aeolus-agency-staging.pages.dev — Not the live site
Services Marketplace About Insights Contact Start the conversation
M&A ADVISORY

What IT Due Diligence Actually Finds in Your Stack

April 1, 2026 · Van Murray

I've been through eleven transactions. Buyer side, seller side, operator during integration. And the thing I've learned is that most sellers don't know what IT due diligence actually looks for — because their banker doesn't know either.

Here's what a serious acquirer's team is looking for when they open your hood.

They're looking for undocumented dependencies.

Your ERP works. Fine. But does anyone know exactly what it's connected to? How many manual exports happen weekly because two systems don't actually talk to each other? What breaks if you move one vendor? Acquirers aren't just evaluating your technology — they're evaluating how much invisible work holds it together. Invisible work is a liability that doesn't appear on the balance sheet.

They're looking at your vendor contracts.

Specifically: what doesn't survive a change of control. A surprising number of SaaS agreements have change-of-control clauses that trigger renegotiation or termination upon acquisition. I've seen deals where the target's critical software licenses weren't transferable. That's not discovered in the letter of intent stage. That's discovered at 11pm during due diligence. Get your contracts read by someone who knows what to look for before the process starts.

They're looking at your security posture — not to check a box, but to price the risk.

If you don't have MFA enforced across the organization, that's a remediation cost. If your email domain isn't protected (DMARC/DKIM/SPF), that's a liability. If you've never done a vulnerability assessment, the buyer will assume the worst and price accordingly. Security gaps don't kill deals — they adjust valuations. Sometimes by a lot.

They're looking at the IT team.

Who knows how everything works? Is that knowledge documented, or does it live in one person's head? If the lead IT person leaves on day 60 post-close — which happens — can the acquirer's team run the operation? Team dependency is an integration risk. Acquirers model it.

What the banker won't tell you.

Investment bankers are good at what they do. They're not technology operators. When your banker says "the IT stuff is fine" during prep, what they mean is they didn't see anything obvious. That's not the same as being ready for a technical due diligence team that will spend two weeks in your systems.

The questions you want answered before the process starts: What are your critical systems and what do they depend on? Which vendor contracts have change-of-control provisions? What's your actual security posture against a basic framework? What does your IT documentation look like — and would a competent outsider be able to run this business using it?

I've been on the buyer side of this enough times to know what kills momentum. And I've been on the seller side enough to know that preparation changes outcomes. Not just the probability of closing — the valuation.

Get someone who's been in that room to walk through your stack before you hire the banker. Not after.

← All Insights | Talk to Van about M&A IT →

Going through a transaction?

Eleven transactions. Both sides of the table. Let's talk about where you are in the process.

Start the conversation