Retention schedule for STATIQ
Version 1.1 (draft) · Owner: JIWA HOLDING AS · Canonical technical source: docs/architecture/retention-schedule.md
The statuses describe the current position: Enforced means the product has a testable control, Platform setting means the deadline must be configured and evidenced with the provider, and Launch requirement means the control is wholly or partly missing and must be in place before launch.
The controls for inactive Free accounts, abandoned registrations and dead-letter messages are implemented and tested in source code. Operational verification in production is still required before launch.
Requirements for payment webhook receipts and accounting records apply before payment features are enabled. Paid sales are off in this release.
| Data | Deadline and action | Status |
|---|---|---|
| Active account, workspace and necessary paid history | Retained while the account is active and the purpose remains. | Enforced |
| Cancelled subscription | Paid access lasts until the end of the period. The workspace then moves to Free without automatic deletion. Previous history remains readable, exportable and deletable. | Enforced |
| Inactive Free account | Notice after 24 months without owner sign-in or workspace activity. Deletion no earlier than 30 days after confirmed delivery to the recipient, only if the account remains inactive. New activity stops deletion. | Enforced |
| Deleted account | Access and sharing links are revoked immediately. Account and workspace are deleted or anonymised without undue delay, within 30 days at the latest. | Enforced |
| Player identity | Deleted immediately if no necessary history exists. Otherwise anonymised without undue delay, within 30 days at the latest. | Enforced |
| Free game and remaining Free review | Deleted immediately when the user finishes without saving. The daily safety job deletes a remaining review on its first run after 6 days, thus no later than 7 days after the last change. An active live game is not covered by the safety job. | Enforced |
| Local, acknowledged game data | Finalised game copies with all events confirmed by the server are deleted at startup, on returning to the app and hourly while it is active, without a network connection. A closed or suspended app cleans up on its next run. Unconfirmed data are retained. Local confirmation of finalisation must be present; unknown finalisation is retained. | Enforced |
| Sharing links | 7 days by default and at most 30 days. Access stops immediately on expiry or revocation; hash/tombstone is deleted within 30 days afterwards. | Enforced |
| Membership invitations | Expire after 7 days and can be used only once. The server stores only the token hash. Hash and minimised metadata are deleted within 30 days after redemption, expiry or revocation. | Enforced |
| Pending workspace, group, game or complimentary-seat invitation on the recipient's device | The raw token may be held locally for at most 1 hour during sign-in and onboarding. It is deleted on redemption, permanent failure, sign-out or expiry and is never logged. | Enforced |
| Generated report files | Deleted after 30 days. Report metadata and history follow the workspace. | Enforced |
| Technical operational logs | Ordinary logs are deleted after 30 days. Redacted error, diagnostic and operational security logs are deleted after 90 days. | Platform setting |
| Minimised audit events in STATIQ | Deleted after 365 days. | Enforced |
| Supabase Auth and other platform logs | Minimised authentication and audit events must be deleted after 365 days. The setting must be configured and evidenced with the provider. | Platform setting |
| Privacy requests and minimal consent evidence | 3 calendar years from case closure or the end of the customer relationship, calculated in UTC. Open cases are retained; older cases without a known closure require review. | Enforced |
| Pilot feedback and minimised session diagnostics | Deleted after 180 days. | Enforced |
| Delivered outbox/queue messages | Deleted 7 days after confirmed delivery. | Enforced |
| Dead-letter messages | Deleted 30 days after the server records the transition to dead-letter. Older rows without a known transition time conservatively start from the migration time. | Enforced |
| Abandoned registration | Deleted after 30 inactive days only when server-confirmed onboarding is incomplete and the personal workspace is empty. Existing confirmed accounts with unknown onboarding status, content, other active memberships and subscription history are protected. | Enforced |
| Minimised Apple/Stripe webhook receipts | Diagnostic timestamps and duplicate review evidence are minimised after 365 days. Necessary event IDs, digests, bindings and financial fields remain for settlement and replay protection. They are deleted when historical inputs are closed, active/unresolved claims are settled and the applicable accounting period has expired; necessity is reviewed annually. Local controls are implemented; production execution remains unverified. | Launch requirement |
| Primary accounting records | Retained for 5 years after the end of the financial year. | Launch requirement |
| Secondary accounting records, where the rule applies | Retained for 3 years and 6 months after the end of the financial year. | Launch requirement |
| Deleted data in backups | Immediately blocked from ordinary use and expire at the next rotation, with at most 28 additional days. | Platform setting |
The GDPR establishes the principles of storage limitation and deletion, but not most of the specific numbers of days above. These are STATIQ product choices. Accounting record deadlines follow bookkeeping rules. EU-based storage does not change the deadlines, and using providers that may transfer data outside the EEA requires a valid transfer basis.
Protected roster identities
Activated teams have a specific deletion date, with a product limit of 730 days. Personal rosters may contain protected first and last names only; birth data and licence status are prohibited there. Organization rosters may also contain a date of birth, birth year and imported licence status. The protected data become unreadable on expiry and are deleted by the retention job. Earlier deletion is available per player or for the whole team; anonymization and team/workspace deletion include the protected roster. Extending a policy does not automatically extend existing identities. Backups follow the schedule above.