Write five short sections: what software you ship and from what components, how you find and fix vulnerabilities, how builds and releases are protected, what is open today, and what you will do next. Put a date and an evidence pointer on every claim. One page forces you to say just what you can show.
The reader
An investor or a deal lead is rarely a security engineer. They want to know whether supply chain risk could surprise them after funding or closing. They will pass your page to a technical adviser, who will test two or three sentences. Write for both: plain words on top, specifics underneath.
Template
| Section | What to say | Evidence pointer |
|---|---|---|
| Inventory | Products in scope, how components are tracked, last SBOM date | SBOM folder, index |
| Vulnerability handling | Where alerts come from, who triages, measured fix times | Known issues register, ticket export |
| Build and release integrity | Review rules, pinned build dependencies, who can publish | Branch rules, workflow files, account register |
| Open items | Count by severity, top three, owners and dates | Register |
| Next 90 days | Two or three specific improvements | Roadmap tickets |
Writing rules
- Use numbers you can source. "Two of five repositories require review" beats "most."
- Name boundaries. "Excludes the legacy admin tool, retiring in December."
- Use dates for everything that changes.
- Avoid superlatives and maturity labels. Describe controls, not ratings.
- Do not claim a certification or audit result that you have not received. If an audit is in progress, say it is in progress and by whom, without implying an outcome.
- Keep each section to three or four sentences.
Example opening lines
"As of 19 October 2026, we maintain SBOMs for our three production services, regenerated at each release and stored with the build." Then the boundary: "The mobile client is covered separately and its SBOM was last generated on 2 October." These are examples to adapt, so change the facts to match yours.
What to leave out
Tool names and long lists. Marketing language. Promises about the future that no ticket backs. Detail that belongs in the register.
Review before sending
Have an engineer read it with a pen. Every sentence either gets an evidence pointer or goes. Check dates against the actual files. Check that numbers agree with the questionnaire and the register. Ask counsel whether any sentence could be read as a warranty.
Keeping it current
Calendar the review for the first of each month during an active process, and after any major release or incident. Keep old versions. A series of one page summaries over time shows a program, not a one off effort.
Quick check
Should the page mention open vulnerabilities?
Yes, in summary with a pointer to the register. A page that says nothing is open will not be believed.
Who signs off on it?
The person accountable for engineering, with legal review if the page will be given to an outside party.
Safeguard's SBOM and dependency scanning, reachability analysis and compliance evidence automation can supply the numbers behind each section. A free scan gives a first inventory.
Last reviewed: 19 October 2026.
