How we keep ourselves accountable
Lawful basis and retention schedule
This document gives the lawful basis for each use of personal data in Wamemba me and the retention period for each category. It agrees with the privacy policy, version 2.0 (privacy.md sections 2 and 7). If this document and the published policy disagree, the published policy is what people were told: correct the one that is wrong, in the same pull request, and bump both versions.
- ICO, Lawful basis: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/lawful-basis/
- ICO, Legitimate interests: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/lawful-basis/legitimate-interests/
- ICO, Storage limitation: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/storage-limitation/
This document is not legal advice. "PA" refers to the processing activity in ropa.md.
1. Lawful basis table
| What Wamemba me does | Art. 6 basis | PA |
|---|---|---|
| Make and run the parent's account; back it up; sign back in | Contract, 6(1)(b) | PA1 |
| Rate limits, security logs, abuse prevention | Legitimate interests, 6(1)(f) | PA1 |
| Keep each child's first name and birthday | Legitimate interests, 6(1)(f) (LIA 1.2) | PA2 |
| Keep sayings, context, speakers and word meanings | Parent: contract, 6(1)(b). Child and other speakers: legitimate interests, 6(1)(f) | PA3 |
| Keep a child's voice clip (coming) | As PA3 | PA4 |
| Show a saying on a card or link the parent sends (coming) | As PA3, on the parent's instruction | PA5 |
| Partner and viewer access; weekly email (coming) | Contract, 6(1)(b) | PA6 |
| Subscriptions, trials, gifts, restore (coming) | Contract, 6(1)(b) | PA7 |
| Keep transaction records (coming) | Legal obligation, 6(1)(c) | PA7 |
| Notifications (coming) | Contract, 6(1)(b), with the OS permission | PA8 |
| Crash reports | Legitimate interests, 6(1)(f) | PA9 |
| Analytics in the UK, EU, EEA and Switzerland | Consent, 6(1)(a); PECR reg. 6 consent for the device identifier | PA10 |
| Analytics elsewhere | Legitimate interests, 6(1)(f), with an opt-out | PA10 |
| Waitlist emails | Consent, 6(1)(a) | PA11 |
| Server logs of the websites | Legitimate interests, 6(1)(f) | PA11 |
| Answer messages | Legitimate interests, 6(1)(f) | PA12 |
| Rights requests and complaints | Legal obligation, 6(1)(c) | PA12 |
| Creator and press outreach | Legitimate interests, 6(1)(f) | PA14 |
| Engineering operations | Legitimate interests, 6(1)(f) | PA15 |
1.1 Notes
- Article 9. Wamemba me does not ask for special category data and needs no Article 9 condition. A saying can mention health or belief by chance; that is incidental, chosen by the parent, never analysed. A voice clip that is only stored and played back is not biometric data (
dpia.md4.3). - PECR and analytics in the UK. Since 5 February 2026, PECR Schedule A1 paragraph 5(1)(c) (DUAA s.112) lets a service store or read device information without consent for statistics about the use of the service, if that is the sole purpose, the data isn't shared for anyone else's purposes, and people get clear information and a free, simple way to object. Wamemba me still asks for consent in the UK: the EU needs consent anyway, one rule for both is simpler and kinder, and it matches the "private by default" rule (spec §3 rule 5). Revisit only with a product reason.
- Sentry on the device. The Sentry SDK keeps unsent reports in app storage. This is treated as strictly necessary to provide a service that works safely (PECR reg. 6(4)(b)). Unverified: whether the regulator agrees for crash reporting; the solicitor brief asks.
1.2 Legitimate interests assessment: children's data (PA2 to PA5)
Following the ICO's three-part test.
Purpose test. The interest is the parent's: to keep a record of their young child's words and age, which they would otherwise lose; and Wamemba me's: to provide the service the parent pays for. Both are legitimate, lawful and clearly stated. The child also has an interest in a record of their early childhood existing.
Necessity test. The service cannot work without the child's first name (whose saying it is) and the words themselves. The birthday is optional and needed only for the exact age. No less intrusive way gives the same result: a local-only store would lose sayings with a phone and could not be shared with a partner.
Balancing test.
| Factor | Finding |
|---|---|
| Nature of the data | Children's data: more weight to the child. Not special category |
| Reasonable expectations | A parent keeping a child's words in a notebook or phone note is normal family life. The child would reasonably expect the record to stay in the family |
| Likely impact | Low while private; higher if shared widely (R2, R5) or leaked (R1) |
| Vulnerability | Very young children, who cannot object: weighed heavily |
| Safeguards | Minimal data; family-only access; first names only on anything shared; no advertising, profiling or AI training; private word meanings; delete at any time; the child's own right to ask for deletion later |
| Could the child object? | Through the parent now; directly once competent. Objection (Art. 21) is honoured by deleting the saying |
Conclusion. The parent's interest, and ours in serving it, is not overridden by the child's interests or rights, given the safeguards. Wamemba me relies on 6(1)(f) for the child's data and reviews this assessment when sharing (S3) and the family circle (S6) ship.
Other named speakers ("Dad", "the bus driver"): the same assessment, with lower risk, because the data is a first name or role in a family's private note.
1.3 Other legitimate interests assessments
| Use | Purpose | Necessity | Balance | Result |
|---|---|---|---|---|
| Crash reports (PA9) | Fix faults that lose sayings | No other way to see crashes on real phones | No content; account id only; EU storage | Pass |
| Analytics outside UK/EU (PA10) | Improve activation and speed | Aggregate counts need events | No content; opt-out (coming, A2) | Pass once A2 ships |
| Server logs (PA11) | Security and operation | Standard and short-lived | IP only, days | Pass |
| Outreach (PA14) | Reach parent creators and press | Direct contact is the channel | Public business contacts; one-click opt-out honoured; no children | Pass |
| Operations (PA15) | Run the service | Schema and aggregate queries | No family content unless asked; A5 | Pass with the rule |
2. Retention schedule
"Enforced by" says how the period is applied: code, vendor (setting or contract), manual (runbook), or not enforced (a gap with an action).
| Data | Retention | Enforced by | In policy v2.0? |
|---|---|---|---|
| Account, children, sayings, meanings | Until the parent deletes them or the account | code (RLS deletes; account delete coming, A6) | Yes |
| Deleted rows in backups | Supabase daily physical backups kept 7 days; no PITR (read 2026-10-14) | vendor | Yes ("within 7 days") |
| Copy on the parent's phone | Until the saying, child or account is deleted, or the app removed. Account deletion must wipe it (docs/decisions/2026-10-14-session-for-deleted-account.md) | code | Yes (implied) |
| Never-subscribed anonymous account | 90 days after the app was last opened, with a 7-day notice if notifications are allowed | not enforced yet: S4 job, after the "gone" carry-over | Yes, marked coming |
| Accounts that ever started a trial or paid | Until the parent deletes the account | code | Yes |
| Voice clips (coming) | With their saying | code (storage delete with the row) | Yes |
| Share links (coming) | Until revoked, or the saying or account is deleted | code | Yes |
| Auth and API logs (Supabase) | Per plan; Pro: 7 days | vendor | Yes ("up to 30 days") |
| Website logs (Vercel) | Runtime logs 1 day on Pro; internal retention unverified | vendor | Yes ("up to 30 days") |
| Crash reports (Sentry) | 30 or 90 days by plan | vendor | Yes ("up to 90 days") |
| Analytics events (PostHog) | 1 year on the free plan; 7 years on paid plans, which cannot be shortened | vendor. Trigger: before any paid plan, change the policy or delete by API | Yes ("up to 1 year") |
| Analytics person on account deletion | Deleted with the account | not enforced yet (A6) | Implied by deletion |
| Waitlist | Until unsubscribe or request; at most 12 months after the app goes on sale | manual (action R-1) | Yes |
| Support and privacy emails | 2 years after the last message | not enforced (action R-2) | Yes |
| Request and breach logs | 6 years; no names or emails (hash only) | manual | Yes |
| Purchase records (coming) | 6 years from the end of the accounting period (Finance Act 1998 Sch. 18 para. 21) | vendor (stores, RevenueCat) + manual | Yes |
| Outreach contacts | 12 months after the last contact | manual | Not stated (not a user-facing activity) |
3. Actions
| ID | Action | Owner |
|---|---|---|
| R-1 | Calendar the waitlist deletion: 12 months after the store release | system |
| R-2 | Mail retention rule (2 years) for Wamemba me mail, once it has its own mailbox | system |
| R-3 | Re-check this schedule when S3, S4 and S6 land | system |
| R-4 | Before a paid PostHog plan: change the policy's analytics row, or delete events after 1 year by API | system |
4. Review
With ropa.md, every 6 months, and when a vendor changes its retention. Next review: 2027-04-15.