How we protect your child’s information
Version 2026-08-05-v1 · Effective date: [to be set on adoption]
Draft — not yet in force. This policy is under attorney review and does not take effect until an effective date is set above. It describes how StoryKinder is actually built, and we publish it now so parents can read it before we ask for anything.
We maintain a written security program covering all children’s personal information we hold. This page summarizes it in plain language. The full program is an internal document, kept that way deliberately — publishing our risk assessment would mostly help someone attacking us.
The main control is not collecting much
Most of the risk to a child’s information is designed out of StoryKinder rather than defended against. We hold no child’s real name, email address, home address, phone number, birth date, photograph, audio, video, biometric identifier, or location. Children do not sign in and cannot type free text anywhere in the product.
What remains is a nickname, an avatar you chose from our set, an optional age band, and a record of what was read. The less we hold, the less there is to lose.
What protects the rest
- Access control at the database itself. Every table holding a child’s information is restricted to the parent account that owns it, enforced by the database rather than only by application code.
- Separation of roles. Authors working in the StoryKinder Studio cannot reach reader data at all. Elevated roles cannot be granted by a user to themselves.
- A locked parent area. Reviewing, exporting, or deleting a child’s information requires a PIN or re-authentication, so a child on a signed-in device cannot reach it.
- No third-party code on children’s pages. A Content Security Policy blocks third-party requests on the routes children use. There are no advertising SDKs, no analytics tags, and no session-replay tools.
- Encryption in transit and at rest, including backups.
- Secrets held only in encrypted hosting configuration — never in our code, never in a page sent to your browser, never in a log.
We test the controls, and we test that the tests work
Access controls are checked automatically on every deployment, including attempts to read, write, and delete another family’s data using a real second account. Those checks run against a real database, not a simulation.
We also hold ourselves to a stricter rule: each security test must be confirmed to fail when the control it covers is deliberately removed. A test that would still pass with the protection switched off is not a test.
Vendors
A small number of vendors help us run StoryKinder — our database and authentication provider, our hosting provider, our payment processor, and our email provider. They are listed by name, with what each one can see, in section 5 of our Privacy Policy. Each may use information only to provide its service to us, and any vendor that can reach children’s information must give us written assurances that it protects that information.
If something goes wrong
If we suspect that children’s information has been exposed, we contain the problem, determine what was affected, notify affected parents, notify authorities where the law requires it, and fix the cause. We would rather tell you about a problem than have you discover it.
Review
The program is reviewed at least once a year, and whenever we change our architecture, our vendors, or what we collect. Any change that would collect more about a child than you agreed to requires a fresh notice and fresh consent before it takes effect — see section 7 of the Privacy Policy and our Retention and Deletion Policy.
Contact
If you have a security concern about StoryKinder, we want to hear it directly.
TradePals LLCPrivacy and legal: legal@storykinder.com
Everything else: support@storykinder.com
[STREET ADDRESS], San Antonio, TX [ZIP] · [PHONE]
