Rehearse ten questions: what open source you use, how you track it, how fast you fix serious vulnerabilities, who can change production, how builds are protected, what license risks exist, what past incidents occurred, what is end of life, who maintains what, and what you would fix first. Have a two minute answer and an artifact for each.
Why rehearse
Diligence calls are short and technical reviewers ask follow ups. Founders who have never written their answers down tend to ramble, contradict the questionnaire or promise things they cannot show. Practising with a colleague playing the buyer exposes weak spots while there is time to fix them.
The ten questions
| Question | Two minute answer includes | Evidence to point to |
|---|---|---|
| 1. What open source do you ship? | Where the list lives and how often it refreshes | Latest SBOM, dated |
| 2. How do you learn about new vulnerabilities? | Source, owner, response time | Alert routing, ticket examples |
| 3. How quickly do you fix critical ones? | A target and the real record | Closed tickets with dates |
| 4. Which findings are open today? | Count by severity, top items | Known issues register |
| 5. Who can change production? | Roles, approvals, MFA | Access export, branch rules |
| 6. How are builds protected? | CI permissions, pinned actions, secrets handling | Workflow files, settings |
| 7. What are your license obligations? | Copyleft present or not, policy | License report, policy |
| 8. Have you had security incidents? | Facts, timeline, fix | Incident log |
| 9. What is out of support? | Runtimes, packages, systems | EOL list with dates |
| 10. What would you fix with more time? | One honest priority | Roadmap item |
How to practise
- Assign the questions to the people who actually know, not to whoever is most senior.
- Each person writes a one paragraph answer and lists the artifact.
- Run a thirty minute mock call. The listener interrupts with "show me".
- Fix anything that could not be shown: create the record, correct the answer, or drop the claim.
- Agree who speaks to what, and who says "we will follow up in writing".
Answers that work
Short, specific and bounded. "We generate an SBOM at each release and store it with the build. The last one was 14 October. It covers the API and web app, not the mobile client, which has its own." That tells the buyer what exists and where it stops.
Answers that hurt
Absolutes such as "we never" and "all of our". Vague comfort such as "we take security seriously". Numbers you cannot source. And inconsistency: if the questionnaire says two weeks and the ticket history says two months, the buyer will notice.
When you do not know
Say so, name who will find out, and set a date. A prompt written follow up reads as competence. A guess that turns out wrong reads as a risk.
Try it yourself
Click through it at your own pace, or open it full screen.
Use it to practise explaining why a flagged vulnerability does or does not matter in your product, which is what question 4 turns into.
Safeguard provides reachability analysis, SBOM and dependency scanning and compliance evidence automation that produce several of these artifacts. A free scan gives you a first set of findings to rehearse with.
Quick check
Should the CEO or the CTO lead the call?
Whoever owns the facts. Let the engineering lead answer technical questions and the CEO cover commitments.
Can I share the rehearsal answers in the data room?
Share the evidence, not the script. The answers should be consistent with your written documents.
Last reviewed: 19 October 2026.
