handling breaches, subject requests and regulator inquiries

# Handling breaches, subject requests and regulator inquiries

The 3 A.M. Slack message

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.

Clock #1: the breach timeline

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. There is no single US breach law; each state sets its own deadline. California's Civil Code triggers notification "without unreasonable delay." New York's SHIELD Act and its Department of Financial Services cybersecurity rule (23 NYCRR 500, applicable to licensed financial entities) requires notice to the NY DFS within 72 hours of a determination that a cybersecurity event occurred, a deadline that converges with GDPR by coincidence, not coordination. This patchwork is exactly why fintechs licensed in multiple states build one internal 72-hour standard and apply it everywhere.

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.

Clock #2: the erasure request

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:

• Legal obligation: AML (Anti-Money Laundering) rules under the EU's AML Directives, and in the US the Bank Secrecy Act, typically require retaining transaction records for 5 years after account closure.
• Legal claims: data needed to defend against disputes or chargebacks.

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.

Cross-border notification traps

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).

The regulator inquiry that follows

Breach notifications rarely end at the 72-hour filing. Regulators often open a follow-up inquiry weeks later asking for:

• The data flow map: where the data lived, who could access it, what third parties (cloud vendors, analytics tools) touched it.
• Evidence of a Data Protection Impact Assessment (DPIA), required under GDPR Article 35 for high-risk processing, which transaction-level financial data almost always is.
• Logs proving least-privilege access (only staff who need data can see it) and encryption at rest and in transit.

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.

Building the response playbook

A workable incident response plan assigns, before anything happens:

1. Incident commander