How to track vendor terms of service changes
Your vendor's terms changed last quarter. Nobody noticed.
Not because anyone was careless. The change was announced the way these changes are always announced: a line item in a product-update digest, or an email to the billing contact who left in March. Sometimes there is nothing beyond a new date on a terms of service page you have no reason to open. Somewhere in that page the liability cap moved, or the uptime credit you priced into your own customer SLA quietly became discretionary. You are still paying the invoice, which in most vendors' reading means you agreed.
This is the practical case for learning to track terms of service changes across the vendors you actually depend on. A handful of pages on a handful of vendor sites carry real money and real compliance exposure, and none of them will interrupt you when they move.
The notice you were promised is a notice designed not to work
In most cases a vendor can change its terms of service without telling you directly, because the contract you signed says it can. Vendors do technically notify. The notification is engineered to be dismissible.
The standard clause reads some version of "we may update these terms from time to time; your continued use of the service constitutes acceptance of the revised terms." That sentence does two things at once. It transfers the monitoring obligation to you. And it treats ordinary inaction as consent, so paying an invoice or leaving an integration running becomes your signature. The only durable artifact of the change is a "last updated" date, which tells you that something moved without telling you what.
Courts have been less impressed by this than vendors would like. In Douglas v. Talk America, the Ninth Circuit held that a company could not amend an existing customer contract by posting revised terms on its website, writing that parties to a contract "have no obligation to check the terms on a periodic basis to learn whether they have been changed by the other side." Regulators have made a parallel point about privacy terms specifically. In February 2024 the FTC published a warning that quietly changing your terms of service could be unfair or deceptive, aimed at companies that adopt more permissive data practices "and only inform consumers of this change through a surreptitious, retroactive amendment to its terms of service or privacy policy," pointing at a 2023 enforcement action against a genetic testing company that had retroactively rewritten its privacy policy.
So the pure post-and-continue model is generally unenforceable, at least in the US, at least against consumers. That is worth knowing and worth roughly nothing to you operationally, for three reasons. Enforceability is jurisdiction-specific and fact-specific, so it is a thing your lawyer argues rather than a thing you rely on. Most serious vendors have moved to clickwrap re-acceptance, where an admin somewhere on your team clicks "I agree" on a renewal screen, and that generally does bind you. And in every version, the remedy is a dispute, which you can only raise if you noticed. Being right two years later, in an argument you did not know you were having, is not a control.
The Silent Re-acceptance Loop
The Silent Re-acceptance Loop is the five-step pattern by which a customer accepts a contract change nobody on their side ever read. It repeats across vendors, in this order:
- The vendor edits the page and updates the "last updated" date.
- Notice goes to a channel your team does not treat as inbound: a digest, a billing alias, a status-page RSS feed nobody subscribed to.
- Nobody reads it, because nobody's job description contains "read vendor legal pages."
- Normal operations continue. The invoice is paid, the API keeps getting called.
- That continuation is later characterized, by the vendor and sometimes by a contract, as acceptance.
Its defining property is that no step requires anyone to act in bad faith. The loop works entirely on the gap between how vendors publish and how customers read, and it closes the moment one person is actually looking at the right five pages.
The five URLs to watch for every critical vendor
Five pages per vendor carry almost all of the risk. Everything else on a vendor's site is marketing.
| # | Page | What moves there | Why it costs you |
|---|---|---|---|
| 1 | Terms of service / MSA | Liability caps, indemnities, auto-renewal windows, arbitration and class-action waivers, acceptable-use limits | Changes what you can recover when the vendor causes you a loss, and how you are allowed to fight about it |
| 2 | Privacy policy | Data retention periods, new sharing categories, secondary uses such as AI training on customer data | Contradicts commitments you have already made to your own customers |
| 3 | DPA / data processing addendum | Transfer mechanisms, security schedules, breach-notification timelines, audit rights | Your GDPR Article 28 paper trail. If theirs changes, your own DPAs downstream may no longer be accurate |
| 4 | Subprocessor list | New vendors and new jurisdictions in your supply chain | This is the one with a clock on it. See below |
| 5 | SLA / uptime commitment | Uptime targets, credit formulas, definitions of "downtime," support response times | You may have resold this number in your own SLA at a level the vendor no longer promises |
The subprocessor list deserves separate attention because it is the only page in the list where missing a change forfeits a specific right on a deadline. GDPR Article 28(2) provides that where a processor operates under general written authorisation, "the processor shall inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object to such changes."
That opportunity to object is the whole point, and DPAs routinely give it a window, commonly thirty days from posting. The window runs from publication, not from the day you read it. A subprocessor addition you notice in month four is a subprocessor you have accepted, whatever you think of the jurisdiction it sits in. This is the change most worth catching on the day it happens, and it is published on the page least likely to be on anyone's reading list.
The Data, Dollars, Downtime rule
Most vendor legal changes are cosmetic. A change is worth your attention if it touches data, dollars, or downtime.
- Data. Anything altering what the vendor may do with information you gave them, who else may hold it, where it goes, or how long they keep it. New subprocessors, new secondary uses, longer retention, weakened deletion commitments.
- Dollars. Anything altering what a failure costs. Liability caps, indemnity carve-outs, auto-renewal and notice periods, price-change clauses, changes to how credits are calculated or claimed.
- Downtime. Anything altering what the vendor promises about availability and response, including redefinitions. A vendor that keeps a 99.9% target but redefines "downtime" to exclude degraded performance has cut the promise without touching the number.
Changes that fail all three tests get logged and ignored: a rebrand, a reformatted document, a new registered address, a clarified support-hours table. The rule exists to keep the watchlist survivable. A vendor watchlist that produces thirty items a month gets muted in six weeks, which is the same outcome as never building one.
The definitional trick under "Downtime" is the thing to read for, and it shows up across all three categories. The expensive changes usually land in the definitions the numbers depend on. A number is conspicuous enough that someone would query it; a defined term sits in a section most readers skip. Watch for edits to defined terms: "Confidential Information," "Personal Data," "Service," "Downtime," "Affiliate." A term redefined in a definitions section rewrites every clause that uses it, several pages away, and it is exactly the kind of edit a "last updated" date discloses nothing about.
Vendor change feeds, and where they run out
Some vendors publish their own change feed. Subscribe wherever one exists, then accept that it will cover a minority of your list.
AWS is the good case. Its AWS sub-processors page offers email updates ("if you subscribe for updates, AWS will notify you by email of changes to this page") alongside a separate page documenting what has changed. Several large vendors do something comparable for subprocessors specifically, which makes sense given that Article 28 effectively obliges them to.
Three things limit how far this gets you. Coverage is thin below the top tier of vendors, and the mid-market SaaS tools holding your customer data are usually the ones with no feed at all. Where a feed exists it is often scoped to the subprocessor list, leaving the MSA, the SLA and the privacy policy unannounced. And the vendor decides what counts as a change worth sending, which puts the definition of "material" in the hands of the party making the edit.
Two formats defeat casual watching entirely. A DPA published as a PDF can be swapped for a revised file while the page linking to it stays byte-identical, so nothing watching that page registers a change. Terms kept inside a login-walled trust center are worse, since the document is only reachable by a person with an account. For those, the fallback is a calendar reminder against the renewal date and a request to your account manager for the current executed version in writing.
What to do when a change lands
Have a response ready before the first alert, because the useful window is short.
- Diff it. Compare the new version against the previous one and find the actual edited language. This is the step that fails without preparation, since vendors rarely publish redlines and the old version is usually gone from the site the moment the new one appears.
- Classify it. Apply Data, Dollars, Downtime. Most changes stop here and go into a log.
- Check for a clock. Subprocessor objection windows, auto-renewal notice periods, and any "if you do not agree, you may terminate within N days" clause. Anything with a deadline gets handled this week, not this quarter.
- Route it to the person who owns the consequence. Data changes to whoever owns privacy commitments, dollars to whoever signed the contract, downtime to whoever wrote your own SLA.
- Log the version. Date, what changed, what you decided. Two renewals from now, this log is the only evidence of what you were actually offered when you signed.
Step one is the reason people watch these pages with tooling rather than a calendar reminder. Change monitors, the category that includes changedetection.io, Visualping and Webtingle, exist to re-check a URL on a schedule and show you a before-and-after diff of the exact language that moved. Any of them will do the job. The setup is per-page and mechanical, and the walkthrough for how to monitor a website for changes covers it, along with the options for getting notified when a website changes once you have one running.
The harder half is editorial. Decide once which five pages per vendor you will actually read when they change, and which of your colleagues owns the consequence of each. Teams that skip that step end up watching sixty pages and reading none of them, the same failure mode that sinks competitor monitoring programs.
How to find out what a page said before you started watching
Two archives can give you a previous version: the Wayback Machine for pages somebody already captured, and a snapshot you take yourself.
The Wayback Machine holds dated captures of most large vendors' legal pages going back years, which is usually enough to answer "what did this say when we signed?" after the fact. Coverage thins for mid-market SaaS, and the gap tends to be widest exactly where the risk is, so treat a hit as luck rather than a system.
The system is the snapshot you control. Archive.org's Save Page Now captures any URL on demand, free and without an account, and hands you a permanent link to that version. Run your five URLs through it the day you sign a vendor, and again whenever a change clears the Data, Dollars, Downtime test. That gives step five of the runbook something to point at, and it costs about a minute per vendor. Pages that block crawlers, and terms published only as a PDF or behind a login, stay outside this.
Which vendors are worth the trouble
Build the watchlist for the vendors whose failure lands on you, and skip the rest.
The test is whether the vendor touches customer data, sits in your production path, or bills you enough that an auto-renewal you missed would hurt. For most small companies that is four to eight names: the cloud provider, the payments processor, the CRM or database holding customer records, the auth provider. Twenty to forty pages, checked automatically, and the Silent Re-acceptance Loop stops being something that happens to you.
The vendors will keep publishing changes the same way. The only variable you control is whether anyone is reading.
Start free with Webtingle. 14-day trial, no credit card. A vendor page takes about two minutes to set up.