A technical due diligence document request list is the set of materials a buy-side team asks a potential acquisition target to hand over before the software audit starts. MEV's list has five must-haves and four nice-to-haves. What the target sends back, and how fast, gives the buyer an early signal before the TDD team reviews the code. MEV runs both buy-side and vendor-side technical due diligence in two to four weeks at a fixed fee between $5,000 and $30,000.
In a software M&A deal, the buy-side team's first move is a document request list, sent to the target before any code review starts. What comes back sets the terms of the whole audit.
A complete set means your team spends its two to four weeks assessing the system. A thin set means part of those two to four weeks goes to rebuilding the target's documentation before the assessment can start.
MEV runs technical due diligence on both sides of a deal, buy-side and vendor-side, in SMB and lower-middle-market software M&A, with extensive expertise in healthcare, data, and AI systems.Here is the technical due diligence document request list we recommend sending, and what each item reveals.
Technical Due Diligence Document Request List: the nine items we send on every buy-side deal
What Is a Technical Due Diligence Document Request List?
A technical due diligence document request list is the set of documents a buyer asks a target to hand over before the software audit begins. MEV's initial document request list has nine items: five must-haves and four nice-to-haves.
Buyers sometimes confuse it with the due diligence questionnaire (DDQ), a separate document where the target writes answers to a buyer's list of questions about the business. The difference comes down to what each one asks for: the request list wants files the target already holds or should hold, while the DDQ wants written answers the target has to compose.
Technical due diligence (TDD) is a structured review of a target's technology, run before software acquisition, to score its condition and price the work you would inherit.
First the parties involved sign an NDA. Then the target then opens a virtual data room (VDR), the secure repository where deal materials get shared, and returns the requested documents through it.
The five must-haves describe the system you are buying: what the product does, how it is put together, what it runs on, what it is built with, and which regulations it falls under. The four nice-to-haves describe the people and process around it.
When should a buyer send the document request list?
The buyer sends the full list as soon as the LOI, the letter of intent, is signed and the exclusivity window begins. A lighter screen can run before the LOI, but the full nine-item list waits for exclusivity, when the target commits to a single buyer and grants full access.
Choosing between a pre-LOI screen and the full post-LOI audit is its own decision: the pre-LOI screen tests your bid before you commit; the post-LOI audit verifies what the seller claimed before you close.
Sending the list early gives the target time to locate documents it already has, and gives you time to react when something is missing.
What Are the Five Must-have Documents in a Technical Due Diligence Request List?
MEV's buy-side technical due diligence request list has five must-have documents: the product overview, the system architecture diagram, the infrastructure diagram, the technology stack overview, and the compliance scope. Together they describe the asset you are buying, before anyone opens the code.
The stack overview is also your first look at what open source you inherit. Your request should cover whether the target maintains a software bill of materials (SBOM), a list of every open source component and the license on each one.
The license on any one of those components can break a deal. Some open source licenses trigger the moment you hand the software to someone else, or let people reach it over the internet, which covers most hosted products. When that happens, you are legally forced to make your own source code public and free for anyone to copy. To prevent this, your team has to read the terms of every single component.
If the target company already has a SBOM, you can check every license in about a day. Without one, your audit team builds that list from scratch. Since modern software relies heavily on open source, building that list manually can take up some time.
Black Duck's 2026 OSSRA report, based on 947 audited codebases across 17 industries, found open source license conflicts in 68% of them, up from 56% a year earlier. Black Duck notes that exposure like this tends to surface during events such as M&A due diligence.
The target's product is one piece of software. The company almost always runs others: a marketing website, sometimes a customer login portal. Ask for a list of every site the target runs on a domain it owns. Each one becomes your team's problem the day the deal closes. An old marketing site running an unpatched WordPress plugin is the kind of thing attackers scan for, and it is now attached to the company you just bought.
What is the difference between a system architecture diagram and an infrastructure diagram?
A system architecture diagram shows the software components and how they communicate.
An infrastructure diagram shows the actual servers, networks, and cloud services running those components. Companies often send just one of these diagrams and claim it covers both.
What if the target says no regulations apply?
The answer should come in writing, signed by the seller. If the system turns out to have stored patient records or card numbers, the fines land on you, because you now own the company. A signed statement, given before the money moves, is what your lawyers will need if that happens.
What Are the Four Nice-to-have Documents in a Technical Due Diligence Request?
The four nice-to-haves are the team overview, security documentation, testing documentation, and API documentation. They describe how the team around the system works.
The audit can start even if you don't have all four. But every diagram the target company sends saves your team a round of interviews and hands you a finding much earlier in the diligence window.
Missing API documentation costs the most audit time. In Postman's 2024 State of the API Report, a survey of more than 5,600 developers, 44% said they dig through source code to understand an API, and 39% named inconsistent documentation as their biggest roadblock. Your audit team does that same reading, inside the window.
Ask for all nine items in one request. Their response is your first indicator of the target's engineering discipline.
What Does the Target's Response to the Document Request List Tell You?
The response shows how the target runs its engineering. A target that returns current diagrams and a named compliance scope keeps documentation as part of how it builds. A target that returns a sales deck and offers a call keeps that knowledge in people's heads.
In SRS Acquiom and Mergermarket's 2025 due diligence study surveying 150 US investment bankers, 40% of boutique bank executives called incomplete target data one of the biggest hurdles in their last buy-side deal.
Two things in the reply are worth reading closely.
The first is what came back. The items a target cannot produce are the items your audit team will have to reconstruct from the system itself, inside the window you are paying for.
A company that only returns four of the nine items is showing you exactly which parts of their own product they never documented. Also, check for stale documents. A diagram from two years ago rarely matches current production, so your team will have to verify every document against the live system before trusting it.
The gaps also weigh differently. A healthcare target that cannot name its compliance scope hands you unknown regulatory liability, and that can lower your offer. Missing API documentation, on the other hand, just costs your team extra reading time and delays the post-close roadmap, but it won't impact the purchase price.
The second is how long it took. A buy-side audit only runs two to four weeks. Every week the target spends hunting down its own files directly eats into your review time, yet your audit still has to finish before exclusivity runs out.
What if the target cannot produce a document?
The missing document becomes a finding, and the audit continues. Your team derives the same information from the system, reading the stack off the repository and the infrastructure off the cloud console. Undocumented integrations come out of the logs.
On MEV's buy-side manufacturing engagement, confidentiality blocked the diligence team's access to the target's systems, and the company provided zero hardware or inventory documents.
To map the environment without disrupting operations, MEV combined stakeholder interviews and vendor records with remote diagnostic scripts to pull endpoint versions and patch levels.
That reconstruction surfaced 14 aging workstations, some still running Windows 7. Based on the findings, the team produced a technical report with a staged, low-disruption upgrade path.
The report grouped fixes by urgency: securing endpoints and verifying backups in the first 90 days, segmenting the network and adding monitoring over the next few months, and tackling full modernization down the road.
What does the document request list not cover?
The nine items above describe the software. There are four other checks involved in a M&A deal, and each covers different part of it:
- IP ownership
Any code a contractor wrote without a signed IP assignment still belongs to that contractor. Your lawyers verify the target owns what it is selling, and the seller warrants that ownership in the purchase agreement (SPA), the binding contract that transfers the company and sets the final price and terms. - A data inventory
Compliance scope names the rules that apply, like HIPAA or GDPR. A data inventory, the list of what personal and patient data the system holds and where it is stored, is what tells you whether the target is following those rules. It is usually where the first violation may potentially turn up, like patient records sitting in a database nobody secured. - The cloud bill
The infrastructure diagram shows the architecture. The last several monthly bills show the cloud spend you inherit and its direction, so request a few months instead of just one recent invoice. A bill that climbs month over month means the cost keeps rising as usage grows, and that rising cost is yours from close. - Contract transferability
When you buy the company, you inherit its contracts with customers and vendors. Some contain a change-of-control clause, which lets the other side cancel or change terms when the company is sold. A major customer could leave, or a vendor the product depends on could raise its price, triggered by your purchase. Your lawyers read the key contracts before close to find these upfront.
Bottom Line: How Do You Use the Technical Due Diligence Document Request List?
The five must-haves describe the system: the product overview, the system architecture diagram, the infrastructure diagram, the technology stack overview, and the compliance scope. The four nice-to-haves describe the team around it: the team overview, security documentation, testing documentation, and API documentation.
With a complete set, your audit team spends the full two to four weeks scoring the system. When items are missing, part of that window goes to rebuilding documentation the seller never wrote, on your clock.
You can download MEV's technical due diligence document request list, the same one our buy-side team sends. Hand it to the target as soon as the LOI is signed.
References
We wrote this because a buyer's first move on a software deal is a document request, and what the target sends back sets the terms of the whole audit before engineers open the code. A complete set means the full two-to-four-week window goes to scoring the system. A thin one means part of that window goes to rebuilding files the seller never wrote. So we put down the exact nine items we send and what each reply reveals about the target.
What is included in a technical due diligence checklist?
A technical due diligence checklist is the set of documents a buyer reviews before acquiring a software company. MEV's covers nine: product overview, system architecture diagram, infrastructure diagram, technology stack overview, compliance scope, team overview, security documentation, testing documentation, and API documentation.
What documents are must-haves versus nice-to-haves?
Five must-haves describe the system: product overview, architecture diagram, infrastructure diagram, stack overview, and compliance scope. Four nice-to-haves describe the team: team overview, security, testing, and API documentation. The audit can start without the four
What is the difference between a document request list and a due diligence questionnaire?
A document request list asks the target to hand over files that already exist, like architecture diagrams and test reports. A due diligence questionnaire (DDQ) asks the target to compose answers to specific questions about the business. The document request list comes first.
What happens if the target has no documentation?
Your team derives the same information from the system itself: the stack from the repository, the infrastructure from the cloud console, the integrations from the logs. The reconstruction costs hours out of a two-to-four-week window, and the gap itself becomes a finding about the overall engineering processes at the target company. .
Who prepares the technical due diligence document request list?
The buyer's technical advisor, before the audit starts. On MEV engagements, MEV sends the list and reviews what comes back.
