Service: kids51.com · Operator: Dzmitry Pliachko, ul. Stanisława Drabika 63/19, 52-131 Wrocław, Poland Version: DRAFT v0.1 — 14 October 2026 · Effective date: [EFFECTIVE DATE] Owner: Dzmitry Pliachko, who also coordinates our information security program.
This is our written data retention policy required by the FTC’s COPPA Rule, 16 CFR §312.10. It sets out, for each kind of information, why we collect it, why we need to keep it, and when we delete it. It is published as part of our Privacy Policy and covers all personal information we hold, with children’s information marked [CHILD]. We never keep children’s personal information indefinitely.
The retention periods in this policy are also implemented in our code (a single RETENTION setting from which the table on our website is generated), and an automated job deletes data when a period ends.
1. Retention schedule
1.1 Children’s information [CHILD]
| Data | Purpose of collection | Business need to retain | Deleted when |
|---|---|---|---|
| Child profile: nickname, avatar (fixed set), optional age band, profile ID, creation date | Show and operate the child’s profile for the parent | Needed for as long as the family uses the profile | When the parent deletes the profile or the account (immediately), or when an inactive account is deleted (see 1.2) |
| Practice events: skill, correct/incorrect, response time, game mode, timestamp | Adapt practice; show recent progress; worksheets from mistakes | Recent detail is needed for short-term adaptation and the parent’s recent-activity view; older detail is not needed because a summary is kept | 90 days after the event, automatically |
| Skill progress summary: skill, review level, next due date, right/wrong counts, last seen | Keep adaptive practice working after events are deleted | Needed for as long as the profile exists | With the profile |
| Child device link: hashed token, profile IDs allowed, device label (fixed list), created/last used | Authenticate the child’s paired device | Needed while the device is in use | When the parent unlinks the device or deletes the profile/account, or automatically after 90 days without use |
| Class membership (future teacher feature): nickname + avatar in a class | School-authorized classroom use | Needed during the school year | 60 days after the end of the school year, or earlier when the teacher deletes the class [TO CONFIRM definition of school-year end, e.g. 30 June] |
| Anonymous analytics from children’s screens (no identifiers) | Aggregate usage counts | Not personal information; kept for trend analysis | 3 months (platform limit) |
1.2 Parent (account holder) information
| Data | Purpose | Business need to retain | Deleted when |
|---|---|---|---|
| Account: email, verification date, created, last active, marketing choice, language | Provide the account and service emails | Needed while the account exists | On account deletion; or after 24 months of inactivity, 30 days after a warning email |
| Sign-in link records (hashed) | One-time sign-in (valid 15 minutes) | Short-term abuse investigation | 24 hours after creation |
| Sessions (hashed) | Keep the parent signed in | Until expiry | When the session expires (30 days after last activity) or on sign-out/deletion |
| Consent records (notice/terms versions, grant or withdrawal, timestamps incl. confirmation and withdrawal, method; hashed one-time confirm/withdraw links valid 30 days) | Prove COPPA consent and agreement to terms | Legal proof of consent | Life of the account + 3 years [TO CONFIRM — see Review Pack: conflict with deletion cascade] |
| Subscription record | Provide paid plan, reminders, cancellation, refunds | Needed while the account exists | On account deletion (financial part moves to the ledger) |
| Word lists, family charts (future) | Features requested by the parent | While the parent uses them | When the parent deletes them or the account |
| Email delivery log | Prove required notices were sent (e.g., renewal reminders) | Evidence in case of billing disputes | 18 months after sending; also on account deletion |
| Support/privacy correspondence | Answer requests | Follow-up and evidence of handling | [TO CONFIRM, e.g. 24 months after closure] |
1.3 Business and system records
| Data | Purpose | Business need | Deleted when |
|---|---|---|---|
| Financial ledger (transaction IDs, amount, currency, tax, date, refund) — no email, no child link | Accounting and tax | Legal obligation under Polish accounting and tax law | 5 years from the end of the tax year of the transaction [TO CONFIRM with accountant] |
| Payment webhook events (minimal payload) | Process each payment event exactly once | Short-term duplicate protection | 90 days |
| Deletion request record (hashed email, dates, scope) | Prove we honored deletion requests | Legal evidence | 3 years |
| Server logs (no request bodies, masked IP) | Security and troubleshooting | Short-term incident investigation | 7 days |
| Abuse-protection counters for device pairing: keyed hash of the network address (never the IP address itself), action, attempt time | Limit pairing attempts (20 per hour per network) so pairing codes cannot be guessed | Needed only for the one-hour counting window | 1 hour after the attempt, automatically (checked every minute) |
| Analytics events (no identifiers) | Usage statistics | Trend analysis | 3 months |
| Database backups (point-in-time recovery) | Disaster recovery | Restore after an incident | Rolling 30 days; deleted data is gone from backups within 30 days |
1.4 Data held by our service providers
| Provider | What | Retention |
|---|---|---|
| Cloudflare | Hosts everything above | Follows our deletion; platform logs/analytics as stated above |
| Stripe | Parent’s payment data | We delete the Stripe customer record when the account is deleted. Stripe keeps transaction data required by its own legal obligations under its privacy policy |
| [EMAIL PROVIDER — Postmark, TO CONFIRM] | Sent-message data | [TO CONFIRM: provider’s message/activity retention setting — set to the shortest available] |
2. How deletion works
- Automatic expiry. A scheduled job runs daily [TO CONFIRM frequency] and deletes rows whose period has ended. A monthly retention report checks that nothing is older than allowed.
- Child profile deletion (by the parent): immediately deletes the profile, its practice events and skill progress, and removes it from linked devices.
- Consent withdrawal without account deletion (dashboard, or the one-time link in the consent confirmation email): in one database transaction, unlinks all of the family’s devices, deletes all practice events and skill progress, pauses the child profiles (nickname and avatar only remain, nothing is collected) and records the withdrawal. The parent account and subscription are kept; the parent can give consent again later.
- Account deletion (dashboard or public form): runs immediately in one database transaction and calls Stripe:
- revoke all sessions and device links;
- delete all child profiles, practice events and skill progress;
- delete word lists and charts;
- cancel any subscription immediately and delete the Stripe customer;
- move financial lines to the anonymous ledger; delete subscription, email log and consent records [TO CONFIRM — R3];
- delete the account; record only a hashed email as proof of deletion; send a confirmation email. Commitment: completed within 7 days of the request (normally immediately); removed from backups within 30 days.
- Method. Deletion is permanent removal from the production database (SQL
DELETEin a single, tested code path), followed by expiry of point-in-time backups. Access to production data and deletion tools is limited to Dzmitry Pliachko (owner) with two-factor authentication. Deleted children’s data is not copied, exported or archived anywhere. - Inactive accounts. After 24 months without sign-in we send a warning email; if there is no sign-in within 30 days, the account is deleted as in step 3.
3. Review
This policy is reviewed at least once a year, and whenever we add a feature that collects new data, together with the annual risk assessment under our information security program (16 CFR §312.8). Any change to children’s data retention is reflected in the Privacy Policy, and material changes are notified to parents.
Retention schedule
This table is generated from the same setting our deletion job uses.
| Data | What is stored | Why | Deleted when |
|---|---|---|---|
| Child profile | Nickname, avatar (fixed set), optional age band, profile ID, creation date | Show and operate the child's profile for the parent | Immediately when the parent deletes the profile or the account, or when an inactive account is deleted |
| Practice events | Skill, correct/incorrect, response time, game mode, timestamp | Adapt practice; show recent progress; worksheets from mistakes | 90 days after the event, automatically (a summary stays in skill progress) |
| Skill progress summary | Skill, review level, next due date, right/wrong counts, last seen | Keep adaptive practice working after events are deleted | With the profile |
| Child device link | Hashed token, allowed profile IDs, device label (fixed list), created/last used; while pairing: hashed 6-digit code, its expiry (10 minutes) and a count of wrong guesses (the code stops working after 5) | Authenticate the child's paired device | When the parent unlinks the device or deletes the profile/account, or after 90 days without use |
| Parent account | Email, verification date, created, last active, marketing choice, language | Provide the account and service emails | On account deletion; or after 24 months of inactivity, 30 days after a warning email |
| Sign-in link records (hashed) | Token hash, email, expiry (15 minutes), used time | One-time sign-in link valid 15 minutes | 24 hours after creation |
| Sessions (hashed) | Session ID hash, parent ID, created, expiry | Keep the parent signed in | When the session expires (30 days after last activity) or on sign-out/deletion |
| Consent records | Consent kind (terms, COPPA notice, marketing), grant or withdrawal, policy version, method, timestamps (given, confirmation email sent, confirmed by the parent, withdrawn); hashed one-time confirm/withdraw links (valid 30 days) | Prove COPPA consent, its email confirmation and any withdrawal, and agreement to terms | On account deletion (a minimal consent proof is kept, see next row) |
| Consent proof after deletion | Hashed email, consent kind, grant or withdrawal, policy version, dates. No child data | Legal proof that consent was obtained (COPPA, California §17602) | 3 years after account deletion (or 1 year after the subscription ended, if later) [1] |
| Subscription record | Provider, customer/subscription IDs, plan, status, trial and period dates | Provide the paid plan, reminders, cancellation, refunds | On account deletion (financial part moves to the ledger) |
| Email delivery log | Template name, sent time, provider message ID | Prove required notices were sent (e.g., renewal reminders) | 18 months after sending; also on account deletion |
| Financial ledger | Tombstone ID, provider transaction IDs, amount, currency, tax, date, refund. No email, no child link | Accounting and tax (Polish accounting and tax law) | 5 years from the end of the tax year of the transaction [2] |
| Payment webhook events | Provider event ID, type, received time, minimal payload | Process each payment event exactly once | 90 days |
| Deletion request record | Hashed email, dates, scope | Prove we honored deletion requests | 3 years |
| Abuse-protection counters (hashed) | A keyed hash of the network address (never the IP address itself), the protected action (e.g. device pairing), attempt time | Limit device-pairing attempts (20 per hour per network) so pairing codes cannot be guessed | 1 hour after the attempt, automatically (checked every minute) |
| Anonymous analytics | Event name, route template, zone, country, device class. No identifiers, no cookies, no IP or user agent | Aggregate usage counts | 3 months |
| Server logs | No request bodies, masked IP | Security and troubleshooting | 7 days |
| Database backups | Everything above | Restore after an incident | Rolling 30 days; deleted data is gone from backups within 30 days |
| [1] Proof period to be confirmed by counsel | |||
| [2] Period to be confirmed by the accountant | |||