A trust page needs three answers: how you decide what to fix first, what reachability means for customers, and how you tell them about a specific vulnerability. Keep each under 100 words, state limits, avoid absolute claims and make sure every sentence matches what your team actually does.
Principles before drafting
Public text becomes a promise. Customers quote it in questionnaires, and auditors compare it with your records. So write only what you can show.
- Describe the process, not the result.
- Use verbs for what you do, not adjectives for how good it is.
- Include one limit per answer.
- Date the page and name an owner.
FAQ one: how do you decide what to fix first?
Draft:
"We rank findings using published severity, whether the vulnerability is known to be exploited in the wild, and whether the vulnerable code is reachable in our product. Exploited issues move first. Findings we cannot classify are treated as reachable until reviewed. We record the reason for every decision."
Check before publishing: does your policy really say unknown is treated as reachable? CISA advises using its KEV catalog as an input to a prioritization framework, so naming exploitation status as a signal is consistent with that guidance.
FAQ two: what does reachability mean?
Draft:
"A software library can be present without its risky function ever running. Reachability analysis checks whether any path from our code reaches that function. It helps us focus. It is not a guarantee: some code paths are hard to see, so we review results and rerun them on each release."
The limit is in the last two sentences. Keep it.
FAQ three: how will you tell me if a vulnerability affects my deployment?
Draft:
"When a vulnerability is disclosed in a component we use, we assess it and tell affected customers a status: under investigation, not affected, affected or fixed. We can provide this as a VEX document for customers who use one. We name the versions covered and the date."
The four statuses come from CISA's minimum elements for VEX. The OpenVEX specification adds that a not affected claim needs a justification label or an impact statement, so be ready to provide one.
A table to test each answer
| Check | Question |
|---|---|
| True | Can we show a record for this on request? |
| Limited | Does it state what we do not claim? |
| Consistent | Does it match our policy and questionnaire answers? |
| Owned | Who updates it, and when was it last reviewed? |
What to leave out
Leave out percentages, speed claims and comparisons with other companies unless you can source and defend them. Avoid words like "best", "complete" and "guaranteed". Do not mention certifications you do not hold, and do not describe an audit as finished when it is in progress.
Keep it linked to reality
Review the page when your policy changes. A mismatch between the public page and your internal rule is the kind of thing an auditor finds by simply reading both. For deeper reading, see how to explain reachability to a customer security reviewer.
Quick check
Should the trust page show our policy windows?
Only if you are willing to be held to them. Many teams describe the process publicly and share windows under NDA.
Do we need a VEX example on the page?
Not required. Offering to provide one on request is enough.
Safeguard offers reachability analysis and policies that back claims like these with records. You can try the free scan.
Sources
- Known Exploited Vulnerabilities Catalog, CISA
- Minimum Requirements for VEX, CISA
- OpenVEX specification
Last reviewed: 19 October 2026.
