In software security due diligence, buyers ask six things: what is in your code and dependencies, what incidents you have had, who has access to what, where customer data lives, what compliance you hold, and how fast you fix problems. Good answers are specific, dated and backed by evidence you can show.
The six areas buyers probe
Code and dependencies. They want a list of the components you ship, their licenses, and known vulnerabilities. A software bill of materials is the usual format. CISA describes an SBOM as a nested inventory, a list of ingredients that make up software components.
Incidents. They ask about past breaches, near misses and how you handled them. Silence reads worse than a bad story told well.
Access. Who can reach production, source control, cloud accounts and customer data, and how is that reviewed?
Data. Where customer data is stored, which vendors touch it, and how it is deleted.
Compliance. Which reports or attestations you hold, and which are in progress.
Remediation speed. How long a critical finding sits before a fix ships.
What a good answer looks like
A good answer names a system, an owner and a date. "We review production access quarterly, last done in September, here is the export" beats "we follow least privilege."
Buyers also read for consistency. If the questionnaire says one thing and the engineering call says another, the whole file gets discounted.
What worries buyers most
Not a long finding list. Every real codebase has findings. What worries a buyer is a company with no way to see its own estate: no inventory, no owner for vulnerabilities, no record of past fixes.
Unknowns get priced. Known issues with a plan usually do not.
How to prepare in a week
- Generate a current dependency inventory and license report.
- Write a one page incident history, including what changed afterwards.
- Export access lists for source control, cloud and production data.
- List your vendors that process customer data.
- Gather the compliance documents you can truthfully share.
See also asset discovery for merger and acquisition due diligence for the inventory step.
Safeguard can produce the dependency inventory, vulnerability and reachability view, and evidence collection for this kind of request. A free scan is available at https://gold.safeguard.sh/scan.
A worked example
Imagine a 40 person software company selling to a larger acquirer. The buyer sends a 90 question list. Twenty questions are about policy, forty are about evidence, and thirty are follow ups from the first answers. The seller that finishes fastest is not the one with the best policies. It is the one that can export an access list, a dependency report and an incident log in an hour.
The lesson is to prepare exports before the list arrives. Assign each of the six areas to a named person, agree one place where answers live, and review every answer for consistency before it goes out. Two people answering the same question differently is the most common avoidable problem in these processes.
Quick check
Do buyers expect zero vulnerabilities?
No. They expect you to know what you have, rank it and fix it on a schedule you can show.
Should we volunteer bad news?
Yes, in a short factual note with the fix. It is better coming from you than from their scan.
Sources
Last reviewed: 19 October 2026.
