Trust

Security overview

Last updated November 3, 2026

TaleTykes holds information about children, so we build security into how the service works rather than adding it later. This page describes our written information security program in plain words: where data lives, who can see it, how people sign in, how we watch for problems and what we do when one happens. It ends with how to report a vulnerability to us and what we do not claim.

Schools can ask for a fuller description of the program from schools@taletykes.com.

Our security program

We keep a written information security program, as the amended COPPA Rule and many state student privacy laws require. A named person at TaleTykes owns the program and answers for it. Under it we:

list the risks to the information we hold and review them at least once a year, and after any significant change to the service
put safeguards in place for each risk, and test that they work
limit access to the people who need it, and record that access
check vendors before they receive data, and bind them by contract
train everyone who handles personal information
keep a written incident response plan
review and update the program at least once a year

The rest of this page describes the main safeguards.

Hosting and encryption

TaleTykes runs on Vercel (website, app servers and private file storage) and Neon (our Postgres database), both in the eastern United States. The Subprocessors page lists every company that receives data.

All traffic is encrypted in transit with TLS 1.2 or newer. Our domain is on the HTTP Strict Transport Security (HSTS) preload list, so browsers only ever connect over HTTPS.
The database and file storage are encrypted at rest by our providers.
Some fields get a second layer of encryption with our own application keys (AES-256-GCM): roster tokens, Google Classroom refresh tokens, consent evidence and the accommodations a grown-up sets for a child.
Sign-in secrets that only need checking, never reading, are stored as one-way hashes: children's picture passwords and passphrases, trusted device tokens, one-time sign-in codes and link tokens.
Book pictures and audio are kept in private storage and served through our own server after a permission check. There are no public links to them.

Database isolation

The database itself decides who can read each row, not only the application code.

Every table has Postgres row-level security turned on and forced. A parent's session can read only that family's rows, a teacher's only their own classes and classes shared with them, and a child's only their own.
The application connects with runtime roles that cannot bypass row-level security and own nothing. They cannot change the schema or turn the rules off.
Who is asking is set once per database transaction and cleared when it ends, so one request can never inherit another's identity.
The role that owns the schema is used only by the migration job in our deployment pipeline. No person or running application uses it.
An automated check confirms every table has row-level security on and forced, with at least one policy. It runs on every proposed change and every night against the live database.

Application security

Every server action and API route follows the same order: check the session, validate the input strictly and reject anything unexpected, limit the query to what the signed-in person owns, and return only what the screen needs.
Every page sends a strict Content Security Policy. Only scripts we ship can run, and pages cannot be framed by other sites. There are no third-party scripts, analytics, trackers or ads.
Responses to signed-in people are marked private and are never cached by shared caches.
Webhooks, such as payment events from Stripe, are read as the raw body, verified by HMAC signature with a constant-time comparison, and recorded by event id so a replay has no effect.
Requests our server makes to addresses a customer gives us, such as an LMS, go through a guard that refuses private and internal network addresses.
Sign-in attempts, sign-in codes, quote requests and other sensitive actions are rate-limited. The counters are keyed by one-way HMACs, never raw email addresses or IP addresses.

Adults

Parents, guardians and teachers sign in with an email link, an 8-digit email code, a passkey, Google, Apple or, for schools, their district's SAML single sign-on. Families have no passwords to leak.
Email links and codes expire after 5 minutes, allow a limited number of tries, and are stored hashed.
Adults can add an authenticator app as a second step. Before sensitive account changes, such as adding or removing a sign-in method, we ask for a fresh check.
Sessions end after a period of no use and after a maximum length: 30 days idle and 90 days at most for parents, 12 hours and 30 days for teachers.
Removing a passkey or turning off a second step signs out every other session. Other devices are signed out within a minute.

Children

Children are never account holders and have no email or password. They sign in only on a device a grown-up has trusted, with a picture password, a three-word passphrase, a username or a class badge.
A child space locks for 15 minutes after 5 missed attempts.
Child sessions are short: 4 hours idle and 24 hours at most on a family device, 10 hours on a class device, 30 days in the iOS app on a trusted device. A grown-up can sign a device out at any time.
A child without a parent's core consent, or a school's authorization, cannot sign in.

Staff

Staff sign in only with a second step, every session. Staff sessions end after 8 hours idle and 24 hours at most.
See the next section for how staff access to data is limited.

Staff access controls

Most TaleTykes staff never need to see a child's information. When someone does, for example to answer a parent's request or review a safety concern, access is limited and recorded.

Named roles. Each staff member holds one of seven roles, such as safety reviewer, support or privacy officer. Each role opens only the parts of the staff console it needs.
Two-person grants. Granting or changing a staff role needs a request from one person and approval from a second. The system refuses approval by the requester or by the person the request is about. Requests expire if not approved.
Break-glass windows. Reading a specific family's or child's records needs an access window with a written reason. Windows last at most 30 minutes, the database enforces that limit, and they close on their own.
Hash-chained audit log. Sensitive actions, including every staff access to child data, every role grant and every change to consent, are written to an append-only audit log. Each entry includes a hash of the one before it, so an edited or removed entry breaks the chain and shows. No one, including our own engineers, can edit or delete entries through the application.
Fast removal. One person can sign a staff member out everywhere at once; removing access never needs a second approval.

Staff roles are granted only through a reviewed script, never from a web form.

Secrets and keys

Secrets such as database credentials, vendor keys and encryption keys live in our hosting platform's encrypted settings, separate for production, preview and development.
No secret is ever sent to the browser. An automated check on every change fails the build if a secret appears in the code sent to browsers.
Secrets are never committed to our code repository.
Each AI vendor has a separate key for each environment, with spending limits, and a switch can stop all generation at once if we need it.
When someone leaves or a key may be exposed, we rotate the keys involved.

Vendor security

Before a vendor receives personal information, we review its security and privacy practices, confirm it will not use our data for its own purposes, and sign a contract that requires security, confidentiality, breach notice and deletion at the end of the service. We review vendors at least once a year. The Subprocessors page describes this process and lists every vendor.

The AI pipeline

AI helps write book text and draw pictures. We keep it apart from children's personal information.

Children never type to a model. Their inputs are pictures, tiles and choices.
Requests to AI vendors are built from book settings and menu choices. A check runs on every request and blocks it if it finds personal information.
No child or student identifier is ever sent to an AI vendor. Names are added after generation, only if a parent allowed them.
Nothing generated reaches a child until our own code checks it for decodability, readability, safety and format. We never stream unchecked text to a child.
AI vendors operate under terms that bar them from training on what we send and limit retention.
Spending on each vendor is counted and capped, so a fault cannot run up unlimited requests.

The AI page explains more.

Secure development

All code changes go through a pull request, and only the owner merges to the main branch. The main branch is protected, and the required checks must pass first.
Every proposed change runs linting, type checks, unit tests, the row-level security check, and database isolation tests that try to read across families and classes and must fail to do so.
Database changes are forward-only migrations, applied by the pipeline, never by hand to production.
Our rules ban building SQL from raw strings, running code from strings, reading configuration outside one checked module, and inserting unsanitized HTML.
Dependencies are pinned to exact versions in a lockfile. New package releases wait three days before we can adopt them, except same-day security fixes to our core framework packages, and only approved packages may run install scripts.

Logging and monitoring

Server errors and request logs are written to our hosting provider's logs, where they are kept for 30 days or less. We do not use any third-party error-tracking or crash-reporting service, so error details stay with our host.
We keep logs free of children's names, writing and sign-in secrets.
Our staff console shows open incidents, safety cases and the audit log, so the people responsible can spot unusual activity, such as unexpected staff access.
The nightly row-level security check and the audit log chain help us spot changes that should not have happened.

Backups and recovery

Our database provider keeps continuous, encrypted backups that let us restore to a point in time within a rolling window of up to 30 days. Older backups roll off, so deleted data leaves backups within 30 days. We practice restoring from backup so we know it works.

Incident response

We keep a written incident response plan. It says who leads, who is called, how we contain and investigate a problem, how we record what happened, and when and how we tell people.

Schools. If we confirm a security incident affecting a school's students, we tell the school within 72 hours of confirming it, or sooner if its data privacy agreement says so. We include what happened, what data and how many students were involved, what we have done and what the school can do.
Families. We tell affected parents and adult account holders without unreasonable delay, and within the time state law sets.
Regulators. We notify state attorneys general and other regulators when the law requires it.
Afterwards. We write a review of every significant incident, fix the cause and update the plan.

Reporting a vulnerability

We welcome reports from security researchers and anyone else who finds a problem.

How to report

Email security@taletykes.com. Tell us what you found, where, and the steps to reproduce it. Screenshots or a short proof of concept help. Please do not include real children's information in your report.

What is in scope

www.taletykes.com and its subdomains that we operate
the TaleTykes app for iPhone and iPad
our API, including the routes the iOS app and LTI platforms use

What is out of scope

services run by our vendors or by integrations, such as Stripe, Google or Clever (report those to them)
denial-of-service or load testing
social engineering, phishing or physical attacks on our staff or offices
spam, or sending many messages through our forms
reports from automated scanners with no shown impact
missing security headers or settings with no shown way to exploit them

Rules for testing

Use only test accounts you create, and never access, change or delete other people's data. If you reach real personal information by accident, stop, do not keep a copy, and tell us.
Do not test in a way that harms the service or its users, or that involves children.
Give us reasonable time to fix a problem before you disclose it. We ask for no public disclosure until the problem is fixed or 90 days have passed, whichever is sooner, and we are glad to agree a date with you.

Our safe harbor

If you follow these rules in good faith, we will not take legal action against you or report you to law enforcement for your research, and we will treat it as authorized. If someone else brings a claim against you over research that followed these rules, we will make it known that your work was authorized.

What happens next

We reply within 2 business days to confirm we have your report. We keep you informed while we investigate and fix it, and we tell you when it is fixed. With your permission, we will thank you by name when we publish a fix.

We do not run a paid bug bounty program yet.

What we do not claim

We are a young company. We do not hold SOC 2, ISO 27001 or any other security certification, and we do not claim the results of any audit or penetration test we have not had. We plan independent penetration testing before launch and after major changes. If that changes, we will update this page.

No system is perfectly secure. What we can promise is that we follow the program on this page, review it regularly, and tell you honestly if something goes wrong.

What schools can request

Schools and districts can ask schools@taletykes.com for:

a summary of our written information security program
answers to a reasonable security or privacy questionnaire
our incident response commitments in writing, in the school agreement or a data privacy agreement
our list of subprocessors and the 30-day change notice
a signed state data privacy agreement or the National Data Privacy Agreement
confirmation in writing that a school's data has been deleted
a call with the person who owns our security program

Our School terms set out these commitments in contract form.