🚨 Personal-Data Breach Response Runbook

GDPR Art. 33 (72 h regulator notification) + Art. 34 (subject notification if high risk) + equivalent state obligations. Goal: contain within 1 h, assess within 24 h, notify within 72 h.

0. When this runbook fires

A personal-data breach is any accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data. In this product, that includes:

Someone outside the user's account gains read access to their video, profile, or analysis.
The users/, jobs/, or mail/ collections are queryable by unintended principals.
A sub-processor or recipient (Firebase, RunPod, Resend, Apple, Google Play, or Stripe) reports an incident that touches our data.
A lost laptop with a firebase login session or a leaked API key (RESEND_API_KEY, App Store Connect key, Google Play service-account credential, RunPod key, or Stripe secret/webhook secret).
Stripe, App Store, or Google Play customer, subscription, purchase-event, or entitlement data is exposed or altered. Card details are collected on Stripe-hosted pages, but a payment incident still requires immediate provider-account and log review.
Ransomware / malware infection on a developer machine.

If in doubt: treat it as a breach and run the runbook. Better to discover it's a false alarm than miss the 72 h clock.

1. Immediate containment — within 1 h of discovery

Step	Action	Owner
1.1	Page the on-call engineer in #acesense-oncall	Discoverer
1.2	Assemble the breach response team: Eng lead + DPO + Founder	On-call
1.3	If exploit is active, rotate or revoke the affected credential first: Firebase (reauth + revoke sessions), Resend, App Store Connect, Google Play service account, RunPod, or Stripe API/webhook credential. Verify webhook destinations after rotation.	Eng lead
1.4	If data in the `mail/` or `jobs/` collections is exposed, tighten security rules to block further reads	Eng lead
1.5	Preserve logs. Export Cloud Functions logs, Storage access logs, Firestore audit logs for the 30 days pre-incident + ongoing	Eng lead
1.6	Open a private incident doc `incidents/YYYY-MM-DD-shortname.md` in acesense-docs	DPO

Do not tweet, blog, Slack-publicly, or email customers yet.

2. Assessment — within 24 h

Answer these in the incident doc:

What happened? Root cause — best guess backed by logs.
What data was affected? Categories + approximate volume + whether the data included children's records, biometric-adjacent data, or special categories.
How many data subjects? Approximate — underestimates are worse than overestimates.
Where were the subjects located? EEA, UK, US (which states), elsewhere — this drives the notification map.
Is the data recoverable / is the exposure ongoing?
Likelihood and severity of adverse consequences for subjects: identity theft? financial loss? physical harm? discrimination? reputational damage? Pick each applicable.
Measures already taken + measures proposed.

Output: a completed incident doc + an Art. 33(3) draft (see §4 below).

3. Notification map (by jurisdiction)

Regime	Trigger	Deadline	Authority / method
GDPR (EU 27 + EEA)	Any breach unless "unlikely to result in a risk"	72 h from becoming aware	Supervisory authority of the DPO's Member State; if none designated, lead authority of each affected state
UK GDPR	Same as GDPR	72 h	ICO notification form
CCPA/CPRA (California)	Any breach of unencrypted personal info	"Most expedient time possible, without unreasonable delay" — typically interpreted as ≤30 days	California AG (via web form) + affected residents
Other US states	State-specific — most require notification; several (VA, CO, CT) follow GDPR-ish timeframes	30–60 days typically	State AG + affected residents
LGPD (Brazil)	Relevant breaches	"Reasonable timeframe" (ANPD guidance: 2 business days)	ANPD
PIPEDA (Canada)	Real risk of significant harm	"As soon as feasible"	OPC + subjects
PDPA (Singapore)	≥500 affected OR significant harm	72 h + subject notification	PDPC
APPI (Japan)	Certain categories (health, minors, >1,000)	3–5 days	PPC
Australia Privacy Act	Eligible data breach (serious harm likely)	30 days	OAIC
POPIA (South Africa)	"Unauthorized acquisition"	ASAP	Information Regulator
DPDP (India)	Any breach	72 h	Data Protection Board (once in force)
Apple App Store	Significant breach	7 days	Developer-relations contact
Google Play	Same	7 days	Play Console

When multiple apply, notify the earliest deadline across the set.

4. Drafting the notification (Art. 33(3) template)

1. Nature of the breach:
   - Description: …
   - Affected categories of data subjects: (e.g. active users in DE, FR)
   - Affected categories of personal data: (e.g. email, age attestation,
     tennis video, derived pose coordinates, billing customer/subscription metadata)
   - Approximate number of data subjects affected: …
   - Approximate number of records affected: …
2. Name + contact of the DPO:
   Email: dpo@acesense.io
3. Likely consequences of the breach:
   …
4. Measures taken or proposed to address the breach and mitigate
   adverse effects:
   …

Keep the draft inside the incident doc. Send only after DPO sign-off.

5. Notifying data subjects (Art. 34)

Required when the breach is likely to result in a high risk. In this product, that bar is hit when:

Videos, analyses, or account credentials of individual users are exposed to a third party.
Biometric-adjacent (pose) data is exposed to a third party.
Age-attestation, billing-customer, or subscription metadata is exposed in a way likely to enable fraud, phishing, or account compromise.

Channel: transactional email via Resend + in-app banner inside AceSense. Draft stored in the incident doc before send.

Content must cover (in plain language):

What happened.
What data was involved.
What you are doing about it.
What they should do (change password; watch for phishing; contact us).
Name + contact for follow-up.

6. Post-incident

Close the incident doc with root-cause analysis + remediation.
Update this runbook if gaps appeared.
Hold a blameless post-mortem within 5 business days.
File with the board / advisors if material.
If notification deadlines were missed, document the reason — regulators are more forgiving about delays you document honestly than ones you try to hide.

7. Drill cadence

Quarterly — pick a scenario, run it cold, time it, note where you fell off the process.
Annually — full tabletop with an external observer if possible.

Last drill: 2026-Q2 drill 1. Schedule the next drill for 2026-Q3.

Was this page helpful?

0. When this runbook fires​

1. Immediate containment — within 1 h of discovery​

2. Assessment — within 24 h​

3. Notification map (by jurisdiction)​

4. Drafting the notification (Art. 33(3) template)​

5. Notifying data subjects (Art. 34)​

6. Post-incident​

7. Drill cadence​