Back in the day, SMTP was used to distribute and receive email and this was not secure, the content was sent unprotected from one server to another. Things have moved on…

Most email servers (Google estimate 92% and this is changing fast) now offer to receive emails using TLS encryption and will, by default, try and send email using TLS. Whether or not your email is sent encrypted will depend on the capabilities your email server and  those of the receiving email server.  nhs.net is configured to send email over TLS v1.2 if it is available at the receiver server, if not it will fall back to the most secure mutually available alternative.  You can check a receivers’ email encryption capability using tools such as https://www.checktls.com 1.  All mail sent from nhs.net to Google mail accounts and from Google mail accounts to nhs.net accounts in the last 12 months was encrypted.

Pathway Analytics' domain is hosted by Google.  Mail sent to any address @pathwayanalytics.com from an address @nhs.net of @gov.uk will be encrypted using TLS v1.2.  Mail sent from other domains will attempt to use TLS v1.2 and then fallback to the next most secure and mutually available alternative.

The use of mandatory TLS where your mail server will only send emails to a TLS enabled recipient is considered good enough for HIPAA in the USA.  If you have been using email encryption tools for compliance consider configuring your email server to use mandatory TLS for sensitive traffic instead and make a saving.  

When distributing sensitive material to an ad hoc 3rd party, the use of email generally offers suitable security to protect the material in transit (ie TLS v1.2) and the recipient email server has a valid domain certificate.  However, what happens to the material on arrival is up to the receiver (ie how secure are the email host servers, the email client and local storage etc).  Email content encryption tools are useful where emails are being sent to shared mailboxes or mailboxes where the access controls are not strictly controlled.

If you are distributing SAR material to a data subject and they have agreed to receive the material by email, then presumably the risk is theirs to manage and they are happy with that - you may want to insert a warning for them to delete the content from their mail server if they are concerned.

A suggested workflow for sending SARS by email is:

1. Receive appropriate consents along with preferred means of delivery (ie email in this case), in the case of email validate the email server has a valid domain certificate and receives secure traffic over TLS 1.2 before accepting the email address.
2. Authenticate the email address by sending a token to the email address and a second token over a separate channel (ie in person, post, telephone, SMS etc) to eliminate typos.
3. Package the email content and send it.
4. Where the package is too large for email, drop it onto a file sharing service that offers one-time links, send the link in the email instead and then delete the data after a set period (eg 7 days), or after it has been downloaded a preset number of times. This will mitigate the risk of subsequent compromises to the recipient email account.

Google’s Confidential Mode for Gmail, places attachments in a Google Drive and constrains access to them by the recipient eg time expired and limiting options to forward, copy, print, and download.  It is designed to ensure the recipient is the correct person (OTP sent by SMS) and to prevent the recipient re-using or distributing the data, this is not a suitable tool for sending SARS data to the Data Subject who should be entitled to do as they wish with it.