M&A Technical Due Diligence Checklist: First 72 Hours

Imagine you signed the letter of intent three weeks ago, and closing is on the calendar. Your engineering team is busy preparing the data room, your CFO is fielding finance questions, and your lawyers are stress testing the purchase agreement. Then the buyer’s technical auditors arrive for M&A due diligence and, within 72 hours, file findings that put the agreed price back on the table.

This happens more often than anyone wants to admit, and it’s totally preventable with a timely software audit. According to Deloitte’s 2025 M&A Trends Survey, 79% of corporate and 87% of private equity leaders expect deal volume to keep climbing this year, which means more buyers are running these audits more often and with sharper questions. Sadly, most sellers learn what those questions actually are about a week too late.

We wrote this guide because nearly every M&A technology due diligence checklist on the internet reads like a Big Four marketing brochure: long lists, vague categories, and nothing about what the auditor on the other side of the table actually opens first when the data room goes live. So this is not as much an article as a test plan a buyer’s technical auditor really runs in those first three days, the standards they score the target against, and the three findings that most often reset the deal price.

If you are the seller, read this as your dress rehearsal. If you are the buyer, read it as a sanity check on whether your own team is asking the right questions in the right order.

What Do M&A Buyers Check During Technical Due Diligence

Here is the direct answer, because that is what you came for:

During technical due diligence, buyers check four things, roughly in this order: how the target builds software, what the target legally owns, how protected the software is, and how fragile the architecture is. Everything else in a typical M&A due diligence checklist is supporting evidence for these four questions.

What changes the conversation, though, is that the auditor does not walk in with an open mind. They walk in with three reference standards open in front of them. The first is the NIST Secure Software Development Framework, which defines disciplined software development. The second is the Software Assurance Maturity Model from OWASP, which scores how mature each of those practices is in the real world. The third is ISO/IEC 27001, the international standard for information security management, which confirms whether anyone in the target company is genuinely accountable for any of it.

Together, those three frameworks become a scorecard:

NIST tells the auditor what to look for
OWASP SAMM measures how well the target is doing it
ISO 27001 verifies that someone owns the result

Sellers who walk into due diligence without knowing they will be measured against these three get blindsided.

Together, those three frameworks become a scorecard:

Why the First 72 Hours of M&A Due Diligence Decide Re-Pricing

A typical M&A due diligence process runs 30 to 60 days. However, the findings that move the price surface on days one through three. That is because of how auditors actually work.

Day one is document triage.
Day two is forensics on the code itself.
Day three is when the auditor meets with the engineering lead to ask the questions the documents could not answer.

By the end of day three, the buyer’s deal team has a preliminary scorecard, and that scorecard is what shapes every conversation that follows. If the first 72 hours produce confidence, the rest of the diligence period is mostly verification. However, if they produce doubt, the rest is renegotiation.

There are three findings, in particular, that we see reset the price almost every time. We will get to them in detail, but here is the short version. First, gaps in who actually owns the code. Second, change records that fall apart when you look back three years. Third, undocumented pieces of software the business depends on but cannot afford to lose. Each of these cleanly maps to one of the three reference standards, and each one signals to a buyer that the headline valuation may not survive contact with reality.

M&A Due Diligence Checklist: What Buyers’ Auditors Test in the First 72 Hours

The 72-Hour Test Plan, Hour by Hour

This is what we can conclude from our M&A due diligence consulting experience, expressed in simple language that non-engineers and auditors can understand. In writing the following plan, we used both our experience with such projects and current regulations.

Hours 0 to 24: Document Triage and Standards Mapping

The first day is paperwork. The auditor wants to quickly see whether the target has the artifacts a mature software organization should have on hand. The list usually includes:

Development policies
Intellectual property register
Complete list of every third-party software component the product uses (software bill of materials, or SBOM)
Access control matrix for code repositories
The last two penetration test reports
Three-year history of security incidents

The auditor is not reading these documents in detail yet. Rather, they are checking for presence and freshness. For example, a pentest report from 18 months ago is a yellow flag, but no pentest report at all is a red one. An SBOM that was generated last week, just for the data room, signals that nobody has been paying attention to dependency risk until now.

Each artifact then gets mapped onto the three reference standards. NIST groups practices into four buckets: Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities. The auditor checks which of those buckets has supporting evidence and which has only verbal assurances. OWASP SAMM assigns each practice a maturity score from 0 to 3. ISO 27001 maps policies to specific Annex A controls and asks whether they are implemented or only documented.

By the end of day one, the auditor has a heat map. Green where the target is well prepared, yellow where evidence is thin, red where there is nothing at all. This is also the day on which our auditors have historically caught the most serious issues for our clients, simply because the heat map exposes how the target really works in 24 hours, not 24 days.

Hours 24 to 48: Code and Repository Forensics

Day two is when the auditor actually touches the code, or more precisely, the records around the code. The goal here is to verify that what the company says it owns matches what the code repository says happened.

The first task is checking who wrote what. The auditor pulls the commit history and reconciles every contributor against the IP assignment agreements signed by employees and contractors. Therefore, if a freelancer in 2021 committed a meaningful chunk of the core product but the company cannot produce a signed agreement transferring ownership, the buyer now has a problem. The same applies to code suggested or generated by AI tools, which is why buyers in 2026 are suddenly asking very specific questions about how the engineering team uses them.

The second task in an M&A due diligence checklist is licensing. The SBOM from day one is now compared against the actual contents of the codebase. The auditor is hunting for two things:

Open-source components used under licenses that contaminate the proprietary code around them and can effectively force the company to release its own source code.
Unlicensed or expired commercial libraries that nobody noticed because the original developer left two years ago.

A thorough code review often surfaces these issues weeks before a buyer’s auditor would, which is why sellers who plan ahead run their own pass before the data room opens.

The third task in the auditor’s technical due diligence checklist is reconstructing the change-management trail. They walk through the repository for the last three years and ask a simple question: for any given change to production, can I trace it from the original ticket to the pull request to the commit to the deployment?

If the answer is yes for most changes, the company is in good shape. However, if the answer is no, or if there are large gaps, force pushes to the main branch, or commits that bypass review, that is a finding the buyer takes very seriously.

The fourth task in M&A due diligence is mapping the dependencies. The auditor is looking for components that the business depends on but cannot easily replace. Such examples could be a library maintained by a single volunteer who has not committed to it in two years, or a runtime version that the vendor stopped supporting last quarter. These are the silent points of failure that show up in post-merger budgets as eight-figure surprises.

Hours 48 to 72: Process and People Validation

Day three is the human day of technical due diligence. The auditor sits down, usually for several hours, with the head of engineering and a small handful of senior contributors. The goal is to confirm that the picture from days one and two matches what the people building the software actually do.

The conversation moves through a familiar arc. Threat modeling comes up first because the auditor wants to know whether security is something the team designs in or bolts on at the end. Incident response comes next, with the auditor asking the engineering lead to walk through the most recent serious incident from start to finish. The way that the story is told reveals more than any policy document. Then comes key-person risk, where the auditor asks, very politely, what would happen if a particular engineer were to leave next week. The honest answers are often uncomfortable.

By the end of day three, the auditor closes the laptop, writes a one-page summary for the deal team, and the negotiation begins to shift based on what is in it.

Due Diligence M&A Standards-Based Findings That Re-Price Deals

Below, we’ll explain the three most common auditors’ findings that immediately affect the price of the deal. We will also share insights from our M&A due diligence consulting experience on how to address such issues if they arise. However, the easiest way to avoid problems at this stage of your deal is to conduct an audit on your side before the buyer’s technical due diligence team arrives.

Finding One: IP Provenance Gaps

Provenance simply means proof of where something came from. In M&A due diligence, IP provenance gaps mean the company cannot fully prove that it owns the code it is selling.

This shows up in specific ways:

Contractors who built meaningful parts of the product without signing an IP assignment agreement.
Open source components used in ways that violate the license terms.
Code generated by AI tools without any record of which prompts produced what output.
Acquired code from a previous deal for which nobody can find the original transfer paperwork.

NIST SSDF practice PS.3, which addresses archiving and protecting each release, requires the company to maintain a clear record of every artifact in each release. ISO 27001 control A.5.32 requires explicit protection of intellectual property rights. Therefore, when a buyer’s auditor cannot reconcile the code with the contracts, the response is predictable. Indemnity carve-outs in the purchase agreement get larger. Escrow holdbacks increase, and in serious cases, the headline price is reduced by 5% to 15%, sometimes more if the contaminated code is in the core product.

For sellers, this is the easiest of the three findings to fix in advance, but only if you start at least 60 days before the data room opens.

Finding Two: Change-Management Trails That Do Not Survive a Three-Year Lookback

The second finding is about the company’s history, not its present. Buyers want to look back three years in the source control system and see exactly how any given change in production got there. This includes who proposed it, who reviewed it, who approved it, and who deployed it.

When that trail is solid, the buyer is reassured that the engineering culture is disciplined and that the codebase is unlikely to contain hidden surprises. However, if the trail is patchy, the auditor starts looking for what else might be missing. Common patterns that fail this test include:

Manual deployments without a corresponding ticket
Force-pushes that erase history
Branches that were never protected
Code reviews performed by the same person who wrote the code
Long stretches of time during which nothing was logged at all

NIST SSDF practice PS.1 expects clear control over all forms of code and supporting documentation. The OWASP SAMM secure-build practice expects every change to be reproducible and traceable. ISO 27001 control A.8.32 requires formal change management. When all three are weak, the buyer responds with what is essentially an integration risk premium. Mandatory pre-close remediation, an extended escrow, or a portion of the purchase price moved into a deferred earn-out tied to engineering hygiene improvements.

This is the finding that catches the most companies off guard, because the engineering team usually believes its hygiene is fine until someone actually looks.

Finding Three: Undocumented Critical-Path Dependencies

The third finding is the most expensive to fix after the deal closes, which is why buyers care about it most.

Every modern software product depends on dozens or hundreds of pieces of code written by other people. Some of those pieces are well-maintained and widely used, and others are fragile. The dangerous ones are the dependencies that the business cannot run without, but that nobody in the company actively monitors. This usually includes:

A library maintained by one volunteer in another country
A microservice that quietly calls into a developer’s personal cloud account
A configuration file with secret credentials that have not been rotated since 2022
A scheduled job on a server that nobody on the current team set up

NIST SSDF practice PW.4 expects the company to reuse only well-secured software components. The OWASP SAMM software dependencies practice expects continuous monitoring of all external code in use. ISO 27001 control A.8.30 requires explicit oversight of outsourced development and third-party code. If a buyer’s auditor finds a critical-path dependency that nobody can explain, the response is rarely a price cut. Instead, it’s a longer transition services agreement, retention bonuses for the engineers who do understand the dependency, and a reserve fund set aside specifically to migrate or replace the fragile component after closing.

Steady, ongoing software maintenance is the cheapest insurance against this finding, because it forces the company to keep an honest inventory of what its software actually depends on.

How Sellers Can Self-Score Before the Buyer Arrives

If you are 30 to 90 days from a signed LOI, you still have time to fix more than you think by implementing the following straightforward principle: run the same test plan on yourself that the buyer’s team will run on you.

Pull the same artifacts, score them against the same standards, and compare what you find against the three findings above. The exercise takes a small team about two weeks if everything is in reasonable shape, and four to six weeks if it is not. In our experience, there are five fixes that move the most score in the least time.

Sign IP assignment agreements with every active contractor and document the chain of ownership for every commit.
Regenerate the software bill of materials and reconcile it against the codebase, fixing any license violations.
Turn on branch protection in the main repository and require all changes to go through a documented review.
Inventory every third-party dependency in production and identify the three or four that pose the highest risk.
Write down, in plain language, what the engineering team would do if a key person left tomorrow.

These fixes will not make every finding disappear, but they will demonstrate to the buyer’s auditor that the company knows where its weaknesses are and is taking them seriously, which often matters more than the underlying findings themselves.

If you would rather have an independent team score you before the data room opens, that is exactly the work our software audit services practice does. We use the same scorecard that the buyer’s team will use, and we tell you in two weeks what they would tell the buyer in three. So, contact us today, and we’ll go from there.

For a deeper walkthrough of the framework we use across all our audits, see our SDLC Audit Checklist post, which covers the same ground from the development team’s perspective. And remember, if there is one thing we hope you take away from this article, it is that the buyer’s auditor is not trying to catch you out. They are trying to confirm that the price on the term sheet matches the company’s inside. The faster you can demonstrate that it does, the faster you close. The longer they have to look, the more they find.

FAQ

What's on a technical due diligence checklist?

A technical due diligence checklist covers four areas:

Software development process
Intellectual property and licensing
Security and data governance
Architecture and dependency risk

The buyer’s auditor assesses the target’s evidence in each area against three reference standards: NIST SSDF, OWASP SAMM, and ISO 27001. Specific items include the SBOM, IP assignment agreements, change-management records over a three-year lookback, pentest reports, incident logs, the access control matrix, and an inventory of third-party dependencies.

How long does M&A technical due diligence take?

A full M&A due diligence process usually takes 30 to 60 days, with larger or cross-border deals running 90 days or more. The findings that influence the deal price, however, are typically identified in the first 72 hours of the technical workstream, when the auditor reviews documents, performs code repository forensics, and interviews the engineering lead.

Who performs M&A technical due diligence?

For large deals, an external software audit firm or a specialized M&A consultancy usually leads the technical work, with support from the buyer’s internal CTO or head of engineering. For smaller deals, the buyer’s internal technical team often runs it directly. Sellers increasingly hire their own external auditor in advance to score themselves before the buyer’s team arrives, which gives them time to fix issues that would otherwise reset the price.

What's the difference between an SDLC audit and M&A technical due diligence?

An SDLC audit looks inward and helps a company improve its own software development process. Meanwhile, M&A technical due diligence looks outward and helps a buyer decide what a target company is actually worth. The two share a lot of the same evidence, namely code repositories, development policies, security records, and dependency inventories, but they ask different questions. The SDLC audit asks how to improve the team, and the M&A audit asks whether to pay full price.

What is M&A cyber due diligence, and how is it different from technical due diligence?

M&A cyber due diligence focuses specifically on cybersecurity posture, including breach history, identity and access management, data protection, and regulatory compliance. Technical due diligence is broader and includes cyber due diligence as one of its four pillars, alongside development process, intellectual property, and architecture. For most software acquisitions, the two workstreams are run in parallel, and findings often overlap.

Can a seller self-assess before due diligence starts?

Yes, and the sellers who do it well are noticeably better positioned in negotiation. The exercise involves running the same test plan the buyer’s team will run, scoring the results against NIST SSDF, OWASP SAMM, and ISO 27001, and prioritizing the fixes that close the biggest gaps in the time available. The window that matters most is 60 to 90 days before the LOI is signed, because that is enough time to remediate the issues that most often re-price deals.