How we keep ourselves accountable
DPIA: children's sayings, voices and family use
This data protection impact assessment (DPIA) covers Wamemba me: an app in which parents keep the funny things and made-up words their young children say, with their first names, birthdays and (coming) short voice clips, and share some of them with family. It follows the steps of the ICO DPIA template and includes the assessment of whether the ICO Age Appropriate Design Code (the Children's Code) applies.
- ICO, Data protection impact assessments: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/
- ICO, Children's code, services covered: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/childrens-information/childrens-code-guidance-and-resources/age-appropriate-design-a-code-of-practice-for-online-services/services-covered-by-this-code/
- ICO, Likely to be accessed by children (2023 guidance): https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/childrens-information/childrens-code-guidance-and-resources/likely-to-be-accessed-by-children/
Risk scores use severity (1 to 5) × likelihood (1 to 5): 1-4 low, 5-9 medium, 10-15 high, 16-25 critical (the scale of the legal-risk-assessment method, risk-assessment.md). This document is not legal advice. A qualified lawyer has not reviewed it. The regulator named "ICO" here has been the Information Commission since 30 September 2026 (ropa.md section 1).
1. Why a DPIA is necessary
A DPIA is mandatory. The processing meets these criteria from the ICO list and the EDPB guidelines (WP248 rev.01):
- Vulnerable data subjects: children. The service exists to keep data about children aged about 2 to 8: their first names, birthdays, their words and (coming) their voices. Children cannot understand or control this processing.
- Data about people who are not users. The children, and other people named as speakers, never deal with Wamemba me.
- Matching or combining with sharing. Sayings can be shared outside the family by link and card (coming), which takes the child's words beyond the household.
- Systematic processing that people will rely on for years. Families will keep a child's words for their whole childhood; a loss or leak cannot be put right.
- Transfers to the USA for some vendors (
tra-international-transfers.md).
Three or more criteria are met (WP248: two are normally enough). The ICO's list also names "processing the personal data of children" for profiling, marketing or online services offered directly to them; Wamemba me does none of these, but the data is about children, so the assessment is done in full.
2. Description of the processing
2.1 Nature
| Flow | What happens | Who receives it | State |
|---|---|---|---|
| First launch | The app signs in anonymously and makes an account (random UUID) | Supabase (London) | Live |
| Add a child | First name, optional birthday | Supabase | Live |
| Dictate a saying | The phone transcribes the parent's speech on the device; audio is not kept or sent | Nobody: on the device | Live (iOS; Android 13+) |
| Save a saying | Saved on the phone first, then synced: lines, speakers, context, made-up word flag, meaning (parents only) | Supabase | Live |
| Back up | Link Sign in with Apple or an email address | Supabase; Apple | Live (email: see R12) |
| Crash reports | Error reports with the account id, never content | Sentry (EU) | Live |
| Analytics | Fixed events with numbers and fixed words only; consent first in UK, EU, EEA, CH | PostHog (EU) | Live (consent screen coming) |
| Voice clip | Parent records the child saying it again; stored privately | Supabase Storage | Coming (S3) |
| Cards and links | A card image; a private link showing first name, age, context, words, clip | Recipients chosen by the parent; Vercel | Coming (S3) |
| Family circle | Partner (full access); grandparent viewers; weekly email | Supabase; Resend | Coming (S6) |
| Subscriptions | Store purchase; entitlement via RevenueCat webhook | Apple, Google, RevenueCat | Coming (S4) |
| Notifications | Trial reminder; On this day; clean-up notice. Generic lock-screen text | Expo, APNs, FCM | Coming |
| Clean-up | Never-subscribed anonymous accounts deleted 90 days after the last open | Supabase | Coming (S4) |
Nothing goes to an AI model. There is no advertising SDK, no ad identifier, no tracking across apps, and no sale of data.
2.2 Scope
- Data: children's first names and birthdays; the text of what they said; who said each line (a child, or a name the parent types); context; private word meanings; (coming) audio of a child's voice. Parent: account id, optional email or Apple identifier.
- Volume on the effective date: none in production (internal testing only). Planned: consumer scale in the UK and the US.
- Duration: as long as the family keeps the account. A lapsed subscriber keeps read and export access for good (spec §3 rule 3), so retention is long by design.
- Geography: UK first, the US, and other storefronts (EU open:
ropa.md2.2).
2.3 Context
- The parent chooses what to keep and expects the privacy of a family notebook or a shoebox of keepsakes.
- The children are very young and cannot know, consent or object. Later in life they may be glad of the record, or embarrassed by it. The words are funny because they are innocent; they can still be about bodies, toilets, family arguments, illness or a parent's absence.
- A made-up word can be a family's private language. Its meaning is kept private by design (spec §4.3).
- Separated parents, step-families and grandparents all appear in family life. A parent can share a child's words with people the other parent would not choose.
- Public concern is high about children's images and voices online, AI voice cloning and "sharenting".
- The product's own rules already answer much of this (spec §3): real voices only, transcription on the device, no ads, no training, first names only, parent-operated.
2.4 Purposes
To let a parent catch what a young child said before it is forgotten, keep it with the child's age and the moment, look back on it, and share it with family if they choose. The business purpose is a paid subscription; data is never the product.
3. Children's Code: is Wamemba me likely to be accessed by children?
3.1 The test
The Code applies to information society services "likely to be accessed by children" (under 18). "Likely" means more probable than not, and the ICO asks whether a significant (more than de minimis) number of children use the service. A service that decides it is out of scope must record its reasons with evidence, and conform if evidence later shows a significant number of children use it. Since 5 February 2026 (DUAA s.81; SI 2026/82) the "children's higher protection matters" duty in UK GDPR Article 25(1A) applies to services in the Code's scope; the ICO says conforming to the Code is likely to meet it.
3.2 Assessment against the ICO factors
| ICO factor | Wamemba me | Points to |
|---|---|---|
| Nature of the service and who it is for | A keepsake tool for parents; the value is to the adult, years later | Adults |
| Content that appeals to children | The brand is crayon-coloured and the subject is children, but the app has no games, characters, rewards or child-facing content. Screens are lists of sayings and forms for adults | Mostly adults. Watch the crayon style (the onboarding film and store art) |
| How the service is accessed | A paid subscription bought through the App Store or Google Play from the first session (no free tier); store purchases need the account holder | Adults |
| Store category and audience declarations | App Store Lifestyle, never Kids; Google Play target audience 18+; no marketing that appeals to children (spec §9) | Adults |
| Marketing | Parent creators, parenting press, gift seasons for grandparents. Paid ads show parents only (spec §7) | Adults |
| Similar services | Baby and child journal apps (Tinybeans, Qeepsake, Cuote) are used by parents | Adults |
| Research and user evidence | Go-to-market research (2026-10-12) found the audience is parents of 2 to 8 year olds; no evidence of child users | Adults |
| Age of the children in the data | 2 to 8: most cannot read; they are subjects of the content, not users | Not users |
| Ways a child might still use it | (a) a child is handed the phone to say something; (b) a child plays clips on a parent's phone; (c) a child opens a grandparent's shared link | Incidental, supervised |
3.3 Conclusion
Wamemba me is not likely to be accessed by a significant number of children. The Code does not formally apply. Children are the subjects of the data, not users, and the incidental uses in 3.2 happen on an adult's phone, in the adult's account, with the adult present.
The children's data is still fully protected by the UK GDPR (Recital 38: children merit specific protection). So Wamemba me adopts the Code's standards voluntarily where they fit:
| Code standard | How Wamemba me meets it |
|---|---|
| 1 Best interests of the child | This DPIA weighs every flow against the child's interests (section 4.2) |
| 2 DPIA | This document |
| 4 Transparency | The privacy policy has a plain section on children and on the child's own rights |
| 5 Detrimental use of data | No advertising, profiling, nudges or engagement tricks; no use of a child's data except to keep it for the family |
| 7 Default settings | Private by default; nothing shared unless the parent sends it; analytics off by default in the UK and EU |
| 8 Data minimisation | First name and birthday only; no surname, photo, school or location |
| 9 Data sharing | Only on the parent's instruction; first names only; revocable links |
| 10 Geolocation | None collected |
| 12 Profiling | None |
| 13 Nudge techniques | None aimed at children; the paywall is aimed at adults and must not use guilt (brand rules) |
3.4 What would change the conclusion (review triggers)
- Any feature a child is meant to use: a child mode, the child recording into the app themselves, games, stickers, rewards.
- Marketing or store art that appeals to children, or an App Store category change. (Apple 5.1.4: an app outside the Kids category must not imply that children are its main audience in its name, subtitle, icon, screenshots or description; Google Play may require the Families policy if the listing has youthful animation.)
- Evidence of child users: support messages, reviews, or usage patterns.
- Shared links becoming discoverable (search, a public gallery).
Review at each trigger, and at every DPIA review.
4. Necessity and proportionality
4.1 Lawful basis
| Data subject | Basis | Why |
|---|---|---|
| Parent | Contract, 6(1)(b) | The parent asks Wamemba me to keep their family's sayings |
| Child, and anyone else named as a speaker | Legitimate interests, 6(1)(f) | Not party to the contract. LIA in lawful-basis-and-retention.md 1.2: the purpose is legitimate (keeping a family's memories), the processing is necessary (the sayings are the service), and the balance favours it because the data is minimal, private to the family, never used for any other purpose, and deletable at any time, including at the child's own request |
No Article 9 condition is needed: the service does not ask for special category data. A saying can mention health ("my tummy hurts") or a parent's beliefs; that is incidental, chosen by the parent, never inferred or analysed. A voice clip is not biometric data (4.3).
Consent is not used as the basis for the child's data: the child cannot give it, and a parent's consent "on behalf of" a young child is not needed where legitimate interests fits and would make deletion depend on withdrawal mechanics.
4.2 The child's best interests
| Question | Answer |
|---|---|
| Does the child benefit? | Yes: a record of their early words that the family treasures and can give them later |
| Could the processing harm the child? | Through disclosure: a saying that embarrasses them later, shared beyond the family; a clip of their voice reused or cloned; a leak tied to a full identity. The design answers each (section 6) |
| Can the child exercise rights? | Through the parent while young; directly once they are competent (from about 12 in the UK). The privacy policy and dsar-procedure.md 3.3 say so, and say we listen to the child |
| Is a separated parent's or wider family's interest affected? | Yes, possibly: one parent can share what the other would not. Terms section 5 asks parents to share only in ways the child's parents would be happy with; the solicitor brief asks whether more is needed |
4.3 Is a voice clip biometric or special category data?
No. The ICO says a raw audio recording is personal data but becomes biometric data only after "specific technical processing", and special category data only when processed to uniquely identify someone (ICO biometric data guidance, key concepts: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/lawful-basis/biometric-data-guidance-biometric-recognition/key-data-protection-concepts/). Wamemba me stores and replays clips and nothing else. Rule: no speaker recognition, voiceprints, voice cloning or audio analysis of clips, ever, without a new DPIA. The same rule keeps clips outside COPPA's 2025 "biometric identifier" (voiceprint) definition.
4.4 COPPA (United States)
COPPA governs personal information collected online from a child under 13 by an operator of a service directed to children or with actual knowledge (16 CFR 312, as amended in 2025; compliance date 22 April 2026). The FTC's COPPA FAQ A.8 says COPPA does not apply to information about children collected from parents. Names, birthdays and sayings that a parent enters are therefore outside COPPA.
Open risk (R9): a voice clip "contains a child's voice", which is personal information under COPPA. If the app prompts the child to speak into it, that could be read as collecting from the child. The 2025 audio-file exception (§312.5(c)(9)) does not help, because it requires immediate deletion. Mitigation in the design: recording is the parent's act ("Got them to say it again?"), on the parent's phone, in a paid adult account; the app is not directed to children. A US legal opinion before clips ship is in the solicitor brief.
4.5 Is each flow necessary, and could less data do?
| Flow | Necessary? | Less data? |
|---|---|---|
| First name | Yes: whose saying | Initials would break the product; first name is already the minimum |
| Birthday | Optional; needed only for exact age | Could store age only, but age at each saying needs the date of birth. Kept optional |
| Sayings and context | The service | The parent chooses what to keep |
| Word meanings | Optional, private | Separate table, parents only |
| Server copy | Needed for backup and family sharing | Local-only would lose sayings with a phone |
| Dictation | Convenience | On the device; no audio kept |
| Voice clip | Optional bonus | Parent's choice per saying; private bucket |
| Crash reports | To fix faults | No content, no screenshots, scrubbed taps |
| Analytics | To improve activation | No content; consent in UK/EU; could drop the user id, but lessons from Doxa (spec §10 lesson 4) show the funnel breaks without it. Kept, with deletion on account deletion (A6) |
| Long retention for lapsed subscribers | A promise to families (spec §3 rule 3) | Storage limitation tension: the purpose (the family's archive) continues while the account exists. Mitigation A9: a gentle check after 3 years without an open |
4.6 Information to people
Privacy policy version 2.0 (privacy.md), written in plain language with "in short" summaries, a section on children and the child's own rights, and a clear list of what is live and what is coming. Children are not users, so no child-facing notice is given; the policy tells parents how to explain it if a child asks.
5. Consultation
| Who | How | Result |
|---|---|---|
| Parents | Product research (2026-10-12): parents keep sayings in phone notes and fear losing them; "held my entries hostage" | Export any time; lapsed members keep access |
| Children | Not consulted directly (aged 2 to 8). Their interests are represented through section 4.2 | Action A10: when the app has users, ask parents what their older children think of having their sayings kept |
| Processors | Vendor terms read 2026-10-14 (register) | PostHog training opt-out and DPA; Sentry DPA; Namecheap transfer gap; Supabase email limit |
| Legal advice | None yet | Solicitor brief (solicitor-brief.md) before public launch |
| DPO | None appointed (ropa.md 2.3) | The privacy lead wrote this DPIA with the legal plugin's methods |
6. Risks to individuals
Inherent risk is the risk before Wamemba me's measures. Residual risk is after the measures in section 7.
| ID | Risk to the individual | Sev. | Lik. | Inherent | Measures | Residual |
|---|---|---|---|---|---|---|
| R1 | A breach or row-level security error exposes a family's sayings, children's names and birthdays to strangers. Harm: a child's identity and words exposed; distress | 4 | 3 | 12 high | M1, M2, M3 | 4 low (4×1) |
| R2 | A shared link reaches people the family didn't intend (forwarded, posted). Harm: a child's words and voice outside the family | 3 | 4 | 12 high | M5, M6 | 6 medium (3×2) |
| R3 | A child's voice clip is downloaded and used to clone their voice or misused. Harm: impersonation, deepfake | 4 | 2 | 8 medium | M5, M6, M7 | 4 low (4×1) |
| R4 | Content leaks through telemetry: crash reports, analytics, lock-screen notifications. Harm: disclosure to vendors or people nearby | 3 | 3 | 9 medium | M4, M8 | 2 low (2×1) |
| R5 | The child later objects to having been recorded and shared ("sharenting"). Harm: embarrassment, loss of control over their own story | 3 | 3 | 9 medium | M6, M9, M10 | 6 medium (3×2) |
| R6 | One parent shares or keeps a child's words against the other parent's wishes (separation). Harm: conflict; the child caught in it | 3 | 2 | 6 medium | M6, M10, Terms s.5 | 6 medium: solicitor brief |
| R7 | A lost, shared or unlocked phone shows the sayings to someone else; the local copy is in the app sandbox, not separately encrypted | 2 | 3 | 6 medium | OS sandbox and file protection; keychain for tokens | 4 low (2×2). Action A7: consider an app lock |
| R8 | Data is kept longer than needed: lapsed accounts forever; abandoned anonymous accounts; waitlist | 2 | 4 | 8 medium | M11, A8, A9 | 4 low (2×2) once the clean-up is on |
| R9 | US law: a voice clip of a child is treated as collected "from a child" under COPPA, needing verifiable parental consent | 3 | 2 | 6 medium | §4.4 design; parent's act; paid adult account | 6 medium: legal opinion before S3 |
| R10 | Vendors use data for their own purposes (model training, analytics) | 3 | 3 | 9 medium | No content to vendors except Supabase; PostHog opt-out (A3); Sentry setting (A4) | 3 low (3×1) |
| R11 | A parent loses their sayings (no backup, phone lost, account "gone", the 90-day clean-up deleting a paying family's data). Harm: loss of irreplaceable memories | 4 | 3 | 12 high | Local-first store; anonymous account from day one; Restore Purchases brings the family back (spec §5); clean-up only for never-subscribed accounts; the "gone" carry-over before clean-up | 4 low (4×1) |
| R12 | A parent backs up with email but the confirmation never arrives (Supabase's built-in email reaches only team members). Harm: the parent believes they are backed up when they are not | 3 | 5 | 15 high | A1 (custom SMTP before public release) | 3 low after A1 |
| R13 | Operations sessions read family data under consumer AI terms | 3 | 2 | 6 medium | Rule: schema and aggregate queries only; A5 | 3 low |
| R14 | Analytics run before consent in the UK or EU, or a parent elsewhere cannot opt out | 2 | 2 | 4 low | privacy.ts defaults off where consent is needed; tests | 2 low; A2 adds the opt-out |
7. Measures
| ID | Measure | State |
|---|---|---|
| M1 | Row-level security on every table; deny by default; pgTAP tests per table as anon, owner, viewer and another family's member, on prod's Postgres image, required on every PR | Live |
| M2 | Every change through the recursive quality gate; critical tier for database, auth, export, delete, sharing, money and microphone capture | Live |
| M3 | Breach procedure with a 72-hour clock and an automatic fallback (breach-response.md) | Live |
| M4 | Telemetry minimisation: Sentry with no screenshots, view hierarchy, replay or default PII; breadcrumbs scrubbed; analytics sanitise() and a declared event list; tests guard both | Live |
| M5 | Share links: unguessable token, revocable, a definer function returning only first names, ages, context, lines and clip URL; signed clip URLs with a short life; caching and rate limits; no indexing (noindex) | Coming with S3; must be in S3's PR |
| M6 | First names only on cards and pages; never surnames, birthdays or meanings (spec §4.4, brand rules) | Rule; enforced in S3's tests |
| M7 | Real voices only: no cloning, no voice analysis; clips stored privately | Rule (spec §3 rule 2; terms s.6) |
| M8 | Notification text never quotes a saying | Rule for S4/S8 |
| M9 | Delete any saying, child or account; export any time | Delete saying and child: live. Account delete and export: coming (A6) |
| M10 | The child's own rights recognised in the privacy policy and the request procedure | Live (v2.0) |
| M11 | Retention schedule (lawful-basis-and-retention.md) | Live as policy; clean-up job coming |
8. Actions
| ID | Action | Owner | When |
|---|---|---|---|
| A1 | Custom SMTP (Resend, eu-west-1) for auth emails | system | Before public release |
| A2 | Analytics consent and opt-out screens (onboarding and Settings) | system | S4, before public release |
| A3 | PostHog: sign the DPA (Garth); opt out of model development (system) | Garth / system | Before public release |
| A4 | Sentry: accept the DPA and turn off aggregated identifying data for wamemba-me | system | Now |
| A5 | Confirm Commercial Terms for the operations AI account | Garth | Now |
| A6 | In-app account deletion (with PostHog person deletion and the phone's copy wiped) and export | system | Before public release (App Store 5.1.1(v), Google Play deletion link) |
| A7 | Consider an optional app lock (Face ID) for the sayings | system | Backlog |
| A8 | Turn on the 90-day clean-up only after the "gone" carry-over exists | system | S4 |
| A9 | Decide a re-check for accounts unopened for 3 years (email, keep or export) | Garth | Before the first anniversary |
| A10 | Ask parents what older children think (survey) | system | After 1,000 families |
| A11 | Legal opinion: COPPA (clips), UK GDPR basis for the child's data, separated parents | Garth | Before public launch; clips before S3 ships |
9. Outcome
With measures M1 to M11 and actions A1 to A6 done before the public release, no residual risk is high. The remaining medium risks (R2, R5, R6, R9) are inherent in letting families share their children's words; they are reduced by design and by the parent's control, and R6 and R9 go to the solicitor. Prior consultation with the regulator (Article 36) is not needed.
The app must not be released to the public while R12 is open (email backup fails for real parents) or while A2 and A6 are not done.
10. Sign-off
| Role | Name | Decision | Date |
|---|---|---|---|
| Prepared by | Claude (AI agent), for the privacy lead | Recommend approval subject to A1, A2, A6 before public release | 2026-10-15 |
| Controller (director) | Garth Watson | ________ | ________ |
| Legal review | Not yet done | ________ | ________ |
11. Review
At each trigger in section 3.4; when clips, sharing, the family circle or purchases ship (update section 2.1 and the risks); after a breach; and every 6 months. Next review: 2027-04-15.