Show live data only where you can keep it accurate, and label everything else with the date it was true. Policies and audit periods are point-in-time. Dependency counts, open findings, and uptime can be live. Always say which is which, and give a source and timestamp for each number.
Two kinds of fact
A trust page mixes facts that change at different speeds.
| Fact | Type | How to show it |
|---|---|---|
| Policy text | Point-in-time | Version and review date |
| Audit report period | Point-in-time | Period and issuing firm, once issued |
| Subprocessor list | Changes on events | Last updated date |
| SBOM for a release | Point-in-time per release | Timestamp and version |
| Open advisories | Live-ish | Updated date and link |
| Service availability | Live | Link to a status source |
The risk is not that some facts are old. The risk is that an old fact looks current.
Timestamps do the work
The 2026 CISA SBOM minimum elements make this point for SBOMs. The timestamp records the date and time of the most recent update, and each version has a new timestamp. The Frequency element says each software version or update should have an associated SBOM, and that new details or corrections should lead to a revised one. A customer reading an SBOM should be able to tell which release and which moment it describes.
Apply that idea page-wide. Next to every number, add a date. Next to every report, add the period it covers.
Why continuous matters for the inventory
A one-time scan misses what happens after release. New vulnerabilities are disclosed against components you already shipped. CISA's guidance notes that after learning about a new vulnerability, an organization can check its SBOMs for the component, which speeds response. That only works if the SBOMs and the matching process are kept up to date.
For the trust page, that means two things: say how often you re-check your inventory, and keep that statement true. "We re-scan on every release and check for newly disclosed issues daily" is a testable claim. If it is not true, do not write it.
Do not overpromise on live data
A live widget that shows green all the time raises questions. Avoid showing a single score without explaining it. If you show counts, define them: of what, measured how, when. A buyer who cannot interpret a number will either ignore it or ask you to explain it.
Offer a snapshot on request for those who need evidence for an audit. A dated export is easier for an auditor to file than a screenshot of a dashboard.
A short rule set
- Every number gets a date.
- Every report gets a period.
- Every live element gets an owner who watches it.
- If you cannot keep a live element accurate, replace it with a dated snapshot.
- State your re-check rhythm and meet it.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how monitoring catches changes after a release. That is the difference between a snapshot and a live view.
Where Safeguard fits
Safeguard's SBOM and dependency scanning and its continuous approach help keep inventory data current between releases. A free scan is at gold.safeguard.sh/scan.
Quick check
Should a trust page show live vulnerability counts?
Only if you define them, own them, and can keep them accurate. Otherwise a dated snapshot is safer.
How do I show that a report is current?
State the period it covers and the date it was issued, and say what comes next.
Sources
Last reviewed: 19 October 2026.
