Account emails
We've updated our privacy policy: when a small app must send that email, and what goes in it
Most "We've updated our privacy policy" emails say nothing: a link, a line about how much the company values your privacy, and no hint of what moved. A small app doesn't need to copy them, and often doesn't need to send one at all. Here's when the email is owed and when a new date on the page is enough, how much notice the big services give, the three lines the email has to carry, why it goes to people who opted out of your newsletter, and the changes no email can make on its own.
The short answer: fixing typos or wording needs no email. A new use for people's data, a new kind of company receiving it, a move outside the EU, a new owner, or a new way to reach you about privacy does. Send it before the change, 30 days is the common figure, on its own with nothing to sell, and say three things: what changes, from when, and what the person can do. If the new use covers data you already hold, the email isn't enough: you need a yes.

Email, or just change the date on the page?
The GDPR asks you to tell people what you do with their data when you collect it (Articles 13 and 14). It says nothing about changes. The EU data protection authorities filled that gap in their transparency guidelines (WP260, endorsed by the EDPB): a "substantive or material" change has to be actively brought to people's attention, and three changes always count: a new purpose, a new controller, and a change in how people exercise their rights. Their example of a change that doesn't count: "corrections of misspellings, or stylistic/grammatical flaws". The test in between is the impact on people and how surprising the change would be to them.
| The change | Email? | When |
|---|---|---|
| Typos, wording, layout, a clearer heading | No. Update the "last updated" date | Any time |
| Yearly review with nothing new (California asks for one every 12 months) | No. New date only | Any time |
| New address or form for privacy requests | Yes (always, per WP260) | Before, or on the day at the latest |
| The company is sold, merged or renamed (a new controller) | Yes (always) | Before the switch |
| A new kind of recipient: an analytics, ads or AI vendor that gets personal data | Yes | Well in advance: 30 days is common |
| Data moves outside the EU/EEA, e.g. a US host or a US support tool | Yes | Well in advance |
| A new purpose for data you already hold: ads, selling it, training a model on customer content | Yes, and a yes from the person | Before you start; no yes, no new use |
| A new feature that collects new data only from people who use it | Optional. Tell people where they switch it on | At the point it's collected |
When unsure, ask the guidelines' own question: would a customer be surprised to learn this from a news story rather than from you? If yes, send the email.
How much notice: what "well in advance" looks like in practice
No law gives a number for privacy notices. WP260 (paragraph 30) asks for notice "well in advance of the change actually taking effect" for fundamental changes, long enough for people to consider it and to object or withdraw consent before it applies. Terms of service at the big services put numbers on it:
| Service | Notice for material changes | How |
|---|---|---|
| GitHub | At least 30 days before the change takes effect | A notice on the site or an email to the account's primary address |
| Dropbox | Effective no less than 30 days after notice; its current terms (from 7 January 2025) are set to change on 1 January 2027 | Email to the account address or an in-product notice |
| Microsoft | The current Services Agreement was published 30 July 2026 and takes effect 30 September 2026: 62 days | With a summary of the most notable changes |
| "Reasonable advance notice", none for new features or urgent legal or abuse cases | Not specified in the terms | |
| Slack | "Reasonable notice" | Email to the account address or a message in Slack |
For a small app, 30 days before the change is a safe default: it matches GitHub and Dropbox, gives people a full billing month to leave if they pay monthly, and is long enough to apply the opt-outs that come back. A new privacy contact address can go out with a week's notice, as long as the old one keeps working for a while.
The three lines that matter
WP260 says the notice should be concise and in plain language, and that the company "should also explain what will be the likely impact of those changes". In an email that comes down to three things, in this order, in the body itself rather than behind a link:
- What changes, one numbered line per change, in the reader's terms: what data, going where, for what. "We've clarified our data practices" isn't a change; "crash reports go to a service in the United States" is. Say what doesn't go ("never your invoices") when that's the question people will ask.
- From when, as a date with the weekday, and "until then, nothing changes".
- What the person can do: nothing, a setting to switch off (with the menu path), or leaving with their data. If there's no choice at all, say how to object or ask questions.
Then two links: the new policy with the changes marked, and the old version people agreed to, at a dated address. Here's the email from the picture, for an invoicing app with EU customers:
Subject: Tallybook privacy policy: two changes from 1 December 2026
Hi Sam,
From Tuesday 1 December 2026 we're changing two things in how
Tallybook handles your data. Until then, nothing changes.
What changes
1. Crash reports go to an error-tracking service in the United
States. When the app breaks, it sends the error, your browser
and your account ID. Never your invoices or your clients'
details. The transfer is covered by the EU-US Data Privacy
Framework.
2. Privacy requests (a copy of your data, a correction, deletion)
go to privacy@tallybook.example. The old address forwards
until Monday 1 March 2027.
What you can do
- Nothing, if you're happy with this.
- Keep crash reports off for your account: Settings > Privacy >
"Send crash reports", before 1 December.
- Leave: export your invoices and close the account at any time,
in Settings > Account.
The new policy, with both changes marked:
https://tallybook.example/privacy/2026-12
The version that applies until 30 November:
https://tallybook.example/privacy/2025-03
Questions? Reply to this email. It reaches a person.
Tallybook, Example Ltd, 1 Sample Street, Dublin
You're getting this because you have a Tallybook account.The subject names the app, the topic and the date. "Important update" and "We've updated our terms" are what phishing emails say too, and people have learned to skip both.
It's a service message, so it goes to everyone
In the US, CAN-SPAM's rule lists this exact email as a "transactional or relationship message": for a subscription, membership or account, a "notification concerning a change in the terms or features" (16 CFR 316.3(c)). In the UK and EU, the ICO treats administrative and customer-service messages as outside the marketing rules, until promotional content is added. So the email goes to every account holder the change affects, including people who unsubscribed from your newsletter.
That status holds only while it stays a notice. Under CAN-SPAM's primary-purpose test, a subject line that reads like a promotion, or a body where the change isn't at the beginning, turns it into a commercial email. WP260 says the same from the privacy side: a notice of changes should be "specifically devoted to those changes (e.g. not together with direct marketing content)". No "while you're here, try Pro", no discount banner. The full line between the two kinds is in Transactional or marketing?
Changes no email can make on its own
The email informs. It doesn't turn an old promise into a new one. Regulators on both sides have said so:
- US, FTC. In 2004 Gateway Learning (Hooked on Phonics) changed its privacy policy to rent out customer data it had collected under a promise not to, without telling customers or asking them; the FTC charged it. In 2023 it charged the genetic testing company 1Health for retroactively widening who it could share data with. In February 2024 the FTC warned that adopting more permissive data practices through "a surreptitious, retroactive amendment" to terms or a privacy policy may be unfair or deceptive.
- EU. A new purpose has to be announced before the new processing starts (Articles 13(3) and 14(4)), and WP260 adds that transparency doesn't "whitewash" a change so big that the processing becomes something else. It still needs a legal basis, often consent.
In practice: if you want to use data you already hold for something new (ads, selling it, training a model on customer content), apply the new rule to new data only, or ask for an opt-in and leave everyone who doesn't answer on the old terms. "By continuing to use the service you agree" does not count as that yes.
Wording matters as much as the change. In July 2025 WeTransfer announced terms due to take effect on 8 August that gave it a perpetual licence to use uploaded files, including to improve machine learning models for content moderation. Users read it as AI training on their files. Within about two weeks the company said it doesn't train AI on user content, removed the machine learning reference and narrowed the licence. An email that had said plainly what it would and wouldn't do with files would have saved that fortnight.
Lines not to write, and what to write instead
| Don't write | Why | Write instead |
|---|---|---|
| "Your privacy is important to us. We've updated our privacy policy." | Says nothing changed for the reader to judge | "From 1 December, crash reports go to a service in the United States." |
| "We've made some changes to better serve you." | Hides the impact WP260 asks you to explain | "It sends the error, your browser and your account ID. Never your invoices." |
| "By continuing to use Yourapp, you agree to the new policy." | Not consent for a new use of old data | "Switch it off in Settings > Privacy before 1 December." |
| "Please check this page regularly for updates." (in the policy) | WP260: "not only insufficient but also unfair" | "We'll email account holders at least 30 days before a material change." |
| "Important update to your account" (subject) | Reads like phishing; says nothing | "Yourapp privacy policy: two changes from 1 December 2026" |
| A Pro plan offer under the notice | Makes it marketing; breaks the service-message status | Nothing. Send the offer another day, to people who opted in |
| Sent from a no-reply address | People's first move is to ask a question | A reply-to that reaches a person, or the privacy address |
Sending it: the dates for 4,000 accounts
Work back from the day the change takes effect. Tallybook's change applies on Tuesday 1 December 2026, so the last email has to leave by Saturday 31 October to give everyone at least 30 days (31 for the last one). On email59's free allowance of 200 emails a day, 4,000 accounts take 4,000 ÷ 200 = 20 days, so the first batch goes on Monday 12 October. That allowance also carries your sign-in codes and receipts, so leave room for them, or buy credits and send the whole list in one afternoon.
- Send one email per person, from the address your app normally uses, with a reply-to that a person reads.
- Show a banner in the app from the same day for people who never open email, until the change takes effect.
- Keep a record of who was sent the notice and when: the GDPR's accountability principle (Article 5(2)) means you may have to show it.
- Apply the opt-outs that come back before the date. The point of the notice is that people can act on it.
With email59 it's the same call as a receipt. category is transactional by default and transactional mail still goes to people who unsubscribed from your marketing:
curl https://email59.com/v1/send \
-H "Authorization: Bearer $EMAIL59_KEY" \
-H "Content-Type: application/json" \
-d '{
"from": "yourapp",
"to": "sam@example.com",
"reply_to": "privacy@yourapp.example",
"category": "transactional",
"subject": "Yourapp privacy policy: two changes from 1 December 2026",
"text": "Hi Sam,\n\nFrom Tuesday 1 December 2026 we are changing two things ..."
}'After the email: the page itself
- An effective date at the top. California's online privacy law (CalOPPA, Business and Professions Code 22575) requires one, and the CCPA rules require the date the policy was last updated.
- Say how you'll announce changes. CalOPPA also requires the policy to describe how you notify users of material changes. One line does it: "We'll email account holders at least 30 days before a material change takes effect."
- Keep every old version at its own dated address (
/privacy/2025-03), linked from the current one. When someone asks what they agreed to in 2025, you can show them. - A short list of changes at the top or bottom, matching the email.
Terms of service changes follow the same pattern: the three lines, 30 days, a dated old version. A price change has its own rules on notice and cancelling, covered in Prices are going up. And when someone takes the third option and leaves, these are the emails before, during and after an account is deleted.
Send your app's notices with email59 One call per email, 200 a day free, and notices still reach people who left your newsletter.
Sources: Article 29 Working Party, Guidelines on transparency under Regulation 2016/679, WP260 rev.01 (11 April 2018, endorsed by the EDPB), paragraphs 29 to 32; GDPR Articles 5(2), 13(3) and 14(4); 16 CFR 316.3 (CAN-SPAM rule: primary purpose and transactional or relationship messages); ICO guidance on direct marketing using electronic mail (service messages); FTC Office of Technology, "AI (and other) companies: Quietly changing your terms of service could be unfair or deceptive" (13 February 2024), on Gateway Learning (2004) and 1Health (2023); GitHub Terms of Service, section R; Dropbox Terms of Service (effective 7 January 2025, change announced for 1 January 2027); Microsoft Services Agreement (published 30 July 2026, effective 30 September 2026); Google Terms of Service; Slack User Terms of Service (all read 26 October 2026); California Business and Professions Code 22575(b); California Civil Code 1798.130(a)(5) and 11 CCR 7011; reporting on WeTransfer's terms change by The Register (18 July 2025) and City A.M. (July 2025).
GitHub, Dropbox, Microsoft, Google, Slack and WeTransfer are trademarks of their owners. email59 is not affiliated with them. Tallybook is a made-up example. This article is general information, not legal advice.