Data Breach Laws and Notifications

1) Introduction and objectives

Data leakage is not only a technical incident, but also a legal procedure with clear deadlines, addressees and formal requirements for the content of notifications. Mistakes in the early hours increase the risk of fines, class actions and reputational losses. This material is a practical roadmap for B2C platforms (including iGaming/fintech) that helps to act in sync: security, lawyers, PR, customer support and compliance.

2) What is considered a "personal data leak"

A personal security incident resulting in accidental or unlawful destruction, loss, alteration, undisclosed access or disclosure of personal data. The fact of risk for the rights and freedoms of subjects (confidentiality, financial harm, discrimination, phishing, etc.) is important.

3) Roles and responsibilities

Supervisor (operator) - determines the goals and means of processing; bears primary responsibility for notifications, accounting and selection of legal grounds.
Processor (processor/contractor) - processes data on behalf of; must notify the controller without delay and assist in investigations and notifications.
Joint Supervisors - Coordinate a single point of contact and assign areas of responsibility in the agreement.

4) Notification threshold: three risk levels

1. No risk (e.g. encrypted media with strong keys, keys not compromised) → incident logging, no external notifications.
2. Risk (there is a possibility of harm) → notification of the regulator on time.
3. High risk (significant harm is likely: finances, health, children, massive leaks, vulnerable groups) → additional notification of subjects in understandable language and without delay.

5) Notification periods (benchmarks for key modes)

EU/EEA (GDPR): the controller notifies the regulator within 72 hours of becoming aware of the leak; subjects - "without undue delay" if the risk is high.
UK GDPR/ICO: similar to 72 hours regulator; keep a register of incidents.
Canada (PIPEDA): to regulator and entities - as soon as possible if "real risk of substantial harm"; keep a register for at least 24 months.
Singapore (PDPA): in PDPC - as soon as possible, not later than 3 days after completion of the assessment; subjects - without delay at risk of significant harm.
Brazil (LGPD): to the regulator and entities - "within a reasonable time"; landmark - as soon as possible after confirmation.
UAE (fed. PDPL )/ADGM/DIFC: in most cases - notification of the regulator within ~ 72 hours at high risk.
Australia (NDB): assessment for up to 30 days; notification "as soon as possible" after confirmation of the "notifiable" incident.
US (state laws): deadlines vary (often "without undue delay," sometimes a fixed 30-60 days). Thresholds for the volume and types of data, notification of the Prosecutor General/agencies in case of major incidents.
India (DPDP): notifications to the regulator/entities - in accordance with the procedure established by the regulator; act promptly after identification.

6) What should be in notifications

• a brief description of the incident and a timeline;
• categories and approximate volume of affected data and subjects;
• probable consequences;
• measures taken or proposed (mitigation, prevention of recurrence);
• DPO/Responsible Group contact
• status: preliminary message with a note about the subsequent addition (if not all the facts are established).

• what happened in plain language and when;
• what their data is affected and possible consequences;
• what has already been done (locks, key changes, forced password rotation, etc.);
• what the user can do (2FA, password change, account/credit monitoring);
• support channels, free services (for example, credit monitoring in case of financial data leakage).

7) Allowable notification delay

In a number of regimes, notification can be delayed at the request of law enforcement if immediate disclosure interferes with the investigation. Record the reason and the grace period in writing.

8) Encryption and safe harbor

Many laws exempt subjects from notification if the data has been securely encrypted and the keys are not compromised. Document algorithms/key management; attach the technical rationale to the incident register.

9) Response procedure: "first 72 hours" timeline

T0-4 h.

Activate the IR plan; assign leads (SIRT, lawyer, PR, DPO).
Isolation of the attack vector, collection of artifacts (logs, dumps), fixing the system time.
Primary qualification: personal data? which categories? volume? geography? contractors?

T4-24 h.

Risk assessment: impact on rights and freedoms; children/finance/health.
Solution: Notifying the regulator? (if yes, we are preparing a "preliminary notice").
Draft notifications to subjects + FAQ for support; PR messages.
Verification of contractors/processors: request for reports, event logs.

T24-72 h.

Sending a notification to the regulator (if required); sending logging.
Finalization of a set of mitigation measures (forced password change, key rotation, time limits for operations, 2FA).
Prepare public statement (if appropriate), launch hotline/bot.

After 72 hours.

Additional reports to the regulator as they are clarified; post-mortem; updating policies and controls.

10) Management of contractors and processing chain

Contractual DPAs/processor responsibilities: "immediate notification," 24/7 contact channels, SLAs per initial report (e.g. 24 hours).
The right of the controller to audit/check the protection measures.
Mandatory recording of all contractor incidents and measures taken.
Extending obligations to sub-processors.

11) Special categories and risk groups

Children, health, finances, biometrics, credentials - almost always high risk → priority notification of subjects.
Combined leaks (PII + credits/tokens) → immediate forced rotation and token disability.
Geo-specific: Some states/countries require notification of credit bureaus/ombudsman at large scales.

12) Content and form of communications

Plain language (B1), without technical jargon.
Personalization of requests, if possible; otherwise - a public announcement and e-mail/push in combination.
Channels: e-mail + SMS/push (if critical) + banner in your account; for mass cases - public post and FAQ.
Do not include phishing-like links in emails; suggest a path through the official website/app.

13) Record documentation and storage

Incident Log: Date/Time, Discovery, Classification, Notification Decision and Justification, Notification Texts, Mailing Lists, Proof of Dispatch, Regulatory Responses, Remediation Measures.
Shelf life - according to the regime (for example, PIPEDA - at least 24 months; for others - internal period of 3-6 years).

14) Sanctions and liability

Fines of regulators (in the EU - significant in case of systemic violations or ignoring deadlines);

Claims of subjects, orders to change safety practices;

Post-incident monitoring and reporting obligations.

15) Typical errors

Delay due to "perfectionism": waiting for the full picture instead of timely advance notice.
Underestimation of indirect risks (phishing after e-mail + full name leak).
Lack of consistency between teams (lawyers/PR/security/support).

Irrelevant contacts of regulators and "Country Matrix."

Ignoring contractual obligations of processors and sub-processors.

16) Readiness checklist (before incident)

1. Approve Incident Response Policy with roles and channels 24/7.
2. Assign DPOs/Responsible and Proxies to liaise with regulators.
3. Prepare Country Matrix: dates, destinations, thresholds, forms.
4. Ready-made templates of letters: to the regulator, subjects, media, FAQ for support.
5. Update the processing registry, data map, and processor/sub-processor list.
6. Work out table-top exercises every 6-12 months.
7. Include in DPA: "notification within X hours," mandatory initial report, audit logs.
8. Enable encryption at rest and in transit, key management, secret rotation.
9. Establish monitoring of data access anomalies and automatic alerts.
10. Prepare PR playbook and public statement policy.

17) Mini-Matrix of Jurisdictions (Summary Benchmark)

(Matrix - reference point. Check current regulations before use.)

18) Document templates (keep in repository)

Incident Response Policy + Runbook 72h

Data Breach Notification — Regulator (draft/preliminary/final)

Data Breach Notification — Individuals (e-mail/SMS/баннер/FAQ)

Press Statement & Q&A

Processor Breach Report Form (for contractors)

Lessons Learned / Post-mortem template

Country Matrix. xlsx (regulator contacts, deadlines, thresholds)

19) Withdrawal

Successful passage of the "legal corridor" in the event of a leak is speed + documentation + transparent communication. The principle is simple: quick advance notification, clear instructions to users, clear coordination with regulators and contractors, and then further clarification of details as the investigation progresses. Regular exercises and an up-to-date set of templates reduce legal and reputational risks at the most critical moment.