Data Breach Notification Rules for File Sharing Services
Understand data breach notification requirements for file sharing services including 72-hour GDPR deadlines, reporting procedures, and remediation steps.
GDPR Article 33 gives controllers 72 hours from becoming aware of a personal data breach to notify the competent supervisory authority, unless the breach is unlikely to result in a risk to natural persons. Article 34 additionally requires notifying affected data subjects when the risk is high, without undue delay. For file sharing platforms, a breach can mean a leaked download link exposed via logs, a misconfigured S3 bucket, a compromised admin account, or a lost laptop holding unencrypted caches. Miss the 72-hour window without justification and you face Article 83(4) fines up to 2% of global revenue.
What counts as a "personal data breach"
Article 4(12) defines it as a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure, or access to personal data. The EDPB Guidelines 9/2022 (adopted October 2022, replacing WP250) categorize breaches as confidentiality (unauthorized disclosure or access), integrity (unauthorized alteration), or availability (loss or destruction). A file transfer link accidentally shared on public Twitter: confidentiality breach. Ransomware encrypting the transfer database: availability breach. An insider editing invoice PDFs before delivery: integrity breach. All three trigger Article 33 analysis.
When the 72-hour clock starts
The clock starts when the controller becomes "aware" — when there is a reasonable degree of certainty a security incident occurred that led to compromise. Investigation time before reaching reasonable certainty doesn't count against the clock, but you can't delay investigation to stall the clock. The ICO and CNIL have both fined controllers for excessive investigation gaps. Rule of thumb: 24 hours from first signal (SOC alert, employee report, external notification) to awareness decision. If more time is needed, document why. Processors' notification to controllers is separate — typically 24-48 hours under the DPA.
Breaches that don't need notification
Article 33(1) carves out breaches unlikely to result in risk to rights and freedoms. The controller decides based on a risk assessment. EDPB Guidelines 9/2022 give examples: encrypted data stolen where the encryption is strong and the key wasn't compromised (no disclosure risk), momentary availability loss with quick recovery and no data corruption. A file transfer service using AES-256-GCM client-side encryption that loses ciphertext to theft has no disclosure breach because the thief holds useless blobs. Document the assessment — regulators want to see the reasoning, not just the conclusion.
The Article 33(3) notification contents
The notification to the supervisory authority must include: nature of the breach including categories and approximate number of data subjects and records affected, name and contact of the DPO or other contact, likely consequences, measures taken or proposed to address the breach and mitigate effects. If you don't have all the facts within 72 hours, Article 33(4) allows phased notification. File an initial notification with what you know, label it preliminary, and follow up as investigation continues. Most DPAs (CNIL, ICO, BfDI) provide online portals with structured forms.
Article 34 notification to data subjects
When the breach is likely to result in high risk to individuals, Article 34 requires notification to them directly, in clear and plain language. Exceptions in Article 34(3): the data was encrypted (strong enough to make it incomprehensible), subsequent measures make the high risk unlikely, or individual notification would require disproportionate effort (public notice substitutes). For a file transfer leak of unencrypted HR files, direct notification is mandatory. For a leak of ciphertext with uncompromised keys, notification is typically not required — cite Article 34(3)(a).
Building a breach response runbook
A working runbook covers: (1) detection sources (SIEM alerts, user reports, external notifications) and escalation paths; (2) triage checklist to classify severity; (3) containment steps (revoke keys, block IPs, isolate systems); (4) evidence preservation (disk images, log exports) for forensics and regulatory inquiries; (5) notification decision tree tied to Article 33 criteria; (6) communication templates for the DPA, data subjects, customers, and the public; (7) post-incident review with documented lessons. Review the runbook quarterly and test it annually with a tabletop exercise.
Evidence a regulator will want
The CNIL, ICO, and BfDI ask consistent questions after a breach: timeline of detection and response, scope of affected data, technical and organizational measures in place before the breach, measures taken after, communications to subjects, and whether the breach could have been prevented. Keep these artifacts: SIEM logs around the incident window, change logs for the affected systems, access logs showing abnormal activity, security posture documentation (ISO 27001 SoA, DPIA), and a detailed post-mortem. Regulators fine harshly when they find incomplete logging — it signals weak security generally.
Processor-to-controller notifications
If your file transfer service is a processor, Article 33(2) requires you to notify the controller "without undue delay" after becoming aware of a breach. Most DPAs specify 24-48 hours. The processor's notification should give the controller enough information to file Article 33(1) themselves: what happened, when, scope, affected data categories, initial response. The controller then files the regulatory notification. A DPA that defers processor notification beyond 48 hours or that requires the controller to ask before receiving notice is non-compliant.
Cross-border breach coordination
For multinational controllers, identify the lead supervisory authority under Article 56 (the authority of the main establishment). File with the lead, which coordinates with concerned authorities via the One-Stop-Shop mechanism. For non-EU controllers without an establishment in the EU but offering goods or services to EU residents, file with every concerned authority where affected subjects reside. This gets unwieldy fast — consider appointing an Article 27 representative who centralizes communications. Keep a current list of DPAs and their online breach portals in the runbook.
Remediation and the follow-up fine risk
Notification isn't closure. Article 83(2) sets factors for fines including the controller's degree of responsibility, preventive measures taken, and cooperation. Post-breach remediation — improved encryption, access controls, DPIA review, staff training — directly reduces fines. The CNIL's 2023 guidance on breach enforcement cites examples where fines were halved for controllers who demonstrated rapid remediation and transparency. Services with strong architectural controls going in (client-side encryption, short retention, documented DPAs) — HexaTransfer's approach — limit both the breach surface and the fine exposure.
A 72-hour compliance calendar
Hour 0: breach signal received. Hour 4: initial triage complete, incident commander assigned. Hour 12: scope assessment complete, preliminary Article 33 decision made. Hour 24: processor notifies controllers (if applicable). Hour 48: draft Article 33 notification reviewed by DPO and legal. Hour 72: notification filed with lead DPA. Day 5-7: Article 34 subject notifications dispatched. Day 30: post-incident review published internally. Day 90: remediation plan completed and documented.
File early, file often, and keep the paper trail clean. Try it at hexatransfer.com — free, no account, 10 GB max.
Send large files securely with end-to-end encryption
Transfer files up to 10 GB for free with end-to-end encryption. No account required. Your files are encrypted in your browser before upload — no one else can read them.
Send a file