How we look after this

This is the written information security programme for TaleTykes. The rule on children's privacy requires one, requires somebody to be named as responsible for it, and requires it to be assessed and tested rather than merely written. It is published rather than filed, because a family should be able to read what we claim to do.

Who is responsible

Connor Maze is the security coordinator for TaleTykes and is accountable for everything on this page. TaleTykes is run by one person, which is stated here plainly: it means decisions are quick and it means there is no second pair of eyes, and the controls below are chosen with that in mind. Where a control would normally be "a colleague reviews it", this product uses a machine check that cannot be skipped instead.

Write to privacy@taletykes.com to report a vulnerability. We will acknowledge it within three working days and we will not pursue anyone who reports one in good faith.

What we are protecting

A child's first name, age group, avatar, hashed sign-in secret, the books they made and what they read. A parent's email address, hashed password, plan, and a one-way fingerprint of their card. We hold no card numbers, no addresses, no photographs, no voice recordings and no location.

The safeguards

One family cannot see another's data, and this is enforced by the database. The application connects as a role that cannot bypass row level security. Every request opens a transaction and declares which parent and which child it is acting for; a query that forgets to declare a context matches nothing rather than everything. Code that legitimately crosses families, such as a payment webhook or the moderation console, uses a separate owner connection and writes an audit entry.

Secrets are hashed with an algorithm chosen for the purpose. Parent passwords and children's PINs use Argon2id. A four-digit secret has little entropy, so the defence is attempt throttling, not secret strength: five wrong attempts locks the profile for fifteen minutes, and a parent can revoke every session.

A child's sign-in is a profile selector, not a security boundary. This is a deliberate design decision rather than an oversight. A child's PIN or picture sequence opens their own shelf on a device a parent has already trusted. It cannot change a setting, reach billing, see another child's books or leave the child area: leaving requires the parent's own account password. The blast radius of a guessed PIN is one shelf of that family's own books on that family's own device.

Addresses and browsers are recorded as one-way hashes. Knowing that two events came from the same place is useful. Keeping the place is not worth the risk.

Pictures and audio are private. They are stored with no public URL and served through a route that checks who is asking and signs a short-lived link.

Records that are evidence cannot be edited. The credit ledger, the audit trail and the consent records accept new rows only; a database trigger refuses updates outright and permits deletion only inside a declared erasure. A mistake is corrected by an opposing entry, never by rewriting the first one.

Staff accounts require a second factor. A staff sign-in needs time-based one-time codes actually enrolled, not merely offered. Every staff action requires a written reason, which goes to the audit trail.

Anything that can run away has a ceiling. Book generation has a per-book cost ceiling and a daily platform cap, both enforced before spending rather than after. There are kill switches for generation, signups, email and the shared library, operable from the console without a deploy.

Nothing becomes public without a person. A book is private to its family unless a parent turns sharing on and a member of staff has read it.

Testing

• The isolation rules have their own test suite, which asserts that one family's connection cannot read another's rows. It runs on every change, against a real database branch, in continuous integration.
• Unit tests cover the safety cascade, the reading checks, the moderation rules, pricing and the consent gate.
• End-to-end tests walk a family from sign-up to a finished book, including the consent gate.
• An accessibility check runs over the parent and child screens in the same pipeline.
• Dependencies are updated on a schedule and on advisory.

Assessment, and how often

The coordinator carries out a written risk assessment at least once a year, and after any change that alters what is collected or who can see it. It records what is held, who can reach it, what could go wrong, what is done about it, and what risk remains. The assessment of risk to children is published alongside this document.

The companies we rely on

Each processor is engaged under contract terms that limit them to processing on our instructions, forbid using anything for their own purposes, and forbid training models on it where that could apply. They are named in the privacy notice rather than described by category, so a family can read their terms too. We obtain and keep written assurance from each before sending anything.

If something goes wrong

1. Contain it: the kill switches stop generation, signups and mail without a deploy, and a compromised credential is rotated first.
2. Establish what was reached, using the audit trail.
3. Tell the families affected, in plain words, saying what happened, what it means for their child, and what we have done. We do this promptly and without waiting to be asked.
4. Notify the regulators that apply, within the time each requires.
5. Write down what we changed so it cannot happen the same way twice.

What this does not cover

Generated pictures are checked by a model against the age band and against the book's own characters. Nothing here matches them against databases of known illegal imagery: the tools that do require an agreement this product does not yet have. This is stated on the safety page too, because a family should know the shape of the check and not only that a check exists.