In technical due diligence, reviewers usually ask what software you run, how old your open vulnerabilities are, whether any known exploited items are open, who owns fixes, and how your process works. Prepare a dated, honest pack covering those five areas, and state limits plainly instead of polishing the numbers.
This is practical guidance, not legal advice. Deal terms and disclosure duties vary, so involve counsel on what you share and when.
What reviewers are trying to learn
They are pricing risk and effort. Can the company see what it runs? Does it fix things on a predictable rhythm? Is there a hidden pile of old issues that becomes the buyer's cost after closing? The metrics are a way to answer those questions without reading code.
The five areas to prepare
| Area | What to have ready |
|---|---|
| Inventory | A current list of applications, services, and their dependencies, such as SBOMs |
| Age | Open findings by age band and severity, with the oldest items explained |
| Exploited items | Count of open known exploited vulnerabilities, and the plan for each |
| Ownership | Who owns each service and who approves exceptions |
| Process | Written remediation targets and how often you meet them |
How to prepare, in order
- Refresh the inventory. A stale list is the easiest thing to be caught on.
- Run a full scan across production and note the date and scope.
- Compute the median time to remediate and the open age distribution for the last four quarters.
- List every open known exploited item with status.
- List every active risk acceptance with owner, reason, and expiry.
- Write a one page summary that explains the numbers and the method.
Say what you do not know
A reviewer will trust a team that says "this part of the estate is not yet scanned" more than one that presents a perfect picture that falls apart on the first question. Include a coverage statement: what share of production is in scope, and what is outside.
Things to avoid
- Backfilled numbers. Present the data as it stood, with method notes.
- Claims about certifications or attestations you do not hold. State the status accurately, including work in progress.
- Dropping old findings just before the review. Reviewers can compare tracker history with your summary.
- Naming customers or incidents without clearance.
After the review
Expect follow up questions on the oldest items. Have owners ready to explain each. Where an item is a deliberate acceptance, show the record with the date and approver.
Where Safeguard fits
Safeguard can help with the inputs behind this. It runs SBOM and dependency scanning, reachability analysis to separate reachable findings from the rest, and policies and gates that you set. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Open the dependency inventory and see how components, versions, and findings line up, which is the first thing reviewers ask to see.
Quick check
Should we clean up the tracker before diligence?
Fix real issues and close stale duplicates, but do not rewrite history. Keep an audit trail of what changed and why.
Do we need an SBOM for every product?
Reviewers commonly ask for one per deployable. Having them current is a clear way to answer inventory questions.
Last reviewed: 19 October 2026.
