TL;DR
- Turning up the TLS setting does not make emailing personal information safe. It secures the connection between mail servers, which is not where the risk lives.
- Once delivered, that message is a copy of personal information outside your retention policy, unauditable, irrevocable, and replicated into backups and devices you do not manage.
- IPP 5 of the Privacy Act 2020 asks for reasonable safeguards, and adds that when it is necessary to give information to another person, everything reasonable must be done to prevent unauthorised use or disclosure. An uncontrolled mailbox copy is hard to defend against that second clause.
- "Reasonable" is proportionate, not absolute. The standard is contextual, which means the defensible position is a recorded decision rather than a maximal control.
- The pattern that works is notification plus authenticated retrieval: the email carries no personal information, and the data is read somewhere access is logged and revocable.
- Shield Platform Encryption does not help. It protects data at rest in your org and has no effect on a message that has left over SMTP.
What You'll Learn
- Why transport encryption answers a different question from the one being asked
- What IPP 5 and Rule 5 of the Health Information Privacy Code actually require
- The four properties of an emailed copy that make it hard to defend
- How to structure notification plus authenticated retrieval in Salesforce
- What to do when content genuinely has to travel by email
- How to record a proportionality decision so it survives review
The Problem
The conversation usually arrives already halfway to the wrong answer. Someone needs to send personal information out of Salesforce, security is consulted, and the question is framed as "is our email encrypted?".
That framing quietly assumes the risk is interception, and interception is not the thing most likely to hurt you. Transport encryption protects a message while it moves between two mail servers. It has nothing to say about the far larger window that opens the moment it arrives: a copy of personal information, sitting in a mailbox for years, which you cannot see, audit, expire, or withdraw.
We covered the transport side of this properly in sending email from Salesforce securely, including why Preferred Verify silently sends in the clear. That post is about making the pipe as strong as it can be. This one is about the fact that a strong pipe does not answer the question when the payload is personal information.
Common questions this article answers:
- If the email is encrypted in transit, is it compliant to send personal information?
- What does IPP 5 actually require when we send data to someone else?
- What should we do instead, and what if the content genuinely must be in the email?
Quick Answer
Transport encryption protects the connection between mail servers, hop by hop. It does not protect the delivered message, which becomes a copy of personal information outside your control: not covered by your retention policy, invisible to your audit trail, impossible to revoke, and replicated into backups and personal devices. IPP 5 of the Privacy Act 2020 requires reasonable safeguards against loss and unauthorised access, use, modification or disclosure, and adds that where it is necessary to give information to another person, everything reasonable must be done to prevent unauthorised use or disclosure. Rule 5 of the Health Information Privacy Code 2020 imposes essentially the same obligation on health agencies. The design that satisfies this is notification plus authenticated retrieval: the email says a document is waiting and carries no personal information, and the recipient authenticates to read it somewhere access is logged and revocable, typically an Experience Cloud portal. If content must travel by email, transport TLS is insufficient and you need message-level encryption or a gateway that does portal delivery, because Salesforce has no native message-level encryption for outbound mail. Shield Platform Encryption is not relevant to any of this.
What IPP 5 actually asks
It is worth reading the obligation rather than the summary of it, because it has two limbs and the second is the one email struggles with.
IPP 5 requires an agency holding personal information to ensure there are reasonable safeguards against loss, against unauthorised access, use, modification or disclosure, and against other misuse. That is the limb everyone quotes, and encryption is a reasonable response to it.
The second limb is the interesting one: where it is necessary to give the information to another person, everything reasonable must be done to prevent unauthorised use or unauthorised disclosure of it. That obligation does not stop at your boundary. It follows the data into the hands of the person you sent it to.
Emailing personal information is precisely the act of giving it to another person, and it is the delivery method that does the least to prevent onward unauthorised use. You cannot restrict forwarding, you cannot expire it, and you cannot tell whether it was disclosed further.
For health agencies, Rule 5 of the Health Information Privacy Code 2020 is essentially the same rule, and the sector has standards specifically about this. HISO 10029 is the Health Information Security Framework, covering security wherever information is held. HISO 10064:2017, the Health Information Governance Guidelines, covers the safe sharing of health information, which is the act in question here, and it carries auditable requirements and a compliance checklist. If you are in the NZ health sector, 10064 is the document that speaks directly to this decision, and it is the one people reach for less often than 10029.
One important nuance before this reads as absolutism: "reasonable" is proportionate. The standard depends on the sensitivity of the information, the size of the agency and the context. It does not demand the strongest possible control in every case, which means the defensible position is not "we encrypted everything", it is "we assessed the sensitivity and chose proportionately, and here is the record".
This is a security design argument rather than legal advice. Where the stakes are high, your privacy officer should be the one signing off the proportionality call.
Four properties of a delivered message
The reason email is hard to defend has nothing to do with cryptography. It is what the copy becomes.
It is outside your retention policy. You may have a careful rule about how long you keep a record. The mailbox copy has its own lifetime, set by someone else, usually forever.
It is unauditable. Your org can tell you who viewed a record. Nothing tells you who opened the email, whether it was forwarded, printed, or synced to a personal phone. If you are ever asked to demonstrate who accessed a person's information, the emailed copy is a gap in the answer.
It is irrevocable. Consent can be withdrawn. Access can be removed. An email cannot be recalled. If a person exercises a right that requires you to stop using their information, you can act inside your systems and not inside a recipient's inbox.
It replicates. Into backups, mobile devices, a personal account forwarded to for convenience, and a laptop that later gets sold. Each copy is one you are still accountable for and cannot enumerate.
Encryption in transit affects exactly none of these. That is why it answers a different question from the one being asked.
The pattern that works
Notification plus authenticated retrieval. The email is a doorbell, not an envelope.
The email carries no personal information at all. Not in the body, not in the subject, not in the preview text. "There is a new document in your account" is the whole payload. Watch the subject line especially, because it is the field most likely to leak a name or a case reference into notification previews on a lock screen.
The recipient authenticates to read it. In Salesforce that is usually an Experience Cloud portal. The value is not the login screen, it is everything the login makes possible:
- Access is logged, so you can answer who read what and when
- Access is revocable, so withdrawal of consent is an action you can take
- The data stays inside your retention policy, because there is one copy and you own it
- Sharing is governed by your sharing model, not by whoever hits forward
That converts an uncontrolled export back into a controlled read, which is the whole argument in one sentence.
The trade is real and worth stating: authenticated retrieval is more friction for the recipient, and for some audiences that friction reduces engagement. That is a genuine cost, and it is the sort of thing proportionality is for. A marketing preference update is not a discharge summary.
Two implementation notes that catch people out. Make sure the link does not itself carry personal information in query parameters, because URLs end up in logs, referrer headers and browser history. And check what your portal's own notification emails contain, since it is easy to solve this in your custom flow and have a standard Salesforce notification undo it.
When the content genuinely has to travel
Sometimes retrieval is not available. A recipient with no portal access, a counterparty who will not authenticate, a statutory obligation to send something directly.
In that case, transport TLS remains insufficient and you need protection that survives delivery:
Message-level encryption, meaning S/MIME or PGP, encrypts the content itself so it stays encrypted at rest in the mailbox. Salesforce has no native message-level encryption for outbound mail, so this capability lives in a gateway you relay through rather than in the org.
Secure gateway portal delivery is the more common enterprise answer. Products in this space intercept the message and replace it with a retrieval link, which is the same pattern as above applied at the mail layer rather than the application layer. Since you are relaying anyway to control TLS properly, this is often a setting rather than a project.
Compliance BCC does not protect anything, but it gives you an archived record of what actually left, which is the only place a complete answer to "what did we send" exists.
And once more, because it comes up in almost every one of these conversations: Shield Platform Encryption is not a control here. It encrypts data at rest inside your org. It has no bearing on a message that has already left over SMTP. Rooms have signed off on emailing sensitive data on the strength of "we have Shield", and it does not follow.
The Salesforce-specific exposure
The design decision above is only as good as your control over who can bypass it.
Report exports in your org carry permissions, step-up authentication and transaction security policies. Email carries almost none of that, and three things can send:
- Apex, which can put arbitrary content into a message to an arbitrary address
- Flow, with the same reach and a much lower barrier, often built by someone not thinking about egress
- Guest users, where an unauthenticated visitor can trigger a send on an Experience Cloud site
The question that finds real problems is not "do we email personal information", it is "can the recipient address be influenced by data?". A flow that emails a case summary to an address read from a field is an exfiltration primitive the moment the person filing the case can set that field. It will not look like a security control failure. It will look like a working notification.
Worth pairing with a look at guest-reachable paths generally, which we cover in grading guest user exposure by real reachability.
Recording the decision
Because the standard is proportionate, the artefact that matters is a short written decision. Not a policy document, a paragraph per sending pattern:
What is sent: the actual fields, including anything in the subject line. Sensitivity: health information, financial, contact details, and whether the combination identifies someone who would be harmed by disclosure. Why this channel: what made retrieval unavailable, if it was. Safeguards applied: transport, message-level, gateway policy, archival. Who accepted it: the person who owns the proportionality call, usually the privacy officer.
The value is not paperwork. It is that "reasonable" is judged against what you knew and decided at the time, and an undocumented decision is indistinguishable from no decision when someone reviews it two years later. It also makes the next review cheap, because the reasoning is already written down.
Frequently Asked Questions
Q: Our email is encrypted with TLS. Is that not enough for personal information?
A: It addresses interception between mail servers, which is one risk among several and not the largest. It does nothing about the delivered copy, which sits outside your retention policy, cannot be audited or revoked, and replicates. IPP 5's second limb asks you to do everything reasonable to prevent unauthorised use after you give information to someone, and transport encryption does not speak to that at all.
Q: Does Shield Platform Encryption make emailing personal information safe?
A: No. Shield encrypts data at rest inside your org. A message that has left over SMTP is not covered by it in any way. The two are conflated often enough that it is worth stating plainly before someone signs off on the strength of it.
Q: Is it ever acceptable to put personal information in an email body?
A: Sometimes, because the standard is proportionate rather than absolute. Low-sensitivity information to a recipient who cannot authenticate, with the decision recorded, can be reasonable. Health information is at the other end of that scale. The test is whether you can explain the choice against the sensitivity, not whether you avoided email entirely.
Q: What about the subject line?
A: Treat it as the highest-risk field. It appears in notification previews on lock screens, in mail client lists, and in logs at more points than the body. A subject containing a name and a clinical service has disclosed something before anyone opens the message.
Q: We use an Experience Cloud portal already. Are we covered?
A: Only if the notification emails are clean. It is common to design the retrieval flow carefully and then have a standard notification email include the record name or a summary, which reintroduces exactly what the portal was meant to avoid. Check what the platform sends, not only what you built.
Key Takeaways
- Transport encryption answers the wrong question. The risk is the copy that persists after delivery, not the seconds in flight.
- A delivered email is outside retention, unauditable, irrevocable and replicated. Encryption changes none of those four.
- IPP 5 follows the data outward. Where you give information to another person, everything reasonable must be done to prevent unauthorised use or disclosure.
- Notification plus authenticated retrieval is the pattern, because it converts an uncontrolled export into a logged, revocable read.
- Shield Platform Encryption is not relevant to anything that has left over SMTP.
- "Reasonable" is proportionate, so the defensible artefact is a recorded decision per sending pattern, not a maximal control everywhere.
What's Next?
Recommended Reading:
- Sending email from Salesforce securely for the transport side, including why Preferred Verify sends in the clear
- Mapping Salesforce security to NZISM, the NZ Privacy Act and ISO 27001
- Why Salesforce Health Cloud needs its own security review
- IPP 3A and indirect collection notices
Action Items:
- List every place your org emails personal information, including subject lines, and include Apex, Flow and anything a guest user can trigger.
- For each, ask whether the recipient address can be influenced by data. That question finds the exfiltration primitives.
- Convert the highest-sensitivity ones to notification plus authenticated retrieval, and write a one-paragraph proportionality decision for whatever remains.
Responses
Checking your session.
Loading responses.