How often should you re-check a vendor's terms and privacy pages?
A “last updated” date tells you a page changed at some point — not what changed, not whether it matters, and not whether it happened before or after you last actually read it. Below is a practical cadence by vendor risk, and the events worth checking on regardless of schedule.
A cadence by risk, not one calendar for every vendor
Checking every vendor on the same schedule either wastes review time on low-risk tools or lets a high-risk one go unwatched for as long as the slowest tier allows. A vendor that stores regulated data, acts as a subprocessor to your own product, or sits deep in a supply chain carries more exposure from a quiet change than a marketing tool with no access to your data at all.
| Vendor risk tier | Example | Suggested cadence |
|---|---|---|
| High — processes regulated data, or is itself a subprocessor in your data path | Payment processor, a data processor named in your own DPA, an infrastructure host | Monthly |
| Medium — core SaaS vendor with broad account or data access, not itself regulated | CRM, support desk, analytics platform your team logs into daily | Quarterly |
| Low — limited or no access to your data | A marketing site tool, an internal wiki with no customer data | Twice a year, or after a triggering event below |
These are starting points, not a compliance requirement — your own contract, regulator, or internal policy may set a stricter cadence for a given vendor. Tighten the tier rather than loosen it if the two disagree.
Four events worth an off-schedule check
A fixed cadence misses changes that cluster around specific events. Check outside the normal schedule when:
- A security incident or breach is disclosed involving the vendor or one of its own subprocessors — terms and subprocessor lists are often revised in the same news cycle.
- The vendor is acquired or merges — ownership changes frequently bring rewritten data-handling, retention, or subprocessor terms within weeks.
- A pricing or plan change ships — terms edits sometimes land in the same release as a pricing announcement, and get less scrutiny riding alongside it.
- A contract renews, or a procurement review starts — capture the current text on record regardless of when it last changed, so the review has a dated snapshot rather than a memory of what the terms used to say.
Why the date on the page is not the signal
A “last updated” date is the vendor's own claim about when the page changed, worded however they choose to word it, and it is common for the same date to cover a formatting fix and a substantive clause rewrite alike. It also says nothing about when you last read the page, so a date from six months ago could sit in front of a change you have already seen, or behind one you have not. What actually answers the question is a diff against your own last capture: the section that changed, the words that moved, and the two timestamps of when each capture happened.
A first capture of a page is reported as captured, never as “unchanged” — there is nothing yet to compare it against, and a check with no basis for comparison must never read as stability. See Vendor Change Watch to capture a page and get that diff on your own schedule, in the browser or from the command line.
Common questions
How often should I re-check a vendor's terms of service?
There is no single right answer, but a practical default is to match the check to risk: vendors that touch regulated data, hold a subprocessor role, or sit deep in your supply chain get checked monthly; core SaaS vendors with broad access to your data get checked quarterly; low-risk tools with no data access get checked twice a year or simply after a news event names them. A calendar reminder is enough to trigger the check — it is the fetch and the comparison that are worth automating, not the schedule itself.
Does a vendor's own 'last updated' date tell me anything?
It tells you the page changed at some point, not what changed, not whether the change affects you, and not whether it happened before or after you last actually read the page. Many vendors also bump that date on formatting-only edits, so treating it as a signal either over-alerts on cosmetic changes or, worse, trains a reviewer to stop trusting the date at all. A source-linked diff against your own last capture answers the question the date cannot: what changed since I looked.
What should trigger an immediate re-check outside the normal schedule?
Four events are worth an off-cycle check regardless of a vendor's normal cadence: a public security incident or breach disclosure involving the vendor or one of its own subprocessors; an acquisition or merger, which frequently rewrites data-handling and subprocessor terms; a pricing or plan change announcement, which sometimes ships alongside quiet terms edits in the same release; and a contract renewal or procurement review, where you want the current text on record regardless of when it last changed.
Should every vendor get the same re-check cadence?
No. A vendor with no access to your data and no subprocessor role carries a different risk than one that stores regulated records or sits in your product's own data path. Checking both on the same calendar either wastes review time on the low-risk vendor or, more commonly, lets the high-risk one go unchecked for as long as the slowest tier in a flat schedule.
Want the mechanics of the diff itself, not the cadence? See the tool's own FAQ, or how this compares to a general-purpose watcher on this tool vs. changedetection.io.