Your product sends email. Notifications, digests, alerts, receipts, comment replies. Each one is a copy of some portion of your customers' data, leaving your systems, into an inbox you do not control, retained indefinitely by a provider you did not choose.
Email is the one channel where you hand data to a third party as a matter of routine and nobody counts it as a data flow.
This post is what to put in a notification and what to leave out. For whoever writes the templates.
The inbox is not a controlled environment
Four properties worth holding in mind.
It is not deleted. Your product may have a thirty-day retention policy; the notification is in a mailbox forever, and in the archives of whoever it was forwarded to.
It is forwarded and shared. To colleagues, to personal addresses, into ticketing systems, onto screens in meetings.
It is searchable by whoever has the mailbox. Including a successor after someone leaves, and including an attacker who gains mailbox access, for whom your notifications are a convenient index of your customer's activity.
It is scanned. By the provider, by security tooling, and by preview generators that fetch links.
So the question for every field in a template is not whether the recipient is entitled to see it, but whether you are content for it to exist in that environment permanently.
Notify, then link
The pattern that resolves most of it: tell them something happened and let them come and look.
Priya commented on the Q3 forecast. View it in the app.
rather than including the comment text, the document contents or the record details. The recipient is one click from the full context, in a place where your access controls still apply, where revocation works, and where you can log the access.
This costs a click and it removes the entire class. The argument against is engagement, since inline content gets read and a link gets ignored, and that is a real product trade rather than a security absolute.
What should never be inline
A short list, and each has a reason:
Credentials of any kind. Passwords, API keys, tokens. If you must deliver a token by email, make it single use with a short expiry, and remember that link preview fetchers will consume it before the human clicks.
Full identifiers. Complete card numbers, national identifiers, account numbers. Last four digits exist for this reason.
Special category data. Health, biometric and similar. The inbox is the wrong place for it regardless of consent.
Someone else's data. A digest listing what other people did is a disclosure to whoever now reads that mailbox, including a successor who was never a colleague of those people.
Anything you have promised to delete. A notification containing data you undertook to erase is a copy outside your deletion pipeline, and a deletion request cannot reach it.
The security notifications are the ones to get right
Password changed, new sign-in, multi-factor disabled, API key created, email address changed. These exist specifically to be noticed by a legitimate owner during a compromise.
Which means: send them to the previous address as well as the new one on an email change, include enough context to judge (time, approximate location, device type) without including the full precision that makes them a tracking record, and give them a direct action, a link to revoke or to lock the account, that works without first signing in through a flow the attacker may now control.
And never suppress them for being noisy. The reason to send them is the low-probability case.
Practical hygiene
Look at one of each template in a mailbox, rendered, and read every field. Templates accumulate fields as features are added, and nobody re-reads them.
Check your email provider's retention and their subprocessor status. They hold every notification you have sent. They belong on your subprocessor list, and if your notifications carry customer content, that is a data processing relationship with more substance than most people assume.
Strip tokens from URLs in emails. Use a short-lived redirect if you need to route somewhere specific, so the durable artefact in the mailbox is not a capability.
Give administrators control over what notifications contain for their tenant. Some regulated customers will want link-only notifications, and offering it is easier than arguing about it.
The concession
Inline content is genuinely better product design in many cases. A comment you can read without leaving your inbox is more useful than a link, mobile users especially benefit, and a digest that summarises nothing is a digest nobody opens.
So the line is by sensitivity rather than by principle. A notification about activity on a document can name the document and the person. It does not need the contents. And where a customer's data classification says otherwise, let them turn it down. That keeps the product decision where it belongs and the compliance decision with the customer who carries the obligation.
The implication
Every notification is a permanent copy of some of your customers' data in a place your controls do not reach and your deletion pipeline cannot touch.
Open your own product's notification emails and read them as though they were a data export. That is what they are, delivered in small pieces, continuously.
