Data protection
Data protection impact assessment
A summary of the risks we identified, what we built in response, and what risk is left over. Published rather than filed, because a service handling children’s data should be assessable from the outside.
Last reviewed 8 August 2026.
Status of this assessment
Why an assessment is required
A DPIA is mandatory here on more than one ground. The service is directed at children, so the ICO’s Age Appropriate Design Code applies. It processes data in a context where a failure has a physical safety consequence rather than only a financial one. And it processes information about a child in circumstances the child cannot meaningfully understand or object to.
We would have written one anyway. The interesting question in this product is not whether the data is lawful to hold, it is whether the design leaks identity — and that question is only answerable by working through it in this form.
What is processed
The full inventory is in the privacy notice. In summary: a parent’s email; emergency contact names and numbers; a three-word phrase; one-way checks derived from a child’s first name; alert records containing a finder’s self-declared name, number and location; and lookup logs containing a one-way check of an address.
No child’s name, age, date of birth, photograph, description, school or location is stored in readable form, or in any form from which it can be recovered.
Necessity and proportionality
Two design choices carry most of the weight, and both were chosen to reduce what is held rather than to add a feature.
The asymmetry. A lookup returns confirmation and nothing else. The finder is never given the family’s name, number, address, or the number of contacts. Information flows one way, from the finder to the family. This makes the obvious attack — look up a phrase to learn about a family — worthless, because there is nothing to learn.
The second factor is a check, not a record. A first name is a low-entropy secret, spoken aloud constantly, so it is useless as a stored asset and valuable only as a confirmation. Storing a keyed one-way digest gives the full security benefit of the second factor while making the underlying name unavailable to us, to an attacker with a database copy, and to a subject access request. We consider the loss of subject access over that one field to be proportionate, and we say so on the privacy notice rather than hiding it.
Less intrusive alternatives were considered and rejected: a QR code on a wristband can be read by anyone who photographs it and carries no second factor; a phone number printed on a label discloses the family’s number to everybody who sees the child; a tracking device is a categorically larger intrusion for a different problem.
Risks and controls
| Risk | Control | Residual |
|---|---|---|
| Someone guesses or enumerates phrases to trigger alerts or confirm a family exists | Per-address rate limiting with a block, a human check on the lookup page, every attempt logged, and a second factor the guesser does not have | Low. A hit still discloses nothing about the family |
| A database copy is stolen | Phrases and name checks are keyed one-way digests; the key is held in the runtime environment, never in the database. Tokens are stored hashed | Medium for contact details, which must be usable and so are stored plainly. Low for anything about a child |
| A person with bad intent is genuinely standing with the child | Cannot be prevented by any three-word system — they can ask the child their name. The control is evidential: name, working mobile number, timestamp and log | Accepted and published. See the safeguarding statement |
| A family’s phrase becomes public — printed on a bag tag, posted online | Phrase reissue, up to five times; guidance to treat the phrase as a house key | Low, and in the family’s control |
| An alert is sent to the wrong person because a number was mistyped | A contact must confirm their own number or address before it is ever used; unconfirmed contacts are excluded from every send | Low |
| A child cannot recall the phrase when it matters | Concrete imageable words, pictograms that work before reading age, a parent-written sentence, and word order that does not have to be remembered | Not yet evidenced. The recall study is outstanding |
| The service fails and a family believes they are covered when they are not | Nothing fails closed: a failed name check downgrades an alert rather than blocking it. Copy never implies supervision or protection | Low, and actively managed through the wording |
| A child is identified by combining our data with something else | There is no readable child data to combine. The strongest link is a family label such as “Child 1” | Low |
Residual risk
The residual risk we accept, and publish, is this: ThreeSafe cannot stop a person who is genuinely with a child from learning that child’s first name and using it. No phrase-based system can. What it converts that person into is somebody who has given a name, a working mobile number and a location, at a recorded time, to a family who can ring them and to staff who can act.
Against that we set the counterfactual, which is a distressed child who cannot say a phone number and a parent who is not found for forty minutes.
What is still outstanding
- The completed statutory DPIA document, signed off.
- ICO registration and the fee.
- The record of processing activities under Article 30.
- Executed data processing agreements with each named processor.
- A documented breach response procedure with named roles.
- The child recall study.
- An independent security review before any live deployment.
Questions, or a request for the working document, go to privacy@threesafe.org.