# Handling breaches, subject requests and regulator inquiries
It's 3:07 a.m. A security engineer at a mid-sized neobank pings the incident channel: an S3 bucket (a cloud storage container on Amazon Web Services) holding 180,000 transaction records was misconfigured and publicly readable for 11 days. Names, account numbers, merchant categories, geolocation tags. Two hours later, unrelated but now excruciatingly badly timed, a customer's right-to-erasure request lands in the compliance inbox, demanding permanent deletion of their transaction history.
This lesson walks through both events as one continuous timeline, because in practice they collide constantly. You'll leave with the actual clocks regulators impose, the disclosure traps that catch fintechs operating across borders, and the checks you should be running before 3 a.m. ever happens.
A "personal data breach" under GDPR (General Data Protection Regulation, the EU's core privacy law) is any security incident leading to accidental or unlawful destruction, loss, alteration, or unauthorized disclosure of personal data. A misconfigured S3 bucket qualifies immediately, no hacker required.
Hour 0 to 72: notify the regulator.
GDPR Article 33 requires notifying the relevant DPA (Data Protection Authority, the national regulator, e.g., Ireland's Data Protection Commission) within 72 hours of becoming aware of the breach, unless the breach is unlikely to risk individuals' rights and freedoms. For transaction data (financial, quasi-sensitive), "unlikely to be risky" is a hard argument to win.
Comparable US clocks are fragmented, not federal.
When to notify the individuals themselves. GDPR Article 34 requires informing affected customers "without undue delay" if the breach is likely to result in *high* risk (fraud, identity theft, financial loss). For 180,000 exposed transaction records with account numbers, this bar is met. Silence here is what turns a technical incident into a front-page one.
GDPR Article 17 (the "right to be forgotten") lets individuals demand deletion of their personal data. Fintechs get exactly one month to respond, extendable by two more months for complex requests, but the extension itself must be communicated within the first month.
Here is the trap: erasure is not absolute. Article 17(3) carves out exceptions, and financial services triggers several:
So the honest answer to most erasure requests on transaction data is: "we will delete what we can, and retain what regulation requires, ring-fenced and excluded from marketing or analytics use." That response, documented, is the actual compliant outcome, not a flat refusal or a full wipe.
Fintechs rarely breach in just one jurisdiction, and this is where teams get burned.
Trap 1: "Lead supervisory authority" confusion. Under GDPR's one-stop-shop mechanism, a company with its main EU establishment in one country notifies that country's DPA, which coordinates with others. But if your incident affects data subjects across member states and your EU entity structure is unclear (common after fintech M&A), you can notify the wrong authority and restart the clock.
Trap 2: UK is not the EU anymore. Since Brexit, the UK GDPR, enforced by the ICO (Information Commissioner's Office), runs on a parallel but separate 72-hour clock. A breach affecting both EU and UK customers requires two separate notifications, not one.
Trap 3: US state-by-state stacking. A breach touching customers in California, New York, and Texas triggers three different statutes with different deadlines and different "risk of harm" thresholds. Some states (like California under the CCPA, California Consumer Privacy Act) also grant individuals a private right of action for certain breaches, meaning customers can sue directly, not just complain to a regulator.
Trap 4: Payment scheme rules stack on top of privacy law. If card data is implicated, PCI DSS (Payment Card Industry Data Security Standard) requires notifying the card networks (Visa, Mastercard) and your acquiring bank, on a separate timeline from any privacy regulator. Missing this is a contractual, not just legal, breach.
A useful primer on the EU mechanics: EDPB guidance on personal data breach notification (European Data Protection Board, free).
Knowledge check
1. A misconfigured S3 bucket exposes transaction records publicly for 11 days, but no evidence emerges that anyone accessed the data. Under GDPR, why does this still likely qualify as a reportable personal data breach?
2. A compliance officer argues the breach doesn't need to be reported to the DPA because 'it's unlikely to risk individuals' rights and freedoms.' Given the exposed data includes names, account numbers, and geolocation tags, why is this argument weak?
3. A US-only fintech is deciding how to structure its breach notification procedures. What is the most accurate description of the US regulatory landscape compared to the EU's approach?
4. Select ALL correct answers about why the timing collision between a breach and a right-to-erasure request creates practical compliance complexity.
Select all the correct answers.
5. Select ALL correct answers about the GDPR Article 33 breach notification requirement.
Select all the correct answers.
Breach notifications rarely end at the 72-hour filing. Regulators often open a follow-up inquiry weeks later asking for:
If you cannot produce these on request, the inquiry itself becomes the bigger enforcement risk. This is why "audit-readiness" is not paperwork theater, it is the actual product regulators are buying when they ask for evidence.
A minimal breach-readiness check, the kind a data team should run quarterly:
# pseudocode: quarterly access audit
for bucket in cloud_storage.list_buckets():
if bucket.contains_pii() and bucket.is_public():
alert("CRITICAL: public PII bucket", bucket.name)
if bucket.encryption_status != "enabled":
alert("WARNING: unencrypted PII store", bucket.name)
log_access_review(bucket, reviewers=compliance_team)This is not a substitute for a real cloud security posture management (CSPM) tool, but it captures the two checks that show up in almost every fintech breach post-mortem: public exposure and missing encryption.
A workable incident response plan assigns, before anything happens:
1. Incident commander: one named role, not "whoever's online," who declares the breach and starts clocks.
2. Legal/DPO sign-off: the Data Protection Officer (a GDPR-mandated role for organizations doing large-scale sensitive data processing) confirms notification obligations and drafts filings.
3. Comms holding statement: pre-approved language for customers and press, so nothing improvised goes out at 4 a.m.
4. Erasure request triage: a documented decision tree distinguishing deletable data from legally retained data, so responses to Article 17 requests are consistent, not case-by-case improvisation.
🎬 [VIDEO: "GDPR Data Breach Notification Explained" - youtube.com/results?search_query=gdpr+data+breach+notification+explained - a walkthrough of the 72-hour rule and what counts as a notifiable breach, useful as a refresher before building your own playbook]