Keeping legal content current: why change starts outside the document

In short

A published legal text does not go out of date because someone wrote it badly. It goes out of date because something around it moved. Three kinds of movement typically create a reason to review: the legal framework changes, the website or the offering changes, or the version that is live is no longer the version that was approved.

These three triggers have different origins, different evidence and different consequences. Separating them is the difference between a traceable process and an annual full re-read that nobody enjoys and that still leaves gaps.

This guide sorts the three triggers and shows what a review process that absorbs them looks like. It does not answer the underlying legal questions — whether a specific change requires a specific edit is a legal assessment.

Three reasons a legal text becomes review-worthy

Most advice on this topic recommends an interval: review once a year, better every six months. An interval beats nothing, but it does not address the actual problem — that change does not happen on a calendar. It happens when a legislator, a product team or a deployment causes it.

A distinction by cause is more useful in practice:

• The legal framework moved. A new or amended rule, a new disclosure duty, a shifted interpretation. The text is unchanged; what is expected of it is not.
• Reality moved. A new tool on the website, a new payment provider, a new offering, a new market. The text may now describe a state of affairs that no longer exists in that form.
• Delivery diverged. A new version is approved internally, the old one is live. Or the German version is current and the English one lagged behind. Everything is decided — it simply did not arrive.

The third case is easy to overlook because it does not feel like a content problem. Operationally it is the most common one: it appears during relaunches, in caching, in copied full texts and in email templates nobody maintains alongside.

Trigger 1: the legal framework changes

Legal change is the trigger people think of first — and the one where most effort flows in the wrong direction. The usual sequence: a newsletter, a law-firm mailing or a trade portal reports a change. Then the actual work begins, which is working out whether and where it lands at all.

That question is rarely answered with “affects every document” or “doesn't concern us”. It depends on which brands are operated, in which markets, with which document types and which business model. A change that matters for one brand's B2C shop may have no consequence for the same company in a B2B context.

So the effort is not in editing, it is in narrowing down. How to structure that narrowing is covered in a law changed — which of your legal documents actually need reviewing?

Trigger 2: website, product and business reality change

The second trigger is the quieter one. Legal texts describe a state: which services are embedded, how orders are placed, who the contracting party is, which data is processed for what. That state does not change in a legislative procedure. It changes in a sprint.

An analytics tool is added, a chat widget embedded, a payment provider swapped, a newsletter form introduced, a new language rolled out. Any of these can mean the published text no longer fully reflects the actual state — but it need not. A new frontend framework typically changes nothing about data processing; a new vendor quite possibly does.

So the useful question is not “did the website change?” but “did something change that the legal text describes?” — and whether that change is evidenced well enough for someone to judge it. The guide your website changed — should your legal content be reviewed too? goes into detail.

Trigger 3: what is live is not what was approved

The third trigger has nothing to do with content. It appears when a decision was made and documented but never reached the place where it should be visible. That state is called legal content drift here.

Typical patterns:

• Version 4.2 is approved, the footer still serves 3.9.
• After a relaunch the CMS still points at the old privacy page.
• Order confirmations attach a PDF that is two versions behind.
• A landing page carries a copied version that was never brought along.

Drift is an operational state, not a legal assessment — but unlike the first two triggers it can be established objectively: either the delivered version matches the approved one or it does not. The basics are in what is legal content drift? — and the distinction from trigger 2 in website change or legal content drift?

Why this gets disproportionately harder as the portfolio grows

With one website carrying four legal texts in one language, all of this is manageable. The effort does not scale linearly though — it scales across several axes at once:

• Brands: a company with five brands has five legal notices, five privacy policies, five sets of terms — partly identical, partly deliberately different.
• Languages: every language version is its own delivery state that can lag behind separately.
• Markets: the same text may carry different mandatory information depending on the target market.
• Channels: website, app, order confirmation, contract documents and checkout all show the same text in different places.

“Four documents” turns into several dozen delivery states fast. A change notice that starts as one line in a newsletter ends up as a matrix. And the effort lives in that matrix — not in the wording. How to model variants without duplicating full texts is covered in how TermShelf models variants for language, market and site profile.

What a workable review process has to do

Independently of the tooling, five requirements can be named that a process can be measured against:

• Notice the trigger. There has to be one place where changes accumulate — rather than hoping the right person reads the right notice.
• Narrow the relevance. A trigger has to be broken down to concrete brands, markets and documents, otherwise every notice becomes a full audit of your own material.
• Evidence it. Whoever assesses it later needs the evidence: what exactly was observed, when, and where.
• Let humans decide. The assessment belongs to people with the relevant qualification — including the decision that nothing needs doing.
• Publish traceably. What was decided has to be captured as a version and delivered under control — otherwise trigger 3 appears immediately.

The last point closes the loop: a clean approval and publishing process is also the most effective prevention against drift. More on that in review workflows for legally relevant website content.

How TermShelf models the three triggers

TermShelf is a system for Legal Content Operations: for running already-published legal texts, not for drafting them. Its observation layer is called Document Intelligence, and it maps exactly the three triggers above as distinct signals:

• Legal Change Monitoring tracks publicly available legal sources and assesses change events in the context of your own brands and the documents you actually publish.
• Website Change Monitoring detects changes on a monitored website, evidences them and relates them to a possible need to review. This signal is marked beta: available and under active development.
• Legal Content Drift reconciles the version visible in production against the approved one — per website, language and market.

Each signal results in a review finding with evidence, status and history. A confirmed finding can become a proposed change as an unpublished draft. Nothing is adopted or published automatically — every proposal runs through review and approval. The full chain is described in from change signal to review finding.

What this does not do

TermShelf does not produce legally binding content and is not a substitute for legal advice. An observation layer can surface triggers and prepare them; it does not establish legal consequences and does not promise to catch every relevant change. Public sources are incomplete, website detection is heuristic, and whether a detected trigger actually requires an edit is a professional assessment.

The value sits elsewhere: changes accumulate in one place, carry evidence and feed a documented decision process — instead of disappearing into an inbox. The feature overview lists what exists; the glossary defines the core terms.