Personal data breach response

Use this procedure when personal data that Wamemba me holds is lost, destroyed, changed, disclosed or accessed without authority, by accident or on purpose. It follows the regulator's guidance:

• ICO, Personal data breaches: https://ico.org.uk/for-organisations/report-a-breach/personal-data-breach/
• ICO, Report a breach: https://ico.org.uk/for-organisations/report-a-breach/
• ICO, Self-assessment: https://ico.org.uk/for-organisations/report-a-breach/personal-data-breach-assessment/

The regulator has been the Information Commission since 30 September 2026; its reporting pages are still on ico.org.uk (unverified after the change: check the URL at the first report). This document is not legal advice.

1. The rules in short

• Log every breach (section 7), also when you do not report it (Art. 33(5)).
• Report to the regulator within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to people (Art. 33(1)). The 72 hours include nights and weekends.
• If facts are missing at 72 hours, report what you know and add the rest later (Art. 33(4)).
• Tell the families affected without undue delay if the risk to them is high (Art. 34).
• Any confirmed unauthorised access to a family's sayings, children's names or birthdays, or voice clips, linked to that family, is high risk. Children are involved and the harm can't be undone. Report it and tell the families.
• If the app is offered in the EU (open, ropa.md 2.2), an EU authority may also need a report. Check at the first breach.

"Aware" means a reasonable degree of certainty that a security incident affected personal data. A short investigation is allowed; it must not be used to delay.

2. Roles

If the breach lead cannot be reached within 24 hours, the technical lead completes containment and writes the draft report in the log. If the breach lead has not answered by hour 60, the technical lead submits the initial report on behalf of The Doxa Way Ltd, with hello@wamemba.me as the contact, and records this. The deadline must not depend on one person.

3. Contacts

Supabase commits to notify without undue delay and, where feasible, within 48 hours. Most others say only "without undue delay". Do not wait for a vendor if we learn of a breach another way.

4. Procedure

Hour 0: detect and log

1. Write the first log entry: time of awareness, who found it, what is known.
2. Write the 72-hour deadline in the log.
3. Tell the breach lead at once.

Hours 0 to 24: contain and assess

1. Contain. For example: revert or tighten an RLS policy; revoke share links in bulk (share_links.revoked_at, coming); rotate a leaked key; turn off a function or page; sign out sessions; ask a recipient who got data by mistake to delete it and confirm.
2. Keep evidence: Supabase and Vercel logs, Sentry and PostHog records, the commit or deploy that caused it. Do not delete evidence while containing.
3. Scope: how many families and children; which data (names, birthdays, sayings, meanings, clips, emails); exposed to whom; for how long.
4. Assess risk (section 5).

Hours 24 to 72: decide and report

1. Decide whether to report and whether to tell families. Record the decision and reason, also when it is "do not report".
2. Report with the online form before the deadline if section 5 says so: what happened; categories and approximate numbers of people and records; likely consequences; measures; contact. Save a copy and the reference in the log.

Without undue delay: tell families (if high risk)

1. A notice in plain words (Art. 34(2)), in the brand's voice but never soft on facts: what happened; which data; what it could mean; what we did; what the parent can do (for example, switch off a link, delete a saying); how to reach us. Email where we have one, and an in-app notice. A notification's lock-screen text must not quote content.
2. Art. 34(3): no notice is needed if the data was unintelligible to the recipient, or later measures removed the high risk. If individual notices need disproportionate effort, use a public notice.

After: learn and fix

1. Fix the cause through the quality gate, with a test that fails without the fix.
2. Update dpia.md if the breach shows a new risk.
3. Close the log entry with lessons learned.

5. Assess the risk

6. Scenarios specific to Wamemba me

7. Breach log template

Keep the log in docs/privacy/breach-log.md (create it at the first entry). No names, emails or saying content in the log: use a SHA-256 hash of the lower-case email where a person must be identified. Keep each entry 6 years.

## <YYYY-MM-DD> <short title>

| Field | Entry |
|---|---|
| Breach ID | WM-BR-<YYYY>-<NN> |
| Found by / how | |
| Time of awareness (UTC) | |
| 72-hour deadline (UTC) | |
| What happened | |
| Systems and vendors involved | |
| Data categories (children's names? birthdays? sayings? clips? meanings?) | |
| Families affected (approx.) | |
| Records (approx.) | |
| Containment actions and times | |
| Risk (severity x likelihood, reason) | |
| Reported to the regulator? | yes / no, and why |
| Reference and date | |
| Families told? | no / yes, date, channel |
| Cause | |
| Fix (PR) and test added | |
| Lessons learned | |
| Closed (date, by) | |

8. Test and review

Run a tabletop test once a year, and before the public launch (first by 2027-04-15). Review with ropa.md.