Often yes. A stale trust page asserts things that may no longer be true, and a buyer who finds one error doubts the rest. A short, dated page with accurate claims beats a long one that has drifted. When you cannot maintain a section, remove it or label it clearly with a date.
What the standard says about stale data
RFC 9116, which defines the security.txt file, makes this point directly for contact details. It says that not having a security.txt file may be preferable to having stale information in it, because reports can go to the wrong place and issues can be exposed. It requires organizations to use the Expires field so researchers know when the data stops being valid, and it says information in the file and in any referenced pages, mailboxes, and phone numbers should be kept current and under the organization's control.
You can borrow that idea for a whole trust page: every section should say when it was last confirmed.
Signs your page has drifted
- The audit status names a period that ended long ago.
- Named people have left the company.
- The subprocessor list does not match your current contracts.
- Links point to a retired document or a 404.
- The page describes a product name or feature that no longer exists.
- Claims use present tense for work that was only planned.
A drift audit in ten minutes
Open the page in a private window and do the following.
- Click every link. Note any that fail.
- Read each date. Anything older than your review rhythm gets flagged.
- Compare the subprocessor list to your vendor register.
- Send a test message to the security contact and see who answers.
- Search the page for words like certified, compliant, and guaranteed, and check each against its evidence.
Write the flagged items in a list with an owner and a date.
Choose: fix, date, or remove
For each stale item, pick one.
| Situation | Action |
|---|---|
| Still true, not recently confirmed | Confirm now and update the date |
| Partly true | Rewrite to what is true today |
| Unknown | Remove until someone can confirm |
| Planned, not done | Move to a dated plan, label it as planned |
Removal feels like a loss, but a smaller accurate page is easier for a customer to trust and easier for you to defend.
Put dates where readers look
Add a visible "last reviewed" line to the page and to each major section. Dates also help answer engines and search tools show the right version. If you publish files, such as SBOMs, include the timestamp inside the file as well. CISA's 2026 minimum elements define the SBOM timestamp as the date and time of the most recent update to the data, with a new timestamp for each version.
Where Safeguard fits
Safeguard's compliance and evidence automation supports keeping evidence current, and its continuous SBOM and dependency scanning keeps inventory data fresh. Try a free scan at gold.safeguard.sh/scan.
Quick check
How often should I review my trust page?
At least quarterly for fixed content, and whenever a subprocessor, audit status, or product change alters a claim.
Should I delete a section I cannot keep current?
Yes, or label it with the date it was last confirmed. An old unlabeled claim does more harm than a missing one.
Sources
- RFC 9116: A File Format to Aid in Security Vulnerability Disclosure
- 2026 Minimum Elements for a Software Bill of Materials (SBOM), CISA
Last reviewed: 19 October 2026.
