Compliance

GDPR Compliance: How to Send Sensitive Documents Safely

Sending sensitive documents safely under GDPR takes five steps: minimise the file, verify the recipient, encrypt the document itself, set an expiry, and keep the access record.

Willy Cheah

September 3, 2026

9 min read

Most sensitive-document incidents start with a simple action: someone presses send.

Someone picks the wrong recipient, or attaches more personal data than the purpose needs. Sometimes a file simply leaves the organisation with no practical way to revoke access or verify who opened it.

For DPOs, Compliance and Security teams, the question is not simply whether email is encrypted. It is whether sensitive information remains appropriately controlled and whether the organisation can demonstrate what happened if something goes wrong.

This article covers how to send sensitive documents safely. Four common failure modes follow, with the GDPR provisions behind them and the controls that can reduce the risk.

Key Takeaways

The send is a critical control point, because recipient choice, data minimisation and access policy are all decided before disclosure.
TLS protects data in transit, not persistent document access, because transport encryption does not control a copy the recipient has saved.
What you attach decides how big the breach can be, so redaction under Article 5(1)(c) shrinks what you would later have to assess.
Erasure obligations do not provide a technical deletion mechanism for recipient-held copies, so persistent access control can matter after delivery.
Controls need evidence, because accountability depends on showing what happened, who accessed the document and what you did next.

GDPR Risk and Control Matrix

For compliance and security leaders, each disclosure risk should map to a practical control and to evidence someone can review later.

Risk	GDPR consideration	Control	Evidence
Wrong recipient	Confidentiality and breach risk	Named recipient and identity verification	Recipient and access record
Excessive disclosure	Data minimisation	Remove unnecessary fields or records	Approved document or version
Access persists too long	Security and storage limitation	Expiry and revocation	Policy and revocation event
Insufficient investigation evidence	Accountability and breach documentation	Per-recipient access logging	Exportable audit trail

What Does It Mean to Send Sensitive Documents Safely Under GDPR?

It means applying technical and organisational measures appropriate to the risk, and limiting access to authorised recipients. You also keep enough evidence to demonstrate how the disclosure was controlled. Article 32(1) requires measures appropriate to the risk, while Article 24(1) requires controllers to be able to demonstrate compliance.

Sending is a disclosure, not a handover of responsibility. Article 4(9) treats the person at the other end as a recipient of personal data, and you stay accountable for the disclosure you made. The recipient may become a controller in its own right for whatever it does next.

Why Transport Encryption Is Not the Answer

Because TLS primarily protects data in transit between systems. It does not, by itself, give the sender persistent access control over an attachment once the recipient has received or saved it.

Article 32(1) of Regulation (EU) 2016/679 does name encryption, in a list it introduces with the words "including inter alia as appropriate". So the Regulation leaves the choice of measure to you, and it does not accept the channel as evidence.

The Four Ways an Email Send of Personal Data Fails

Four failure modes create most GDPR exposure. The list runs: the wrong recipient, more data than the purpose needs, access that persists too long, and no record of who opened the document. Each maps to a different provision of Regulation (EU) 2016/679.

1. You Choose the Wrong Recipient at Compose Time

Autocomplete makes this failure for you. A name resolves to the wrong address, or a distribution list still holds someone who left.

Ireland's DPC recorded 6,521 valid breach notifications in 2025, and almost half came from correspondence sent to the wrong recipient. ICO guidance on bulk email calls failure to use BCC correctly one of the top breaches reported to it every year.

A misdirected send is a personal data breach under Article 4(12). Article 33(1) then requires notification without undue delay and, where feasible, within 72 hours of becoming aware. That falls away only where the breach is unlikely to risk people's rights and freedoms.

2. You Attach More Data Than the Purpose Needed

Over-attachment is the quiet failure, because nothing visibly breaks. The whole payroll export goes out when three columns would have done.

Article 5(1)(c) requires personal data to be "adequate, relevant and limited to what is necessary in relation to the purposes". That makes the contents of an attachment a compliance decision, not an administrative one. A misdirected pack of 240 records is also a different notification from a pack of 12.

In October 2024 the ICO fined the Police Service of Northern Ireland GBP 750,000. Staff answering a freedom of information request left a hidden source worksheet in the spreadsheet they published, holding details of all 9,483 officers and staff. The file came down within three hours, and the data still had to be treated as compromised.

3. The Attachment Outlives the Relationship It Was Sent For

Sent files do not expire on their own. The audit ends, the tender closes, the adviser moves firm, and the copy stays where it landed.

Article 17(1) binds the controller and Article 17(2) reaches only data the controller made public, so neither touches a copy in someone's downloads folder. ICO guidance on erasure says you "must contact each recipient and inform them of the erasure", unless that is impossible or disproportionate. Informing them is the whole of the power.

Where the recipient is your processor, Article 28(3)(g) gives you a contractual route to deletion. Where the recipient is a separate controller, such as external counsel, the position is weaker. Article 19 requires you to communicate an erasure to recipients, without giving you a mechanism to delete the copies they hold.

4. You Cannot Show Who Opened It

Evidence is the failure nobody notices until an investigation starts. Your controls may have worked perfectly, and you still cannot prove it.

CNIL fined France Travail EUR 5 million in January 2026 under Article 32 alone. The regulator found permissions on Cap Emploi adviser accounts, an external partner network, defined too broadly, and logging too weak to detect abnormal behaviour.

Article 24(1) puts the burden on you to demonstrate that your processing complies, and Article 5(2) does the same for the Article 5(1) principles. Any breach then needs documentation under Article 33(5): the facts, the effects and the remedial action taken. A per-file access record covering opens, timestamps and locations supplies the facts, though not the effects or the remedy.

How to Send Sensitive Documents Safely in Five Steps

Send sensitive documents safely in five steps. Minimise the file, name and verify the recipient, encrypt the document itself, set expiry and revocation, then keep the access record.

Minimise before you attach. Strip the fields the recipient does not need, because Article 5(1)(c) limits data to what the purpose requires.
Name the recipient, then verify them. Address the file to a person rather than a list, and require an identity check at the point of opening.
Encrypt the document itself. Protection has to sit inside the file, so a forwarded or downloaded copy stays unreadable without authorisation. A protection toggle inside Gmail keeps that one action rather than a separate workflow, since body and attachments encrypt automatically once it is on.
Set expiry and keep revocation. Tie the window to the purpose, and make sure you can withdraw access once the copy has left.
Keep the access record. Log who opened which file and when, so an Article 33(5) file can state what actually happened.

The first two steps limit what is at stake. The last three decide whether the send stays governed after it arrives.

Real-World Example: A Health Letter Emailed to the Wrong Address

Encryption did its job here right up until the password went to the same wrong address.

The Scenario

Ireland's Data Protection Commission publishes this as a breach notification case study. A statutory body that investigates complaints about experts' professional conduct attached a letter to an email. The letter held personal data of several people, including health data, and it was encrypted.

What Happened Next

The email went to an incorrect address. A second email then sent the password for that encrypted letter to the same wrong address. One mistake defeated both controls.

The Outcome

The DPC confirmed notification of all affected people under Article 34, and the body reviewed its data protection processes. Alongside that, the regulator restated the continuing obligation to secure personal data that was accidentally disclosed.

Its conclusion is the line to keep. Encryption "is a valuable tool that can help to protect against accidental disclosures", but "a single mistake in an email address can negate the benefits".

What Should We Do

Three changes would have kept this send from becoming a disclosure.

Send the password by a separate medium. A phone call or an SMS, which is the DPC's own advice.
Tie the open to the recipient's identity. Then no password travels, and a wrong address gets no further than the verification step.
Keep a way to withdraw access after the send. A wrong address can then be closed off rather than only reported.

Article 34(3)(a) recognises that design, lifting the duty to communicate with data subjects where encryption renders the data unintelligible to anyone unauthorised. The second email removed exactly that protection.

What Each Sending Method Actually Reaches

Each method reaches a different point in the file's life. The table below sets the four failures above against three common ways of sending a sensitive document.

Capability	Plain email attachment	Basic password-protected sharing link	Identity-bound protected document
Stops the wrong recipient opening it	✗ No, nothing stands in the way	Only while the password stays private	✓ Yes, opening needs verified authorisation
Revocation reaches a copy already saved	✗ No, the copy is permanent	✗ No, the download stays readable	✓ Yes, where decryption needs the sender's authorisation
Shows who opened the file	✗ No record at all	Depends on whether the link requires named-user authentication	✓ Yes, per access event
Survives a forward	✗ No, forwarding grants access	Protection weakens if the password or link is forwarded	✓ Yes, forwarding alone grants nothing

No technical control can eliminate every capture method, including photography or manual retyping. Screenshot protection, dynamic watermarking and identity-bound access can, however, discourage unauthorised capture and strengthen accountability.

What DPO, Compliance and Security Teams Should Verify

Before approving a workflow for sensitive documents, review both the control itself and the evidence it produces.

Recipient identity. Confirm how the recipient is authenticated at the point of opening, not only at the point of sending.
Persistent policy enforcement. Check whether access rules continue to apply after the document leaves the sender's environment.
Revocation scope. Verify whether revocation affects previously saved protected copies or only disables the original sharing link.
Auditability. Confirm that the log captures access, policy changes and revocation events in enough detail for an investigation.
Security integration. Check whether the tool can export events to your monitoring, SIEM or compliance workflows through APIs or webhooks.

How to Choose a Tool for Sending Sensitive Documents

Judge a sending tool on four questions. Each maps to one of the failures above, and each has an answer you can test rather than take on trust. Category background sits in our roundup of email encryption tools.

Does the Encryption Sit Inside the File?

Only if the downloaded copy stays unreadable without authorisation. Ask the vendor to send you a protected file, then try to open it on a machine that has never touched their product. If it opens with no identity check and no call back to the sender's authorisation, the encryption protected the channel and not the file.

Can You Name and Verify the Recipient?

Yes, when the tool ties access to a named person instead of to possession of a link. Look for an identity check at the moment of opening. A password in a second email verifies nothing about who is reading.

Does Revocation Reach a Copy Already Downloaded?

That depends on where the authorisation to decrypt lives. If the file needs an authorisation the sender controls, revocation reaches the saved copy. If it decrypts once locally and stays open, revocation stops at the link.

Can the Access Record Leave the Product?

Yes, when the tool exposes events rather than only dashboards. Ask whether access events can reach your SIEM through an API or webhooks. Manually assembling access evidence from screenshots makes investigations slower and harder to audit.

PPAD supports this with webhooks for file and recipient lifecycle events in real time. Behind that sits an access log recording who opened a document, when, and from where. Exportable events can make investigations and evidence collection easier to operationalise.

Common Mistakes When Sending Sensitive Documents

Six common practices create avoidable exposure.

Treating TLS as proof. Transport encryption is real, and it says nothing about the file after delivery.
Sending the password down the same thread. Anyone who received the attachment in error usually received the password with it.
Trusting message recall. Recall needs sender and recipient in the same organisation and the message still unopened. Once the mail has left your tenant it does nothing at all.
Reading link revocation as deletion. Closing a link ends access to the original, not to the copy someone already saved.
Logging opens that nobody reads. An access record only helps if someone reviews it on a schedule and at project close.
Assuming Article 17 reaches the recipient's copy. Erasure obliges you, and it gives you no mechanism over a separate controller's files.

Frequently Asked Questions

Is Email Safe for Sending Sensitive Documents Under GDPR?

It depends on what protects the attachment. Transport between modern mail servers is encrypted, so the journey is rarely the weak point.

The key question is what protects the document after delivery. Email becomes more defensible when encryption sits inside the document, access stays tied to authorised recipients, and you can withdraw it when the purpose ends.

Does GDPR Require Encryption When You Send Documents?

No. Article 32(1) names pseudonymisation and encryption as examples, introduced by the words "including inter alia as appropriate".

The Regulation asks for measures appropriate to the risk and leaves the choice with you. For special category data, encryption will often be an important measure to consider as part of a risk-based security approach.

Is a Misdirected Email a Personal Data Breach?

Usually, if personal data has been disclosed to an unauthorised recipient. Article 4(12) covers unauthorised disclosure of personal data.

Whether the breach must be reported to the supervisory authority depends on the risk to individuals' rights and freedoms. Article 33(1) requires notification without undue delay and, where feasible, within 72 hours unless the breach is unlikely to result in such a risk. The assessment should be documented.

Does Password-Protecting an Attachment Satisfy GDPR?

Rarely on its own. A password gates the first open and controls nothing afterwards, since the recipient can save an unprotected copy or pass the password on.

Password protection also fails the evidence test, because you learn nothing about who opened the file. Treat it as a floor rather than an appropriate measure for special category data.

Can You Delete a Sensitive Document After You Have Sent It?

Not on your own. Article 17 obliges you to erase your own copies and, under 17(2), to take reasonable steps where you made the data public.

Neither duty reaches a file in someone's downloads folder. Deletion becomes real only where the recipient is your processor under Article 28(3)(g), or where opening the file depends on an authorisation you can withdraw.

Who Is Responsible if the Recipient Mishandles the Document?

It depends on the recipient's role. A processor acts on your documented instructions under Article 28(3)(a), so its mishandling reflects on your choice of processor and on those instructions.

A separate controller, such as an auditor or external counsel, answers for its own processing. You still have to show that the disclosure was lawful and appropriately secured.

Final Recommendation

Start with the sensitive document your team emails out most often, and send yourself a copy the way you normally would. Then ask two things: can you tell who opened it, and can you stop them opening it tomorrow? If either answer is no, that is the gap to close before you write another policy.

PPAD is built for the part of a send that begins after delivery. Files are encrypted before they leave the sender, and access can remain tied to authorised recipients. Revocation can also reach a file after it has been saved. Access events are logged to support investigation and compliance evidence.

See how PPAD helps maintain control over sensitive documents outside your organisation.

Book a 15-minute demo | Try for free

Sources

Sources and regulatory position verified 2 September 2026. This article is general information, not legal advice.