How do the definitions of a notifiable breach differ across regimes?
Four materially different trigger designs. The GDPR family: 'personal data breach' covers any security breach leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure or access (Article 4(12)), with notification to the authority unless the breach is unlikely to result in risk to individuals (Article 33) and to individuals when risk is high (Article 34), so the trigger is a risk assessment, not a data-category list, and availability incidents (ransomware encryption) count. US state statutes: trigger on unauthorized acquisition (some states: access) of statutorily enumerated categories, classically name plus SSN, driver's license, or financial account, with the modern statutes adding health data, biometrics, login credentials, and taxpayer IDs, but the lists vary state by state, which is why the same incident is notifiable in one state and not its neighbor, and why breach counsel runs a 50-state chart on every consumer incident; most states include a risk-of-harm analysis that can excuse notice, documented. HIPAA: presumption-based, an impermissible use or disclosure of unsecured PHI is presumed a breach unless a documented four-factor analysis demonstrates low probability of compromise, the inverted burden being the point. Sector and disclosure regimes: the SEC's Item 1.05 triggers on materiality of a cybersecurity incident (a securities concept, not a privacy one, judged by the reasonable-investor standard), NIS2 and DORA trigger on significant/major operational incidents whether or not personal data is involved, and CERT-In's directions in India cover enumerated cyber incident types regardless of personal-data impact. Practical consequence: the incident-classification step of your response plan must run all applicable trigger tests in parallel, a ransomware event can be simultaneously an Article 33 breach (availability), a non-event under a state acquisition statute (if no data was taken), a HIPAA breach (presumed), an SEC materiality question, and a NIS2 significant incident, and the answers are independent.
What are the actual clocks, regime by regime?
Regulator notification: GDPR and UK GDPR, without undue delay and where feasible within 72 hours of awareness, phased submissions accepted, late filings requiring documented justification; LGPD, ANPD regulation has firmed 'reasonable period' to 3 working days from knowledge; PIPL, 'immediately' to the CAC-system regulators on defined harm scenarios; APPI, 'promptly' to the PPC (practice: preliminary within ~3-5 days, final within 30/60 days per the PPC's rules for the incident type); Australia NDB, assessment of suspected eligible breaches within 30 days, notification to the OAIC 'as soon as practicable' once eligibility is formed; Quebec, to the CAI 'promptly' for serious-injury-risk incidents; India, DPDP requires Data Protection Board notification per the rules' timelines, and CERT-In separately requires reporting enumerated cyber incidents within 6 hours, the world's tightest, applying to intermediaries and body corporates regardless of personal-data analysis; US states, AG/regulator copies typically ride the individual clock with thresholds (500 residents in many states); HIPAA, HHS within 60 days of discovery for 500+ (with concurrent media notice in affected regions), annual log for smaller incidents; SEC, Form 8-K Item 1.05 within 4 business days of the materiality determination, which itself must not be unreasonably delayed. Individual notification: GDPR family, without undue delay when high risk (no fixed hours); US states, 'most expedient time possible' with hard caps in a large minority, 30 days (Colorado, Florida, Washington's 30 for most cases) or 45 days (several states), plus consumer-reporting-agency notice at volume thresholds; HIPAA, 60 days from discovery; Quebec and Australia, alongside or promptly after the regulator. Vendor-to-controller clocks: GDPR Article 33(2) 'without undue delay,' HIPAA business associates 60 days (contracts routinely shorten), and negotiated DPA clocks of 24-72 hours doing the real work. The design rule: the plan's clock engine runs all applicable timelines from a single awareness timestamp per regime, because 'when did the clock start' is the first dispute in every enforcement action.
Who must be notified, and what must the notices contain?
The audience matrix has five rows. Regulators: which authority depends on regime and sector, the lead DPA under GDPR one-stop-shop (or every concerned DPA absent a main establishment), state AGs above thresholds, HHS OCR, the SEC via EDGAR, ANPD, the CAC hierarchy, the PPC, the OAIC, the CAI, plus sectoral overseers (banking regulators, insurance commissioners under the NAIC model law states, NYDFS's 72-hour rule for covered financial entities). Individuals: with content mandates that differ enough to require per-regime templates, GDPR Article 34 requires plain-language description, DPO contact, likely consequences, and measures taken; state statutes prescribe elements down to formatting (California's mandated headings, 'What Happened, What Information Was Involved, What We Are Doing...'), toll-free numbers and credit-agency contacts where SSNs are involved, and several states mandate free credit monitoring offers (Connecticut: 24 months for SSN breaches); HIPAA specifies content plus a toll-free contact held open 90 days. Credit reporting agencies: US state thresholds (commonly 1,000+ residents) require notifying the big three. Media: HIPAA's regional-media requirement for 500+ in a state; some state statutes allow substitute notice (website plus media) where contact data is lacking. Contractual counterparties: your B2B customers under DPA clocks, your insurers under policy notice terms, and, if you are the processor, controllers, whose own clocks your notice starts. Content discipline across all of them: consistency, the regulator filing, the individual letter, the 8-K, and the press statement will be laid side by side later, and divergence (worse: minimization in the public statement contradicted by the regulator filing) is how notification failures become deception cases; the pre-cleared template set with one fact pattern feeding every rendering is the control.
How do safe harbors and risk thresholds excuse notification?
Three main relief mechanisms, none identical. Encryption safe harbors: most US state statutes exempt breaches of encrypted data outright provided the key was not compromised (the definitions vary, some require 'unusable, unreadable, or indecipherable,' some name standards), HIPAA's 'unsecured PHI' concept reaches the same result through the HHS guidance on encryption and destruction, and the GDPR reaches it through the risk analysis, Article 34(3)(a) expressly relieves individual notice where measures like encryption rendered the data unintelligible, though the Article 33 authority notice may still be due if risk is not fully eliminated; the operational moral is that disk- and field-level encryption with sound key management is the cheapest notification insurance available, and post-incident the forensic question 'were the keys reachable' determines millions in response cost. Risk-of-harm thresholds: the GDPR's two-tier structure (any risk → authority; high risk → individuals) with the EDPB's factor framework; state statutes' 'reasonable likelihood of harm' analyses (about half the states), which must be documented and in several states filed with or available to the AG; Australia's 'serious harm' eligibility test with its reasonable-person framing; Quebec's 'serious injury' standard. These excuse notification only as well as their documentation survives hindsight, the register entry recording the analysis is the artifact that converts 'we decided not to notify' from concealment into judgment. Law-enforcement delays: nearly universal (state statutes, HIPAA, GDPR by practice through the authority), permitting delayed individual notice where notification would impede an active investigation, never excusing the regulator filing under GDPR, and the SEC's national-security/public-safety delay requires the US Attorney General's written determination, granted rarely. What has no safe harbor anywhere: notification obligations triggered by contract (your customers' DPAs do not care that a statute's threshold was unmet), and the SEC's materiality analysis, which encryption does not moot if the incident is operationally material. The composite discipline: run the relief analysis per regime, document each, and treat 'no notification required anywhere' conclusions with institutional suspicion proportional to their convenience.
What does one response plan serving all these regimes look like?
Five design features turn the comparative mess into an executable plan. A jurisdiction-scoping step wired to the data map: within the first day, the incident commander needs affected individuals by residency (which regimes), data categories per regime's definitions (which triggers), and record counts against thresholds (which audiences), answers that come from inventory queries if the map is real and from weeks of forensic archaeology if not; residency data quality is thus a breach-readiness issue, not just a marketing one. A regime configuration table, maintained like the rights matrix: per jurisdiction, trigger test, regulator identity and portal mechanics, clocks with extension/phasing rules, audience thresholds, content mandates, safe-harbor tests, and citation with last-verified date, owned by counsel, refreshed on legal change, because breach law moves fast (Washington's 2024 amendments, the SEC rule, ANPD's regulation, India's commencement each rewrote a row recently). Pre-built notification templates per regime rendering one fact pattern: the Article 33 form fields, state AG formats, the California-mandated headings, HIPAA content elements, the 8-K skeleton, all pre-cleared so the 72-hour window is spent on facts rather than drafting. A clock engine and decision log: all applicable deadlines computed from awareness timestamps, escalations as windows shrink, and every notify/no-notify decision logged with its analysis, the register that is simultaneously GDPR Article 33(5) compliance and the defense exhibit. Drills that exercise the matrix: tabletops whose scenarios force multi-regime scoping (a breach touching EU, California, Brazil, and health data), including the vendor-notification variant (you learn late, clocks already running) and the phased-facts variant (initial scope wrong by 10x), graded on clock performance and log quality. The honest summary of the global landscape: the regimes agree that speed, candor, and documentation are the whole game, and disagree about nearly every number; the plan's job is to make the numbers configuration, so the team under pressure executes one process while the table handles the world's disagreement.