Shipping every week? Five changes that put your privacy policy out of date.

On a Tuesday in March somebody on your team swapped the transactional email provider. Deliverability had got worse, the alternative was cheaper, and the migration was an afternoon's work: one environment variable, a different client library, sixty lines of template. Nobody opened a ticket for the legal side, because nobody saw a legal side.

From that afternoon on, every email address in your database is disclosed to a company that was not there on Monday, on servers nobody at your company picked and possibly outside Europe. Your privacy policy still names the old provider, or nobody at all, and is still the version you published at launch.

Six weeks later an enterprise prospect sends a security questionnaire. It asks you to list every third party that receives customer data and where each one processes it. You answer from the running system, because that is what you know, and the reviewer reads your answer with your published privacy policy open beside it.

That gap, between a document written once and a product that ships every week, is privacy policy drift. Most people arrive at it hoping the answer is a calendar. A calendar cannot work here, because for at least one kind of change the deadline falls before the change goes live.

So if you run a live product against a privacy policy you wrote once, you need to know which changes move that document, and to catch them as they happen. Otherwise the mismatch surfaces in somebody else's review before it surfaces in yours.

What is privacy policy drift?

A privacy policy does not read like a policy. It reads like a description, because that is what GDPR Article 13 asks for: where you collect personal data from a person, you tell them who you are, what you are doing with the data, on what legal basis, who else receives it, whether it leaves the EEA, and how long you keep it 1. Every one of those is a factual claim about a running system. Claims about a running system stop being true when the system changes, and nobody edits the document at the moment that happens. Two decades of the public record agree: Amos et al.'s study of a million privacy policies found them consistently failing to name the third parties and tracking technologies their sites were running.

Transparency is not something you did once in 2018. Guidelines endorsed by the European Data Protection Board 4, the body that coordinates the EU's national privacy regulators, say that being accountable for it "applies not only at the point of collection of personal data but throughout the processing life cycle" 2.

Which product changes make a privacy policy wrong?

Five stand out, named across two lists in guidance the EDPB has endorsed 2.

1. A new purpose for data you already hold. You built support ticket storage to answer tickets, and this quarter you started running analytics over the same tickets, or sending them to a model to draft replies. Nothing new was collected. The purpose changed. Telling people is not the whole of it: a new purpose has to be compatible with the original one under Article 6(4) or rest on a legal basis of its own, before the question of when to disclose it arises 1. And a model call rarely stops at the purpose: an LLM API adds three disclosures of its own, starting with the vendor behind it.
2. A change to the identity of the controller. You reincorporated, moved the contracting entity to a holding company, or were bought in a way that moves that entity (a share purchase usually does not). The name and contact details in the policy are now somebody else's.
3. A change to how people exercise their rights. You replaced the support address, moved the delete-account flow, or changed where a data request goes. The route you published no longer exists.
4. A new category of recipient. Someone added a vendor that receives personal data: the email provider above, an error tracker, a session replay tool, a support desk, a model API. It is also the change that goes missing at scale: when Timothy Libert audited 200,000 privacy policies against the data flows of a million sites, fewer than 15% of the flows he could attribute to a company were disclosed by the site producing them.
5. A transfer out of the EEA. The vendor in item 4 processes the data outside Europe. Article 13(1)(f) makes that its own disclosure, separate from naming the recipient, and it has to say whether the Commission has decided the destination offers adequate protection, or which safeguard the transfer rests on instead 1. Regulators have enforced on exactly this change: Sweden's privacy authority ordered four companies to stop using Google Analytics over the personal data their sites sent to the United States, fining Tele2 12 million kronor.

Four of these happen inside ordinary sprint work, with nobody in the room thinking about a legal document. Moving the contracting entity is the exception, since it already has lawyers attached to it.

Neither list is exhaustive, and other parts of the document drift on the same deploys. Taking log retention from thirty days to twelve months rewrites the storage period you published, and legal bases and automated decisions sit in Article 13 too 1. I start with the five above because they are the ones the guidance attaches a notification duty to.

Does every new vendor change the document?

Usually, and the room to say no is narrower than it looks. Article 13(1)(e) asks for "the recipients or categories of recipients of the personal data" 1, so a policy may name your email vendor or describe a category instead. The same guidance is specific about which to prefer: controllers must give the information that is most meaningful to users, "in practice, this will generally be the named recipients", and a category is acceptable only when it is as specific as possible about the type of recipient, the industry, the sector and sub-sector, and where the recipients are 2.

So "email delivery providers" is not the hiding place it looks like: a category written to that standard carries a location, which moves when the vendor moves. If it were my document I would name the vendors, accept that it moves more often, and build for the moving. The transfer disclosure does not care either way, since a new country is a new disclosure whichever style you chose.

When do you have to tell users, and is editing the page enough?

For a new processing purpose, before the processing starts. Article 13(3) is explicit: where you intend to further process personal data for a purpose other than the one it was collected for, you "shall provide the data subject prior to that further processing with information on that other purpose" 1. The deadline attaches to the moment the new processing begins, so shipping the feature and disclosing it at the next review is already late.

For the other four the GDPR sets no timing, and the EDPB-endorsed guidance fills the gap. Where a change is fundamental to the nature of the processing, or is merely relevant to and likely to impact the user, the information "should be provided to the data subject well in advance of the change actually taking effect", by a method that is explicit and effective, so the user has time to consider it and to exercise rights such as objecting or withdrawing consent 2.

Quietly editing the published page falls short on both counts, because nothing about it reaches the user or arrives in advance. The guidance is blunt about the sentence most policies carry: telling users they should regularly check the policy for changes or updates is "considered not only insufficient but also unfair in the context of Article 5.1(a)" 2. A notification has to arrive by a modality devoted to the change, an email or a letter or a pop-up rather than something folded into a marketing send, and it has to meet Article 12(1)'s concise, intelligible, plain-language bar 1. The guidance also asks you to explain what the change will mean for the reader 2.

Why does an annual privacy policy review miss all of this?

Because the review runs on the calendar and the obligation runs on your deploys.

Hold those changes against a weekly release train. A purpose change owed its notice before the code ran, and a new vendor owed advance notice before the change took effect, months before any review. All a review can establish is how long the document has been wrong.

Reconstruction is the second problem. A review asks somebody to remember which of the last few hundred merges touched personal data, and almost nobody can produce that list from memory. What happens instead is a skim for anything that looks stale, which finds the vendor you remember and misses the one you do not. I would not keep an annual review as the primary control here.

The people who actually open your privacy policy are a prospect's security reviewer, a customer's legal team during a DPA negotiation, and a user who wants to know where their data goes. All three read it against the product you are running now. In 2026 regulators are looking as well: the EDPB launched a coordinated enforcement action on transparency under Articles 12, 13 and 14 on 19 March, with 25 authorities contacting controllers and aggregating findings in the second half of the year 3.

How do you catch drift at the change instead of at the review?

Move the check to the moment the change is made, the only moment anyone knows what changed and why.

Four things I would do this week, none of which need a new process:

• Put four of the five on your pull request template, as one question: does this change use existing data for something new, change how a user exercises a right, add a recipient, or move data out of the EEA? The entity change is left off, because a legal entity does not move in a pull request. Whoever opens the PR knows the answer and will never know it as well again.
• Get the vendor inventory out of people's heads. One list of every third party that can receive personal data, with the country it processes in. If you already publish a sub-processor list, that is the same artifact, and it has to agree with your policy's recipient and transfer sections. The browser's network tab is the fastest audit: in our crawl of 458 Product Hunt launches, 59.7% of the products with a policy and a third-party script said nothing about international transfers.
• Write down whether the policy names vendors or categories, and make the text consistent with the choice.
• When one of these happens, publish the new version before the change goes live, with its effective date set to the day the change takes effect, and tell users through a channel devoted to it.

All four still depend on somebody noticing, which is what we built Lawcel for. It keeps a company's legal documents matching the product it ships: it connects to GitHub, Linear or Jira, reads each change as it lands, works out whether the change makes a published document wrong, and comments the answer on the pull request, naming the affected documents with suggested text. Behind those documents it keeps a record of the facts they rest on: the third parties that receive data, the transfers out of the EEA, and the notice periods you promised in your own terms and DPA. Publishing a new version lets you stamp it with an effective date, so the text can go up ahead of the deploy it describes and still tell readers when it starts to apply.

Your privacy policy was true the day you wrote it. If you would rather not discover in a procurement review which sentence stopped being true in March, connect the repository your product ships from and let the next pull request raise it.