How to deliver a DSAR response file without email attachments

Your DSAR-intake tool did its job. The 30-day clock is half-spent, your team has assembled the data subject's file — pay stubs, performance reviews, a Slack export, two years of HR correspondence — and now you're staring at a 247MB zip and a request from the data subject for it "by Friday." Your inbox blocks attachments over 25MB. Your IT department says "use SharePoint." Your DPO instinct says: how do I prove this person actually received it, and how do I prove I destroyed it on the back end?

This is the part of GDPR Article 12 nobody trains you on. The regulation says the response must be delivered "in a concise, transparent, intelligible and easily accessible form, using clear and plain language" — and "free of charge" within one month. It does not tell you which file-transfer pipe to use. So privacy officers improvise. Most improvisations leak.

The DSAR delivery gap nobody talks about

There is a thriving market for DSAR intake tools — OneTrust, TrustArc, Securiti, DataGrail. They handle the request portal, the identity verification, the discovery workflow, the redaction queue. They do not handle the last mile: getting the assembled response file into the data subject's hands.

What we hear from DPOs in onboarding calls:

• "I emailed it as a password-protected zip and texted the password. I don't think that's compliant but my manager signed off."
• "Our SharePoint link is public to anyone with the URL. We send it via Outlook and hope it doesn't get forwarded."
• "We use SFTP. The data subject is a 73-year-old former employee. They couldn't figure out FileZilla. We ended up driving a USB drive to their house."
• "Legal wants a paper trail showing the subject downloaded the file. None of our tools produce that."

The discovery problem is solved. The delivery problem is a privacy officer wiring together email, file-sharing, and a Word doc tracking who confirmed receipt. That improvised pipeline is where the next breach lives.

Why email attachments fail Article 12 in practice

Email attachments fail for four boring, mechanical reasons that compound:

Size limits. Corporate Exchange Online tenants often cap message size at 25MB by default. A standard employee DSAR response — HR file + payroll history + Slack export + email archive — clears 100MB easily. Splitting into a 12-part zip-bomb across 12 emails is not "clear and plain language."

Recipient mailbox controls. Gmail blocks zips that hide certain file types, including password-protected archives that obscure their contents from scanning. Outlook quarantines unknown attachments from external senders. Your DSAR response sits in the data subject's spam folder; you don't know; the 30-day clock keeps ticking; you are now non-compliant and don't know it.

Forwarding. Once the file lands in the data subject's inbox, you have lost custody. They forward it to their lawyer, who forwards it to two paralegals, who copy excerpts into a discovery binder. You are now the controller for personal data sitting on four laptops you cannot reach. Article 5(1)(f) — integrity and confidentiality — is broken.

No proof of receipt. Email's "read receipt" is advisory. It depends on the recipient's client honoring the header, which Gmail and most mobile clients do not. When the data subject later claims they never got the file and escalates to the supervisory authority, your evidence is: "I sent it on Tuesday."

These four failures are why we built the privacy and compliance workflows the way we did. The delivery layer needs to be a separate, auditable thing — not a side-effect of whatever mail server happens to be in the path.

What the regulation actually requires of the delivery step

Strip out the directive's hedging language and the delivery step has four operational obligations:

1. The data must reach the data subject. Not "be sent." Reach. The controller has the burden of proof.
2. The data must reach only the data subject. Article 5(1)(f) again — confidentiality. Misdelivery is a notifiable breach under Article 33 if it crosses the harm threshold.
3. The delivery itself must be documented so the supervisory authority can audit it. Article 5(2) accountability principle — you can't just be compliant, you must demonstrate compliance.
4. The delivery must not create new processing risks downstream. Forwarding the data subject's file to your IT support team because the link broke, and IT then keeping a copy on a debug server, is itself a new processing event you'd need to justify.

Most DPOs read those four obligations and think: identity verification at delivery, a one-time link, a receipt, and no copies left lying around. Right. Now find a tool that does all four.

The DPO at a 4,000-employee fintech client described their previous workflow this way: "Our DSAR tool produced the file. Then I spent two hours every Friday emailing files, tracking receipts in a spreadsheet, and deleting the SharePoint links Monday morning. I called it my Friday penalty box."

A practical delivery workflow that survives an audit

Here is the workflow we recommend, regardless of which tool you use. The pattern matters more than the vendor:

1. Verify the data subject's identity before generating the delivery link

Most DSAR portals verify identity at request time. They rarely re-verify at delivery time. The gap matters because 30 days have passed; the email account that filed the request may have been compromised in the interim; the requester may have left the company that originally hosted them.

The cheap way to close this: require the data subject to confirm a delivery email address through a one-time verification link before the response file is generated. The expensive way: a video identity check. The wrong way: trust the original portal session.

2. Use a link with an enforceable view or download cap

The data subject needs to download the file exactly as many times as they actually need it. For a standard DSAR response, that is one to three downloads — once for their records, once for their lawyer, once if the first download corrupted. After that, the link should be dead. Permanently. Not "expired and possibly recoverable."

This is the central design pattern of our zero-knowledge link architecture: every shared link has time, view, and download caps, and the file is destroyed server-side when any cap is hit. The data subject cannot forward an active link to four lawyers because the link will not work for the second one through. If they want to share with counsel, they share the downloaded file — which is now their custody decision, not yours.

3. Generate a proof-of-delivery artifact you can hand the supervisory authority

This is the piece most privacy officers don't realize exists. When the response file is delivered and destroyed, you want a signed, machine-verifiable artifact saying:

• This share (referenced by its opaque ID, plus a hash of the encrypted payload — not the plaintext, which CIPH4 never sees) was made available to this recipient (identified by verified email address)
• On this date and time
• It was downloaded N times
• It was destroyed at this date and time
• This entire sequence is part of a tamper-evident audit chain

On the Enterprise tier, CIPH4 generates this artifact as a signed Proof-of-Deletion Receipt — a small file you can store with your DSAR response record indefinitely. It's signed with our service's private Ed25519 key, and anyone (the data subject, the supervisory authority, your auditor) can verify the signature at the public receipt verifier without needing access to your systems. You can hand it to an ICO investigator and they can confirm it's authentic in 30 seconds.

This is the artifact that converts "we delivered the file" from a claim to a fact.

4. Document the delivery in the same record as the request

Your DSAR register needs to link the original request, the discovery scope, the redaction decisions, the delivery event, and the destruction event into one record. The supervisory authority audit asks "show me how request 2026-1142 was handled" — you produce one record, not five tools' worth of screenshots.

The integration here is mundane. Most DSAR intake tools accept a webhook for "response delivered." Point that webhook at your delivery system. CIPH4 fires separate audit events for delivery (the recipient downloaded the file) and destruction (the share burned, expired, or was revoked); subscribe to both, and your DSAR tool records each on the request record to close the loop.

What "destroyed" actually means after delivery

The single most common DPO question we get: "When you say the file is destroyed, what do you actually mean?"

Three things happen, in order, when a CIPH4 link hits any of its caps:

1. The database row is flipped to a burned state and stops serving bytes immediately. No further download attempts succeed.
2. The encrypted file in object storage is queued for physical deletion. The default five-minute delay applies to cap-hit and time-expiry burns (a defense-in-depth window for in-flight responses still draining bytes); explicit revokes run with no delay.
3. A receipt is generated, signed, and attached to the audit chain.

The decryption key was never on the server in the first place — it lived in the URL fragment the data subject's browser used to decrypt the file. When the link dies, the decryption key dies with the data subject's browser tab closing.

This is what makes the destruction provable in a way that "I deleted it from SharePoint" is not. There is no copy on a backup tape we could theoretically restore; the ciphertext is gone and the key was never ours.

The DPO's pre-delivery checklist

Before you click "send response" on the next DSAR, run through this:

• Have you verified the delivery email address belongs to the same person who filed the request, with a fresh verification step in the last 24 hours?
• Have you set a download cap that matches the data subject's plausible need (1-3 downloads, not unlimited)?
• Have you set a time expiry that gives the subject time to retrieve the file but does not leave it live for weeks (we recommend 7 days max; CIPH4's system ceiling enforces this)?
• Will you receive a signed, durable artifact you can attach to the DSAR register proving delivery and destruction?
• If the data subject's lawyer needs a copy, do you have a plan that doesn't involve you re-sending? (Answer: the data subject downloads, then shares the downloaded file with their counsel themselves. You're not in the chain.)
• If the delivery fails — broken link, recipient on holiday, mailbox bounce — do you have a documented retry path that doesn't reset your clock?

If any answer is "no" or "I'd have to ask IT," your delivery layer is improvised. That's the gap.

Where this fits in your broader Article 12 posture

DSAR delivery is one workflow. The pattern — identity-verified delivery, enforceable caps, signed destruction proof, integrated audit trail — applies to every regulated data transfer your privacy team handles:

• Erasure confirmations under Article 17 (you deleted their data; here's the proof)
• Rectification confirmations under Article 16 (you corrected their record; here's the updated extract)
• Data portability deliveries under Article 20 (here's their data in machine-readable form)
• Breach notification packages to supervisory authorities under Article 33
• Privacy impact assessment evidence packages requested by the ICO

Our legal and compliance workflow surface describes how the same primitives — links that expire, receipts that prove destruction, audit chains that prove integrity — slot into each of these flows. The DSAR response is the highest-volume use case for most DPOs, which is why it's worth getting right first.

What to do next

Look at the last five DSAR responses your team delivered and ask: do we have a signed artifact proving the data subject received the file, and a signed artifact proving the copy was destroyed? If the answer is "we have an email saying it was sent," the gap is real and worth closing before the next supervisory audit.

If you'd like to see what those artifacts look like, you can verify a sample deletion receipt at the public receipt verifier without an account — it's the same surface your auditor would use.