Most privacy policy updates land as silent diffs. The legal page gets a new "Last updated" timestamp, users get a banner they dismiss, and the trust signal disappears. EFF did the opposite this month: published a companion post explaining what changed, why and how the new wording maps to specific user-facing decisions. This article extracts the playbook for any SaaS doing the same.
Why most updates erode trust
Three failure modes are common:
- Silent updates without notification
- Notification that only links to the full text, asking the user to spot the difference
- Updates framed as "clarifications" when they actually expand data use
None of these reach a regulator, but all of them lose B2B sales cycles. Procurement teams audit policy histories. A pattern of opaque updates is a red flag.
The 4 artifacts of a trust-preserving update
1. The new policy text (table stakes)
Published with a clear effective date and the previous version still accessible via a permalink. Version history visible.
2. A changelog summary at the top
3-7 bullets, plain language, in the same prominence as the rest of the policy. Cover what changed, what is new, what is removed.
3. A companion explanatory post
This is the EFF move. A blog post or notice that explains why the change happened (regulatory pressure, new product, lessons from an incident), what the user can do (opt out, request more info), and what stays unchanged.
4. An archive permalink for every prior version
Pattern: /privacy/v/3, /privacy/v/4, etc. Users and auditors can compare. This is what EFF and other privacy-forward orgs publish; it should be the default for any serious SaaS.
| Artifact | Effort | Trust signal |
|---|---|---|
| New text | Variable | Neutral |
| Changelog at top | 30 min | Strong |
| Companion post | 2-4 hours | Very strong |
| Version permalinks | One-time setup | Very strong |
The EFF post is short, around 600 words. It does not require a comms team. It does require the company to know which changes are material and which are cosmetic, then write that distinction plainly.
The notification channel matters
Where you tell users about the update changes how it is received:
- In-app banner with a single CTA "See what changed": best for active users
- Email with the changelog inline (not just a link): best for legacy users
- Footer notice only: weakest signal, but acceptable for cosmetic changes
If the update changes a material clause (new sub-processor, new data category, change to retention), in-app + email is the floor. Footer-only fails most B2B audits.
The retention question
Privacy laws (GDPR, CCPA, LGPD) require users to be notified of material changes "in advance". "In advance" is rarely defined precisely; most regulators accept 14-30 days notice. The companion post pattern double-counts as compliance with this requirement: the post timestamp documents when notice started.
From EFF's update post: "We tell you what changed, why, and what stays the same. Privacy policies are read by lawyers and by people. We want to honor both." The line is worth pinning above your next policy update.
Conclusion
The policy update itself is unavoidable; regulation moves, your product evolves, sub-processors change. The trust around the update is optional, and it is what separates SaaS that build long-term relationships from SaaS that lose B2B customers at every renewal cycle. The four artifacts above are not expensive; they are a habit.
If you want a policy hosting layer that publishes version permalinks and changelogs automatically on every update, try Termerly free and ship policy updates the way EFF does.
