Balance — Data Retention and Deletion Policy

Effective date: 28 June 2026 Last updated: 28 June 2026

Reviewed annually: next scheduled review by 9 June 2027. Applies to: every personal-data category Balance processes.

This is the written data-retention and deletion policy required by the U.S. Children's Online Privacy Protection Act ("COPPA") under 16 CFR § 312.10. It also satisfies the storage-limitation and data-minimisation duties under GDPR Articles 5(1)(c) and 5(1)(e) and UK GDPR Articles 5(1)(c) and 5(1)(e) Article 14 of Chile's Law 21.719, the retention rules under Colombia's Law 1581 and its regulatory framework, and the equivalent rule in every other country.

This document is published at retention.html as a Layer-A companion to our Privacy Policy (Section 8 of which contains the user-facing summary) and our Children's Privacy Notice (Section 8 of which contains the COPPA-specific written schedule for kid data).

If the user-facing wording in the Privacy Policy or the Children's Privacy Notice ever appears inconsistent with this Retention Policy, this Retention Policy governs the operational retention period (the Privacy Policy and Children's Privacy Notice are the public-facing summaries, and we may need to clarify them; if there is a conflict, please write to and we will reconcile).

1. Principles

Balance retention is governed by four principles. Every retention period in this Policy must satisfy each:

1. Purpose limitation (GDPR Art 5(1)(b), COPPA § 312.7). We retain personal data only for as long as necessary to perform the parental-control service the parent contracted for, to comply with our legal obligations, or to defend a legitimate claim. We do not "round up" retention periods to convenient numbers.
2. Storage limitation (GDPR Art 5(1)(e), COPPA § 312.10). Retention periods stated below are maximums, not minimums. Where the parent initiates deletion sooner — or where the operational purpose ends sooner — the data is deleted sooner.
3. Data minimisation (GDPR Art 5(1)(c)). We hold the smallest dataset that the purpose requires. We never retain a category we do not need.
4. Default to deletion (UK Children's Code, OECD privacy principles). For each new feature, the design choice is deletion-by-default unless retention has a specific stated purpose.

Every retention rule in Section 3 below is mapped to one or more of these principles in the "Why this period" column.

2. Roles

• Data controller: BabaYaga Program, TOO (Kazakhstan; BIN 260540024651).
• Process owner: , Director — also acts as Privacy Officer () and Designated Child Safety Officer ().
• Service providers that hold copies of the data (sub-processors): the list is in Section 6 of the Privacy Policy. The controller is responsible for ensuring each sub-processor honours the retention rules below — written into the data-processing agreement with each provider.
• Annual reviewer: , Director, signs off on the annual review (Section 12) and on any change to a retention period.

3. Master retention table — by category

This is the source-of-truth retention table. The Privacy Policy (§ 8) and Children's Privacy Notice (§ 8) display the user-friendly summary derived from this table.

3.1 Account-side categories

3.2 Kid-device-derived categories

3.3 End-to-end-encrypted proof media and keys

3.4 Ephemeral verification and pairing tokens

3.5 Operational data

4. Deletion mechanics

4.1 Parent-initiated deletion of a kid (per-kid delete)

When the parent uses the in-app "Delete kid" action (under the privacy settings) and confirms, or writes to requesting deletion of a specific kid, the backend:

1. Stops further collection from the kid's device immediately (the foreground service on the kid device receives a kill signal at next health-check; the device's pairing is invalidated so future uploads are rejected at the API gateway).
2. Marks the kid record for deletion and schedules the cascade to run after a 1-hour in-app cool-off. Requests submitted by email to are honoured under the statutory deadlines in § 5 (GDPR 30 days; COPPA 10 business days; CCPA 45 days), not the 1-hour cool-off.
3. Runs the deletion cascade once the cool-off window elapses: - delete the kid's usage records, installed-apps catalogue, per-kid settings, notifications, task definitions and instances, earned-time ledger and settlements, streaks, recovery envelopes, and family-generation flags; - delete every encrypted device key belonging to that kid; - delete the parent media-key material tied to that kid; - delete every proof-media object stored for that kid in our Google Cloud storage location — using direct object deletion, not lifecycle, so the deletion is immediate; - delete every media metadata record referencing that kid; - delete the kid record itself.
4. Send a confirmation email to the parent on the account.

4.2 Parent-initiated deletion of the parent account (account delete)

When the parent uses the in-app "Delete account" action (under the privacy settings) and confirms, or writes to :

The in-app "Delete account" action applies a 1-hour cool-off (same mechanism as § 4.1): the account is marked for deletion and the cascade runs once the cool-off elapses. Email/manual requests sent to are honoured under the statutory deadlines in § 5, not the 1-hour cool-off.

1. Runs the per-kid cascade in § 4.1 for every kid attached to the family.
2. Deletes the family record.
3. Deletes every encrypted device key belonging to the parent.
4. Deletes the parent account record.
5. Sends a confirmation email to the address that was on file at the moment of the request.
6. Subscription state: any active Google Play subscription is not auto-cancelled by us — we instruct the parent to cancel in Google Play → Subscriptions (we cannot cancel a Google Play subscription on the parent's behalf without an OAuth-scoped action the parent does not grant us). The parent is reminded of this at the deletion-confirmation step.

4.3 Account dormancy (discretionary)

We may close and delete accounts that have been inactive for a long period. If we decide to do so for a particular account, we will email the parent a notice before any deletion and give a reasonable opportunity to log in and keep the account active. There is no fixed dormancy period — this is a discretionary clause to give us a path to clean up obviously-abandoned data while protecting parents who simply use Balance infrequently. (This mirrors Privacy Policy § 8 word-for-word and is part of the same softened position adopted on 9 June 2026.)

4.4 Withdrawal of consent

The parent may withdraw consent to ongoing collection from a kid's device at any time. The most direct route is to delete the kid (§ 4.1). Removing the kid stops further collection immediately and triggers the deletion cascade once the 1-hour in-app cool-off elapses (or under the statutory deadlines in § 5 for email/manual requests). The lawfulness of past processing carried out before withdrawal is not affected.

4.5 Deletion of specific categories without deleting the kid

A parent who wants to keep the kid but delete one category (for example, "delete every proof video older than 7 days") can: - in-app: open the kid's media tab and tap "Delete" on each item, or use the bulk-select action in the in-app media tab; - by email: write to with the request. We will reply within the deadline in § 5 below.

4.6 Backups

Operational backups continue to hold a deletion-protected snapshot for the rolling backup window described in § 3.5. Our own periodic backups with Google Cloud are retained on a 30-day rolling window; once a backup rotates out, the deleted data is no longer recoverable. The hosting provider's own operational snapshots rotate under their published backup-retention policy. The Privacy Policy discloses this exception (§ 8). It is the only lawful exception to the "deletion is immediate" promise.

5. Subject-rights timelines

We honour every statutory deadline applicable to a parent who exercises a right (access, rectification, erasure, restriction, portability, objection):

• GDPR / UK GDPR: 30 calendar days from receipt of the request; extendable by up to 60 additional days for complex requests, with written notice.
• U.S. state privacy laws (CCPA/CPRA, VCDPA, CPA, CTDPA, UCPA, TDPSA, and other state laws): 45 calendar days, extendable by 45 days with notice.
• COPPA verified parental deletion requests: without unreasonable delay, in practice within 10 business days.
• Other countries: the deadline set by the local data-protection statute.

The Privacy Officer () tracks every request in the internal DSAR log under . Each request is closed with a written disposition.

6. Legal-hold and exception register

We may retain a specific record longer than § 3 indicates only in the following circumstances, and only for as long as the circumstance requires:

1. Tax and accounting retention under Kazakhstan law (subscription records — see § 3.1).
2. Legal-hold orders from a competent authority (a court order, a regulator's preservation notice, a lawful production demand) — duration set by the order.
3. Child-safety preservation under 18 U.S.C. § 2258A(h) (90 days, extendable by 90 days on agency request) for matters classified under § 7 of the Child Safety Standards.
4. Active legal dispute in which we are a party — duration: until the matter is closed plus the limitation period for appeals under the applicable procedural law.

Any retention beyond § 3 must be approved in writing by the Privacy Officer and logged in the retention-exception register held under . The register is reviewed at every annual review (§ 12).

7. Cascade verification — backend testing

For each release of the backend, we maintain a regression test that exercises the deletion cascade end-to-end. Our automated deletion tests verify:

• deleting the account removes every stored record for every kid attached to the parent;
• every proof-media object stored for the family is deleted (not merely marked for lifecycle expiry);
• every encrypted device key, media-key record, and media metadata record tied to the parent or any of the parent's kids is removed;
• a deletion confirmation email is dispatched.

We run the cascade test on every CI run on the deletion-relevant code paths. A failed cascade test blocks the release.

8. Sub-processor retention alignment

Each sub-processor (Section 6 of the Privacy Policy) is bound by a written data-processing agreement that obliges them to:

• not retain personal data for longer than necessary to perform their stated service;
• delete or return personal data on our instruction, including immediately on a per-record deletion request and at termination of the DPA;
• maintain their own backup-retention window not longer than 30 days where applicable;
• give us written confirmation of retention practice on request.

Specifically:

9. Encryption-key rotation

Encryption keys themselves are also subject to a lifecycle. Our key-rotation runbook documents:

• The server-side key that protects stored email (an AES-256-GCM key used to encrypt parents' email addresses at rest): annual rotation cadence; ad-hoc rotation on suspected compromise. Rotation requires re-encrypting every stored email in a single migration job.
• The server-side pepper added to one-time-code hashes (a server-only secret combined with SHA-256 before storing one-time codes): annual rotation cadence; on rotation, all live one-time codes become unverifiable and are removed within 1 hour. One-time-code windows are intentionally short, so the user-visible impact is bounded.
• Per-device E2EE keypairs (X25519 device keys held by the parent and the kid): managed by the clients; the backend only stores the public half. Rotation is driven by the device when the user re-pairs or migrates to a new device — see Section 9 of the Privacy Policy.

The runbook lives under control.

10. Continuous improvement

We periodically review and improve our automated retention and deletion jobs to keep them aligned with this Policy. Where an implemented retention window or deletion job is being brought into alignment, the interim operational behaviour is governed by our existing automatic-deletion schedules and cascade logic, and any deviation is logged in the retention-exception register (§ 6) and reconciled at the annual review (§ 12).

11. How a parent can verify retention

A parent can verify our retention end-to-end at any time:

1. Export the family's data using the in-app data-export action (under the privacy settings). The export delivers a downloadable JSON archive of every category we hold, with the recorded / created / last-seen timestamp on each row. Anything older than the retention window for its category indicates a retention failure — please report it to .
2. Delete the kid or the account, then re-export 30 days later. The export should be empty (or, for the parent account, contain only the post-deletion confirmation record).
3. Ask us directly. Email and ask "show me everything you hold about my family". We will deliver, within the deadlines in § 5, the same export with a written confirmation that nothing else exists.

We invite parents who find a discrepancy to report it to us without retaliation risk — we treat retention errors as bugs and we credit the reporter.

12. Annual review

The Privacy Officer reviews this Policy at least once a year, by 9 June each year. The review covers:

• the master table in § 3 — each row and its automatic-deletion schedule;
• the deletion-cascade test suite — confirming it covers every row in § 3;
• the retention-exception register (§ 6) — confirming nothing has been retained outside the published schedule without a logged reason;
• the sub-processor DPAs (§ 8) — confirming each is current;
• the continuous-improvement review (§ 10) — confirming our automated retention and deletion jobs remain aligned;
• the key-rotation cadence (§ 9) — confirming the last rotation was within the previous 12 months.

A material change to any retention period requires:

• the "Last updated" date at the top of this document;
• a corresponding update to the Privacy Policy § 8 and the Children's Privacy Notice § 8 (whichever the change touches);
• a 30-day in-app + email notice to parents on the account where the change extends a retention period;
• where the change is a reduction in retention, no advance notice is required (the change is to the parent's benefit).

13. Country annexes

Country-specific retention nuances (for example, a longer mandatory tax-document retention in a specific country, or a shorter mandatory deletion-cascade deadline) are published in the country-annex set that travels with this Policy at retention.html. Inherited territories follow the parent-country annex, consistent with Section 18 of the Privacy Policy.

14. Quick-reference contacts

• Privacy / DSAR / data export / deletion: ()
• Child safety reports: (also )
• General help:
• EU representative: Prighter EU Rep GmbH, Schellinggasse 3, 1010 Vienna, Austria
• UK representative: Prighter Ltd (UK), 20 Mortlake High Street, London SW14 8JN, United Kingdom
• Postal: BabaYaga Program, TOO, ul. Ongarsynova 10, kv. 175, Esil district, Astana 010000, Kazakhstan
• Telephone:
• Companion documents:
• Privacy Policy: privacy.html
• Children's Privacy Notice: children.html
• Terms of Service: terms.html
• Subscription Terms: subscription-terms.html
• Child Safety Standards: child-safety.html

End of Data Retention and Deletion Policy.