Inside the Room: What Acquirers Actually Check in Technical Due Diligence

Last updated: September 14, 2026

By Kris Drouet, Engineering Executive, in partnership with KORE1

Day two of management presentations, a little after lunch, and the diligence lead asked a question I have heard in some form on every deal I have worked from the buy side.

“How often do you deploy to production?”

The VP of engineering at the target, a lending software company with around sixty engineers, said daily. He said it with confidence. He believed it.

The reviewer next to me had the CI export open. Eleven production deploys in the previous quarter. Not daily. Not really weekly either.

Nobody was lying. I want to be clear about that, because the seller’s team assumed afterward that we thought they had been. In that VP’s head, a deploy meant a merge to main, and main got merged daily. Production ran off a release branch with a change-approval meeting every Tuesday, which is a perfectly defensible way to run a regulated lending platform. Had he said that, the whole exchange would have taken ninety seconds.

What he said instead cost his company about two weeks. Once one answer in the room contradicts the evidence, a diligence team stops taking answers and starts checking all of them. Every claim in the deck got re-verified against raw exports. The scope memo grew a section. The deal still closed, with a retention condition on two engineers and a longer escrow than the seller’s banker wanted, and I would not swear the deploy answer caused either one. I would not swear it didn’t.

That is the room. The checklist gets you into it. It does not get you out.

I have spent a lot of hours on the buy side of this, reading someone else’s system on a four-week clock. KORE1 staffs exactly that kind of work, placing the architects, security engineers, and platform people who make up a technical due diligence engineering bench for deal teams, and I write with them, so there is a firm behind this byline with a commercial interest in diligence happening at all. This piece is for the other chair anyway. The leader whose company is about to be read.

The Six Rows Everyone Lists, and the Weighting Nobody Publishes

Technical due diligence is the acquirer’s structured review of a target company’s software, infrastructure, security posture, and engineering organization, usually run between a signed letter of intent (LOI) and close. Its job is to confirm the technology can carry the deal thesis and to put a price on the risks it cannot.

Every published checklist has roughly the same rows. Mine does too. What those lists leave out is that the rows do not carry equal weight, and a seller who spends a month polishing the wrong one arrives exhausted and still exposed. Here is how the six compare from the reviewer’s chair. The last column is my own read across the deals I have worked on, not a survey, so treat it as one practitioner’s calibration.

People sits at the bottom of that table and at the top of the risk. More on that below.

Code health surprises sellers in the other direction. Founders lose sleep over it. Needlessly, mostly. It almost never moves a number by itself, because every acquirer already assumes your code carries debt. Theirs does too. A reviewer who finds a 400-line controller and a test suite with patchy coverage writes it down, estimates it, and moves on. What they cannot move on from is debt nobody at the company can describe. If yours does not have a name and a cost attached yet, the argument in why “tech debt” is the wrong frame for executives is where I would start, because a named and costed problem reads as management, and an unnamed one reads as a surprise waiting for a reviewer to find it.

What the Buyer Reads Before You Walk In

By the time anyone schedules an interview with you, the diligence team has usually spent a week with your documents. Sometimes two. The request list varies by buyer, but on a mid-market software deal it tends to include the following, rarely in this order.

• Architecture diagrams and a service inventory. Current ones. Reviewers can date a diagram by which services are missing from it.
• Read-only repository access, or, when the buyer competes with you, an automated scan run by a third party so nobody on the buy side reads proprietary code directly.
• A dependency and license report, ideally as a software bill of materials, whether you produce it or their scanner does.
• The last penetration test, plus whatever happened to its findings afterward.
• Your SOC 2 report if you have one. If you do not, a long questionnaire shows up in its place.
• Twelve to twenty-four months of incident history. All of it, not just the postmortems you were proud of.
• Deploy and change history exported from the tools rather than summarized on a slide.
• Twelve months of cloud invoices and every material vendor contract.
• An org chart with tenure, plus a list of contractors and their IP assignment agreements, which is the item sellers most often cannot produce on the first ask.
• The product roadmap you showed the buyer’s deal team.

That last one matters more than engineers expect. The roadmap is the thesis. Half of what a technical reviewer does is hold the roadmap slide in one hand and the codebase in the other and ask whether the second can produce the first on the timeline the model assumes.

Scanning has also gotten far better at the part sellers used to get away with. Black Duck’s 2026 Open Source Security and Risk Analysis, built on 947 audited codebases across 17 industries, found license conflicts in 68% of them, up from 56% the year before and the largest single-year jump the report has recorded. Open source turned up in 98% of the codebases. Mean vulnerabilities per codebase rose 107% year over year. Black Duck sells scanning tools, so weigh the framing accordingly, but the direction matches what I see in data rooms. Assume the buyer will find every copyleft library somebody linked in 2019 and forgot.

The Interviews Are Where the Report Gets Written

Documents tell a reviewer what to ask. Interviews tell them what to write.

A typical session puts two or three people from the buy side across from your CTO or VP of engineering, sometimes with a principal engineer or the security lead pulled in for an hour. They have read your material. They have a list. And the questions that decide things are almost never the ones on the list, because a good reviewer uses the list to find the seams and then spends the session asking about the seams.

These are the ones I reach for most, along with what I am actually listening for, since that second part is what nobody publishes.

“Walk me through the last three incidents. Not the worst one. The last three.” Everybody has a polished story about their worst outage. The last three are random, and random tells me how the team really operates. I am listening for who noticed, how long detection took, and whether anything changed afterward. A leader who has to go look it up is fine. A leader who describes an incident the log does not contain is not.

Usually second, I ask who could ship a change to one specific service tomorrow if the person across from me were unreachable. I pick the service from the commit history the night before. I already know the answer. On one deal the CTO told me the whole team worked across the pricing engine. Thirty-one of its last thirty-four commits carried one engineer’s name. He was not hiding anything. He had simply never looked.

“What have you built that you would buy today?” That one is the build vs buy decision run backward, and it is my favorite, because a quick, specific answer comes from a leader who revisits old decisions. “Nothing” is the worrying reply. Every team has built something it would buy today.

Some of it is blunt.

“Which parts of the roadmap you showed us can this codebase not do yet?” If the answer is none, the reviewer’s next week just got longer.

“Show me the data on that.” I say it more than any other sentence in these rooms, usually right after someone offers a number. Deploy frequency, uptime, cloud spend as a share of revenue. Sellers hear distrust. It is really the moment I learn whether the number came from a tool or from memory, and the figures that hold up are the ones I argue for in the four delivery metrics that predict engineering velocity, pulled straight from the pipeline instead of rebuilt for the deck.

Contradiction Costs More Than Debt

If I could put one section of this on the wall of every engineering leader heading into a process, it would be this one.

Acquirers price technical debt all day long. It goes into an integration budget, a line in the model, occasionally a price adjustment, and everybody moves on. What they cannot price is a leader whose account of the system does not match the evidence, because once that happens the reviewer has no reliable way to estimate anything else. Every answer becomes a claim to verify. Scope expands. The timeline slips. Then the lawyers start drafting protections where the bankers would otherwise have adjusted a number: specific indemnities, larger holdbacks, and retention conditions on named engineers. None of those is catastrophic alone. Every one of them costs more than saying “we release to production weekly behind a change-approval meeting, and here is why.”

Buyers have earned the jumpiness. In a 2011 Harvard Business Review piece, Clayton Christensen and three co-authors put corporate acquisition spending above $2 trillion a year. Then the failure rate. Somewhere between 70% and 90%. Nobody on a deal team wants to be the person who waved through the reason theirs failed. A reviewer who catches one confident wrong answer has every professional incentive to go looking for a second.

Rehearsal will not fix it. Rehearsed answers are the worst kind in these rooms, smooth and slightly too round, and experienced reviewers can hear the practice in them. What fixes it is knowing where your own evidence lives, and being willing to say “I don’t know offhand. It’s in the incident tracker. Give me ten minutes.” Ten minutes costs nothing. A guess costs a week.

Underneath, it is a clarity problem. The three layers I check first in a struggling engineering org, which I call the Clarity Stack, are whether leadership knows what done means, whether priorities are written where the team can see them, and whether decisions live in systems or in hallway conversations. That turns out to be most of a diligence interview in a different suit. A team with all three layers can answer almost anything a reviewer throws at it. A team without them finds out in front of a buyer, which is the most expensive possible place to find out.

Key-Person Risk Is the One Finding You Can Move in Ninety Days

Every diligence report I have read has a people section, and the finding in it that changes deal terms most often is concentration. One engineer who understands billing. One who holds the production deploy credentials. A founder-CTO who is the only human alive who has read the data model end to end.

Buyers cannot fix that by paying more. So they hedge. That is where retention packages and earnouts tied to named individuals come from. The engineers involved usually know precisely what they are worth to the deal, too, which becomes its own negotiation, and nobody on the sell side enjoys that one.

For a seller, the encouraging part is that this is also the most fixable row on the table, provided you start before the process does. Ninety days will not make your code clean. It can make a critical service survivable without one particular person.

• Pick the three services where one name dominates recent commits and pair a second engineer on each for a full quarter. Real changes, not shadowing.
• Spread production deploy rights and on-call for those services so at least two people exercise them every month.
• Get the runbook out of the key engineer’s head and onto a page. Expect resistance, and do it with them in the room rather than around them.
• Confirm every contractor who touched core code signed an IP assignment. Pure paperwork, about a week of chasing, and its absence can hold up a close.

Nothing on that list requires a consultant. I made a version of this argument about inheriting an engineering team you did not hire, from the other side of the table, where the leader arrives after close and finds the concentration the report warned about. The advice converges because it is one problem seen from two chairs.

Open Source, Secrets, and the AI Code Question

Three items on the security row generate more follow-up than everything else in it combined.

License conflicts come first, for the reason in the Black Duck numbers above. A GPL or AGPL component linked into a proprietary product is not automatically a disaster. It is a legal question, though, and legal questions get escalated out of the engineering conversation into one where your counsel and theirs both bill by the hour. Run a scan yourself before anyone asks. Fix what you can. Then document how each remaining component is actually used.

Secrets second. The scanner does not only read your current code. It reads your git history, which is why GitHub’s own guidance treats revoking or rotating a committed secret as the first step, before any history rewrite. I watched one seller rotate every API key and database credential the week before diligence opened, a genuinely good move, and still collect a finding, because keys committed back in 2021 were sitting in history exactly where anyone with repository access could see them. What turned it into a non-issue was not the rotation. It was a ticket, with dates, showing when each credential had been replaced and that the old ones were dead. Evidence beat cleanliness. It usually does.

The third item is newer, and I now hear it on most deals. What share of the code came out of AI assistants like GitHub Copilot or Cursor, under what policy, and has anyone checked that output for license and IP exposure? In the same Black Duck report, 76% of surveyed organizations said they check AI-generated code for security risk, while only 24% run the full set of IP, license, security, and quality evaluations on it. Buyers have read that gap. “Engineers use Copilot, we don’t track it” earns a follow-up memo. A one-page written policy and a record of how AI output gets reviewed answer the whole question in a paragraph.

If an audit is on your roadmap anyway, what SOC 2 actually changes for engineering leaders day to day covers most of the evidence habits a diligence team will test, which is a pleasant side effect of building them for the auditors first.

A Ninety-Day Runway Before the Banker Calls

If there is a real chance your company goes to market in the next year, this is roughly how I would spend the quarter before. Not everything. The work with the best return per hour.

People skip the mock interview. Please don’t. Have someone who has sat on the buy side read your data room for a day and then ask you the questions above without warning you which ones are coming. The first time I ran one for a leader, he contradicted his own architecture diagram inside twenty minutes and laughed about it. Right outcome, right room. Better mine than a buyer’s.

Some of this needs hands the team does not have while it is also shipping the roadmap. A scoped project staffing engagement for the scan cleanup and documentation usually costs less than pulling your two strongest engineers off product for a quarter. KORE1 reports that 92% of its placements are still in the role twelve months later, which matters more than it sounds here, because the person you bring in may end up explaining their own work to a buyer.

Once the LOI Is Signed

Two jobs. They pull in opposite directions.

The first is running the room. Assign one person to own the technical data room, answer every request from source systems, and keep a running log of every question the buyer asked and the answer you gave. Answers drift over four weeks of interviews. The log catches it. Do not coach engineers to shade anything. Coach them to say “I’d have to check” rather than guess, which is harder than it sounds for people who are good at their jobs and used to knowing.

The second is keeping your team. Rumors travel faster than NDAs, and the engineers a buyer most fears losing are exactly the ones recruiters call first. Daniel Kim’s research on startup acquisitions, summarized by MIT Sloan, found 33% of acquired workers gone within a year, against 12% of comparable regular hires. Talk to your key people before the process leaks. Not after. If the deal closes and the acquired systems have to move onto the buyer’s platform, that work tends to land on the same few engineers, and it usually needs more of them than the combined company has spare, which is the gap KORE1’s post-acquisition systems integration staffing desk was built around.

Things Sellers Want Settled Before the Data Room Opens

Realistically, How Long Does Technical Due Diligence Take?

Two to six weeks for most mid-market software deals, with the management interviews clustered in the middle and the written report due a few days before the investment committee meets.

Larger or messier targets run longer, and a deal where week one turns up contradictions can double. Preparation is what compresses it. A seller with a complete data room on day one gives the reviewers nothing to wait on, and waiting is where most of the calendar actually goes.

Do We Have to Let Them Read Our Actual Code?

Usually, in some form, though it depends on who the buyer is. Private equity buyers commonly get read-only repository access under NDA, while a strategic buyer that competes with you often gets a third-party scan instead.

That third-party arrangement exists so nobody who might build a competing product reads your source directly. Counsel decides that one. Engineering’s job is to make whichever route gets chosen fast, which mostly means a sane repository structure and a dependency manifest that reflects what actually ships.

Is a Missing SOC 2 Report a Deal Problem?

Not by itself. Plenty of acquired companies have no SOC 2 report, but its absence turns into a long security questionnaire, and every answer on it needs evidence you can produce quickly.

It becomes a real problem with regulated buyers, say a bank or a healthcare company acquiring a vendor it will run inside its own compliance boundary. They may need proof that controls have operated over time, and a questionnaire cannot manufacture history. History takes time. If that is your likely buyer, start the audit a year ahead.

What Finding Actually Kills a Deal?

Rarely one technical finding. Deals die when findings stack up against a thesis the buyer already doubted, or when trust breaks and the buyer decides it cannot price what it cannot verify.

I have seen a serious licensing problem resolved with a specific indemnity and a remediation plan, and I have seen a deal with fairly modest debt stall because the seller’s answers kept moving. Severity matters. Credibility matters more. If there is one thing a buyer should hear from you first, it is the worst thing, and early.

Should We Pay Down Tech Debt Before Going to Market?

Some of it, selectively, and never in a way that looks like hiding. Fix what is cheap and visible, such as dead services and stale dependencies, and document the expensive debt with a cost estimate.

A frantic refactor six weeks before a process is a risk of its own. It shows up in the commit history as a spike of changes to core systems right before a sale. Reviewers notice. They ask why. Named debt with a plan reads as a team that knows its system. Buried debt reads as the opposite the moment someone digs it up.

Does the Diligence Change With a Private Equity Buyer?

It changes in emphasis more than scope. Private equity reviewers focus on whether the platform can carry the growth plan and at what cost, while strategic buyers care most about fitting your systems and people into theirs.

That shifts which rows get the most hours. A PE deal leans hard on cloud cost, delivery speed, and the leadership bench that will run the business after close. A strategic deal spends longer on architecture fit, data models, identity, and which of your engineers the acquirer wants to keep. Ask the banker which kind of buyer is likely. Ask early. It decides what you prepare first.

Know Where Your Evidence Lives Before They Ask

If you carry one thing into a diligence room, carry this. The reviewers across the table are not trying to catch you. They are trying to learn whether your account of the company can be trusted, because the model they are about to hand an investment committee depends on it.

Give them a leader who knows where every number came from and says “let me check” instead of guessing. Almost everything else has a price.

If a process might be coming in the next year and you want a second read on what a buyer would find, connect with me on LinkedIn and tell me roughly what you are running. And if the honest answer is more cleanup than your team can carry alongside the roadmap, bring KORE1 in to scope the extra hands before the data room opens rather than after.