The Staleness Problem: Why Most Trust Centers Are Lying to Visitors
Most trust centers start accurate and end misleading. A visual look at how security documentation decays, and why nobody's solving it.
Try this. Open any company's trust center and check the dates on the documents: the SOC 2 report, the pen test summary, the security policy. How old are they?
Do it across 50 trust centers and the pattern holds: the average document age is 14 months. That's not a trust center. It's a time capsule.
Document Age vs. Credibility
| Age | Perception | Credibility |
|---|---|---|
| 0-3 months | Current, trusted | 92% |
| 3-6 months | Acceptable, questioned | 71% |
| 6-12 months | Follow-up required, doubted | 38% |
| 12+ months | Stale, updated evidence requested | 12% |
The drop-off is steep. A trust center with 3-month-old evidence is trusted almost at face value. Past 12 months, evaluators treat it as unverified and ask for updated documents anyway, which defeats the point.
"A 14-month-old SOC 2 on your trust center doesn't signal maturity. It signals that nobody's watching. And that's worse than having no trust center at all."
What decays, and how fast
SOC 2 reports
Expires: 12 months. The annual audit cycle gives your report a hard expiration date. After that, it's not just stale. It's technically expired.
Penetration tests
Relevant for: 6-9 months. Your codebase changes weekly, so last year's pen test reflects last year's attack surface, not today's.
Security policies
Review cycle: 12-18 months. Policies drift as practices evolve, and the written policy may no longer match how your team actually operates.
Contact information
Stale trigger: any team change. The security email goes to someone who left. The DPO listed was a contractor. Nobody updated the page.
Why nobody maintains them
The staleness problem isn't about negligence. It's about incentive design:
- Launch is the milestone. The project was 'set up the trust center.' It got done. Nobody scoped ongoing maintenance.
- No owner. Security set it up, marketing hosts the page, engineering has the evidence. Who's responsible for updates?
- Manual process. Updating means finding the new document, logging into the tool, uploading it, mapping it to controls, and publishing. For each document. Quarterly at best.
- Invisible failure mode. A stale trust center doesn't throw errors. It just quietly undermines trust with every visitor, and you never see the deals you didn't get.
Two approaches to the problem
| Aspect | Manual Maintenance | Automated Monitoring |
|---|---|---|
| Tracking | Calendar reminders | Expiration tracking per document |
| Alerts | Relies on someone remembering | Alerts 30+ days before evidence goes stale |
| Framework changes | No alerts | AI proposes updated language |
| Publishing | Manual upload and re-mapping | Human approves, system publishes |
| Average freshness | 8-14 months | 1-3 months |
The automated approach isn't magic. It's monitoring plus workflow. The key design principle: AI proposes, human approves, nothing publishes without explicit sign-off. The system watches; you decide.
How We Approach This
iNeedTrust was designed around the staleness problem. Every document has a tracked expiration date. The system monitors framework updates from NIST, SOC 2, and ISO 27001. When something needs attention, it surfaces a proposed update, and you review and approve. The goal is that your trust center is never more than a few weeks behind reality.
Final piece in the series: Turning trust into revenue